The Sabre Breach: What we can learn from large-scale backend systems

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:

SSE Group contributes to McAfee’s Q4 Threat Report

As a follow up to our BlackHat EU 2015 presentation about benign applications not securing user data in the cloud (Backend-as-a-Service) we also looked into malicious applications whether we can find similar data leakages. In a collaboration with McAfee Security Lab (Intel Security Lab) we analyzed 294,817 malware-laden mobile apps and found that 16 of them are connected with vulnerable Backend-as-a-Service instances implemented in Facebook Parse. Since the malware authors did not secure the backend (BaaS-backend) securely we had access to the complete database including Command&Control (C&C) communications and tasks for victims. This gave us very interesting insights about current state-of-the-art C&C communication/protocols in the context of mobile malware.
The results were presented at VirusBulletin 2015 and AVAR 2015. More details can be looked up from our whitepaper and the corresponding slides. This project is also part of McAfee’s Q4 Threat report.

Media report:

SSE Group is presenting at Black Hat Europe 2015

At this year Black Hat Europe conference, we will talk about our Backend-As-A-Service investigation, which we published a couple of months ago.

The talk will contain a full disclosure about our investigation including details about our automatic “exploit generator”.


If you are around, feel free to join our talk and also to meet at the conference.

SSE Group Detects Massive Data Leaks in Apps using Backend-as-a-Service


With the help of CodeInspect, Appicaptor and an internally developed tool, researchers from TU Darmstadt and Fraunhofer SIT have found that many mobile applications store private information in the cloud, in an easily accessible manner.

Many users of mobile applications want their data to be synced across multiple platforms (iOS/Android/Windows/OSX/…). For app developers it is typically hard to support synchronization, as they need to set up backend servers on which the data can be stored and synchronized. Cloud providers such as Amazon and therefore provide backends as a service (BaaS). With BaaS, app developers can simply connect to pre-configured servers using a few lines of program code. This makes data storage and synchronization through the cloud very easy. Some apps use BaaS to share public data, which is ok as long as the data is configured to be read-only. Many apps, however, use BaaS also to store confidential data such as user names, email addresses, contact information, passwords and other secrets, photos and generally any kind of data one can think of. Such data should only be accessible to the individual app user who stored the data. The researchers found more than 56 million sets of unprotected data, including email addresses, passwords, health records and other sensitive information of app users, which may be easily stolen and often manipulated. Read the official release here.

An Investigation of the Android/BadAccents Malware

BadAccents Malware

Earlier this year, we reported on the Korean threat we identified in collaboration with McAfee Mobile Research. We have now released a technical report describing in detail the Android/BadAccents malware. Furthermore, we also describe a new tapjacking attack (also reported earlier this year) the malware exploited.

The technical report also describes the fix we submitted to the Android Security Team in January this year. Until now (approximately 4 month later), the official AOSP still doesn’t include the fix, meaning likely all Android versions are still vulnerable. Unfortunately, there is no real protection-mechanism for the user against this attack. A general recommendation from our side is the installation of apps from the official app stores and the usage of anti-virus applications (many AV vendors already detect this malware family).

Responsible Disclosure: Darmstadt Researchers Discover Security Vulnerability in AppGuard Pro

Stephan Huber (Fraunhofer SIT Darmstadt) and Siegfried Rasthofer (TU Darmstadt) discovered a security vulnerability in versions 2.0.0 – 2.0.5 of the security tool AppGuard Pro. A few weeks ago, we informed the vendor Backes SRT who has now fixed the vulnerability in the latest release. The vulnerability gives malicious apps full control of all settings in the AppGuard Pro application. The vulnerability not only allows such apps to bypass any and all of the tool’s security measures, on top of that the malicious apps can even misuse AppGuard Pro to convince the user into perceiving the malicious app as harmless. Users should download the update as soon as possible.

Continue reading