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 they do 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 Celsius), 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 have a feature that allows users to prevent the devices from automatically joining wireless networks. Enabling this “ask to join networks” feature blocks Apple devices from automatically joining networks they have never seen 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 (this can be disabled by unselecting “Ask to Join Networks”). But enabling it doesn’t prevent the device from connecting to, say, “attwifi” if it has previously connected to a network of that name.
The researchers have posted a video on Youtube that explains their work in greater detail.
Update, 1:08 p.m. ET: Added link to video and clarified how Apple’s “ask to join networks” feature works.
“Manually setting the date of your iPhone or iPad all the back to January. 1, 1970 will permanently brick the device”
This is not quite correct. There are ways to recover from doing something as stupid as this. A DFU restore will usually fix it, and, if not, running the battery all the way down or disconnecting it for a few seconds will allow recovery. Apple Stores have been disconnecting the battery for phones brought in with this problem for over a month (and not charging for the service). And the 9.3.1 update was 2 weeks ago.
Larry,
1. This vulnerability was discovered more than 2 weeks ago. Read the article.
2. Leaving your iPad at 50C for an extended period of time will destroy components it needs to function. I think that counts as “bricking” the device.
3. What’s “stupid” here is a flaw where you can destroy your device by setting it’s date to something outside the near present.
I saw somewhere else the idea of decrementing it instead of one big leap, which would still work.
This approach worked a bit differently than the “finger vector”. The largest difference being the heat and the slow declination of the device. It was also impossible to shut down, once the process began.
There is a way to repair the device, now. That is what I worked closely with Apple to confirm. Prior to 9.3.x, it wasn’t possible… even for Apple, to restore the device. That is why we’ve waited so long to publicly report this.
Yes, the process of pushing time back where it shouldn’t was rooted with persistence. Told enough times from a “trusted source”, it was willing to comply.
Hope this helps in understanding the flaw and the approach.
In all cases, this bug could be resolved by putting the iOS device in DFU mode (not recovery mode) to restore it and then waiting an hour or so while the progress bar is showing.
I’ve confirmed this myself (as have others). The biggest issue is being patient and leaving the device plugged into something that can charge its battery. If it isn’t plugged in, this bug can cause the battery to fully drain in less than an hour.
Though I really don’t have the time to argue each point of this work, I’ll address this one.
With the NTP version of this attack, it does not restore as the previous versions might have. Ourselves and Apple engineers left devices unplugged for days. It did not allow DFU mode. It did not permit a restore. The devices continued to sit on worktables are increase in temperature. We used multiple laptops, multiple devices and multiple images. Our collective assessment was that the device keeps running and will not permit any sort of hard shutdown.
I understand others were able to restore devices after manually rolling back the time, but it didn’t in all of the devices we thoroughly tested. We were very thorough in assessing that stage.
However, when using 9.3.x/iTunes, we along with Apple, were able to restore the devices. Prior versions did not work.
We did our very best to provide due diligence and test all previously documented steps. I appreciate your skepticism. It keeps the industry honest.
> 2. Leaving your iPad at 50C for an extended period of time will destroy components it needs to function. I think that counts as “bricking” the device.
No. iOS-devices shut themselves down before they reach dangerous temperatures (and yes, this effectively prevent using an iPad in the sun on a hot day).
> 3. What’s “stupid” here is a flaw where you can destroy your device by setting it’s date to something outside the near present.
Yes and no. Actually it’s absolutely correct behavior to prevent the device from running software with invalid certificates, it’s the very foundation of the security system (ask the FBI about that ;)). The stupidness in this is a combination of two flaws:
1) It is possible to set the clock to ridiculous values.
2) All certificates (even for the DFU mode firmware!) are invalid at there ridiculous values.
“No. iOS-devices shut themselves down before they reach dangerous temperatures (and yes, this effectively prevent using an iPad in the sun on a hot day).”
Yeah, unless this vector is used. Temp management fails altogether, along with many other critical phone functions.
Apple fixed this already See Apple Releases iOS 9.3 With Night Shift, New Quick Actions, App Improvements, ‘1970’ Bug Fix and More http://www.macrumors.com/2016/03/21/apple-releases-ios-9-3/
Y’know, believe it or not, I have actually set my iPod Touch 6th generation (64-bit, iOS 9.3) to the 1970 date and, the device did NOT heat up, yet I still have complications with the battery. It doesn’t last as long as it should, and if anyone can reply to me about this, I have had the phone for about 5 1/2 months, and I dropped it in water at about 3 weeks after first activation. The phone was completely submerged for 5 or so seconds, and I shut down the device and put it in a bag of rice for 24 hours, and everything worked. I didn’t have water in the ports after, so I didn’t have to clean it out, and there was no rice in the ports. The speakers worked perfectly, and the buttons worked. I have already had complications with an iPod Touch 4, and let me say, it did not go well. (Trust me, it was and still is bricked, but once again, it did not heat up.) Miraculously, they both happened on the same day. What are the odds?
It sounds like ntp, or ntp configuration, is broken on these devices. It should be impossible for ntp to “set” a time that is so far distant (the beginning of the Unix epoch), from the device’s current time. No?
This is a clever and well-used mechanism to prevent NTP issues, but it’s not part of the spec at all. Mobile devices lack a discrete realtime clock (they count on having a charged battery at all times) so there are cases where the device will be expected to have to resync a long way from “now” because IIRC the default time is something like midnight jan 1 2001. Only allowing big syncs forward, not backward would be one way to prevent this issue, but they probably were not considering that such a drastically malicious NTP server would ever exist.
Actually it doesn’t seem to do big syncs. Quotation:
“One thing we noticed was when we set the date on the iPad to 1970, the iPad display clock started counting backwards.”
That’s how Unix ntp clients I know work per default, so that they don’t break software with too huge time differences.
Of course it’s more or less ridiculous, that it is possible to set the date on a value long before the device was manufactured. It’s normal behavior for most hardware I know, but nevertheless it’s a fundamental design flaw.
To be fair, that could be read as incrementing backwards from January 1st, 1970 and not incrementing backwards from the current date to 1970 and beyond. If you notice they talk about how it reached 1968 and 1965, which could mean the increment started at 1970.
While I personally would like the ability to alter the NTP server to values I want to use, attackers could just intercept 123/UDP to MITM all NTP requests so that’s not a defense against this (or any other NTP-based) exploit.
Brian, Thanks for the article! I’m not an Apple user but want to pass the info along to friends who are. I’m not clear how they should get version 9.3.1. The “update to the latest version of Apple iOS” link in the article takes me to a page titled “If you changed the date to May 1970…” Even if that’s the correct set of update instructions it would be very confusing for a non-technical iPad user who just wants to follow directions to update her tablet to the latest release. Is there a better link available?
Are old Apple devices vulnerable too ?
I mean those not upgradable to iOS 9.
Only 5S (64 bit) and up.
The auto-connect feature is also a great way to be tracked. There is the option to forget a network, but that is only available whilst you are actually still connected to it!
There are so many ways to track any smartphone that one additional more or less won’t change anything. iPhones actually have some protection from WiFi tracking; when scanning for networks (before they connect) they send a bogus MAC address. Once you connect, of course, this doesn’t count.
This doesn’t change the *other* stupidity here, which is the lack of some sort of actual authentication of network IDs. It isn’t even technically difficult:
1. Each wifi router generates a key pair.
2. In addition to its human-readable name it advertises the public key of that key pair.
3. Devices that want to know “is this a network I’ve connected to in the past” begin by comparing the network’s advertised public key with a list of known network keys.
4. Upon finding a match there is a challenge-response handshake where the router proves it knows the corresponding private key.
5. The network is only considered familiar if it passes this challenge. If it does not prove knowledge of the private key, or the public key is unknown to the phone, the network is considered unfamiliar on that occasion.
No need for certificates, a web of trust, or a chain of identity of any sort. We’re not so much interested in proving that the network is really owned by Starbucks as in simply proving that it’s the same attwifi that we saw last Tuesday.
What can be done to protect older iDevices (like iPhone 4) which Apple ceased to update?
The bug only affects 64-bit iOS devices running iOS 8 or later. As the iPhone 4 lacks both, it is not affected by the bug.
Also, NITZ overrides NTP on iOS, making this attack not work on iPhones connected to a cell network.
It’s not the solution that you might prefer, but turn off the feature that auto connects to networks that it’s connected to previously.
It may be a pain to enter a password each time you connect, but it’s probably better than watching your 4s fry.
Am I the only one who thinks that you must be completely jobless in life and have absolutely nothing else to do whatsoever to perform a test like that in the first place? I mean, why would any normal human being voluntarily go and manually set the date to the 70s? Missing the free love era that much? 😀
For security researchers, that *is* their job.
Kal, I find your comment severely short-sighted. You’re missing the point. If these guys didn’t discover this bug, someone else with more dangerous intentions definitely would have.
The fact that it involves an Apple device (which consumers mistakenly think are “safe, private and hack-proof”) is even more revealing.
Eh, any device is hackable.
I keep cleaning malware off Macs of individuals who think they don’t need to keep updating their systems and yet still think Macs are hack-proof. Thankfully I haven’t had any repeat behavior, once has been enough to scare them into paying attention to what they’re doing. And to continue installing updates.
Still, there’s always going to be the one guy in the group who thinks shooting the messenger is a good defense. What we don’t know can’t hurt us, right?
Apparently there was a rumor going around that setting the time back would give you a “vintage” look UI.
“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.”
Yeah, but pretty much any date older than a few will predate an iPhone’s cert issuance and will NOT brick the phone.
It sounds like there are a combination of factors. Simply setting the date back enough to invalidate the certificates doesn’t cause the device to hang. NTP would still have to slew its time until reaching the earlier date, but apparently can do that without overusing the CPU.
However, setting to the January 1, 1970 date is special. That date is the Unix Epoch because dates are represented internally with a signed integer (originally 32-bit). That value is all zero bits. Apparently NTP then failed to notice it was already at the low bound of the data type, and still tried to decrement. Then, perhaps (since a negative number turns on the high bit of the data type to represent the sign), NTP was doing an Unsigned comparison with a signed number (bad but common mistake for programs written in C/C++). This would cause it to think it had not yet reached the target date, and keep decrementing below January 1, 1970.
I suspect it was the infinite loop triggered by this bug that caused the hard freeze, rather than the certificates being invalidated. But the certificates being invalidated did mean that critical system software was unable to run (and that makes it practically impossible to recover from the hard freeze).
That is my armchair analysis…
Wait, WHAT? “By spoofing time.apple.com”…. — WHAT?!?!
Are you telling me that iOS doesn’t require a secure connection (SSL / TLS) to an apple machine / network? That sounds incredibly stupid & egregious.
I was (am) assuming that iOS doesn’t update time via NTP, correct? I mean, the protocol from the (70s?) with absolutely no authentication?
Um, tlsdate, mkay?
Without a proper date, there’s no real way to verify certs (that have a start and end date). iOS also prefers dates from NITZ and CDMA2000 (and possibly GPS) over ntp, that’s why this is significantly harder to trigger on iPhones.
“….another brick in the wall.”
There’s an app for that ya know.
It’s an old problem that seems never got fixed. Well, maybe an update will make the world right again (I doubt it). The Windows and nix worlds have gone through this. Though it is part of why I would still rather have a wired desktop. It’s all a series of headaches I don’t deal with since I don’t actually own any iphone or ipad. Nothing is invulnerable but no update or app can replace the control a responsible user can have over their machines.
Brian, you write a fantastic blog. I never miss a posting.
FYI typo in this posting: Celcius >>> Celsius
Ahhh, the old “Reverse Y2K Bug”, yeahhhh seee?
Was wondering if someone could dig up an old security tool from 2009 called airpwn. Basically you wouldn’t even need to stand-up a rogue, given that you know how to respond for time.apple.com you could do it to any iphones that connect to a known open access point (attwifi is a great example).
Brian,
Thanks for getting this out there! It’s important that people are aware of it and can choose if they want to risk their phone and privacy. Bottom line…just update!
There is absolutely no reason to be alarmed or concerned, just update your device and move on.
Sounds like if you set it to January 2, 1970 you could achieve the same results…?
I guess this is, for the millionth time, where we demand that Apple will finally add the basic function of letting us manage the list of known network SSIDs to iOS. I mean seriously, how is it that my phone due to backups and restores still connects to networks that have the same SSID as the hotel wifi from a vacation in 2010??!
WiFi devices connect by WiFi MAC address not only by Wi-Fi network name. If MAC address is different, iPhone notifies and asks user to join new network. Therefore, you have to spoof exact Wi-Fi spot mac address, not just a common Wi-Fi name to connect seamlessly.
“The flaw is present in all Apple devices running anything lower than iOS 9.3.1.”
The flaw, which appears to have been caused by a bad compare between an unsigned 32-bit time and a 64-bit time, as it only affects 64-bit devices running iOS 8.0 or later, which would limit it to the iPad Air and later and the iPad mini 2and later. iOS devices with a valid SIM card would appear to be immune to the NTP hack as iOS prioritizes time sync from NITZ (for GSM) and CDMA2000 services.
It was also entirely fixed in iOS 9.3.
The iOS 9.3.1 update only had changes to swcd, SharedWebCredentials.framework, symptomsd (all for the links bug), and mobileactivationd (for the iCloud activation bug present on iOS devices released in 2013 or earlier). It had no other changes.
The video this article links to was originally filmed on February 24th, as you can see by the date in the one console. This is before the release of iOS 9.3, so the iPad appears to be running running iOS 9.2.1, not iOS 9.3.
I think the reason why the researchers said “upgrade to iOS 9.3.1” was because it was the latest version available when they decided to post the video on Tuesday and it is bad form to recommend people update to iOS 9.3 when iOS 9.3 still had the nasty links bug (which was a security bug as it occurred due to data from a third party) from iOS 9.0.
Tell me again just how safe and secure iphones are…..
How hackers eavesdropped on a US Congressman using only his phone number
http://arstechnica.com/security/2016/04/how-hackers-eavesdropped-on-a-us-congressman-using-only-his-phone-number/
What does it have to do with iPhones?! They attacked the Cell phone carrier, not the phone.
“What does it have to do with iPhones?! They attacked the Cell phone carrier, not the phone.”
lmao
Why laugh at that? The Ars article doesn’t once mention the iPhone. Did you read it?
I wonder if this also affects Macs or other BSD computers….,
While 1970 is an epoch date elsewhere, the bug does not affect other devices. It was caused by a bad compare (32-bit vs 64-bit) in some iOS-specific validation code.
While NTP itself is known to be insecure, desktops and laptops will filter out bogus servers if they follow the recommendations in the NTP RFCs. Such as using more than one time server and/or also using dates embedded in response packets. The other common method is to ignore dates that occur before a certain event.