Rui CarmoUpdate (2008-02-05): Got a template reply back from Apple stating: Regarding the issue you reported, after further investigation it has been determined that this is a known issue. We take any report of a potential security issue very seriously. It is being addressed, and we would like to thank you for taking the time to pass it along to us. No name on the signature, though, but at least it’s been confirmed as a dupe and this page now serves as corroboration of their acknowledgement. “#5722062”:Radar:5722062 was closed as a duplicate, indicating “#4370291”:Radar:4370291 as the original report.
Update (2008-02-03): Filed “#5722062”:Radar:5722062 because I was tired of having people ask me about this and whether I had any feedback from Apple (I didn’t file it before because it was apparently filed by a number of other people back in ’06, and closed on them without any feedback).
Update (2007-11-17): The situation hasn’t changed in Leopard, other than a new
User-Agentstring (WebDAVFS/1.5 (01508000) Darwin/9.1.0 (Power Macintosh)) – iDisk still does not use SSL, and authentication methods seem to be precisely the same.
I’ve written about this more than once in the past, but I was catching up on BUGTRAQ and going over a few pieces on Ajax and HTTP session hijacking techniques (some of which I had flagged for further study after that George Ou piece hit the fan a couple of weeks ago), so I decided to take a look at my iDisk traffic using Wireshark.
Took me a good while to get around to it, because you need a wired connection to do proper sniffing and nearly all my Macs are wireless these days – but today I found the time and motivation to do it, since I also needed to sniff Yaki HTTP traffic to watch session cookies and gzip compression at work.
After all, some day Yaki is going to have a web UI of some sort, and I want to make sure it isn’t trivially exploitable.
But let’s get back to iDisk. First, the good news: Apple still uses digest authentication on iDisk’s WebDAV, which means that your password isn’t transferred in the clear.
The bad news is that all of your iDisk traffic still goes unencrypted over the wire, which means that if you use public Wi-Fi hotspots or are in a campus LAN, anyone can not only see what files you’re accessing, but also copy the entire file content for themselves.
But don’t take my word for it: Grab Wireshark (it’s available in MacPorts, and you need X11 to run it), set it to capture traffic to and from idisk.apple.com (set the filter to host 17.250.248.77), and have a look for yourself:
As you can see, all the filenames you read or write and all the data associated with them go over the wire in plain sight – all you need is the trivial knowledge of how to look at it – readily available, including plenty of graphical tools, to any bored teenager within Wi-Fi range.
And I haven’t even begun to scratch the surface. And I won’t – there is enough “non-news” regarding Mac OS X security as is, and I’ll just stick to the plainly obvious facts that anyone can reproduce by themselves.
In case you’re a reporter looking for fodder for your latest silly season piece, keep in mind that this has been going on ever since we got iDisk – it isn’t news, merely a renewed note of caution regarding something that Apple needs to fix.
So last year’s piece of advice still stands: don’t use your iDisk for storing sensitive data.
And pray that the noises about techniques for exploiting weak nonces in HTTP digest authentication don’t pan out into actual pre-packaged, 1-click utilities, otherwise your .Mac password is sure to become toast as well.
This doesn’t mean (in any way) that .Mac is insecure as a whole, but iDisk is an unacceptably weak point that is often on by default, and people use it without any care in the world.
Me, I’ve had it off by default for ages now.
Not to mention that this goes a long way towards cementing my current impression that 10GB of insecure storage for US$99/year isn’t that good a bargain.