Case #18: I know what you did last summer - and also what you will be doing this one

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
Security Monday
Information leak
OWASP 2017 A5

tl;dr 🔗

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.

Summary 🔗

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

Background 🔗

I had just paid for my vacation with Ving when I got an e-mail from Thomas Cook Airlines with a link to 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.

Approach (technical stuff) 🔗

The links from all the e-mails from Thomas Cook Airlines to their domain were click registration URLs also containing a redirect URL. The redirect URL was of the format
hxxps://<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 '' \
    -H 'Cookie: ASP.NET_SessionId=<session ID>; <lotsa cookies 🍪>; .AIRSHOPPENAUTH=<some auth token>' \
    -H 'Origin:' \
    -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:<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>
        &SignInModel.SelectedTourOperatorTag=<short name tour operator>
        &SignInModel.DepartureDate.Day=<departure day>
        &SignInModel.DepartureDate.Month=<departure month>
        &SignInModel.DepartureDate.Year=<departure year>
        &SignInModel.BookingNo=<booking number>
        &SignInModel.HashValue=' \

That call returned markup with personal and flight information. However, I quickly saw that this call could be shortened to this:

curl '' \
    --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.

Which travel companies were affected?

I never download a lot of data as I don't want anyone to question my motives, but I do like to get an idea of the scope of a data leak, so I did a few tests to see if I could see how many bookings this was affecting.

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 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. 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.

Security issues

It was possible to retrieve the following information from Thomas Cook Airlines using only a booking number:
  • Full name of all travelers on that booking
  • E-mail address of person registering the booking
  • Departure:
    • Date
    • Airport
    • Flight number
  • Return:
    • Date
    • Airport
    • Flight number

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.

Reception and handling 🔗

Day zero 🔗

I really struggled to find a proper contact point for, but I submitted a web form with the closest possible topic telling them about the issue. I got an automatic reply by e-mail.

Day 1 🔗

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.

Day 8 🔗

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.

Day 11 🔗

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.

Day 14 🔗

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.

Day 15 🔗

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.

Day 19 🔗

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.

Is this leak a problem? 🔗

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..?

Media coverage 🔗

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.

Conclusion 🔗

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.

Get notified when there are new posts! :-)