A Lesson in Web Application Security Part 2

**Read Part 1 to get the full picture of post**

Notice that there is no user confirmation that the phone number is correct and that I really do want to receive the results via SMS especially because receiving the results comes at a cost of B$3.00! Yes it does give a cancellation code which I could have sent back to not receive the results SMS. The delay between the 2 SMS’s was 3 minutes which is ample time to send a reply, if you are actively checking your phone.

Exploit #1: Overwhelming a single person with many result SMS, and having them be charged at $3.00 a piece. If the person is using a prepaid plan, you could effectively use all their credit creating a denial of service attack. If they are using a post paid account they could just rack up the charges.

Solution: Request users to send a confirmation SMS saying they do indeed want to receive the results.

Taking things a bit further I tried a few things like putting invalid data. Good enough they did validation of the data I put in.

Validation error

After some investigation I found that the problem of this validation is that lies solely on the fact that they used Javascript alone to do the validation check. Javascript being a client side processing means that it can be subject to change. Firefox users have Greasemonkey and Opera users have user scripts. Or you can do what I did and view the source of the page, copy it to a local file, make the necessary changes to the source, load it up without validation checks and send the form on. And what did I do? I registered a my friend’s foreign mobile phone number. My friend confirmed that he received the results SMS despite the fact that he is not in Brunei. This leads to exploit #2 which could effectively rack up foreign SMS charges to SMS gateway that is providing this service.

Exploit #2: By pass client side validation of data

Solution: Use server side validation of data, in this case in the PHP code

This exploit relies on the fact that the application assumes that the information it receives is valid data. This should never be the case. You cannot assume that the user will input the correct information, you must sanitize the data accordingly to ensure that you only have valid data in your application. It is things like this that lead to SQL injection which could cause catastrophic results on your server and even information theft. So whenever designing and implementing any system, you as a developer should do you job properly and factor this in and ensure your application does not suffer from this flaw.

 

PS. This being my first vulnerability disclosure was indeed an experience but and it didn’t go too well I have to say. After I emailed them regarding this issue they didn’t even get back to me. I had to call them up 2 weeks after that to ask if they got it and apparently my email just happened to disappear somewhere. Go figure… So the guy I was talking to gave me his direct email address and he thanked me for my input saying that there are some things that they could change and some things they couldn’t. After another month and 2 emails I sent asking for updates, there was still no word from them. But 3rd times a charm and I finally got a reply saying that they fixed some of the Javascript. Despite that not being the best solution I felt I had waiting long enough and came to disclose the problem. It’s not even a hard fix to implement. Oh well. I shall wait for a reply from the next organization who I sent another security concern too. So far no reply after 3 days.. So I wait….

A Lesson in Web Application Security Part 1

So it was today that the ‘O’, ‘AS’ & ‘A’ Level Results came out and in the recent days before, it was pretty well advertised that students could get the results by SMS. So when I heard word that the results were out I went to the Registration page to be greeted with a pretty, how would I put it, not so aesthetically pleasing site. Yes I know functionality is what is important and I do personally believe in that and I know my skills in design need a lot of work but come on people!

screenshot of SMS registration site
The site in question

So I decide to take a look around and see how they handle the registration of users….

Step 1: Input Details
Input details

Step 2: Confirmation
Confirmation

Step 3: Nothing, we’re done!
Nothing, we're done!

It does state that registration is free which is good however they was a huge flaw in the design process of this registration. As shown in the next 2 steps:

Step 4: Receive Confirmation SMS
Registration for BN123 4321 CANDIDATE NAME is successful.
To cancel the registration, type MOE CANCEL 98765 and
send to 8885555

Step 5: Receive Results SMS
O LEVEL RESULT 2008
Exam Center: BN123
Candidate Index: 4321
A.M = A
B.M = A
BIO = A
CHE = A
COM = A
ENG = A
MAT = A
PHY = A
RSLT = 8 0

–Update: Actual candidate name and results changed for illustration purposes

Part 2 will be released once Mach Telecommunications Systems fixes the exploits in question (or if they don’t do anything about it, forcing me to release it)

Update: Read Part 2 here