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
126.96.36.199, 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.
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.
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.
14 thoughts on “This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes”
Fixing some of those vulnerabilities in the John Deere software will also cause problems for many farms. Several of those vulnerabilities are used to circumvent the “Authorized Repair” checks that prevent equipment owners from fixing things themselves. Farmers often wait weeks to get their harvesting equipment working again because while they have replaced the part, an “John Deere Authorized Technician” needs to come out and connect to one of the controllers in the machine and transfer a cryptographic key before the machine will start.
Farmers are using SSRF attacks to log into John Deere servers? Many of the researchers on this story are also big right-to-repair supporters. You have a source for this claim?
My source is that I personally know some of the people doing that work. And they aren’t about to reveal how they are doing it because they kinda don’t want to end up with the FBI busting down their door for violating a bunch of bullshit laws, nor do they want to have John Deere’s lawyers descending upon them and their customers. We do communicate via an invite-only forum on tor, but I doubt you’d get an invite anytime soon.
I was thinking that too.
Maybe a couple of vulns should be left unpublished and unclosed specifically to allow the end customers the right to repair. Ones that affect he tractors though rather than the manufacturer’s servers/infrastructure.
you have the right to sell your John Deere and buy something that is more flexible in use I would say. I think that by now every farmer has heard about these problems.
I see that you are making a suggestion that is not specific. It would be helpful if you would use that information you have and create a chart showing all the exact replacements that farmers could choose, how much they cost, how available they are, the support network for repairs beyond small replacements, their service contracts and so forth. It would make a great article for hackaday. I’ll bet it is something that farmers have never thought about.
We use Zetor tractors. Cheap-ish, easily repairable and quite sturdy classic-style machines.
Mahindra, #1 selling tractor in the world.
Don’t be such a snarky dewsh.
This is no surprise. Almost every implementation of some form of IT in farming is terribly kludgy, badly designed, and undocumented. This is not because ‘it’s coming from farmers’, it’s because nobody has the slightest idea what is going on. Take for instance Case-IH; their tractor is supplied with three separate screens and an operating system, yet no documentation on the OS. The machine generates error messages that alternately take away the output of one display with no explanation how to make it stop, or others about task files that nobody at the dealership can explain. One of the displays will run out of storage space. The only answer the dealership has is to install a different thumb drive. All the service functions are in the more crippled of the two display systems, and are nearly unusable. Ours is supposed to notify the operator for an oil change every 250 hours. It hasn’t generated an alarm in the three years we have had the machine, and due to a suspension error on the display the hour meter is not visible.
The Boss wanted autosteer and GPS. He called the dealer in to install all the stuff. Turns out the machine already had it. Every feature in the world does no good if you don’t tell anyone about it. My family ran a dealership in the fifties all the way to the mid seventies. If a new tractor was delivered, you had best bet that there was going to be someone on that farm half a day showing the features of the new tractor and how to use them. Now they show up, drop the machine, and are gone. Our last was supplied with a locking fuel cap that was stuck. A brand new machine you literally couldn’t fuel. My great uncle would have fired a salesman over that.
This seems to be a part of a growing problem where you are supplied less useful tools more prone to breakage. I don’t see how that is efficiency. It’s like someone doesn’t want people to be able to do their job. If you value having food, you best start wondering about the machinery and training being supplied to the people you expect to grow it.
im sure other tractor manufacturers dont do the same. were living in a world where you need to pay a subscription fee to use your toaster. frankly im rooting for the hackers on this one.
If they wanted infamy they wouldn’t be white hat… Much more prestige both in busting up – insert big company name here – computers and in being rich, and its rather easy to make yourself rich by being a dick with those skills…
Sure it wouldn’t be your real name, unless you are a moron who really wishes to get prison time, at best… But its still your ego being stroked by whatever name you/your group is going by, and a few big paycheck to help…
Postman is very nice but is closed source. Insomnia and Hoppscotch are both useful, open source API client/design tools that provide _some_ of same functionality. From a CLI or scripting level, curl and httpie can take you a long way once you learn to work with their idiosyncrasies.
> One of the worst problems? Their control panels are Linux systems, running a 2.6.35 kernel. That’s a 10 year old kernel.
Oh, come on… Why would you say it’s one of the worst problems if the researchers didn’t make such a claim? The paper says it’s “likely susceptible” but there are so many _actual_ vulnerabilities in the application that I’d say it’s the least of the problems.
I’d agree it is one of the worst problems – Being on such an old kernel is going to be a root cause of huge numbers of vulnerabilities – can’t use patched anything else that relies on the newer kernel, directly or indirectly as the layers of dependencies move on, and kernel vulnerabilities that have long been patched will still be there…
Being so old is just stupid in a connected system, there is an argument for sticking behind the curve of brand new stuff for the proven stability but that only goes so far.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)