HRS, a hotel booking agency located in Germany had a severe vulnerability which could have been used to book hotels around the world to credit cards of customers running a customized portal page at HRS.
In November 2017, I booked a Hotel via such a branded page like I did before. I’ve got the confirmation mail and within this e-mail a link to the hotel was found. So far, so normal.
But, the link to the hotel in the confirmation email contained a value called “clientId” and this value was looking some kind of encoded/encrypted. So, when clicking the link to see the hotel details, you were automatically connected to the company’s portal site on which the booking was initiated.
Still not a big deal. BUT that is where it starts to get bad. The company which I was booking the hotel with was having a credit card stored to its profile for easier handling. Now I was able to book hotels on their credit card by just having the confirmation email or the link. Tested it and it was working without any further confirmation.
I’ve tried to contact HRS to report this issue. I was trying to get in touch via eMail and Phone. Nothing happened, not after several demands. I’ve talked to their sales, making clear what I’ve found and how it can be used just by knowing a “clientID”. They assured that this is only possible when someone knows that specific link with the encrypted ID and it should be not included in the confirmation email. They will discuss that.
Encrypted ID? Challenge accepted. Just as a random shot I’ve put it into a base64 decoder and there we go. “clientID” is just a country prefix followed by a separator and a company name or short name. Knowing this, a buddy and me were trying several companies might have a company account at HRS. In a high percentage with success. We’ve had now access to portals of Alphabet (BMW), Allianz, Telekom and a lot more.
Open site of a German Insurance Company with Credit Card Information stored:
Finding out not all companies have credit card information stored to their profile but other interesting information like customer numbers which can be used for phone bookings, departmental information, travel agency IDs and some more. Some of them also had special conditions for hotels which were now visible.
This might be a feature for companies offering a hotel booking service to the public but for sure the most of HRS customers running such a portal are not aware of that.
As there was no reply till January I’ve contacted German Tech News heise.de and VDR (German Business Travel Association) in this matter to bring up some more speed to this. VDR was very interested in this story and made some pressure to HRS making them password protect all portals with stored credit card information over one weekend. This super-fast reaction then showed that finally someone at HRS understood how critical that problem was. But still there are a lot of open portal pages you can easily find. That might be okay for some of those companies but I’m not sure if that is well communicated to them.
Same insurance HRS site after they’ve changed login behavior:
The press statement from HRS was: “However, there was a possibility for IT insiders to decrypt the query logics to access customers hotel booking sites. We have closed this vulnerability immediately.”
- there is absolutely no encryption on that query logic
- you don’t have to be a “insider” to decode base64 and to put one and one together
- their reaction was horrible slow to the whole process
- the communication was even worse
At least they should have informed all customers which had stored their Credit Card information to give them a chance to double-check their billings for irregularities. But so far they didn’t.
They now have an email address email@example.com for faster coordinated disclosure to which I’ve sent an email after all that happened and never got a reply at all.
By the way, there was also never a reaction to the XSS vulnerability I’ve found on their site OBB-339415
Thanks to the VDR for their support!