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

Image

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.

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   = "61.6.207.177" ;
    NV1.MediaUserName = "Admin" ;
    NV1.MediaPassword = "123456" ;
    NV1.Httpport      = 80 ;
    NV1.RegisterPort  = 6000 ;
    NV1.ControlPort   = 6001 ;
    NV1.StreamingPort = 6002 ;
    NV1.MulticastPort = 5000 ;

    NV1.ASEMediaSource   =  "202.160.45.35";
    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 http://61.6.207.177/cgi-bin/system?USER=Admin&PWD=123456&SYSTEM_INFO) on the server and retrieve (and possibly even change) information on webcam. Also noticing the Httpport variable I tried visiting the webcam IP (http://61.6.207.177) 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 paypal.com or facebook.com 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.