Prof. Eric Bodden, Ph.D.

5°C

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.

A preprint of the work, accepted for publication at ISSTA, is now available online, as is our implementation and data set:

Just-in-Time Static Analysis (Lisa Nguyen Quang Do, Karim Ali, Benjamin Livshits, Eric Bodden, Justin Smith, Emerson Murphy-Hill), In International Symposium on Software Testing and Analysis (ISSTA), 2017. (To appear.)

Cross-posted from Secure Software Engineering

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:

• Karsten Nohl and Nemanja Nikodijevic’s 33C3 Talk on Travel Booking Systems
• The website for the talk above
• JetBlue Sued for Selling Passenger Information
• Edward Hasbrouck’s blog article on “What can I do to protect my PNR data?”

Cross-posted from Secure Software Engineering

Today we were very happy to host NRW’s minister of science Svenja Schulze and Fraunhofer’s Director of Science Dr. Raoul Klingner for the official inauguration of Fraunhofer IEM. The new institute is the first to be founded within NRW within the past 20 years, and was bootstrapped in just about seven years – a new record in the Fraunhofer Society.

Cross-posted from Secure Software Engineering

Our new S&P paper Hardening Java’s Access Control by Abolishing Implicit Privilege Elevation is now available online. It is a follow-up work to our previous CCS’16 paper An In-Depth Study of More Than Ten Years of Java Exploitation. In this former paper we classified a large number of history Java exploits. In doing so, we found that the largest class of exploits was made possible by shortcuts in Java’s implementation of access control. In the S&P paper we now show that it is possible to go without those shortcuts, without any loss of performance. We also discuss the usability implications that this removal of shortcuts would have.

Cross-posted from Secure Software Engineering

Steven, Siegfried and I have just completed our invited paper for MOBILESoft’17. The paper The Soot-based Toolchain For Analyzing Android Apps summarizes for the first time the Soot-based tool chain for analyzing Android apps that we have built up over the past years. We hope you will enjoy the read!

And if you attend ICSE, maybe consider attending MOBILESoft as well, and you will be able to attend my keynote talk.

Cross-posted from Secure Software Engineering

The local television interviewed me today on Smart Home Security. You can watch the video here. Skip to about 9 minutes.

Cross-posted from Secure Software Engineering

This year I am co-organizing Heise devSeC(), a new developer conference on secure software engineering. We welcome your submission by May 8th!

Cross-posted from Secure Software Engineering

Further information available here

Cross-posted from Secure Software Engineering

Over the past years, Soot has seen a larger and larger user base. It makes us happy that so many people find Soot useful, and we particularly enjoy also the help we have received in terms of feedback, bug reports, bug fixes or even newly contributed features. Thanks for giving back!

Early 2017 we plan to apply for government funding to aid the future development and maintenance of Soot. 

Sounds great? Then please support us by filling out this little web form.

That way you can help us in two ways:

• By letting us know how we can improve Soot you can directly help us prioritize newly planned features.
• By stating your name and affiliation you help us showcasing Soot’s large user base.

Thanks!

Cross-posted from Secure Software Engineering