UPDATE: The developers removed the send to a friend functionality!
There I was using a mobile site that allowed you to send the page you are on to a friend (by SMS). Upon closer inspection it had a huge security hole, it was a hole that each time it was exploited cost approximately 15 to 20 cents. It was also easy to change the destination mobile number allowing it to be used as a denial of service attack on a single number or to spam a range of numbers. It was repeatable and easily scriptable. NOTE I disclosed this to the company responsible, I didn’t even get a response.
It was like designed a web site in 1995… except it was a web site in 2007 – and actually cost money every time it was exploited.
Let’s put a cost on it.
1 exploit every second
= 60 exploits per minute
= 3600 exploits per hour
= run for 15 hours from 6pm to 9 am when its discovered = 54,000 exploits.
= $10,800 @ 20c per SMS exploit
It’s not the end of the world…unless the site can actually handle 100 exploits per second, then its a million dollar exploit, ouch.
It looked like this:
You simply change the destination number and off the SMS went on its way to the number you entered.
So how do you fix it?
Check http parameters
Never trust client http parameters, they can be changed, sometimes simply by re-writing a URL in the browser. Don’t think that because its on a mobile it’s somehow secure. Mobiles are computers and they while it’s a little harder to find out what they are up to while at a website its often just a menu button away. In this case the senders number could also be changed thereby allowing the one piece of evidence of the hackers identity to also be masked. The senders number should not be seen in the URL, it should be part of the session back on the server. If the hacker knew their number was on record they might be a little less inclined to exploit this loop hole – but they probably stole the SIM anyway.
Throttle the connection
Another thing to do is record the time and destination of the ‘send to a friend’ message to send. And only allow a few, say 5, in the last 24 hours. This minimises the exploit to 5 messages per day which any script kiddie will get bored of very quickly.
Use a captcha
Finally use a captha to stop scripts from exploiting the loop hole. This is the only addition that would have real impact on the user experience and if a numbers only captcha was used I think most consumers wouldn’t mind.