Replay! Attack!
Okay, so those two words don’t mean anything to you.
Take one iPhone. Take a Yahoo mail account, supporting “Push IMAP”, although it’s neither P-IMAP nor Lemonade. The iPhone authenticates to Yahoo using a proprietary mechanism called XYMPKI. The exchange goes like this:
iPhone: I’d like to authenticate using XYMPKI, please.
Yahoo: *nothing*
iPhone: Here’s a structured message, containing my device ID and a signature.
Yahoo: *nothing*
iPhone: Here’s my X.509 certificate in DER form.
Yahoo: Okay, I believe you.
Now, people have posted these traces on the web. Everyone knows that PKI is pretty secure, of course.
So, find one, and repeat it:
Me: I’d like to authenticate using XYMPKI, please.
Yahoo: *nothing*
Me: Here’s someone else’s first message, that I snooped off the wire, or grabbed via Google.
Yahoo: *nothing*
Me: Here’s someone else’s certificate, that I also got.
Yahoo: Okay, I believe you.
This is known as a replay attack. It’s not too serious, because any recent IMAP service supports TLS – they’re all mandated to by RFC3501, let alone Lemonade. This prevents replay attacks via sniffing, because you can’t get data. You’re still vulnerable to someone spoofing the DNS, and therefore pretending to be Yahoo’s server, although TLS certificate checking should catch this, too.
Oh, wait – because Yahoo! Don’t! Do! Standards!
So they don’t do TLS.
So not only does DNS spoofing work very nicely – thanks, Yahoo – but also anyone on an unencrypted access point can lift your credentials.
So.
What could Yahoo and Apple have done about this?
Well, firstly, they could have done TLS. That’d protect against the replay attack, as well as bringing them somewhat closer into line with the RFC they’re meant to be following.
Secondly, they could have used a different mechanism, say DIGEST-MD5 (venerable and moving to historic, but still quite good), GSSAPI, or simply TLS and SASL EXTERNAL based on the device certificate. Or some other proprietary mechanism that actually offered real security.
But they didn’t. Because they don’t, apparently, give a flying alliterative-thing about basic security, standards, or indeed anything much other than how to look cool. I don’t know why I’m so angry about this, given I don’t own an iPhone, but it’s a further let-down from people who really ought to know better.
These things ought to be a showcase for technology, not a shiny box of stupidity.
Update, Tuesday 24/07/2007: This post and the one above have been linked to by Isode Ltd, my employer, on their blog. This remains my personal blog, though, and is intended to represent solely my personal views, in my own words. I’ve also edited one word that originally was apparently slightly too “colourful” for some corporate filters. I’d say “alliterative-thing filters”, but it’s quite important that people are aware of this.
To be honest, I was expecting to have the time to write this up in a more formal manner, but everything’s moved quite quickly, and contrary so some news reports, email security isn’t my day job anyway, so I’ve not found the time. But although I’ve changed that one word, my sentiments actually remain.
They should have just used TLS to authenticate the phone to the IMAP service (allowiing them to restrict the access ot the IMAP service to iPhones), then done CRAM-MD5 (or PLAIN) to authenticate the user. Idiots.
BTW, as far as I can tell, the iPhone doesn’t support any form of PUSH. It simply polls for messages at configured intervals and/or when user accessing the boxes in the GUI.
Dave, have you actually tried this replay attack? It’s not clear from your post whether this has actually been demonstrated.
As with all security claims: grain of salt until proof of concept.
Yes, of course I have. :-)
I was researching the iPhone’s “push” mechanism with a trace from Kurt Zeilenga’s iPhone, and wondered what error message I’d get from repeating the authentication. Mainly, to prove that the absence of any SASL challenge messages from Yahoo didn’t mean that the mechanism was susceptible to a reply attack. Instead, I gained access to Kurt’s Yahoo account.
Moreover, you can (by doing a Google for XYMPKI) find other people’s traces and telnet session transcripts – this isn’t a new discovery, as such, it’s merely that I realized the implications.
The replay is dependent on the user not changing the password, I believe that the first structured message contains a “sig” component which is the password signed by the certificate.
If they had simply used a IMAP front end onto the Netapp storage of emails and if they wished implemented XYMPKI and SMS updates on top i.e. IMAP4 AUTHENTICATE command to include XYMPKI
couple of questions:
o would that not have worked ?
o did they try and be clever and end up dumb ?
o can they fix this fast ?
[...] seems the iPhone sends its IMAP mail login credentials to Yahoo without encryption, which means if you’re using a public, unencrypted WLAN then anyone can sniff out your login [...]
Hi,
A little off topic, but I work for an embedded VoIP company who interacts with Yahoo! quite a bit – and all I have to say is that you’re ABSOLUTELY correct, “Yahoo! Does! Not! Use! Standards!”. It annoys me nearly every day. just LOOK at their ‘STUN/TURN” servers, let ALONE their SIP over TCP implementation! Anyway.
Nice find, but your tone… So much latent hostility. What’s with all this “cool” and “hip” talk? You act as if security and “coolness” or “hipness” (whatever those terms mean) are mutually exclusive. As if Apple and/or Yahoo literally pulled resources from the security division to beef up the cool/hip division. Like if the iPhone were less cool/hip, it would somehow magically not have this problem. This is faulty logic. If the iPhone were a butt-ugly abomination, this Yahoo Push problem would still exist.
And I don’t think there’s all that much cool/hip about Yahoo…
I found it a bit bizarre, too, when I was researching an article for Macworld.com on iPhone’s networked data security (i.e., what bits can I see over Wi-Fi from an iPhone?) that Yahoo just blithely sends the push stuff in the clear. I mean, authentication without some form of protection is just stupid. And the iPhone tries to use SSL for any new email account you set up, defaulting to that for Gmail and .Mac mail.
Also, Apple has uniquely serialized iPhones. That are operating over many insecure networks. That are being used by average humans. And they don’t appear to have thought about simply installing a unique, revokable, SIM-tied digital certificate into the iPhone. They do this with iChat, for chrissakes, under Mac OS X. You’d think they could do it with the iPhone OS, right? And then you could use certificate-based authentication and other neat mechanisms.
@Kurt Zeilenga
IMAP PUSH on the iPhone is *only* supported for Yahoo.
Otherwise you’re correct.
I can’t wait until they get Linux running on the iPhone… its like a new vulnerability each day, eventually the phone will be owned. :)
[...] iPhone. It seems every few days we hear about shortcomings in the Safari app, lack of fonts or most recently unsecure data transmission with Yahoo! [...]
It took Yahoo! Mail freaking forever to implement ssl on their standard login to Yahoo web-mail. Perhaps Apple will pressure Yahoo on this if they feel the iPhone brand name is vulnerable.
[...] We’ve posted on this at our blog (Link) and the engineer who discovered the problem posts more entertainingly on it on his personal blog (Link). [...]
[...] Here’s a very quick summary from his blog postings: [...]
[...] wireless access point operator to take full control of connected iPhones. No news on whether the replay attack which allows an attacker to access your iPhone-linked Yahoo mail account has been addressed yet. [...]
I wonder if 1.1.1 has brought sanity to this process.
I kinda doubt it.
[...] read more | digg story [...]