Gathering control over large-scale backend systems is a tempting achievement for criminals. Especially, if these systems collect and process payment data. These systems have to be (and are being) protected by a multitude of defensive measures to keep criminals from achieving control or gathering data.
Central Reservation Systems (CRSs), the systems behind your travel bookings, are a such an interesting target, as they process a high volume of payment data every second of the day. They are deployed on massive scales comparable to operating systems and the variety of systems is rather limited. The two largest players here are the Amadeus CRS deployed in 440 airlines, 90,000 travel agencies, and over 100,000 hotels and Sabre GDS operating for 400 airlines and 88.000 hotels. Additionally, these systems provide gateway (and payment) functionality for rail carriers, cruise lines, and car rental services.
Targeted malware attacks against specific hotels and hotel chains are not uncommon. Recent events include attacks to Holiday Inn and Crowne Plaza Hotels, Hilton Hotels, Hyatt Hotels, and even the Trump Hotel chain. All of these attacks specifically targeted the payment systems. Installing malware on payment terminals, attackers were able to copy the information from the credit cards and create copies of these cards. However, the amount of payment information that can be obtained with such an attack remains rather limited and can be detected by credit card companies comparatively easy.
Recently, one of the larger CRS vendors – Sabre – reported an attack on one of their systems in a quarterly SEC filing.
We are investigating an incident involving unauthorized access to payment information contained in a subset of hotel reservations processed through the Sabre Hospitality Solutions SynXis Central Reservation system. The unauthorized access has been shut off, and there is no evidence of continued unauthorized activity at this time. We have retained expert third-party advisors to assist in the investigation and are working with law enforcement. There is a risk that this investigation may reveal that PII, PCI, or other information may have been compromised. The costs of this investigation, as well as any other impacts or remediation related to this incident, may be material. As noted below, we maintain insurance that covers certain aspects of cyber risks, and we are working with our insurance carriers in this matter.
PII meaning “personally identifiable information” and PCI meaning “payment card industry data” here. The reason why they mention this in a stock exchange filing are the liability and costs attached to this incident.
And this assessment seems legitimate. While the amount of payment data acquired using malware in card terminals is limited to the terminal, the amount of payment data which can be acquired in breaking a CRS represents a large share of the overall travel market, although to this date the size of this specific leak is unknown to the public.
Travel booking systems are old. They still rely on data structures and protocols designed in the 1960s – including restrictions on character sets originating from the use of punch cards. These systems used to be closed systems where the clients use dedicated connections and are well known. To allow for reduced costs and novel applications (e.g., self-booking through Internet services), CRS were opened up to access from the Internet.
What was left out was fine-grained access control. Every client can see the complete record of your travel booking, including personal information and payment information, based on very weak authentication credentials. Questions regarding privilege escalation or leaking data flow cannot even be applied here, as the systems are so open already. They will continue to be that way until a fundamental architectural change can be forced. This, however, is a gigantic undertaking as it involves the whole travel industry… all airlines, all hotels, all car rental companies, etc. The European Commission is currently investigating the security of central reservation systems, which will hopefully move the vendors to implement more defenses and more privacy measures for their system.
More information:
Cross-posted from Secure Software Engineering
In a collaborative effort with Karim Ali (University of Alberta), Ben Livshits (Imperial College London), Justin Smith and Emerson Murphy-Hill (North Caroline State University), my Ph.D. student Lisa Nguyen and myself have just concluded a new piece of research on Just-in-time (JIT) static code analysis. The approach, which we exemplify with a JIT taint analysis for Android, can be applied to most static analyses 
and allows those analyses to execute more efficiently in integrated development environments. In particular, the analysis is tuned such that it executes first in code recently edited by the programmer and then searches its way further “outward” from there. As our experiments indicate, this decreases round-trip times for programmers and hence increases their productivity during the fixing of security vulnerabilities.
