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 is an ingenious way of using search traffic to detect for malware installed on users’ computers. Kudos to Google for looking into this and being proactive about the way they handled the situation.

Google's Malware Warning

By the way, if you are not already subscribed to Google’s Online Security Blog I highly recommend it, especially if you have a Google account of some form. I’ve added it to this site’s blogroll as well.

This is a very good article from Webmonkey explaining why the vast majority of the web is stuck using the HTTP protocol, which sends all information (including usernames & passwords) as plaintext, as opposed to HTTPS, which encrypts it. Whilst HTTP is fine for a lot of static websites, it is very insecure for websites that have access to personal information, or that are accessed using some kind of password.

The problem of HTTP based login sessions doesn’t stop with passwords being sent in the clear though. Whilst users usually only enter their password once per session, their associated session cookie is sent with every request, and so stealing this cookie is a lot easier than stealing the password. The stolen cookie can then be used to hijack the current session of that user.

The main reasons why most websites don’t move to HTTPS has nothing to do with complexity in setup, but rather the high cost of digital certificates, slower speeds of transfer (due to the initial key exchange), and the inability for browsers to cache web pages. So for now, it doesn’t seem likely that your favourite forum or blog (even this one!) will switch to HTTPS.

So what can you do? Well, if you do use websites that require passwords to access, or that store session cookies on your computer, make sure you are using a network that is trusted. In other words, use a network that you know (such as one at your home or work), and in the case of wireless networks, make sure it is secured by at least WPA. Public WiFi access points that are usually found in coffee shops should be avoided, mainly because they are susceptible to Evil Twin attacks.

For users of Firefox who are more concerned about security and less about speed or caching, I highly recommend HTTPS Everywhere, an addon that forces HTTPS on popular websites that are usually served over HTTP.

Karsten Nohl and Sylvain Munaut from Security Research Labs have cracked GSM, enabling them to eavesdrop on any call made by a target device. The pair demonstrated their research at the Chaos Computer Club Congress (CCC), and have released a rough guide to the attack on their website.

What appears to be unique to this type of attack on GSM is that an attacker can specify an actual target device to eavesdrop on. Using a set of cheap Motorola phones with open-source firmware, the researchers were able to see all data being broadcast by the GSM base station. Once a target device is located, the relevant data can be unencrypted by finding the GSM encryption key using a set of rainbow tables. The set of tables used by the researchers was generated over a two month period in a previous research project, and is 2TB in size. An attacker only needs two encrypted known plaintext messages to have a 90% chance of finding the secret key.

In Nohl’s own words, “Now there’s a path from your telephone number to me finding you and listening to your calls, the whole way.”

Let’s just hope the GSM Association (GSMA) take on board the research, and pay special attention to the relative easiness and low cost of actually executing the attack. According to the BBC News write-up, the association have yet to comment on the attack.