Update: O2 Leaking Customer Photos

If you rely on secret URLs as a security mechanism, you should make sure your logs are not public.

On Thursday I posted a blog entry related to the security around O2’s MMS Messaging service. My key point was that O2 were not authenticating the user and relied on URLs with hex strings to access MMS messages. Several people pointed out that URLs were adequate security given the hex strings were 64-bit keys so they couldn’t be guessed. I did not disclose the full extent of the leak as it would have allowed access to non-indexed MMS messages and I wanted to give O2 a chance to fix this more serious problem first.

Note: We have made O2 aware of this more serious problem and because O2 has now taken its multimedia servers off-line, the vulnerability described in this post no longer exists.

Update: On Tuesday I received a response from O2:

Your details were forwarded to our project team who we believe have put a temporary fix in place at present. I’m unable to tell you when a permanent fix to this issue will be implemented. I would like to thank you for your feedback.

Here’s how the attack works – Lets say a customer has a new iPhone 3G. The iPhone 3G doesn’t support MMS messages, so if someone sends a MMS message to that customer they receive a notification to view it on O2’s media server. The link to the media server is a private URL with a hex string, so when it’s clicked on, an HTTP GET request is sent to the web server to retrieve the audio/image/video. This would appear to be secure, as someone would be more likely to win the lottery than guess the key. However, the private URL isn’t so private when it’s publicly available on the O2 web server.

The web server providing the MMS messages uses mod_jk with JBoss/Tomcat and the default security settings are minimal. There’s an information disclosure vulnerability if the Status Page isn’t locked down. The status page contains lots of system information such as the memory usage, data processed and discloses the URL’s of the HTTP Requests to the server. As O2 failed to lock down the status page it was public and anyone could see which URL’s were currently being handled in a web browser.

Here’s a snapshot of the O2 Status Page I took where the HTTP GET requests were made available as well as the IP address of the client accessing the content. Once the URL is known the audio/image/video being viewed and the persons phone number are disclosed. Note: I’ve hidden most of the data but you can see where the GET requests would have been available.

The mediamessaging.o2.co.uk server is now back online and the status page is no longer viewable.

In the past year there have been 2 security issues with O2’s infrastructure linked to URL’s, although in these cases the URL flaw was much easier to exploit. Last February, the following Bluebook issue was reported:

Coding errors in Bluebook created a means for registered users to view other user’s messages (and phone numbers) simply by changing the message ID number in URLs used to access messages on the site. In a statement, the mobile phone giant said that it has fixed the problem.

Last September, it was an issue with the Billing System:

Using the loophole in the site, it would have been possible to write a script to pull a list of mobile phone numbers assigned to particular firms, along with details of the calls made using those numbers over the last three months. In most cases, the name and department of the person making calls was also readily available.[…] Russell was able to access this information through a simple URL manipulation that allowed him to elevate his privileges to view information on the site.