Via mailchannels.com -
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.
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.
No comments:
Post a Comment