CRS/GDS companies and travellers' privacy

[In the middle of the presentation by SRLabs at 33C3 on Tuesday, Nemanja Nikodijevic discovered that Amadeus had taken its “CheckMyTrip.com” PNR-viewing Web site offline to prevent the vulnerabilities of the site from being demonstrated in real time. Screen capture from CC3C video by permission of SRLabs. Click images for larger versions.]

This past Tuesday at the 33C3 conference in Hamburg, Germany, Karsten Nohl and Nemanja Nikodijevic of SRLabs publicly demonstrated that airline reservations systems still have the same fundamental insecurity, in the same ways that I have been writing and speaking about for more than 15 years.

Lest there be any doubt, while the the team from SRLabs was inspired to investigate this subject in part by an interview with me on a German IT news site, I had no contact with them and was entirely unaware of their work until they contacted me last week. They worked entirely independently of me, and had no access to any information from me except my published writing and public speeches. When they contacted me last week to let me know that they would be giving a presentation on this topic at 33Cc, their research was already complete.

I thought that expert security researchers might have found more vulnerabilities than I had found. Perhaps they did, but haven’t yet discussed them publicly. But all of the attacks they demonstrated in their public presentation at 33C3 exploited the lack of real passwords on public Web gateways to Passenger Name Records (PNRs) operated by computerized reservation systems (CRSs/GDSs) for itinerary viewing, and by airlines for online booking, ticketing, check-in, changes, and cancellations.

These specific vulnerabilities have been publicly reported and discussed in print for at least 15 years, starting around the time Amadeus began its beta test of CheckMyTrip.com.

In light of some of the statements attributed to Amadeus — the target of most of the sample exploits demonstrated by SRLabs — in other news stories this week, it’s important for the public and for government officials with authority over privacy and data protection to understand that this was not a demonstration of new vulnerabilities or anything that wasn’t already well-known to Sabre, Amadeus, and Travelport (the current owner of both Galileo/Apollo and Worldspan).

Amadeus’ reported responses have focused on the brute-force attack on PNR record locators, but the real problem, which has long been known, is the use of the record locator as though it were a password and without telling travellers that they need to keep it secret like a password that can’t be changed if compromised. In many real-world targetted attack scenarios, the attacker will have other ways than trial and error to obtain a record locator. And real-world attacks are likely to be targetted: There are easier ways for hackers to obtain credit card numbers or money. The motivation for hacking a CRS/GDS or obtaining PNR data is to find out where someone will be, and when, so that the cyber-attacker can stalk their victim, surveil her, harass or attack her physically, rob her home while she is away, kidnap her and/or her children, or kill her.

To set the record straight, below is more detail than I would normally go into about the chronology of my reporting on this subject, followed by my recommendations for action and the questions I have asked Amadeus.

The lack of a password for access control (more precisely, the use of an unchangeable and non-secret system-assigned “record locator” as though it was a password) was the most serious specific vulnerability I noticed as soon as the first of these CRS itinerary-viewing sites, Sabre’s “VirtuallyThere.com”, launched in 2000. I immediately brought it to Sabre’s attention, and began discussions with Sabre’s privacy officer about possible mitigation and/or correction measures.

Sabre didn’t take this vulnerability and the threat it posed to travellers as seriously as I thought it should, but Sabre’s privacy officer was willing to talk with me, and seemed to be genuinely interested in my threat assessment and to be seriously considering my recommendations.

When I wrote about this vulnerability in “The Practical Nomad Guide to the Online Travel Marketplace”, which went to press in late 2000 and was published in early 2001, I said that, “hopefully Travelocity.com [which at the time was owned and operated by Sabre] will have secured it before you read this.”

That didn’t happen quite so quickly as I had hoped, and in the meantime, the other major CRS/GDs companies all rolled out copycat itinerary-viewing Web sites. Amadeus’ “Checkmytrip.com” officially launched on 24 May 2001 after a two-month beta test.

In April 2002, after further discussions with Sabre and after I published an update on my Web site (quoted here) for readers of the book, calling attention to the continued problem with VirtuallyThere.com and the launch of copycat Web sites with the same vulnerability by the other major CRSs, Sabre made it possible for airlines and travel agents to require a password (after a fashion) for access to Sabre PNRs.

Sabre itself was unwilling to enforce any access controls on its users. Sabre implemented some security for the sites it owned and operated, Travelocity.com (since sold to Expedia) and VirtuallyThere.com. Sabre made it possible to assign a sort of password for Web access to PNR data, but left it to each airline or travel agency to decide whether to employ this feature.

As I said at the time, “These changes [by Sabre] are too little, too late”. But they were still a significant acknowledgement — one of the first and, subsequent events proved, one of the last — of the need for a reassessment of PNR security in light of the opening up of the formerly private and physically secured CRS/GDS cloud to access from the public Internet. In my newsletter and weekly column (original version here) discussing this issue, I congratulated Sabre and urged the other CRSs to follow suit.

Sadly, the changes made by Sabre proved temporary, for reasons that were never satisfactorily explained. And none of the other CRSs made any attempt to emulate Sabre’s minor (and temporary) patches or take any other steps to address the obvious vulnerability of these Web gateways to CRS data, and the airline Web sites that, around the same time, began offering online access to PNR data (with the same vulnerabilities) for reservations, ticketing, check-in, and later changes and cancellations. Airline security has always been about protecting airlines against threats, including threats from passengers, not about protecting passengers. After 9/11, that orientation only strengthened.

For the next several years, I continued to point out to Sabre’s privacy office each time I noticed that the “pseudo-password” protection on VirtuallyThere.com had been removed again or wasn’t working for one or another category of PNR. I also tried to get the other CRSs to recognize and act on this vulnerability, at least to the extent that Sabre had done. I expected that Sabre’s actions and acknowledgement of the problem would create pressure on its competitors, just as the success of Sabre’s VirtuallyThere.com had pressured them to launch their itinerary-viewing sites in the first place. But that didn’t happen.

Galileo/Apollo and Worldspan (both today owned by Travelport) completely ignored me. At Amadeus, I found what seemed to be a sympathetic ear in Amadeus’ North American public relations office. But in a prolonged series of exchanges by phone and e-mail and in person at industry conferences that continued through 2003, they told me that any response would have to come from Amadeus’ headquarters in Europe. (Amadeus’ corporate headquarters is in Madrid, Spain. Software development is based near Nice, France. The main Amadeus data center is in Erding, Germany. I never found out where decisions on this issue were being made.) “My apologies for the delay but I am awaiting info from both Product Management and the Legal Dept,” the Amadeus spokesperson in Miami told me at one point. But finally I was told by phone that nobody at Amadeus headquarters would respond to my vulnerability report and request for comment, or authorize their North American representative to do so.

Nothing changed until this week, although I continued to write and speak about this threat (and others) to travellers’ privacy. From time to time others independently noticed this obvious vulnerability. Ten years ago, for example — and five years after my first published mention of this vulnerability — it was the subject of a lengthy feature in the Guardian, as I noted at the time in my blog.

In addition to the lack of passwords for PNR acess, the lack of access logs makes it impossible for victims, targets, airlines, travel agencies, or even the CRSs to know who has retrieved or viewed any PNR, what foreign countries it has been sent to in response to a CRS system user query, or how often and in what ways these vulnerabilities are exploited. I have written and spoken loudly and repeatedly, in many venues, about this additional critical failure, as was noted in the presentation by SRLabs at 33C3 this week:

[“Logging/Accountability: Fail.” Slide by permission of Karsten Nohl, SRLabs.]

The team from SRLabs concluded their presentation with a short list of key failures and recommended fixes:

[Shortlist of key vulnerabilities of PNR data from presentation by SRLabs at 33C3, 27 December 2016. Slide by permission of Karsten Nohl, SRLabs.]

I was struck by how closely this resembled the short list of key airline reservation privacy issues I identified in my testimony to the Advisory Committee on Aviation Consumer Protection of the U.S. Department of Transportation in 2013:

[Shortlist of key vulnerabilities of PNR data from my testimony to the Advisory Committee on Aviation Consumer Protection of the U.S. Department of Transportation, 20 May 2013.]

The additional item on my list was the need for government enforcement and regulatory oversight. As engineers, the team from SRLabs only considered technical, and not policy, fixes.

Will CRS/GDS companies now choose, or be pressured by their users or the public, or ordered by government authorities, to close the vulnerabilities they have known about, but chosen not to do anything about, for the last 15 years? That will be up to the travel industry (CRS/GDS compnaies and their airline and travel agency users), legislators and government data protection authorities, and the travelling public.

This is not about ignorance of these vulnerabilities, which have long been known to those in a position to fix them. This is not about unknown vulnerabilities, or ones that are not amenable to any technical solutions. Sabre was able to implement significant (if not sufficient) mitigation measures for the lack of PNR passwords in a matter of months in 2002, although it later chose to undo them. This is about policy choices and decisions.

This week I have renewed my offer to assist CRSs and/or other travel companies in threat modeling and in assessing and responding to this vulnerability and the others I have identified over the years.

I’ve gotten no response yet from any of them, but I was told today by a spokesperson for Amadeus at their corporate headquarters in Madrid that my vulnerability report and offer to help is being passed on to their Chief Information Security Officer. I’ve also asked the following questions, which should also be asked of the other CRS/GRS companies:

1. Why did nobody from Amadeus’ security or privacy team respond to me regarding my 2002 report of these vulnerabilities, which I was told had been forwarded to multiple responsible departments at Amadeus’ European headquarters?
2. Should I now expect to be contacted by Amadeus’ team assessing and responding to this vulnerability report? If so, when?
3. What was the basis for the decision by Amadeus not to make any changes in response to my 2002 report and my follow-up inquiries in 2002-2004, specifically including the decisions (a) not to add a password for PNR retrieval, and (b) not to add access logging to the change log in PNR “history”?
4. At what level was that decision by Amadeus not to make changes made? (I am asking for a title, not a name.)
5. (a) Will Amadeus now be adding passwords for PNR retrieval? (b) If so, when do you expect that will be implemented? (c) In the meantime, will Amadeus be making changes to its privacy policy or disclosures to travellers regarding who can access PNRs?
6. (a) Will Amadeus now be adding access logging to PNR histories? (b) If so, when do you expect that will be implemented? (c) In the meantime, will Amadeus be making changes to its privacy policy or disclosures to travellers regarding who can access PNRs or whether Amadeus (or Amadeus subscriber airlines or travel agencies) know which system users have retrieved a PNR?
7. Has Amadeus contacted SRLabs to discuss the finding they have disclosed and any of their undisclosed findings, or to consult with them about remediation or mitigation measures for the vulnerabilities?
8. What, if any, other actions is Amadeus taking or does Amadeus intend to take, on what expected schedule, to mitigate or remediate these vulnerabilities and the associated gaps in privacy policies and disclosures to travelers regarding access to PNR data?

“I’m not sure how much we’ll be able to say,” the Amadeus spokesperson told me today. “But we’ll get back to you next week, after the holidays.”

I’ve been waiting 15 years for answers, and for action. I’ll wait 15 more, if that’s what it takes. But I hope I don’t have to.