Background 🔗

Just hours after I warned Thomas Cook Airlines about a massive leak of flight data, the Norwegian newspaper VG reported about a person who accidentally got logged in as a booking agent on a travel agency's web site. What surprised me was that the travel agency wasn't notified first and that the newspaper published the article without giving any chance to fix the issue.

Who was this? 🔗

The travel agency with the affected system was the Norwegian Amisol (ex Pyramidene Reiser). They were using a booking system called TravelBook from a Swedish company called adb utveckling.

Security issue 🔗

The security issue here was anyone on the Internet could log in as the booking agent for the travel agency:

• The username and password for the booking agent was visible
• The following information about travels from at least 2013 to 2018 was available:
  - Booking number
  • Password for checking booking
  • Info about all travelers on that booking:
    • Full name
    • Birthday
    • Gender
  • Additional info about person registering the booking:
    • Customer number
    • E-mail address
    • Phone number(s)
  • Order date
    - Departure:
    • Date
    • Flight number
    • Airport
    • Meal
      - Return:
    • Date
    • Flight number
    • Airport
    • Meal
  • Info about hotel:
    - Hotel name
    • Room type
    • Meals
  • Excursions
  • Price
  • Amount left to pay
    - It seemed to be possible to change the above information and even cancel the trip
• All personal information was sent unencrypted over the Internet
• Agent username and password was sent unencrypted over the Internet
• End user username and password was sent unencrypted over the Internet

Unethical disclosure 🔗

The person discovering the security vulnerability was no IT person and I can kind of see how he decided to notify the newspaper after doing such a random discovery through Google. However, I cannot understand how the journalist or editor would publish the article the same day as they got the tip about the issue. The newspaper interviewed the CEO of Amisol, but they did not give them or the system vendor any time to actually look at the issue or left alone fix it.

Why is this bad? Well, I read the news article shortly after it was published and I just googled for the term "amisol booking" and found the link with the agent login. I could log in and see all the details about all the travels from at least 2013 to future ones. It would take minutes to make a script that could download all the personal data I listed and anyone could go in and do their best to ruin a future vacation.

In Norway the press have to follow the Ethical Code of Practice for the Press. I don't know if this is a breach of the publication rule 4.3 that says "Always respect a person’s character and identity, privacy, etnicity, nationality and belief." But none the less, VG did indeed risk thousands of people's privacy when giving anyone the description on how to find all these personal data. I don't think that was the right thing to do.

Technical details 🔗

Skip this part 🙈
I wanted to add the technical details of this issue and what should have been in place to avoid it.

1. Enforce SSL 🔗

In 2018 you cannot create a system like this that does not use https. If your old legacy system is still using http you need to upgrade. And remember to check two things:

• Ensure that if you change a https link to http it does a redirect to https instead of returning any content over http.
• Check that the cookie flag Secure is used (or else the browser may send things like the session cookie over http (even if you do the mentioned redirect)).

If you are in doubt if you site needs https or why it's a good idea in general, please check out Troy Hunt's great article and video on the subject. Also, from Chrome 68 Google now labels http sites as "not secure".

It's also a good idea to use HTTP Strict Transport Security (HSTS) to protect against protocol downgrade attacks.

2. Don't accept login information as query parameters 🔗

This is what gave away the Amisol security vulnerabilities. Because the username and password was sent as GET (and with no redirects) instead of POST - and Google somehow got hold of the URL - it was indexed and available through search. Just in case it's worth testing that even though your login form is using POST that it does not accept the credentials in a GET request.

3. Avoid XSS 🔗

I suppose some think of XSS as harmless fun, but I think that's a harmful view. For this site it was - and still is - possible to endanger both administrators and customers. A successful attack would make it possible to steal usernames, passwords, session cookies, personal data, and also to alter and delete data.

4. Use robots.txt 🔗

While some might argue that hiding stuff is security by obscurity, it's a good practice to not let your administrator pages show up in search. It's not what anyone (except for bad guys) want to find when searching for something related to your service. Just remember to not specify direct URLs to your admin stuff in robots.txt or else it just makes it easier to try to find any ways into your system.

5. Keep your software up to date 🔗

Looking at the server's response header it responded with Server: Microsoft-IIS/6.0. If that's right that's pretty crazy. That is software from 2003 - 15 years ago. The list of bugs in the CVE security vulnerability database is pretty long, and I would expect that the belonging Operating System, frameworks and libraries to be of the same age.

6. Have a third party external audit 🔗

The challenge with IT security is that the good guys need to find all vulnerabilities, while the bad guys only need to find one. Security is not easy, or everybody would get it right. Instead, we all get it wrong at some point to some degree. IT security is not a state, it's a process. Any sort of audit would surely discover the flaws in this case.

7. Bonus: Use security.txt 🔗

I've written about security.txt before. I would recommend everybody to include that file on their site. It can be so hard to find the right (or any) contact point at a web site. Often you have to really push through to get a customer support to deliver the right message to the right persons.

Wrapping it up

This security vulnerability and leak was really bad. Who knows who can have misused it for how long. I think the news article in VG qualifies as unresponsible disclosure as it gave anyone the opportunity to misuse the vulnerability. Though with no consequences for anyone we can just sit back and wait for this to happen again.