This radio-proximity exploit can quietly take over your iPhone without you knowing it

Cal Jeffrey

Posts: 4,179   +1,427
Staff member
In a nutshell: While some of us were locked away binge-watching our favorite TV shows on Netflix, one security researcher was figuring out how to hack an iPhone without user interaction. He came up with a way to "inject" malicious code into an iOS kernel object using peer-to-peer WiFi. It requires no action on the user's part and is virtually undetectable.

Using about $100 worth of equipment that included a Raspberry Pi and some off-the-shelf WiFi adapters, Project Zero researcher Ian Beer developed an exploit that can highjack an iPhone over WiFi without the phone even being connected to a network. The attack requires no interaction on the part of the victim.

By broadcasting malicious WiFi packets, Beers could cause a buffer overflow in the AWDL driver. This fault, in turn, allowed him root access. The attack can work on one or even multiple iPhones simultaneously if they are within radio proximity. Even more astonishing, the exploit is "wormable," meaning that malware can be programmed to use the same attack vector to propagate from one nearby device to another.

"For 6 months of 2020, while locked down in the corner of my bedroom surrounded by my lovely, screaming children, I've been working on a magic spell of my own. No, sadly not an incantation to convince the kids to sleep in until 9am every morning, but instead a wormable radio-proximity exploit which 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."

"This is a fantastic piece of work," Project Zero founder Chris Evans told Ars Technica. "It really is pretty serious. The fact you don't have to really interact with your phone for this to be set off on you is really quite scary. This attack is just you're walking along, the phone is in your pocket, and over WiFi someone just worms in with some dodgy WiFi packets."

Beers posted a couple of demos to YouTube showing the exploit in action. The first (above) is a detailed and technical look at how the attack works against a single phone. The second (below) shows him shutting down 26 iPhones of various models all at once.

"There's something hauntingly beautiful watching all these iPhones die at slightly different times, as they get a WiFi broadcast packet of death," Evans tweeted.

What makes the exploit particularly frightening is that once the iPhone is compromised, the attacker has full access to it without the victim's knowledge. As long as the hacker does not do something that would alert the user, the phone will continue to operate normally.

Fortunately, there is little need to worry about encountering this exploit in the wild unless you have an older iPhone that cannot be updated to the latest versions of iOS. Beers informed Apple of the vulnerability, and developers pushed a patch way back in iOS 13.5.

If you are interested in the full technical details, Beers has a 30,000-word writeup on it posted to the Project Zero blog. It's a long but interesting read.

Image credit: Konstantin Savusia

Permalink to story.

 
Fascinating indeed. I wish I knew more about computers on a low level and what not. I also hope that Also hope Apple rewarded Mr. Beer for his finding.
 
Reminds me of an incident at the White Sands Missile Range years ago .... they pulled out a bunch of way out of date hound dog missiles and were using them as target drones for tests. At the same time the NORAD sites lite up with incoming boggie's and it appeared the US was under attack but in actuality the NORAD computer systems databases had been recently "upgraded" and had dropped a number of the slower, older missiles, thus the mistake. A bow & arrow is still an effective way to take down a person and it's a lot more than 20 years out of date!
 
Original article is almost ONE YEAR OLD
July 30, 2019 -- 16:56 GMT (09:56 PDT)
Apple's AWDL protocol plagued by flaws

The fix for the AWDL DoS bug (CVE-2019-8612) rolled out in mid-May, with the release of iOS 12.3, tvOS 12.3, watchOS 5.2.1, and macOS 10.14.5.
 
Yet another case proving a strong hacker-and-beer relationship.

But seriously, buffer overrun or underrun attacks like these are mostly deliberate holes setup by the programmer(s) who programmed a certain module, rather than accidental bugs. After so many years of buffer overrun bugs causing problems, it's almost impossible for an experienced programmer to allow the buffer to overflow the CPU stack. Anyone using a local byte array inside a function (which is how buffer overrun happens), without checking the buffer boundaries (second condition that has to be satisfied), is either a paid "terrorist" or a horrible programmer.

And in most cases it's a deliberate "terrorist" act to allow the government, or some corporations, or some shadowy organizations, to access the user data and/or hijack their phones. Sometimes this can be used for good purposes (catching criminals) but most of the time it's for the most primitive purposes, spying, blackmail, extortion, etc.

Imagine the leverage when you get suspicious data (such as naked pictures, or child porn, or photographed documents, or conversations) from a cellphone belonging to a high-profile politician, or CEO of a big corporation, or leader of a big organization. You can force him to do whatever you want. That's the reason why most of those "bugs" are actually deliberate.

Especially because it's hard to prove that a programmer did it on purpose. He can always say it was a honest mistake. Only polygraph could prove him wrong, but that kind of a "proof" is not accepted by any court of law. Although, someone else could shoot him based on that "proof".
 
Especially because it's hard to prove that a programmer did it on purpose. He can always say it was a honest mistake. Only polygraph could prove him wrong...
I hate to poke a hole in a good tinfoil-hat conspiracy theory, but claiming this was intentional is really unconscionable. Lack of an explicit array bounds check is only one of many ways a buffer overflow can happen, the overflow in question was likely in older library code the programmer in question never even saw directly, and in any case, someone with code access has much easier and harder-to-detect methods to insert a back door.

The real breakdown here is in testing. Does Apple's own iOS validation protocols not include malicious packet test cases?
 
Back