I hope everyone had a wonderful Thanksgiving last week. My household celebrated by welcoming a 4th member to the family. My daughter was born on Wednesday morning, November 25th. And thus explains what I did last week instead of writing the normal Hackaday column. Never fear, we shall catch up today, and cover the news that’s fit to be noticed.
iOS Zero-click Wifi Attack
[Ian Beer] of Google’s Project Zero brings us the fruit of his lockdown-induced labors, a spectacular iOS attack. The target of this attack is the kernel code that handles AWDL, an Apple WiFi protocol for adhoc mesh networks between devices. The most notable feature that makes use of AWDL is AirDrop, Apple’s device-to-device file sharing system. Because AWDL is a proprietary protocol, the WiFi hardware can’t do any accelerated processing of packets. A few years back, there was an attack against Broadcom firmware that required a second vulnerability to jump from the WiFi chip to the device CPU. Here, because the protocol is all implemented in Apple’s code, no such pivot is necessary.
And as you’ve likely deduced, there was a vulnerability found. AWDL uses Type-Length-Value (TLV) messages for sending management data. For a security researcher, TLVs are particularly interesting because each data type represents a different code path to attack. One of those data types is a list of MAC addresses, with a maximum of 10. The code that handles it allocates a 60 byte buffer, based on that maximum. The problem is that there isn’t a code path to drop incoming TLVs of that type when they exceed 60 bytes. The remainder is written right past the end of the allocated buffer.
There is more fun to be had, getting to a full exploit, but the details are a bit too much to fully dive in to here. It interesting to note that [Ian] ran into a particular problem: His poking at the target code was triggering unexpected kernel panics. He discovered two separate vulnerabilities, both distinct from the vuln he was trying to exploit.
Finally, this exploit requires the target device to have AWDL enabled, and many won’t. But you can use Bluetooth Low Energy advertisements to trick the target device into believing an Airdrop is coming in from a trusted contact. Once the device enables AWDL to verify the request, the attack can proceed. [Ian] reported his findings to Apple way back in 2019, and this vulnerability was patched in March of 2020.
Via Ars Technica.
And if a neatly packaged iOS jailbreak is more your speed, Odyssey was recently released, a slick looking open source jailbreak app for modern iOS devices. For even more jailbreak goodness, how about jailbreaking your HomePod? The latest release of Checkra1n makes it partially possible.
Fortinet Devices Getting Owned
Guess what happens when a serious vulnerability is found and fixed, and system administrators don’t roll out the patches? If you guessed mass exploitation, you’d be correct. CVE-2018-13379 was a directory traversal bug in Fortinet VPN gateways, first found way back in 2018. Just recently, a dump of plaintext credentials has surfaced on the Internet — accounts from an eye-watering 49,000+ devices. The whole dump is available in the shadier parts of the internet.
Remember the short-lived panic surrounding unsecured Zoom meetings, and uninvited pranksters connecting to those meetings? It was enough of a moment that “zoombombing” was coined. Well, hold on, because Webex has just brought us “Ghost Users”. The research was performed by IBM’s SecurityIntelligence group. They discovered that it was possible to manipulate the join handshake while joining a Webex meeting, and access the meeting without showing up on the list of listeners. The danger here is that a “ghost” could listen in on a confidential meeting. It’s a reminder that there is a new set of challenges in our brave new world. IBM privately reported their findings, and Cisco has patched the vulnerabilities.
Embedded Code Is Vulnerable Too
There is a whole world of proprietary software stacks out there, hidden away in embedded devices, real time controllers, and industrial applications. One of those stacks is the EtherNet/IP (ENIP) networking stack, sold by Real Time Automation (RTA). In a recent post, Claroty has detailed a pretty serious vulnerability in that software. One of the functions of ENIP is accepting a forward-open request, part of the Common Industrial Protocol. The validation code for those incoming requests isn’t as robust as it should be, and a too-big request results in memory writes outside the allocated buffer.
The vulnerability is bad enough, potentially allowing device compromise over the network without user interaction. The worst part is that this code is locked away on millions of devices that will likely never receive security updates. This sort of vulnerability is a perfect target for the next Stuxnet style attack against infrastructure somewhere. It’s hard to estimate where all this network stack is hidden, but Claroty found a handful of vulnerable devices directly attached to the Internet, ready to be exploited. RTA has been notified, and has fixed their code, but getting that fix applied on every vulnerable device will take years.
Regex for Security?
If you find yourself writing code for an application where security matters, and you turn to a regex for validating something, stop and think about the life choices that have led you to this point. There are just too many ways a regex can go wrong, or an unexpected input can match in a way you didn’t anticipate. Case in point, npm package
John Jackson, AKA [JohnJHacking] found a Server Side Request Forgery (SSRF) flaw in a server application, and started digging to find the cause. An SSRF is a fairly simple style of attack, where a request contains forged data, in an attempt to trick the server into connecting to a different IP. In effect, an attacker can request some data, which they have some control over, and have the server send that data to an arbitrary location. Once an attacker has an SSRF, there are a bunch of potential attacks that primitive can be used for, usually involving sending messages to internal-only services.
The actual vulnerability in
private-ip is an easy one to miss. The package is designed to filter out any requests to private IP addresses, so for example it would block any SSRFs to localhost. So first off,
0.0.0.0 is a special IP address. It acts very similar to
127.0.0.1, but technically means all listening IPs on the local machine. Private-ip successfully detects a request to
0.0.0.0, but an attacker could instead make an SSRF request to
0000.0000.0000.0000. The OS interprets these as the same thing, but the regex code misses the IP address with the extra 0s. Private-ip has released 2.0.0 with a round of fixes and more sane IP matching system.