Security case study: Hole in SMS spam websites allows charges to arbitrary mobile numbers

The Web 2.0 paradigm opens a new web programming model. However, new programming models are all prone to developer incompetence:
Old model:
Client <--> Server <--> Database

New model:
Client <--> Server
\--> Database
The problem, of course, is that the database is now another source of entry. You need to remember: if a client is making a request to your server, you need to scrutinize that request... every time.

The SMS spam website is one of these:

After going through the quiz, your browser is requested to load a script like this:!&MessageVer=Haha&MessageATT=Haha

Which loads something like this:
var Provider='tmobile'; var Code=1777; var LoversName='CHARLIE'; var IQ='85'; var Origin=''; var Meaning=''; var Tester1 = '987'; var Tester2 = '7555'; var Tester3 = '987';
You can use this Web API to learn the service provider for any phone number in the US (works for most numbers):
Phone number:
(do not use dashes here)
After you get that page, read the var Provider='...' part. If that's a Sprint number, you can call 888-211-4727 to see how many minutes were used by that phone number in the past month.

If you had used a URL like the above for your first request, you would also get a: Code=### part. That code could be inputted in to a page like this:
<form action="" method="post" name="form1" onsubmit="Validate(txtPin)">
<input id="Service" name="Service" value="WEEKLY_TRIVIA_44999_999" type="hidden">
<input id="Shortcode" name="Shortcode" value="44999" type="hidden">
<input id="Provider" name="Provider" value="" type="hidden">
<input id="RealPin" name="RealPin" value="" type="hidden">
<input id="Portal" name="Portal" value="" type="hidden">
<input id="LoversName" name="LoversName" value="" type="hidden">
<input id="IQ" name="IQ" value="" type="hidden">
<input id="Origin" name="Origin" value="" type="hidden">

<input id="Meaning" name="Meaning" value="" type="hidden">
<input id="fPin" maxlength="5" name="txtPin" type="hidden">
Now... I'm not giving you the full details to run this request. See update below. But, if you followed through, the result is a simple Web API that allows you to charge money on the phone bill of arbitrary mobile phone users. That's what I call a failure in security.

(Update 2010-01-02, cleaned up URLs and copyediting)
Also, I was ready to post a full exploit today, but it seams like they have cleaned up their act a little. Also, the first page still works.


ING Direct communication case study: How to successfully implement paperless billing

I have seen paperless billing implemented poorly many times... which is a shame because a little time invested in the IT department could save a lot of time and money in the mailing department.

There's a lot of things you can do with a real (paper) bill that you can't do with an e-bill. When banks realize this and compensate for shortcomings, customers will be more willing to accept e-bills.

1. You can be confident in the arrival of a real bill.
When an e-bill is released, the bank sends you an email. If the you do not receive the email, or you don't open it, the bank should promise the to MAIL A PAPER COPY. Then you can be 100% sure you will get the bill.

2. Before you pay a bill, you can keep it on your desk, as a reminder to pay.
Banks should keep your e-bills available on a website and should show you whether you have viewed the bill or not. The bank should also allow you to mark the e-bill as "unread". This is similar to an email inbox, and mimics the function of the real bill on the desk:

3. Real bills are legal evidence in court.
... and this is comforting to know. A PDF e-bill file can be edited to make your balance $10 million and  this is 100% indistinguishable from a legitemate bank e-bill (when printed). Banks should provide verifiable digital signatures (PDF signature, or PGP). Not all customers will understand how this technology works, but the bank need only briefly explain the technology and that this computer file is a legal and verifiable document.

4. Real bills are convenient.
... you open the envelope and WHAM, there it is. There's no logging in. There's no user names. Banks should offer to send e-bills as a direct email attachment. Naturally, these attachments would be encrypted. And since computer encryption is only for advanced users, this should be only be an option. I would recommend: upload a public key and attachments are mailed to you, encrypted against that key.


Here are two examples poorly execution of e-bill systems: ING Direct and Chase:

The lessons are from these failures are:
  • e-bills are saving you the banks LOTS of money. Don't litter these pages with ads or useless links.
  • e-bills are not the standard and require user buy-in. Make it easy and inviting to use. Don't require users to cancel paper billing to try the e-bill feature.