A newspaper published details about a newly discovered serious security vulnerability. Here are the details that the newspaper article did not give.
|Published:||Fri, August 3, 2018, 11:40|
|Updated:||Sat, August 4, 2018, 10:40|
Behind the news
OWASP 2017 A2
OWASP 2017 A3
OWASP 2017 A7
OWASP 2017 A9
OWASP 2017 A10
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.
The security issue here was anyone on the Internet could log in as the booking agent for the travel agency:
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.
Skip this part 🙈
I wanted to add the technical details of this issue and what should have been in place to avoid it.
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:
httpit does a redirect to
httpsinstead of returning any content over
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.
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
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.
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.
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.
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.
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.