Guest blog: How an SMS exposed Virgin Mobile’s website

"Thomas Milne, a test engineer in our Vancouver offices, stumbled across a security hole on Virgin Mobile’s website last week. He informed them of the problem which, fortunately, they’ve now fixed. Now you can hear what happened from his point of view. Over to you Thomas.."

Thomas Milne

My favorite memories from days out on the beach was never the building of a big, intricate sandcastle – it was always stomping it to pieces afterwards.

I’ve always approached software with the same kind of mindset, and this is probably why I’ve found myself working in quality assurance.

This sandcastle stomping mindset can be addictive. It often leads to stumbling into all sorts of interesting things when you’re not looking for them – this blog post is about one I found recently, with my mobile phone provider.

It all began when they sent me a rather boring (and more than a little spammy sounding) SMS text message to my cellphone:

Want front row tickets to So You Think You Can Dance? Click, then select 'My Hot Deals':

Here’s a photograph I took of that SMS message:

Not really my cup of tea but I know some people who might enjoy it. Plus, it might be entertaining… yeah, why not? I’ll have a peek.

You what now? I’m not using a phone, this is a desktop… I wonder what’s going on here. What if I go one level up?

At this point I’m getting the sense that something really isn’t right. What on earth is a MIN? The error message said something about missing phone identification. Guess I’ll throw my phone number in here then?

And there it was – I’m looking at the same thing that I see when I press the ‘My Account’ button on my phone. This worried me a bit- did this mean all it took was a phone number to access an account? I asked if any of my co-workers were on the same network and soon found one that was. And yes, we could access hers too.

So every customer’s account was wide open, using only their phone number. Once inside you could view & change their phone plan, spend their top-up credit on things they didn’t want, and generally do things you shouldn’t be able to. Seeing as this is Graham’s blog I’ll keep it polite and simply say that this came as an ‘unpleasant surprise’ to me.

On the plus side, the interface prompts for a PIN before charging a customer’s credit card, and nor is any personally identifiable data accessible from these accounts. Furthermore the company took the disclosure of this fairly seriously and had it fixed after a few hours.

As much as this might seem like a one off huge mistake that could never happen to any company that takes security seriously, the sad truth is that situations like this aren’t very far fetched. Now I don’t have all the details and am speculating here, but it looks like this breach was because of two very common mistakes that when combined made this possible.

Here’s what I think went wrong.

Firstly – access rules as a single point of failure. When running a server, firewall and access rules are critically important and not to be taken lightly, but they do not solve all your security problems. They 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- remember, there was no authentication at all.

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.

Secondly – test code on production systems. The MIN entry page looks suspiciously like a test page used internally for troubleshooting. Test code like that can be very useful when developing or troubleshooting but should stay firmly outside of the realm of customer facing servers and production systems.

While most people recognize these failings as ‘bad things’, all too often they treat them as best practices rather than rules, and exceptions are made for the sake of convenience. Events like this should serve as a reminder to be careful where you make them.