20
Jan
2015
By Calvin at 11:00 GMT, 9 years ago
Hi all - Ben here, Calvin came to me scratching his head and asked if I would write a quick non-technical explanation of how this security flaw worked. This is all based on Paul Moore's excellent post on the subject, which I suggest you read for a more detailed run down, but what follows is my take on it as an experienced software engineer and internet user.
Immobilise is an online database for registering property in order to aid recovery of said property should it be stolen in future. This is a great idea that has been praised by many, and it has proved very popular with upwards of 28 million items registered to date.
As with every online service, in order to use Immobilise the general public must place their trust in the owners of the service to keep their data safe and secure. There are many things to look for when deciding whether a website is trustworthy or not, a subject for another post, but in this case one would be forgiven for having faith in Immobilise. They proudly display not only the “Secured by Design” logo on their website but also a list of 43 “Police Partnerships”, and as stated on their “Police Forces supporting Immobilise” page: “if your police force is not currently featured on the page below it simply means that the force in question has not yet requested their logo be added”. Sounds good enough to me! So what’s the fuss all about?
Well it all comes down to how those 28 million records are handled after they have been stored in the Immobilise database. Generally when storing information in a database, things are given unique ID numbers so they can be tracked down later on, much like every car has a unique licence plate or person has a unique phone number. So as you add your property to the Immobilise website so too is each item given an ID number in the database, the first item ever added will get a 1, the second a 2, all the way up to the 28 millionth having the ID 28000000. This is a perfectly sound way of doing it and no one would dispute that. In this case the problem comes when these items are retrieved from the database at a later date.
As Paul Moore describes, once you've registered your device, you're given a certificate of ownership. To download your certificate, you're given a link which looks something like this:
https://www.immobilise.com/pdf.php?stage=account&certificate=7161519&user=3714932
Here’s what each part of that link means:
What’s happening when a user clicks that link is that the website looks up the item with the certificate ID of 7161519 and user ID 3714932 in the database and then uses the data retrieved to fill in a downloadable certificate pdf file. As you can see above, the last 2 items are the ID number given to the certificate, and the the ID number of the user who uploaded that certificate. When Paul saw this in the link he wondered if he could simply increase the certificate ID number by 1 and get the next certificate in the database, and to his horror, he could. And if he could just add or subtract 1 to the ID in the link, anyone could. This set off alarm bells for Paul as he knew it would take no longer than an hour or so for someone to write a very simple computer program that could go through each ID starting at 1, downloading each certificate as it counted all the way up to 28,000,000 and beyond as people continue to register new possessions.
To an experienced software engineer, this was a glaringly obvious flaw in the system, and luckily Paul did the ethical thing and contacted Immobilise to get the security hole patched and keep users protected. But there is no way of knowing if he was the first person to find this flaw, and though no proof has come to light, it is very possible that somebody got there first and did download a significant proportion of the data.
What did this data contain? Well as can be seen in the below screenshot, a certificate of ownership contains the owner’s full name, phone number(s), home address, email address, information about the property in question such as type (eg TV/Radio etc), make/model, purchase price, purchase date - even photographs of the item! So it’s no exaggeration when Paul calls it “quite a nice shopping list for a would-be burglar”!!
Immobilise assure us that this problem has been fixed now, and though I am unable to login and check for myself as the Immobilise website is currently down for maintenance, Paul verifies that Recipero, the company behind Immobilise, NMPR and CheckMEND, have added security checks to make sure data is only available to the logged in owners of that data.
So the hole has been plugged, but there are still 2 things about this story that are of particular concern to me. The first being that this was a very obvious security flaw to spot. As someone who has developed many systems like this in the past I find it very difficult to understand how the person who wrote this program did not notice the flaw at the time that he/she wrote it in the first place, let alone how it was not picked up during further testing before it was made available to the public and police services. I certainly don’t get the impression that Recipero take security very seriously, this is most disconcerting when they have such a large database of property owned by the general public under their control.
Secondly, this service was and at the time of writing STILL IS carrying the police Secured by Design (SBD) logo! You can see it for yourself on the Secured by Design website. In fact, I can’t find one mention of this mess on their website at all; they’ve not even thought to warn the public in their news section! According to the entry on the SBD website the product was tested to: BS ISO/IEC 27001:2005/BS 7799-2:2005 Information technology. Security techniques. Information security management systems. Requirements. Now, either the person testing the product missed this fundamental error or maybe the standard itself is not up to scratch.
This is not something I’m very happy about as a member of the public, and not something I’d be too pleased about if I were a competitor of Immobilise and had a perfectly secure system. The SBD 'tick of approval' awarded at the time suggesting that the product was secure was obviously not correct, and I'm quite surprised SBD haven't put a statement on their website to tell the public they are aware of the matter and will be re-evaluating their certification procedure when it comes to products of this type.
So what should you do about this? Paul Moore suggests you “report it to the Information Commissioner's Office and delete your account immediately” - and I wholeheartedly agree. It's not clear whether this data fell into the wrong hands or not, but be safe and check up on your home security using our free do-it-yourself survey.
If you feel strongly about this please feel free to leave a comment below.
Hope that helped!
-Ben
