I recently had the pleasure of booking a night away from it all at a nice little hotel in the Lake District. As I'm sure most people with an interest in security do, I couldn't help but shudder at the word 'Secure' being plastered across the site. Prompting some incredibly quick poking around, I easily discovered a method of extracting the personal and sensitive data of thousands of customers that had used the site before me. Not only could this kind of information allow an attacker to launch an effective and convincing phishing scam, there are other concerns too.
Hotel Hippo
Right off the bat we land at the Hotel Hippo home page and are greeted with a "COMODO - Authentic & Secure" badge on a page served over HTTP. This isn't the best start, and to make matters worse, the page isn't even available over HTTPS properly because the certificate is for a different domain altogether.
Okay, so we have a little configuration issue, it's not the end of the world just yet. Moving on.
Booking and Payment
I was already a little concerned about giving my credit card data to this site, but this concern grew to be even greater when I arrived at the screen to insert my payment details. I could see my booking reference number right there in the URL and so far, I hadn't logged in to create an account nor was I authenticated to the site in any way. Surely though, you wouldn't be able to change that number and retrieve the details from other booking reference numbers, right? You must create an account further down the line and have to be authenticated to retrieve this data, right? Wrong...
https://secure.hotelhippo.com/PaymentProcess.aspx?referenceNumber=HHU_47613
https://secure.hotelhippo.com/PaymentProcess.aspx?referenceNumber=HHU_47616
It turns out you can start walking backwards through the booking reference numbers, which are sequential, and pull out the data associated with each one! Now, I created several of my own bookings to test this with, and although I inserted fake credit card data, I'm pretty sure it doesn't retrieve that with the request rather than dropping it because it was fake. Still though, just a little further down the page are things like my name. address and post code. It's not really ideal that this information is being leaked, but not quite as critical as it would be if my credit card data was going out the window with it. Still though, at least we're on a secure connection and you can click on the little information box to open a window with further information.
Well, at least we're using 256 bit encryption to keep everything super secure...
Or maybe we're not. Again, not a major issue, but just something that damages a little bit of the faith you have in the site when they don't get the basic stuff right. I noticed that the connection is only using TLS1.0, even though I'm running the latest version of Chrome so I should really be seeing TLSv1.2 and a better cipher suite too really. A quick check on Qualys confirms the problem.
The server only supports SSLv2, SSLv3, and TLSv1.0. There is no support for newer protocols like TLSv1.1 or TLSv1.2 and also no support for Perfect Forward Secrecy. They have ECDHE cipher suites available on the server, but they're just buried below other, less secure, cipher suites.
The worst thing is that the above issues actually place the site in breach of PCI compliance, meaning they shouldn't be accepting credit card data at all! The requirements of PCI compliance are clearly outlined and there's no reason for a vendor such as these to be non-compliant. The appropriate information can be found on page 19 of this document and the relevant snippet is below.
Lastly, whilst scanning the secure subdomain over HTTPS I noticed that it returned a 302 to bounce you back to the home page, over HTTP, but out of curiosity I decided to see if I could load the secure subdomain over HTTP instead.
Booking Confirmation
After you've completed your booking through the site you receive an email confirming that it has been successful. The email contains a link for you to download your booking information so I dutifully clicked on it to download a save a copy of my details.
Yikes, no authentication again and here are all my details. The hotel I'm staying at, the dates that I'm there, the amount I spent, the value of my voucher, the value I paid using a credit card and a couple of other bits too. But, there is my booking reference number again in the URL and with a little alteration of the number, we can start walking through the booking information of other customers too. At this point, an attacker has everything they could possibly need to launch a highly effective phishing attack against a user. With name and address details it's pretty easy to look up a phone number and place a very convincing phone call to the customer. You simply say you're from Hotel Hippo, you know their name, address, post code, the hotel they're staying at, when they're staying there, whether they ordered breakfast or not, how many people are going and how many rooms they booked, numbers of adults, children etc... I mean, who else would know this information except somebody calling from the actual company?! From here, they simply explain there was an issue with the card payment, they know the exact amount, and ask for card details over the phone to avoid having to cancel the booking. Hey presto, you've bagged yourself some credit card data with minimal effort. What's arguably even worse is that there's also another risk that you're exposed to.
Burglary
These potential criminals know your name, address and post code, and they also know on exactly what dates you and your family won't actually be in your house... If we think about that for a second, this information presents a prime opportunity to go and turn over somebody's house when you have pretty much guaranteed information that they won't be there. Would you like to advertise to a bunch of criminals that you're on holiday for any given week and your house will be empty? No, I didn't think so, and neither would I.Other security concerns
Whilst I can't confirm whether or not these other issues are a direct risk to a consumer using the site, from what I've seen above I'd say there was a pretty good chance that there could be deeper issues, I just can't go digging around to check them out without crossing some lines.SQL Injection
The most interesting issue I found was a SQL Injection vulnerability on the ID fields used in the URL. Whilst walking through the HotelBrandID values to look at the information for different hotels, I accidentally inserted a non-numeric character.
Oppsie, it seems that someone isn't properly sanitising their input! There are probably other issues in many other fields, I just hadn't set out to look for them.
robots.txt
As everyone who has anything to do with building websites should know, robots.txt allows you to ask crawlers not to crawl certain areas of your site for indexing in SERPs. Yes, it's at the discretion of the crawler whether or not they actually obey this request, but it's a good idea nonetheless.
This robots.txt file allows absolutely any crawler to crawl absolutely any area of the site it wants without restriction. Given that we've seen you can access various hoards of sensitive and private data with just a tweak of a URL, this is a really bad idea, and a quick search on Google confirms it.
With crawlers not being asked to kindly leave the secure area of the site, and having terrible security, we've actually ended up with a Google crawler finding its way to, and indexing the private and confidential data of one Hotel Hippo's customers!
With this, I could jump to the other URL and download the details of where he had his lovely holiday or where/when he is going to be on holiday and when he will be away from his house. Great! Of course, using Google in this way is nothing new, there have been similar malicious uses for Google search results for some time, which is all the more reason things like this shouldn't be happening.