We’ve covered the right-to-repair saga, and one of the companies that have become rather notorious is John Deere. The other side to the poorly managed interconnected mess is security issues. There’s a certain irony to how this story started: Somebody noticed that John Deere equipment didn’t have any CVEs at all. A normal person might think that this must mean their products are super secure, but a security researcher knows that something more interesting is afoot. Our old friends [Sick Codes], [John Jackson], and a host of others saw this as a sure sign that there were plenty of vulnerabilities to be found, and it seems they were correct.
Vulnerabilities included a handful of cross-site scripting attacks, an authentication bypass via request smuggling, misconfigured security, SQL injections, RCEs and more. Put together, these vulnerabilities allowed for full control of the John Deere system, including the ability to manipulate all the equipment connected to the system.
During the Defcon presentation, linked below, [Sick Codes] recalled the moment when they realized they were working on an important problem. Rather than complain about not getting paid for the vulnerabilities found, a contributor simply noted that he valued having food to eat. A coordinated attack on JD equipment could cause big problems for a bunch of farms across a country.
They ended up contacting CISA, due to a lack of serious response from the vendors. CISA took the threat seriously, and the problems starting getting fixed. This isn’t a problem limited to one company. Case had similar issues that have also been fixed, and it was implied that other vendors have similar problems that are still in the process of being addressed.
Octal IPs Strike Again
While we’re talking about [Sick Codes] and his merry band of researchers, there are a few more instances of incorrect parsing of octal formatted IP addresses announced. That is the Rust std::net and the Golang net libraries, both of which just strip the leading zeros off IP addresses. In both cases, the fix is to just treat this as an invalid address. Why is it a problem? Because you can use sneaky IP addresses, like 0127.0.0.1. An octal-aware library sees this as 87.0.0.1, while a library with this vulnerability sees it as localhost. The real problem comes about when the various pieces of a web service use both approaches. If you can control or spoof one of these magic addresses, you could connect to the service and have privileges as if you were using an internal IP. For more information, see the DEF CON talk about this issue.
Exchange RCEs
Remember ProxyLogon? That’s the Microsoft Exchange attack we’ve been collectively battling since the beginning of this year. It’s finally time for the rest of the story. Continuing our conference coverage, [Orange Tsai] detailed this vulnerability, and announced a pair of new Exchange vulnerabilities at Black Hat, including another chain that leads to RCE over port 443. If that wasn’t enough, there are already active attacks leveraging this new flaw.
This new research stems from an architecture change in Exchange 2013, where the web service has been split into a front-end and back-end. There are all sorts of quirky ramifications of this, like the fact that the back-end is listening to all interfaces by default. Another? The front-end doesn’t verify the Host on incoming requests, so an attacker can stuff any arbitrary text in there. That includes a totally different hostname and port, as well as unexpected characters. Putting those together correctly results in an arbitrary SSRF — the attacker can specify any endpoint, either on the public internet, or the back-end itself. Once the normal front-end to back-end flow is compromised, it’s easy enough to abuse an internal endpoint to gain arbitrary write privilege, and RCE. That is the ProxyLogon attack in a nutshell.
The new RCE is known as ProxyShell. It abuses the pre-auth autodiscover endpoint, intended to enable automatic configuration for clients. Appending the desired endpoint to a valid autodiscover request serves as an SSRF tool. The attack is to use this SSRF to make a request to the /powershell endpoint. Combined with a webshell payload uploaded as a draft, this results in yet another pre-auth RCE. Thankfully these attacks have been patched already, but there are still too many systems not yet updated.
Pulse Secure Defeated By Tar
This story starts with CVE-2020-8260, an arbitrary file write vulnerability in Pulse Connect Secure devices, where an uploaded configuration wasn’t checked for path transversal on extraction. A malicious tar file could put files anywhere via ./../ paths. This was fixed in 2020, but a couple of releases later, CVE-2021-22900 was disclosed and fixed. It was a strangely similar problem, and [Rich Warren] of the NCC Group decided to investigate. The original fix added a validateTarFile function, which seems to be a very well done bit of work. It checks for ../ patterns, symlinks, or hardlinks. On top of that, it has a whitelist of allowed files. It would be the perfect solution, if only it was used every time an archive was uploaded. Unfortunately, this robust solution was only used when a config file was uploaded. The second fix was to add the call to validateTarFile to all the other upload functions.
Armed with this understanding, the natural question to ask was whether every file upload circumstance was properly sanitized. Since we’re discussing it, you’ve likely guessed that something was missed. When a config file is uploaded, the parameters of the POST message define the upload type. A profiler database is handled differently, and that code path does not include the validation function, leading to CVE-2021-22937. It appears that this code path is inaccessible through normal use, but modifying the request parameters is trivial. This series of vulnerabilities is limited to an attacker with admin access to the device, greatly mitigating their seriousness. That said, access to the underlying filesystem opens a whole new world of persistent threats. Depending on how it’s implemented, such a rootkit could survive a factory reset.
API Testing 101
The good folks at Detectify published a fun primer to testing web APIs. The first half of the post is dedicated to using Postman for that research. It looks like a useful tool, but appears to be closed-source, unfortunately. The second half of the article covers some common issues in web APIs and thoughts on mitigation. There are some obvious flaws discussed, like private APIs accidentally exposed to the public. On the other hand, there are some good tips for looking for more obscure flaws, like XXE injection (XML External Entity). All told, it’s worth a quick read, particularly if you’re not opposed to running a closed-source tool as part of your toolkit.
Series of Pneumatic Tubes
You may be most familiar with a Pneumatic Tube System (PTS) from a bank or pharmacy drive-in (or from watching Futurama), but they are also widely used in hospitals, among other places. Researchers at Armis just announced PwnedPiper, a set of problems with Swisslog Healthcare’s PTS implementation. One of the worst problems? Their control panels are Linux systems, running a 2.6.35 kernel. That’s a 10 year old kernel. Remember that scathing Google Security blog from last week? This is the sort of nonsense that they had in mind.
The rest of the system is about as bad, with an open telnet service listening for connections, and a hardcoded password common to all devices. Multiple memory corruption bugs all allow for RCE, and the primary communication protocol is unencrypted and unauthenticated, not to mention based on UDP. And finally, the firmware upgrade process is based on this same protocol, with no firmware signing function at all. To put it simply, if you can access the Ethernet network running this PTS, you can trivially own the entire system.
How bad could this be, if actually exploited? Just consider that not only are biological samples sent over this system, as are medicines. One can only imagine how much trouble could be caused by scrambling the destinations. A more malicious attacker could feasibly use such an attack to steal or substitute medications. Sounds like a plot from a Mission Impossible episode, but truth is sometimes much stranger than fiction.
Last-Minute Headlines
The Foxit PDF reader recently released 11.0.1, fixing a whole host of problems, including 8 separate CVEs that could lead to RCE. If you’re one of the users of this popular alternative to Adobe, be sure you’ve updated!
As if we needed something else to interrupt the electronics supply chain, Gigabyte has been hit by ransomware, with the added threat of 112GB of data being leaked. To make that threat worse, much of the data is reportedly under NDA, potentially leading to further consequences for Gigabyte if made public. So far there’s no word on how much the ransom would be.
One more story we thought dead has risen again. There is yet another Print Spooler 0-day. This is another vulnerability related to point-and-print, but this time it’s against the machine that tries to use a malicious remote printer. The previous such vulnerability was inaccessible so long as point-and-print was disabled, which was the default setting. The Microsoft advisory doesn’t list that as a workaround for this one. It appears that this works on a standard config. To add insult to injury, the reporting researcher disclosed this flaw way back in December of 2020.
0 Commentaires