In case my readers haven’t noticed, I’ve changed the tagline of the blog from “A blog about Information Security, Cryptography, and Privacy” to “A blog about Information Security, Privacy, and Ethical Hacking”. If you don’t see it, try clearing your browser cache.

The reason for this small change in direction is threefold:

1. When I started this blog a couple of years ago, cryptography was one of my main interests. These days, whilst I still like reading up on advances in cryptography, I don’t find it as interesting as other aspects of information security.
2. Cryptography itself can be seen as a big part of “Information Security”, so it seemed pointless to effectively include it twice in the tagline.
3. I’ve worked as a penetration tester for almost 6 months now, so ethical hacking is now something I am focusing on and wanting to write about more.

So I’m going to start a small series of simple but detailed tutorials on various skills required when penetration testing. They will range from basic usage of nmap/nessus/metasploit to the more advanced cracking of stolen hashes and attacking web applications. If people have suggestions for other tutorials, be sure to contact me and I’ll do my best to put one together.

I will shortly be getting back to more regular blogging on security issues, but I thought I would inform the readers of my blog that recently I was awarded an MSc in Information Security from Royal Holloway, University of London. I was working on it for the past two years, and am happy to announce that I received a “Pass with Distinction”, the highest grade possible.

Last night I was also informed that my MSc Project (on Fuzz testing Web Applications) received a SearchSecurity.co.UK award for being of “outstanding quality”.

That’s all the personal news for now. I’ve been very busy at work over the past two months, so I have had less time to do personal projects like updating this blog.  As Christmas nears, I’ll have more time for these sorts of things. For now, thanks for reading!

This hasn’t been a good week for Google Wallet, the mobile app that stores your credit cards so you can easily make payments with your phone. Yesterday, zvelo engineer Joshua Rubin revealed that the 4-digit PIN used to authenticate users of the app is stored as a SHA256 hash on the device, and this hash is easily obtained if the device is rooted. The problem here isn’t that SHA256 is insecure (on the contrary, it is a highly recommended hashing algorithm), but rather that there are only 10,000 possible values that the PIN could be (0000 to 9999 inclusive). This means that a brute-force attack is easily executed by simply SHA256 hashing each possible PIN and checking the resultant hash with the one stored on the device.

The following video shows the attack in action. The team who found the vulnerability simply created a separate app that reads the stored hash value and brute-forces it. It only takes the app a few seconds to crack the hash.

If you thought that was a bad design decision by Google, you haven’t seen anything yet. As it turns out, there is no need to root the device or crack the hash, as all an attacker needs to do is ask the phone to reset the Google Wallet application data. This wipes the PIN from storage, but not any card details, so when the Google Wallet app is next opened it asks you for a new PIN and lets you use the stored card details immediately:

Merlin Entertainments

Earlier this year I visited Thorpe Park, a popular theme park in the south of England. At the entrance were signs advertising a new iPhone app for the park, which (among other things) could give you up to date queue times for all the rides. I quickly downloaded the app, and used it to plan my day around the queues.

On the way home I started playing with the app again, and when I tried to check the queue times an error message appeared: “not available off-park”. Clearly the programmers of the app had used the iPhone’s built-in GPS to limit the availability of the queue times; a crude form of location-based security. Only people within a certain location are able to access the queue times; everyone else had to go without. I presume this restriction is meant to stop people from checking ahead and deciding not to go to the park if the queues were too long.

However, I was intrigued at how the queue data got onto the device in the first place, so I decided to do a little investigating. My iPhone is jailbroken, so finding an app that could fake your GPS location was easy enough; there are a few in Cydia, but I found that FakeLocation is very easy to use and does the job well (for a relatively low price). Once installed, I chose my “location” as the middle of the park and restarted the Thorpe Park app. Sure enough, the queue times were now working.

I connected my iPhone to my wireless network at home, and used Wireshark to sniff the network traffic going in and out of the device. When I used the Thorpe Park app to check queue times, a simple HTTP request is sent to http://www.merlincms.com/1.php, which returns a JSON data object containing all the queue time information. However, all the queue times are linked to reference numbers, not the actual names of rides. This was a problem, but as it turned out, it was easily solvable.

Since my iPhone was jailbroken, I decided to see if there were any clues to the references in the app files themselves. I used SSH to connect to my iPhone, and browsed the directory which stored all files relating to the Thorpe Park app. Inside the Documents folder, I found a file named “Thorpe.db”, which I thought might be interesting. I downloaded it and opened it in a database browser, and found practically all the information you’d ever need to create your own Thorpe Park app. Not only did it contain a table mapping references to ride names, but it stored all the opening times, locations of all shops and facilities, and a bunch of random facts about the park.

I was only interested in the reference mappings though, and so I extracted them from the database and used them to create a web page which generates the most up to date queue times for the park.

Thorpe Park Queue Times – Short URL: http://is.gd/thorpepark

The web page can be accessed from anywhere, and on any device that supports web browsing. As an added bonus, I found (via the same method above) that the Alton Towers app does the same thing, and so created a web page specifically for that theme park as well:

Alton Towers Queue Times – Short URL: http://is.gd/altontowersqueue

Now I’m not promising that these web pages will “accurately” display the current queue times of rides in the parks, but what I can promise is that they will display the same times as their respective iPhone app displays. The advantage here being that you can view them from anywhere (with an Internet connection).

It should also be noted that the method I’ve used to get the queue times relies solely on the Merlin Entertainments server being up. The script will stop working (i.e. the web page won’t display anything) if the Merlin Entertainments server is down, or if they suddenly decide to change the method by which they transmit queue times. I doubt they’ll do this, since it will render all the iPhone apps useless in this regard as well. They could block my server IP I suppose, but I’ll cross that bridge if I come to it. I’ve already considered creating a JavaScript version which would get around such a block.

This conversation between my sister and her bank was just posted on her Facebook wall, and I thought it was appropriate to share on this blog.

Bank: Hello Miss Hayter, can you give me the date of birth of Maureen Hayter?
My Sister: Erm, I don’t know a Maureen Hayter.
Bank: That’s great, you’ve passed the security check, how can we help?

Apparently the information that protects your assets isn’t something that only you know, but something that you don’t actually need to know in the first place. So all a criminal needs to do is be ignorant of your personal details, and they can gain access to your account.

My sister also revealed that in order to do an actual bank transfer, she was given a list of addresses that she had to confirm she had never lived at. I don’t know the details of the bank she is with, and even if I did I wouldn’t post them here. However if I had my assets with a bank that failed this badly at Information Security, I certainly wouldn’t keep them there for long.