If you roll way back through the history of open source webmail projects, you’ll find Horde, a groupware web application. First released in 1998 on Freshmeat, it gained some notoriety in early 2012 when it was discovered that the 3.0 release had been tampered with, and packages containing a backdoor had been shipped for three months. While this time around it isn’t an intentional backdoor, there is a very serious problem in the Horde webmail interface. Or more accurately, a pair of problems. The most serious is CVE-2022-30287, an RCE bug allowing an authenticated user to trigger code execution on the connected server.

The vulnerable element is the Turba address book module, which uses a PHP factory method to access a specific address book. The create() method has an interesting bit of code, that first checks the initialization value. If it’s a string, that value is understood as the name of the local address book to access. However, if the factory is initialized with an array, any of the address book drivers can be used, including the IMSP driver. IMSP fetches serialized data from remote servers, and deserializes it. And yes, PHP can have deserialization bugs, and this one runs code on the host.

But it’s not that bad, it’s only authenticated users, right? That would be bad enough, but that second bug is a Cross-site Request Forgery, CSRF, triggered by viewing an email. So on a vulnerable Horde server, any user viewing a malicious message would trigger RCE on the server. Oof. So let’s talk fixes. There is a new version of the Turba module that seems to fix the bugs, but it’s not clear that the actual Horde suite has pushed an update that includes it. So you may be on your own. As is pointed out on the Sonar Blog where the vulnerability was discovered, Horde itself seems to be essentially unmaintained at this point. Maybe time to consider migrating to a newer platform.

Vulnerability or Feature?

The slow-roll continues in regards to Microsoft’s handling of Follina. There’s another, similar, problem: DogWalk. It’s not quite as bad as Follina, this one is a problem in the .diagcab handling. The cab can point to an XML file on a remote WebDAV server, and the files returned bypass the normal checks for disallowed file names. So for instance, \..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe gets created, with predictably disastrous consequences.

Now, is this a vulnerability? Well, on one hand, it’s a file downloaded from the internet that the user intentionally opened. On the other, it’s not an executable and shouldn’t run arbitrary code. A web browser will happily download and let a user run the potentially malicious file. It’s not a 10.0, but that sounds like a vulnerability. Microsoft declined issuing a CVE, similarly to their initial handling of Follina, which is still an unpatched 0-day vulnerability being exploited in the wild. We could speculate that Microsoft has received a National Security Letter regarding the bug, but that’s a vanishingly unlikely scenario.

The Other Vulnerability That Wasn’t

Or maybe it is a vulnerability. You decide. The Formidable library is a Node.js library for parsing form data, including file uploads. The vulnerability is CVE-2022-29622, an arbitrary file upload issue. You may already see the contention there. The file upload library allows arbitrary uploads — by design. This is literally a feature of the library. So was the entire vulnerability report, scoring a 9.8, utter bunk? Well no, there is actually a bug — or at least a feature that doesn’t always act as expected.

When you use Formidable to do a file upload, it replaces the name with a random hex string. There’s an option to keep the file extension, so if you upload example.txt, you get a file named 84d38f5e070c248df3cdccc00.txt on the server. The problem is how much of the filename is considered the extension. Everything after the first period was counted as extension, meaning that if you uploaded a file named test.pdf.jqlnn⟨img src="a"⟩.png, you get a file named randomstring.pdf.jqlnn⟨img src="a"⟩.png. If you were depending on this arrangement to sanitize the uploaded file name, you may get a XSS or even RCE for your trouble. But that isn’t a vulnerability in Formidable.

This is the argument that [Zsolt Imre] makes in his analysis of the issue, and further defense. The real kicker is that the rushed fix introduced an issue at least as serious as the one it was trying to fix.

Confluence Under Exploit

Atlassian’s Confluence has a critical unauthenticated RCE that’s being exploited in the wild. Researchers at Volexity broke the story, after investigating a pair of compromised servers. Samples of the attack have been caught in various honeypots, and it looks like a simple exploit. Because of the nature of confluence servers, this issue has the potential to have follow-on effects, resulting from attackers having a foothold into developer networks.

Bits and Bytes

Just how scary is it to expose RDP to the internet? For these old Linux hands, scarier that exposing SSHD. They clocked almost 40,000 attempts after 4 days, most of which trying for the Administrator account. Also interesting was how many attacks were coming from a pair of network blocks, 45.227.254.0/24 and 194.165.16.0/24, both belonging to Flyserver.

The SSNDOB Marketplace was taken offline, after over 10 years in operation. This was the group likely behind the swatting attack on Brian Krebs. The only unfortunate part of this one is that there haven’t been any arrests as part of the takedown.