New Threat Can Auto-Brick Apple Devices

If you use an Apple iPhone, iPad or other iDevice, now would be an excellent time to ensure that the machine is running the latest version of Apple’s mobile operating system — version 9.3.1. Failing to do so could expose your devices to automated threats capable of rendering them unresponsive and perhaps forever useless.

Zach Straley demonstrating the fatal Jan. 1, 1970 bug. Don’t try this at home!

On Feb. 11, 2016, researcher Zach Straley posted a Youtube video exposing his startling and bizarrely simple discovery: Manually setting the date of your iPhone or iPad all the back to January. 1, 1970 will permanently brick the device (don’t try this at home, or against frenemies!).

Now that Apple has patched the flaw that Straley exploited with his fingers, researchers say they’ve proven how easy it would be to automate the attack over a network, so that potential victims would need only to wander within range of a hostile wireless network to have their pricey Apple devices turned into useless bricks.

Not long after Straley’s video began pulling in millions of views, security researchers Patrick Kelley and Matt Harrigan wondered: Could they automate the exploitation of this oddly severe and destructive date bug? The researchers discovered that indeed they could, armed with only $120 of electronics (not counting the cost of the bricked iDevices), a basic understanding of networking, and a familiarity with the way Apple devices connect to wireless networks.

Apple products like the iPad (and virtually all mass-market wireless devices) are designed to automatically connect to wireless networks they have seen before. They do this with a relatively weak level of authentication: If you connect to a network named “Hotspot” once, going forward your device may automatically connect to any open network that also happens to be called “Hotspot.”

For example, to use Starbuck’s free Wi-Fi service, you’ll have to connect to a network called “attwifi”. But once you’ve done that, you won’t ever have to manually connect to a network called “attwifi” ever again. The next time you visit a Starbucks, just pull out your iPad and the device automagically connects.

From an attacker’s perspective, this is a golden opportunity. Why? He only needs to advertise a fake open network called “attwifi” at a spot where large numbers of computer users are known to congregate. Using specialized hardware to amplify his Wi-Fi signal, he can force many users to connect to his (evil) “attwifi” hotspot. From there, he can attempt to inspect, modify or redirect any network traffic for any iPads or other devices that unwittingly connect to his evil network.

TIME TO DIE

And this is exactly what Kelley and Harrigan say they have done in real-life tests. They realized that iPads and other iDevices constantly check various “network time protocol” (NTP) servers around the globe to sync their internal date and time clocks.

The researchers said they discovered they could build a hostile Wi-Fi network that would force Apple devices to download time and date updates from their own (evil) NTP time server: And to set their internal clocks to one infernal date and time in particular: January 1, 1970.

Harrigan and Kelley named their destructive Wi-Fi test network “Phonebreaker.”

The result? The iPads that were brought within range of the test (evil) network rebooted, and began to slowly self-destruct. It’s not clear why it does this, but here’s one possible explanation: Most applications on an iPad are configured to use security certificates that encrypt data transmitted to and from the user’s device. Those encryption certificates stop working correctly if the system time and date on the user’s mobile is set to a year that predates the certificate’s issuance.

Harrigan and Kelley said this apparently creates havoc with most of the applications built into the iPad and iPhone, and that the ensuing bedlam as applications on the device compete for resources quickly overwhelms the iPad’s computer processing power. So much so that within minutes, they found their test iPad had reached 130 degrees Fahrenheit (54 Celcius), as the date and clock settings on the affected devices inexplicably and eerily began counting backwards.

Harrigan, president and CEO of San Diego-based security firm PacketSled, described the meltdown thusly:

“One thing we noticed was when we set the date on the iPad to 1970, the iPad display clock started counting backwards. While we were plugging in the second test iPad 15 minutes later, the first iPad said it was Dec. 15, 1968. I looked at Patrick and was like, ‘Did you mess with that thing?’ He hadn’t. It finally stopped at 1965, and by that time [the iPad] was about the temperature I like my steak served at.”

Kelley, a senior penetration tester with CriticalAssets.com, said he and Harrigan worked with Apple to coordinate the release of their findings to ensure doing so didn’t predate Apple’s issuance of a fix for this vulnerability. The flaw is present in all Apple devices running anything lower than iOS 9.3.1.

Apple did not respond to requests for comment. But an email shared by the researchers apparently sent by Apple’s product security team suggests the company’s researchers were unable to force an affected device to heat to more than 45.8 degrees Celcisus (~114 degrees Fahrenheit). The note read:

“1) We confirmed that iOS 9.3 a ddresses the issue that left a  device unresponsive when the  date is set to 1/1/1970.

2) A device affected by this i ssue can be restored to iOS 9. 3 or later.  iTunes restored  the iPad Air you provided to  us for inspection.’

3) By examining the device, we  determined that the battery  temperature did not exceed 45. 8 degrees centigrade.”

EVIL HARDWARE

According to Harrigan and Kelley, the hardware needed to execute this attack is little more than a common Raspberry Pi device with some custom software.

“By spoofing time.apple.com, we were able to roll back the time and have it hand out to all Apple clients on the network,” the researchers wrote in a paper shared with KrebsOnSecurity. “All test devices took the update without question and rolled back to 1970.”

The hardware used to automated an attack against the 1970 bug, including a Raspberry Pi and an Alfa antenna.

The researchers continued: “An interesting side effect was that this caused almost all web browsing traffic to cease working due to time mismatch. Typically, this would prompt a typical user to reboot their device. So, we did that. At this point, we could confirm that the reboot caused all iPads in test to degrade gradually, beginning with the inability to unlock, and ultimately ending with the device overheating and not booting at all. Apple has confirmed this vulnerability to be present in 64 bit devices that are running any version less than 9.3.1.”

Harrigan and Kelley say exploiting this bug on an Apple iPhone device is slightly trickier because iPhones get their network time updates via GSM, the communications standard the devices use to receive and transmit cell phone signals. But they said it may be possible to poison the date and time on iPhones using updates fed to the devices via GSM.

They pointed to research by Brandon Creighton, a research architect at software testing firm Veracode who is perhaps best known for setting up the NinjaTel GSM mobile network at the massive DefCon security conference in 2012. Creighton’s network relied on a technology called OpenBTS — a software based GSM access point. Harrigan and Kelley say an attacker could set up his own mobile (evil) network and push date and time updates to any phones that ping the evil tower.

“It is completely plausible that this vulnerability is exploitable over GSM using OpenBTS or OpenBSC to set the time,” Kelley said.

Creighton agreed, saying that his own experience testing and running the NinjaTel network shows that it’s theoretically possible, although he allows that he’s never tried it.

“Just from my experimentation, theoretically from a protocol level you can do it,” Creighton wrote in a note to KrebsOnSecurity. “But there are lots of factors (the carrier; the parameters on the SIM card; the phone’s locked status; the kind of phone; the baseband version; previously joined networks; neighboring towers; RF signal strength; and more).  If you’re just trying to cause general chaos, you don’t need to work very hard. But if, say, you were trying to target an individual device, it would require an additional amount of prep time/recon.”

Whether or not this attack could be used to remotely ruin iPhones or turn iPads into expensive skillets, it seems clear that failing to update to the latest version of Apple iOS is a less-than-stellar idea. iPad users who have not updated their OS need to be extremely cautious with respect to joining networks that they don’t know or trust.

iOS and Mac OS X has a feature that allows users to prevent the devices from automatically joining known wireless networks. Enabling this feature does in fact block Apple devices from automatically joining, for example, “attwifi” if you’ve done so before — but the side effect is that the device may frequently toss up prompts asking if you wish to join any one of several available wireless networks.

Tags: apple, Apple 1970 bug, Brandon Creighton, criticalassets.com, iPad, iPhone, Matt Harrigan, Packetsled, Patrick Kelley, Veracode, Zach Straley

This entry was posted on Tuesday, April 12th, 2016 at 10:41 am and is filed under A Little Sunshine, Latest Warnings, The Coming Storm, Time to Patch. You can follow any comments to this entry through the RSS 2.0 feed. You can skip to the end and leave a comment. Pinging is currently not allowed.