Safe Computing | 20 Aug 2008 | Listen   | Print  |

MobileMe Web Interface Insecure, But Other Apps Get It Right

by Rich Mogull

Although the launch of MobileMe wasn't exactly one of Apple's high points in product releases, even the most acerbic of critics grudgingly admits that its Web interface is one of the more well-designed on the market. Unfortunately, MobileMe's Web application is also one of the least secure: Apple allows anyone to listen in to your communications, including the contents of email and calendar updates.

AppleInsider, reporting on MobileMe on 15-Aug-08, attempted to assuage concerns that the MobileMe Web interface does not use SSL encryption to protect connections from malicious sniffing or hijacking. They stated SSL was unnecessary because:

"Data transaction security in MobileMe's web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple's cloud, rather than the SSL web page encryption used by HTTPS. The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication. This has caused some unnecessary panic among web users who have equated their browser's SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.

"If Apple applied SSL encryption in the browser, it would only slow down every data exchange without really improving security, and instead only provide pundits with a false sense of security that distracts from real security threats."

This is, alas, patently false. Those of you who are Star Trek fans are familiar with the term "technobabble," the fictional, technology-laden lines uttered by actors to give the appearance of scientific accuracy. Just as "altering shield frequencies in harmonic resonance with the Klingon's tachyon beams" is a load of poppycock that sounds authentic, so is "Data transaction security in MobileMe's web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple's cloud." That just means that you log in, and JavaScript is used to handle communications with MobileMe; there's no security magic in there.

As reported by Jens Alfke at the Thought Palace blog, although your initial login to MobileMe is encrypted, the rest of your session is transmitted in plain text. If anyone on your network decides they want to sniff your connection and read your email, there's nothing to stop them.

What AppleInsider's statement boils down to is, "Apple checks that you're a real user when you log in; everything else is sent in the clear between your browser and their servers; and we think SSL would bog down performance without improving security." They couldn't be more wrong about that last conclusion.

You (Should) Get What You Pay For -- To be fair, Yahoo Mail and Hotmail also fail to use SSL beyond your initial log in, while Google only recently added complete-session SSL to Gmail as an option. But that's no excuse for Apple's decision. Yahoo Mail and Hotmail are free services, while we pay $99 per year for MobileMe. Call me demanding, but I expect more from a commercial service. Google now offers SSL for free, and it's almost always an option (or default) for commercial Web services offering mail.

There's also another subtle, but important, flaw in Apple's handling of user authentication. As noted by Alfke, the secure authentication page points to auth.apple.com while the rest of MobileMe uses the domain me.com. By breaking the bond between the digital certificate used by SSL to verify a domain, and the domain where most of the interaction takes place, users are vulnerable to redirection attacks as highlighted by the recent DNS vulnerability (see "Apple Fails to Patch Critical Exploited DNS Flaw", 2008-07-24). DNS can also be poisoned on a local network, where an attacker floods a network with responses for non-secure domains: say, a hotspot where you're logging in.

A bad guy can hijack the me.com domain temporarily and redirect you to a malicious site without affecting your login experience, since you will still be authenticating to the unaffected apple.com domain. While I doubt many bad guys will completely replicate the MobileMe Web interface, a common attack method (and one I demonstrated using Wi-Fi at the recent DefCon hacker conference) is to redirect you to a malicious Web page, which quickly attacks your Mac and then forwards you back to the real me.com before you notice.

Securing an entire session with SSL does not "slow down every data exchange without really improving security." Because MobileMe is a Web-based application, you're not waiting for page refreshes, but for very small amounts of data to pass back and forth. (The JSON mentioned in the gobbledygook paragraph earlier is a format for lightweight JavaScript objects, in fact.)

(Apple does mark its authentication cookie, stored in the browser, with a secure flag. This token, which is used to maintain a persistent logged-in state, is only sent to auth.apple.com via SSL. This avoids sidejacking, a technique that formerly worked with Gmail and other Google services until the company wised up and made sure tokens were as protected as passwords. See "Sidejack Attack Jimmies Open Gmail, Other Services," 2007-08-27.)

Good News, And Protecting Yourself -- While there's a reasonable, if small, risk someone might sniff your connection when you are out in public, the odds of a redirection attack are extremely low. And although MobileMe's Web interface is essentially insecure, the other MobileMe services (except iDisk) are properly protected.

When you set up your MobileMe email account, it defaults to a secure connection, and in testing iCal, I found both the push and manual synchronization process appears to use SSL. Using a sniffer on my own system, I was unable to access the contents of any synchronizing calendar entries or email. iChat authentication is also secure, and MobileMe installs digital certificates to enable secure chats with other iChat users - unlike AOL Instant Messenger and many other free instant messaging options. Note that if you use iChat with MobileMe encryption enabled, but you correspond with an insecure AIM user, that iChat connection is still insecure.

Although I don't need to use it often, since I'm never far from my Mac or iPhone, I love the new MobileMe Web interface. But since I'm most likely to use it on insecure systems and networks, like Internet cafes when traveling internationally, I'll have to skip the convenience and stick with more secure options until Apple decides to support SSL properly.

-

Related Articles

• Apple Fails to Patch Critical Exploited DNS Flaw (24 Jul 08)
• Sidejack Attack Jimmies Open Gmail, Other Services (27 Aug 07)

Top Articles in this Section

• Security Tips For Safe Online Holiday Shopping (26 Nov 08)
• AnchorFree Offers Free VPN for iPhone (24 Nov 08)
• Are Safari's New Anti-Phishing Features Useful? (18 Nov 08)

It's time to speak up with MacSpeech Dictate! Get the all-new
MacSpeech Dictate with spelling and phrase training. Speech
Recognition so good, about the only thing it can't do is
speak for you. Find out more at <http://www.macspeech.com/>