Security researchers Patrick Kelley and Matt Harrigan have uncovered a new way to exploit the infamous January 1, 1970 bug that was found to be the cause of bricked iPhones in February. Despite Apple's patch of the original issue in iOS 9.3, Kelley and Harrigan discovered the way in which an iPhone constantly looks for trusted Wi-Fi networks could lend itself to the malicious bricking of a Wi-Fi enabled Apple device, without the user even knowing it was happening.
/article-new/2015/09/iPhone-6s-main-800x337.jpg?lossy)
In a hypothetical example described by Krebs on Security, if a user confirms that a network called "attwifi" is a trusted connection, any subsequent network they come into contact with boasting the same name will connect with their iPhone. That way, when users revisit the same location frequently, they never have to fiddle with going through the Wi-Fi set-up process again. But the feature could be used to silently weaponize the 1970 bug, connecting users to similarly-named networks they've never encountered and altering the date and time stamps of their iOS devices.
In their research, Kelley and Harrigan used this feature of iPhones and iPads to build a nefarious Wi-Fi network, harnessing the requirement of iOS devices to occasionally connect to a network time protocol (NTP) server to keep date and time in sync. Once a user connected to their thought-to-be trusted network, the iPhone would reconfigure its software to update the date and time information from Kelley and Harrigan's own NTP date, which they specified as January 1, 1970.
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.”
Harrigan and Kelley coordinated with Apple when they discovered their findings to avoid preempting the company's promise of a fix for the bug, and possibly encouraging its malicious use in the wild. As such, the company has fixed the issue and anyone running iOS 9.3.1 will be protected from the new iteration of the 1970 bug. Older iOS releases, including the original iOS 9.3 update, are still susceptible, however.
With the release of their research, the two security experts are understandably encouraging users to update their iPhones and iPads as soon as possible, and have created a video to better explain the issue.
Top Rated Comments
Apple iOS, it just works... oh wait :eek:
Dude, give it up. We get it, you hate all things Apple.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.”
That right there is your problem. As if automatic joining of known SSIDs was not a bad enough idea, iOS also offers no way to see, edit and remove these known SSIDs, unless you are in range. You can only reset your networking settings to clear everything, but who does that on a regular basis? I do not understand why Apple has not done anything about it. I’d wager that there are many iPhone users out there who have long lists of known SSIDs.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.
Who figures these out! :eek:
[doublepost=1460563286][/doublepost]
Apple should just change it to where you cannot change the date on iOS, and all times are adjusted automatically through Wi-Fi or cellular through Apple's servers only.
But then my aunt couldn't cheat at Candy Crush! :pShould never happen if apple is using ntp - the spec and all common implementations forbid time travel (setting clock backwards). So this is purely and Apple bug, not ntp.
Very tiny nitpick: In some situations, the clock will indeed be set backwards with ntp, but it's an unusual circumstance and the change should be quite small.However, ntp's defaults (last I knew) forbid any clock correction exceeding 1000 seconds, so this kind of massive, 40-year correction should not be possible under any circumstances. Either Apple wrote their own time sync client (why?) or changed this default in their implementation of ntp. (Again, why?)
Incorrect device clocks have major security implications for any network, so even without this bricking bug, Apple should be paying closer attention to this. Time sync should never be an afterthought.