Posted
by
samzenpus
on Thursday July 28, 2011 @10:47AM
from the patch-your-phone dept.

CWmike writes "Almost anyone can snoop the secure data traffic of unpatched iPhones and iPads using a recently-revised nine-year-old tool, a researcher said as he urged owners to apply Apple's latest iOS fix. If iOS devices aren't patched, attackers can easily intercept and decrypt secure traffic — the kind guarded by SSL, which is used by banks, e-tailers and other sites — at a public Wi-Fi hotspot, said Chet Wisniewski, a security researcher with Sophos. 'This is a nine-year-old bug that Moxie Marlinspike disclosed in 2002,' Wisniewski told Computerworld on Wednesday. On Monday, Marlinspike released an easier-to-use revision of his long-available 'sslsniff' traffic sniffing tool. 'My mother could actually use this,' he said."

If an attacker can act as the gateway for a victim (man in the middle), he can use this attack. sslsniff works by intercepting requests between the server and the victim, and it removes all HTTPS tags/references/links. In effect, the victim doesn't know there was supposed to be an SSL connection. I don't see how they can patch this with the current technology..

you're thinking of sslstrip, another program by moxie marlinspike
a lot of websites get around this by denying requests to http:/// [http] for login pages and beyond, but some surprisingly popular ones didn't when i played with it last year.

a lot of websites get around this by denying requests to http:/// [http] [http] for login pages and beyond

There is nothing stopping a proxy using ssl to talk to the server while using an unecrypted connection to talk to the client.

Things get a little harder if the site has some pages ssl only and others avilable non-ssl only. In that case you would have to either mangle the hostname to differentiate or store a list of what protocol to use for what pages.

Not really, you simply have to assign each link an identifier so that when they click a link your proxy goes to the original link from your server or might even be more easily done by leaving the https on the links but returning http if the browser is not smart enough to notice the discrepancy.

No, you're thinking of SSLstrip [thoughtcrime.org] which methodically strips HTTPS references. This is a different attack [thoughtcrime.org], where the client accepts certificates signed by any certificate that has a valid chain

I thought the problem was a failure of ios to check the certificate chain? It is a mitm attack but one with a (for the attacked user) valid SSL connection. The patch fixes the incorrect certificate handling and will throw an exception.

" "It's probably been in [iOS] since day one," said Wisniewski, who speculated that even attackers hadn't known of the flaw. "Someone would likely would noticed if it had been used, because every Windows user would have been getting browser warnings [of an invalid certificate] on a public Wi-Fi network even as iPhone users were seeing no such warning." "
Does he seriously think you can't filter out non iOS devices and just forward them to the proper site? even a user agent check would suffice

You may not be able to do a user agent check on the SSL request but you can probablly assume all requests from the same (local) IP came from the same device and most devices are likely to make unencrypted requests as well.

You can't check the User Agent without feeding them the fake SSL cert first, since it's in the encrpted data.

You could of course default pass along everything and only act as a man in the middle for https requests from a device that you've already intercepted an HTTP request from to determine it's of the right flavor. But that does make it ever so slightly more difficult.

To redirect the user off a https page you have to negotiate a ssl session with them and that means you have to present a cert. If the cert doesn't match they will get a warning before receiving the redirect.

but as the GP implies none of this really matters much because most users will go to a http page first anyway.

Exactly. Apple should be ashamed that they don't provide security updates for the original iPhone and the iPhone 3G already. Original iPhone owners have been SOL for over a year now, almost 2 year actually. If Microsoft did this, they would probably be taken to court by the Department of Justice. I'd like to point out though, that other phone manufacturers have the same problem. Take the original droid, the G1. That thing is still running 1.6, right? You can't tell me that's a good thing. As phones evolve i

If Microsoft did this, they would probably be taken to court by the Department of Justice.

I have a 286 running Windows 3.1, can I take MS to court for not releasing security updates any more? That's an extreme example, all manufacturers have to end-of-line their older systems at some point, but I agree that it's a bit soon to do that for the iPhone 3G.

Simple, require manufacturers to release source code (and anything else required in order to build and run the source) once they are no longer willing to provide security updates. Someone else will pick up the slack and provide updates if enough people are still using the devices.

Yes, if Microsoft was still selling Windows 3.1 a year ago and included network connectivity. Also, if people had to sign a 2 year contract with someone and weren't eligible for upgrade to a new device until the 2 years is up. Then yes, Microsoft should be held accountable.

The 3G owners have been screwed since the moment they "upgraded" to iOS4. Damn things ran out of memory so fast they slowed to a crawl after just a short time using them.

Posting anonymously from an iPhone 4 because the Apple fanboys will no doubt descend like flies to defend whatever crap is decanted by The Turtlenecked One, and I'm not posting from the 3GS that iOS4 rendered useless, and couldn't revert back to 3.1.3 because of some other DRM crapple strategy.

second, you can dramatically improve the performance of 3g phones running 4.0+ by disabling all (or most) of spotlight search
settings -> general -> spotlight search, and then uncheck everything you can live without -- I recommend just keeping mail, events, and contacts)

You'd think a bug 9 years old would've been fixed. As usual, no response until it's been publicized enough times instead of fixing it before it can get to this point.
It would really suck if those older users really can't get a fix because they can't upgrade.

Problem is that applying this update for something that is not likely exploited in the wild will hose your Unteathered Jailbreak. Reports on twitter are that redsn0w pointed at 4.3.4 (or 4.2.9) will work for getting a tethered Jailbreak. Many jailbreakers likely wont bother.

Wonder if someone will patch this like they did the PDF exploit and put it on Cydia.

Problem is that applying this update for something that is not likely exploited in the wild will hose your Unteathered Jailbreak. Reports on twitter are that redsn0w pointed at 4.3.4 (or 4.2.9) will work for getting a tethered Jailbreak. Many jailbreakers likely wont bother.

Wonder if someone will patch this like they did the PDF exploit and put it on Cydia.

Sorry but I don't see the problem here. If you are concerned about security in the first place then you should not jailbreak. What exactly do you think a jailbreak is anyway? You are basically stripping the check for code signing and shutting down the BSD jail sandbox mechanism for the OS so that you can run unsigned code but that also means that someone can setup a repo and trick people to download and install malware onto their iPhone. On a jailbroken iPhone, code can access any part of the filesystem wit

I don't care WHO said it. That's nothing but FUD. The fact remains that jailbreaking your phone doesn't leave it wide open. It DOES allow you to do many various things that CAN leave your phone wide open....but in and of itself, it's not really dangerous.

I don't care WHO said it. That's nothing but FUD. The fact remains that jailbreaking your phone doesn't leave it wide open. It DOES allow you to do many various things that CAN leave your phone wide open....but in and of itself, it's not really dangerous.

Jailbreaking destroys the BSD jails in iOS, hence the name "jail break". It also circumvents checks for code signing so unsigned code can run on the iOS device. When there are no jails then each program that you install has free access to the filesystem whereas a stock iOS install limits access to a few areas on the filesystem for non-Apple software.

Jailbroken versus Factory iPhones
Jailbroken phones are much easier to work with than factory phones. The main
difference is that the jailbroken phone disables code signing. This allows for the running
of arbitrary third party, unsigned, applications. Such applications include a shell, sshd,
gdb, python, etc. It is no wonder that researchers prefer to work on jailbroken phones.
After all, besides the code signing, there appears to be no real distinctive difference
between the jailbroken and factory phones. However, this is not the case.

Many researchers, including one of the authors of this paper, have given talks where
their results tacitly relied on the fact a phone was jailbroken. This is because, by
disabling the code signing requirements, it doesnt just change what programs may be
executed, but it fundamentally changes the way the memory page protections work. As
we discussed, at this point, it is not clear how to write to a page and then make that
page executable on a factory phone. While there may be a clever way to accomplish
this, at the present time, any discussion of shellcode with regards to the iPhone implies
the phone is jailbroken. This includes payloads that return into mprotect to set page
permissions for their shellcode. If you attempt to mprotect a page which has previously
had data written to it on a factory iPhone, the mprotect will fail with a return value of -1
and errno set to “Permission Denied”.

Jailbreaking does not magically leave your phone wide open for attack.

Yes it does.

Jailbreaking requires you to write code to modify the bootstrap sequence. If you cannot do this, you must TRUST someone else will ENTER YOUR SYSTEM, and then LEAVE. You TRUST the program(s) they left behind (Cydia or equivalent) do not have any holes (like enabling telnet/ssh/trojan/something else bad by default) or, if they do (Strike 1), they will update their code appropriately and quickly (Strike 2 if they don't).

And that's only if you now use your phone as if it isn't jailbroken. If you

Here's what I don't understand: why don't the jailbreakers modify the phone to add trust for a Cydia root cert (or whoever's), then use that to provide free certs for devs to sign apps on Cydia, etc.? That would provide the same flexibility as a full jailbreak, but without the security impact. Or heck, add trust for all the major CAs so that any standard code signing cert will work.

The problem is that jailbreaking started out as a hack and still hasn't grown up from being a hack into being a usable tool.

I can beat that. Sony Ericsson shipped the XPeria X8 with Android 1.6 some time in about the end of August/beginning of September of last year. It had an upgrade to 2.1 towards the end of November, has had nothing since and Sony Ericsson have announced there will be no further update.

That's just three months - depending on where you are in the world, these phones get released at different times so it could actually work out at more like 2.

This is why I chose the iPhone over others, this being just one example of who mobile users were typically treated pre Apple.

Apple released the 3G in July 2008 and it received iOS updates until November 2010, approximately 6 months after being discontinued so around 2.5 years of support. Compare that to the XPeria X8 mentioned which on release used a one year old OS 1.6, when 2.2 had been out for around half a year and then they assume you should be grateful when they 'upgrade' you to another obsolete ver

So if I want to update the OS on my phone - my 7 month old phone that still has 11 months of contract to run before I can get a subsidised replacement - I have to install an unsupported firmware that will blow any warranty out of the water?

And it's why I chose an Android phone that I knew was easily rootable so I could install whatever OS I wanted on it, and not be reliant on the manufacturer for updates.

Those who choose otherwise get no pity from me. It's easy enough to do the research beforehand, and it's not like hardware manufacturers have a good track record for providing support. Apple does do better than most, but they still drop support for phones that people are on contract for. Being less-bad than the alternatives isn't really a

Kevin could at most convince you to hand the phone over to him to check for electronic gremlins. I doubt he could hack the iPhone worth a damn. He's a social engineering genious; average techie at best.

Did Apple really write a new custom certificate validation stack for iOS? Really?

And then the developers failed to test it against this basic condition (using a valid certificate to sign a fake certificate)? On a device where you can only connect via wi-fi networks, which are inherently untrustworthy!

Why, Jobs, why?

THIS is the kind of gross incompetence that deserves a Congressional investigation. Who was behind this? Was it stupidity or actual malice?

Why is something that is so old, still working on new technology that has been pushed out after it? If Apple can not make sure that their products being shipped at least have the latest updates before shipping, then there is a problem....now i have to review how many times i used wifi hot spots with my iphone.....oh..wait.....i never do that!