This week we learn of a “breathtaking” critical vulnerability in an iOS kernel driver. AWDL is Apple’s proprietary protocol used for stupid things such as AirDrop and other ad hoc nonsense.
But a Google researcher says it was badly written. And that its testing was kinda lacking, too.
As if you needed another reason to reduce your attack surface. Or to keep up to date with updates—this one was quietly fixed a few months ago.
But the vuln is a doozy. And it’s laughable how bad this bit of code was, given the risks. In this week’s Security Blogwatch, we sanitize our inputs, then sanitize them some more.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Amazon dude vs. guineafowl.
Tim pwned again by Google
What’s the craic? Sean Hollister reports—Exploit could have let hackers remotely own iPhones without even touching them:
Ever watch that movie … about the hacker who can instantly take over someone’s device without touching it at all? Those scenes are typically unrealistic as heck. But every once in a while, a real-life hack makes them seem downright plausible.
…
Google Project Zero security researcher Ian Beer has revealed that, until May … iPhones and other iOS devices were vulnerable to an incredible exploit that could let attackers remotely reboot and take complete control of their devices.
…
Apple doesn’t dispute the exploit existed, and in fact cites Beer in the changelogs for several of its May 2020 security updates. … But the company does point out that most iOS users … are already using newer versions of iOS that have been patched.
And Dan Goodin adds in—iPhone zero-click Wi-Fi exploit is one of the most breathtaking hacks ever:
Beer’s attack worked by exploiting a buffer overflow bug in a driver for AWDL, an Apple-proprietary mesh networking protocol that makes things like AirDrop work. Because drivers reside in the kernel … the AWDL flaw had the potential for serious hacks.
…
The researcher said he has no evidence the vulnerability was ever exploited in the wild, although he noted that at least one exploit seller was aware of the critical bug in May. … The beauty and impressiveness of the hack is that it relies on a single bug to wirelessly access secrets locked away in what’s arguably the world’s most hardened and secure consumer device.
Who found it? Ian “warm” Beer calls it An iOS zero-click radio proximity exploit odyssey :
For 6 months of 2020, while locked down … surrounded by my lovely, screaming children, I've been working on a magic spell … a wormable radio-proximity exploit that allows me to gain complete control over any iPhone in my vicinity. View all the photos, read all the email, copy all the private messages and monitor everything which happens on there in real-time.
…
The teams and companies supplying the global trade in cyberweapons like this one aren't typically just individuals working alone. They're well-resourced and focused teams of collaborating experts. [But] the sizes of the security teams dedicated to proactively auditing their product's source code to look for vulnerabilities are very small.
…
The problem for tech companies and certainly not unique to Apple, is that while design review, mitigations, and fuzzing are necessary for building secure codebases, they are far from sufficient.
What’s he not saying? Ian Beer—@i41nbeer—tweets some more personal views:
AWDL is enabled by default, exposing a large and complex attack surface to everyone in radio proximity. … The radio range can be hundreds of meters or more. [It] uses a Raspberry Pi and two off-the-shelf WiFi adaptors for a total cost under $100.
…
ADWL is really neat and the technologies built on it can be revolutionary. For example, [it] played a part in the 2019 pro-democracy protests in Hong Kong, where it was used to share information without fear of censorship.
…
But having such a large and privileged attack surface reachable by anyone means the security of that code is paramount, and unfortunately the quality of the AWDL code was at times fairly poor and seemingly untested. … My prototype exploit gains access to any nearby iPhone’s memory in just a few seconds; imagine launching the exploit from a drone flying across a protest.
…
I’d love to work with Apple to work out if this work qualifies for a bug bounty and donate that in full to charity. … With Apple’s generous donation matching commitment that could be up to $500,000.
Great work. And fast, says Someguyperson:
This is a very impressive vuln for just one researcher to work through in just 6 months. I would expect 3–5 researchers to take ~1 year for this kind of work.
But The Ugly has a slightly more cynical perspective:
If there’s one thing I’ve learned in commercial software development, it is that if one person can buckle down and do it alone in six months, it will take a well run commercial agile team of 10-12 engineers broken into three or four sprint teams with a scrum master and daily standup and detailed quarterly sprint planning at least three or four years of dedicated cross functional engineering before the company creates a new platform team to redevelop part of the solution on the new unified cloud platform.
What’s an iPhone owner to do? Djamé Seddah—@zehavoc—tweets his Gallic disappointment:
I hope everyone last one of you iPhone owners have disabled Airdrop.
And Xenoflargactian makes a broader point:
You need to update to get security patches. Many updates contain fixes for security vulnerabilities, even if they’re not published publicly. This is why you should always update once new versions are released.
…
This is just one exploit chain. I’m sure there are many more we don’t know about. Just check out the security fixes in iOS 14.2 alone. … If RCE exploits like this worry you, your best bet is to install every update as soon as it is released.
Don’t wait for a journalist to pick up on a benevolent researcher’s blog post. That delay increases your vulnerability.
So what about Beer’s opinion that “the quality of the AWDL code was … fairly poor and seemingly untested”? dvt wears tight socks:
I read the entire thing, and honestly the heap grooming is very interesting, but really that's the boring part. … Also interesting that linked-lists aren't used by Apple … but that's neither here nor there. Getting kernel memory read/write is also very interesting, albeit (again) a bit tedious. At the end of the day, it all started with … “an out-of-bounds memmove.”
How did this even pass the smell test? How did it get through code reviews and auditing? You're allocating from an untrusted source. It's like memory management 101. I mean, my goodness, it's from a wireless source, at that.
Meanwhile, sundial212 squints at the time:
There are some pissed off guys in Office of Tailored Access.
The moral of the story?
IT: Ensure your users are getting updates.
Dev: Don’t make the same mistakes as Apple.
And finally
Hat tip: Rob Beschizza
You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
This week’s zomgsauce: Thierry Ehrmann (cc:by)
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
