Forms and Trust

I was forwarded a link to BELIA BRUNEI BERBAKTI – “Wira Kebajikan” a.k.a. Devoted Bruneian Youth – “Heroes of Welfare” (thanks Brunei Times for the translation in this article) and it seems that they have a good intentions but after all the NSA prism stories and the general rise in privacy awareness, we should be careful about the data we give away.

Part of their sign-up form is shown below and part of the required details are:

  • Gender
  • Full Name
  • Date of Birth
  • Age
  • IC Number
  • IC Colour
  • Address
  • Phone Number


I’m personally not comfortable giving away so much details to an organisation that I know little about. But it also raises the question of why is all this information necessary? Perhaps some transparency as to why all these details are necessary. I under the reason for name, gender and contact details but not the rest.

I also wonder if I’m more averse to this because it is an online form. If it were a physical form, I think I would be more accepting (I possibly have even given up such details before in the past without thinking too much of it). Note to self: when organising future events be transparent with details.

HSBC Phishing Email

A few days ago I got an email from HSBC Bank regarding my online Internet Banking account, saying that it was locked and that I could go down to a branch to unlock it or fill in the online form to unlock it. Initially I didn’t think much of it until I was about to go to HSBC and I decided to check whether my Internet Banking account was locked. I logged in without issue and grew suspicious of the email I had received earlier. I re-read email I found that it was a phishing email trying to steal my login credentials via the online form that was attached to the email. Below I will detail a few things that help you identify phishing emails or forms

Below is the received phishing letter and the accompanying update form. Now email with an attached form is always suspicious because you can never really trust anything you receive.

HSBC Phishing Email
HSBC Phishing Email
HSBC Phishing Email's Update Form
HSBC Phishing Email's Update Form

Now to inspect any HTML file or even a website you should always view the source code of the file. Search through the menu items and look for the “View Source” menu item. Below shows how to view source in Google Chrome (For Firefox: View > Page Source)

HSBC Phishing Email - Update Form - View Source
HSBC Phishing Email - Update Form - View Source

Viewing the source code will show you what makes up the webpage you are viewing. For any form that you fill in you should look for the “FORM” tag and in particular the “action” attribute/value as the “action” attribute/value dictates where the data will be sent. The screenshot below shows the source of the ‘Update Form’ attached to the email and as you can see the website that the data is being sent to ( doesn’t seem to be a website that has anything with HSBC. Another thing to take note of is that the url has no “https” in the address that it is sending the form. All banking sites should be sending data via https (e.g. not as HTTPS connections are encrypted (HTTPS server certificates must also be originating from a trusted source, e.g. the bank itself, in order to ensure that the encryption is between a trusted source and not a random malicious hacker’s computer/server).

HSBC Phishing Email - Update Form Source - Action Field
HSBC Phishing Email - Update Form Source - Action Field

Some other notifications that the email was suspicious:

  1. The phishing email “from” field is different from the regular HSBC “from” field (correct: HSBC Brunei, fake: HSBC Bank)
    HSBC Phishing Email - Fake Name
    HSBC Phishing Email - Fake Name

  2. The email they used does not original from or (and going to the website gives a non-existent website)
    HSBC Phishing Email - Fake Email
    HSBC Phishing Email - Fake Email

Note: these 2 notifications can actually be faked to look like the real thing and if they are correct they are not an indication that the email is authentic.

Ways to prevent being a victim of phishing emails

  1. Never blindly trust any emails you receive
  2. Do not fill in any forms without first checking it out properly (view source to make sure it is sending data to a trusted location, ensure https so the data is encrypted and cannot be sniffed)
  3. Do not click any links in an email as a link can display a URL direct you to another (e.g. this link should go to not
  4. Manually type in the bank’s website to go to the Internet banking website (try using https in the address rather than http)

Now despite all this, there can always be security issues that enable hackers to exploit to make things even harder for us to identify fake websites / phishing emails. These tips are not a surefire way to ensure you do not get phished but hopefully the information I’ve shared will help you identify some characteristics of phishing emails so you can protect yourself and help inform others

Is Your Biometric/Card Reader Secure?

If you bought one of that looks like the picture below, I would say it’s not secure. I have a contact (RFID) card that works for a card reader shown below in a certain organization A. One day I saw the exact same model in a different and totally unrelated organization B. Out of curiosity I tried the card I had and was shocked to find out that it actually worked. So for organizations that are using these type of reader or any off the shelf reader/system do read on to understand how this security issue has arisen.

Biometric Reader / Card Reader:
biometric card reader

Biometric Reader / Card Display:
biometric card reader display

The readers have onboard memory to store information of the cards that it allows access to. It stores “Account No” and the name associated to that account number. The pack of RFID cards supplied with the reader (or bought at a later date) can be programmed with a specific Account Number. A central control software for the reader is used to upload new account numbers to each reader.

After some investigation the data field that was being check to grant or deny access was the “Account No” field. When I put my card on the reader in organization A it displays this Account Number and my name associated to it but when I tried it on organization B’s reader it just showed the Account Number without my name. Data is loaded into the readers via some control software that uploads the data into the reader’s memory storing account numbers and names associated to the account number: this explains the lack of my name in organization B’s reader. Technically this Account Number can be changed but it can only be numbers with a maximum of 5 digits and there can always be a possibility of collisions.

There is no quick fix or sure-fire solution to this security issue with the current implementation if the reader only uses the Account Number for authentication (I do not have access to the hardware to see if there are different and more secure authentication methods available). The reader firmware could be upgraded to recognize the serial number for each card (as each card manufactured should have a unique serial number) and this would prevent collisions and unauthorized access assuming cards have all unique serial numbers. If serial number storage is too memory consuming for the reader, alternatively another piece of information e.g. a passphrase could be used to have 2 factor authentication. The reader can store one copy of this passphrase and use the existing current “Account No” for authentication via 2 different pieces of information. This would make things much harder for collisions and unauthorized access to occur. This is certainly not fool-proof but it makes things much more difficult to gain unauthorized access.

So next time be wary of (cheap) off-the-shelf security solutions, it may not provide the full security you think you’re getting.

Note: The model that was affected was the ZKSoftware A11 however I would think anything that uses the ZKSoftware or has the similar display user interface would be affected.

More Lessons in Web Security / Best Practices

So one day I was browsing the Brunet homepage and saw the link to Live Webcams around Brunei, interested I clicked the link only to be greeted with the following meaningless page in Firefox.

Page view in Firefox

So thinking they implemented some IE specific page I loaded up IE and was prompted to install an Active X control. I looked at the source code of the page to figure out what it was using and was interested in what I saw

    NV1.MediaSource   = "" ;
    NV1.MediaUserName = "Admin" ;
    NV1.MediaPassword = "123456" ;
    NV1.Httpport      = 80 ;
    NV1.RegisterPort  = 6000 ;
    NV1.ControlPort   = 6001 ;
    NV1.StreamingPort = 6002 ;
    NV1.MulticastPort = 5000 ;

    NV1.ASEMediaSource   =  "";
    NV1.ASEMediaUserName =  "Admin";
    NV1.ASEMediaPassword =  "123456";
    NV1.ASEControlPort   =  6001;
    NV1.ASEStreamingPort =  6002;

IP addresses and user credentials… So decided to do some more exploring and found out the code is basically some copy-paste work done from ACTi documentation on their IP webcams. Found out they have freely available tools to interact with the web cams themselves. While some utilities only allow scanning web cams on the same network I found that the Snapshot utility allowed me to specify the IP addresses and user credentials and was able to generate snapshots at specific intervals. I wish they used this instead of the live streaming webcam option as it helps save on the bandwidth and makes it much more accessible from any browser that supports images, but then they’ll have to run the application on a Windows server. Oh well

After some more poking around on the ACTi site and the documentation for their webcam’s API I found out that you could visit a specific URL (eg on the server and retrieve (and possibly even change) information on webcam. Also noticing the Httpport variable I tried visiting the webcam IP ( and was greeted by the web configuration page as shown below.

Web cam web configuration page

Entering the Admin user name and password I was given full reign on the configurations of the webcam including specifying new users and even changing the password of the Admin user itself, thus rendering all the webcam pages useless. So I email the people over at Brunei via the contacts page and got no responses. Called them up the following week and the lady on the phone said she’d refer me to a technician and that I should just wait for a call from them. A few hours later I got a call from a technician seeking to clarify this problem I found and thanked me for my mail and the next day when I checked the webcam pages it was all rectified! Nice swift work people at Brunet. A round of applause.

Lessons to be learnt:

  1. Change your default settings/password/user credentials: obvious as it is, quite a few places in Brunei that have free wireless, have not changed their passwords. Using a default passwords page found easily online can easily allow any unauthorized users to change settings and even deny users access to the service or possible DNS spoof users (meaning that even if your browser says you’re on or it could still be a malicious site that farms your user credentials as it points a different IP address altogether).
  2. Understand what you are doing and the security concerns that will arise. In this case, don’t just copy and paste code, see that all is working and be done with it. Analyzing the code clearly shows an administrator login. Understand that any visitor to the page can view the source and see this user credentials. I guess the fact that when people see that it works they can’t be bothered about fiddling with it, in fear of screwing things up. Another scenario would be when somebody wires up their wireless router, switches on the power and all of a sudden they can surf wirelessly they don’t care about setting a wireless password, let alone changing the router configuration password. The old saying “if it ain’t broke, don’t fix it”, just doesn’t work in security(software/ firmware/ hardware needs to be updated to fix security vulnerabilities)

These are just a few simple lessons that we can learn but in the field of computer security there is so much more to be afraid of and we as users need to be more knowledgeable. Places you can start would be Security Now and for the slightly more enthused/technical PaulDotCom Security Weekly. For the more layman kind of person do check out Security Now transcripts, show notes and old episodes as they are very useful. Both these shows are podcasts which in essence is like recorded video or audio that you can watch or listen to anytime you wish: consume the shows you want, at your own viewing pleasure – anytime, anywhere. All you need is a computer, or for audio shows: an audio/MP3 player, for video shows: a video player. A misconception is that iPods are needed to listen/watch podcasts, and that is just plain WRONG. At the least you can use your computer to listen or watch them.

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

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
Exam Center: BN123
Candidate Index: 4321
A.M = A
B.M = 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