New Version of 'January 1, 1970 Bug' Can Brick Pre-iOS 9.3.1 Devices Over Compromised Wi-Fi Networks

[MacRumors]

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.

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.

Article Link: New Version of 'January 1, 1970 Bug' Can Brick Pre-iOS 9.3.1 Devices Over Compromised Wi-Fi Networks

 

[jonnysods]

Shows how vulnerable all our tech really is. This seems so small, yet so problematic.

 

[braddick]

this issue reminds me of the joke, "The patient says, "Doctor, it hurts when I do this." "Then don't do that!"

 

[smacrumon]

Come on, Apple! Find and Replace 1970 in entire Project!
Always fascinating to hear what little bugs present in iOS.

 

[macintologist]

Maybe we need SSL certificates for NTP servers?

 

[kazmac]

Yikes. I keep WiFi Assist off as it was very buggy, annoying (I do not see WiFi Assist mentioned above, but I thought about it while reading this article.)

Scary the vulnerabilities keep mounting. I'm grateful there are honest research teams who want to work with Apple first and I hope that continues.

 

[pat500000]

Another 1970 crap. If you don't know about, don't worry about it. If you know about.....pretend you don't know about it.

 

[viperGTS]

Wait, so you mean that Apple didn't fix the actual cause of the bug (which was apparently how the OS handles January 1st, 1970 in binary), and instead just prevented the user from setting the date as such?

Great...

 

[Black Magic]

Yikes. I keep WiFi Assist off as it was very buggy, annoying (I do not see WiFi Assist mentioned above, but I thought about it while reading this article.)

Scary the vulnerabilities keep mounting. I'm grateful there are honest research teams who want to work with Apple first and I hope that continues.

Yea, but why publish the exploits at all? Let the manufacturer know with the threat to release so they can fix. Releasing it into the wild even after it has been patch benefits no-one except evil doers.

 

[sualpine]

Wait, so you mean that Apple didn't fix the actual cause of the bug (which was apparently how the OS handles January 1st, 1970 in binary), and instead just prevented the user from setting the date as such?

Great...

Unix is Unix.

 

[vertsix]

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.

 

[KPOM]

They probably should have waited another few weeks before publishing this. Corporate users with mobile device management are often told to wait (or even prevented from) upgrading until the update gets approved. They do this to make sure the updates don't interfere with their servers or proprietary apps. At my employer, we just got the approval for 9.3.1 about 2 weeks ago.

 

[kazmac]

Yea, but why publish the exploits at all? Let the manufacturer know with the threat to release so they can fix. Releasing it into the wild even after it has been patch benefits no-one except evil doers.

There lies the rub. I would prefer these not go public either for the exact reason you mention, but this can be said of any information that gives shady parties ideas.

 

[redheeler]

Unix is Unix.

I have older Macs with dead PRAM batteries, every time they are unplugged they are set back to the Unix epoch in OS X (December 31, 1969). It's annoying, but they can be used just fine that way. This is definitely an iOS issue that doesn't exist on OS X.

 

[Traverse]

I'm still astounded at how people find these. Like old hacks in Gameboy color games: "take 3 steps left, head down until you're spotted, press start at the right time to freeze the game, go here, turn around three times = unlimited whatever"

Who figures these out!
[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!

 

[KALLT]

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.

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.

 

[Nothlit]

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.

That wouldn't prevent what is described in this article. These researchers essentially tricked the phone into thinking it WAS receiving a time adjustment from Apple's servers.

 

[maxsix]

Apple iOS, it just works... oh wait

 

[farleysmaster]

Wait, so you mean that Apple didn't fix the actual cause of the bug (which was apparently how the OS handles January 1st, 1970 in binary), and instead just prevented the user from setting the date as such?

Great...

Nope. If you've upgraded you're safe. That's what the article says.

Edit: unless you mean between iOS 9.3 and 9.3.1 in which case, yeah looks at the very least like they missed a way that that date could be set.

 

[JackANSI]

Apple's "focus on security" is a joke.

 

[FieldingMellish]

Answer the doctor would say: "Then refrain from doing that."

 

[Dhmspector]

Should 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.

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.

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 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.

Article Link: New Version of 'January 1, 1970 Bug' Can Brick Pre-iOS 9.3.1 Devices Over Compromised Wi-Fi Networks

 

[farleysmaster]

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.

If you have OS X, you can remove them but yes it wouldn't be a bad idea to let you do that from your iDevice.

 

[Tubamajuba]

Apple iOS, it just works... oh wait

Dude, give it up. We get it, you hate all things Apple.

 

[bearda]

Wait, so you mean that Apple didn't fix the actual cause of the bug (which was apparently how the OS handles January 1st, 1970 in binary), and instead just prevented the user from setting the date as such?

Great...

The bug was fixed in 9.3.1. The method here is an exploit for 9.3 and prior devices only. If you're on the latest version of iOS you're good to go.