Thomas Cook Airlines was leaking passenger information about future og past flights. Information about tens of thousands - or maybe hundreds of thousands - of travels could be systematically downloaded.
Published: | Mon, July 9, 2018, 06:50 |
Category: |
Security
|
Tags: |
Security Monday
Information leak
OWASP 2017 A5
|
It was possible to - partially very systematically - retrieve passenger information for travelers with Thomas Cook Airlines. Data as old as from 2013 and all the way to 2019 was available.
Who: | Thomas Cook Airlines (and especially travelers booking via Ving) |
Severity level: | Medium to high |
Reported: | June 2018 |
Reception and handling: | Fair |
Status: | Fixed |
Reward: | A thank you from Thomas Cook Airlines, a "thank you, but there are no issues" from Ving |
Issue: | Information leak with personal and travel information from at least 2013 including future travels |
I had just paid for my vacation with Ving when I got an e-mail from Thomas Cook Airlines with a link to airshoppen.com where you can upgrade your flight (i.e. meals, seating, etc), buy duty free and do the online check-in. I got a bit curious when I saw that the links from the e-mail did an auto login of my user based on only very little data.
Skip this part 🙈
The links from all the e-mails from Thomas Cook Airlines to their domain airshoppen.com were click registration URLs also containing a redirect URL. The redirect URL was of the format
hxxps://no.airshoppen.com/autologin?ReturnUrl=/oppgrader-flyreisen-din&bookingNo=<integer booking number>&tourOperatorTag=<short name tour operator>&depDate=<departure date>&<some UTM parameters>
That link did another redirect which made you end up as logged in and you could see some of your personal info. Of course, the only natural thing to do was to play with the parameters; change the dates, change the booking number and remove one or more parameters.
The first thing I discovered was that I could log in to my own booking using +-1 day in the URL. I'm sure this is done to avoid problems with timezones when people log in and pick their travel date manually. However, this means that guessing on a close by booking number one only needs 120 guesses to cover a full year of travel dates. To me this is not very assuring.
When you are logged in you are presented with a list of the names of everyone travelling on the same booking. You can then select who any orders will be registered on. Copying that call to curl would make it look something like this:
curl 'https://no.airshoppen.com/Account/SelectPassenger?locale=nb-NO' \ -H 'Cookie: ASP.NET_SessionId=<session ID>; <lotsa cookies 🍪>; .AIRSHOPPENAUTH=<some auth token>' \ -H 'Origin: https://no.airshoppen.com' \ -H 'Accept-Encoding: gzip, deflate, br' \ -H 'Accept-Language: nb-NO,nb;q=0.9,no;q=0.8,nn;q=0.7,en-US;q=0.6,en;q=0.5' \ -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.183 Safari/537.36 Vivaldi/1.96.1147.42' \ -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' \ -H 'Accept: */*' \ -H 'Referer: https://no.airshoppen.com/autologin?ReturnUrl=/oppgrader-flyreisen-din&bookingNo=<integer booking number>&tourOperatorTag=<short name tour operator>&depDate=<departure date>&<some UTM parameters>' \ -H 'X-Requested-With: XMLHttpRequest' \ -H 'Connection: keep-alive' \ --data 'TravelDocumentsRequired=False &Email=<e-mail address> &ShowCanContact=False &IsPersistant=false &SignInModel.SelectedTourOperatorTag=<short name tour operator> &SignInModel.DepartureDate.Day=<departure day> &SignInModel.DepartureDate.Month=<departure month> &SignInModel.DepartureDate.Year=<departure year> &SignInModel.SigninMethodType= &SignInModel.BookingNo=<booking number> &SignInModel.ReturnUrl=%2F &SignInModel.HashValue=' \ --compressed
That call returned markup with personal and flight information. However, I quickly saw that this call could be shortened to this:
curl 'https://no.airshoppen.com/Account/SelectPassenger' \ --data 'SignInModel.SelectedTourOperatorTag=<short name tour operator> &SignInModel.BookingNo=<booking number>'
Now, this was an issue. Using only the three letter short name for Ving and booking information the server would return the same data about the booking.
As this was a POST call I would guess there are no logs that really can tell if this vulnerability has been misused by anyone.
For Ving this was pretty serious as they use a booking number that is seemingly an incremental integer, which makes it possible to iterate through all bookings. It's worth noting that not all Ving travels are using Thomas Cook Airlines, but quite a few of their 400,000 yearly travelers do.
For Ving the oldest bookings I saw were from 2013, and the most recent one from 2019. I suppose this means that data was leaking about at least tens of thousands of travels.
I asked friends and family for booking numbers to test with, and even found some more on Google. It was possible - using only the booking number - to get the data for the travels from the travel companies Ving Norway, Ving Sweden, Spies Denmark and Apollo Norway.
Luckily Apollo doesn't have that easily guessable booking numbers, so I couldn't find any other bookings from the one number I had. I never got any data from the travel company TUI (ex Star Tour), but I didn't have any recent or future booking numbers. (TUI do however seem like the company most concerned and in control in regards of GDPR, so maybe they don't have any old data available in Thomas Cook Airlines' systems?)
Other than that it's only speculations, but airshoppen.com do handle many, many travel companies from Norway, Sweden, Denmark, Finland, United Kingdom and Germany. I would expect at least some of them to be vulnerable through this leak. airshoppen.com also serves travelers travelling with Condor, Atlantic Airways and Small Planet Airlines, but please note that I never saw any actual data for these three airlines.
It was seemingly possible to iterate Ving's bookings with Thomas Cook Airlines from 2013 to 2019. At least data from Ving Norway, Ving Sweden, Spies Denmark and Apollo Norway was affected by this vulnerability.
I really struggled to find a proper contact point for airshoppen.com, but I submitted a web form with the closest possible topic telling them about the issue. I got an automatic reply by e-mail.
The morning after, not having heard back, I felt that this leak was too big to just slide. I asked Ving on their chat for an e-mail address where I wrote them and gave the issue ticket number from Thomas Cook Airlines.
Ving replied back in just a few hours. They thanked me, told me they would pass it on internally and contact Thomas Cook Airlines. They also told me that I would hear back from Thomas Cook and not Ving.
This was the first time Thomas Cook Airlines replied to my inquiry. And guess what? They just said that they needed my booking number to help me. What the ... I tried to clarify that I was reporting a security hole and they probably wouldn't need my booking number for that.
Ving actually wrote me back and told me Thomas Cook Airlines had looked at the issue. They told me that I couldn't log in without having both the booking number and the departure date. What the ...
I replied that this really was an issue and that data back as far as to 2013 was available.
Ving replied and told me I needed the date and it wasn't as easy as I said. I asked them to give me a booking number so I could prove it. I never heard back from them after that.
Annoyed by their ignorance and unwillingness to fix the issue I contacted a journalist.
Like most days I checked if the issue was still there. It was suddenly fixed. Though I hadn't heard a word back from them.
I got an e-mail from a legal counsel in Thomas Cook Airlines verifying that they had identified and closed the vulnerability. It wasn't the most grateful e-mail I've ever got, but they could tell me that they'll keep working to improve the security and that they take their customers' security very seriously.
I got a phone call from the same legal counsel in Thomas Cook Airlines. She wanted to thank me for informing them about the issue and apologized that it took so long before I heard back from them. They were going to follow GDPR in regards of handling of the incident, but from my understanding they don't think it's worth reporting to the data protection authority.
Well, you can try calling an airline or someone working at an airport and ask them for passenger information. You won't get it. You are not supposed to know that person X is currently or probably will be onboard on flight Y.
Also, some people might not like that you can see who they travelled with on vacation maybe 5 years ago. ("Didn't you say you were going to that job conference in Stockholm? And who is this you were travelling with?")
Another problem with this is how this opens up for spear phishing - to use the information to target and deceive a traveler.
Who really knows how long someone can have taken advantage of this leak..?
As in the case with the leaked hotel reservations I decided to publish this through media first. Yle covered the story a few days ago (Swedish link only, sorry). Yle is is Finland's national public broadcasting company. I'm glad to see that big media companies like Yle cares about online security and our personal data.
Another week, another leak. It's disappointing that so much of my personal information and usage data is available for anyone on the Internet. What I can find in just a couple of minutes on a website is surely just the tip of the iceberg.
While we will continue to see leaks like this I hope that companies will get better at handling and dealing with information about security vulnerabilities. For me the whole process reporting this issue wasn't very pleasant. It could be a coincidence, but shortly after I contacted media the issue was fixed and I finally received a proper response. Only after the phone call with Thomas Cook Airlines on day 19 I was more satisfied with how the whole incident in total was handled. The conversation made it clear to me that they really did take this seriously.