[ insider_reports_insider ]
Lessons Learned From Virgin’s Glaring Vulnerability
SecurityProNews
Staff Writer
2009-02-03
 Insider Reports RSS Feed
A customer-facing vulnerability at Virgin Mobile's website could have allowed anyone with knowledge of another person's mobile number to make account changes. Fortunately, beyond a Virgin coders' giant security hole embarrassment, this can be what they call a teachable moment.
 | | Lessons Learned From Virgin's Glaring Vulnerability |  |
Sophos test engineer Thomas Milne narrates how an SMS message advertising tickets to "So You Think You Can Dance" led to the ability to alter any Virgin Mobile customer's account. Finding the screen from where this could be done required a bit more than the commitment of an average consumer, though.
Normally an log-in error screen, even with the phrase "phone identification missing" would send an average user toward the back button, the navigation failure quickly forgotten or marked as typical spam.
A security researcher (or perhaps a hacker, or mischief-maker) has more skills than that and simply went "one level up," which meant basically subtracting a URL parameter. Presented with an ambiguous MIN: and field to fill out, Milne did some quick guesswork by inserting his mobile phone number.
This gave him access to his mobile account. He tested again with a colleague's number and achieved the same results. You'll be happy to know (if a Virgin Mobile customer) he contacted Virgin and the problem's been resolved.
Milne finished his blog post with a quick tutorial about how such a glaring vulnerability was left Web-side and how companies can prevent these things in the future:
[Firewall and access rules are often quite complicated and all it takes is one person to one one mistake when updating the rules to leave you wide open. Simply assuming that ‘a customer would never see this!' is not enough…
"A more secure approach might be to have something inside the phone's browser that sends an account-specific custom key in the http headers when it talks to the account server. The server could then check for this when authenticating the connection, making sure that the key connection came from the the account holder's phone. Making sure this transaction all happened in HTTPS instead of HTTP would also be a good idea. Throw in some user agent verification on top, and you've got something that would be a little more robust."
He also advised making sure test pages are never placed on customer-facing servers.
About the Author:
SecurityProNews is a daily online and email publication focusing on internet security issues.
More insider_reports_insider Articles
Insider Reports RSS Feed
|
|
iEntry 10th Anniversary
RSS
Archive
