This is a short summary of selected talks (i.e. those that I found the most interesting of those I was able to personally attend) of the GI Sicherheit 2016.
First of all, congratulations to Dr. Fabian Yamaguchi, who received an award (the GI Promotionspreis) for his PhD thesis “Pattern-Based Vulnerability Discovery“!
His work presents an “approach for identifying vulnerabilities which combines techniques from static analysis, machine learning, and graph mining to augment the analyst’s abilities rather than trying to replace her” by identifying and highlighting patterns of potential vulnerabilities in source code.
Dominik Schürmann and Lars Wolf gave a talk on “Surreptitious Sharing on Android“, which is a class of vulnerabilities that was first named by the authors.
I want to go a bit more into detail here to outline the problem: The vulnerability can be roughly described as follows.
A malicious android application can send an intent to a different app (as example, the authors showed examples of apps that pretend to be crashed and an error report shall be sent to the app vendor or a “share music in Threema” button within a malicious music player app). The particular scenario doesn’t matter, the only point here is to trigger the intent and make it plausible to the user to confirm some action in the next step.
The intent makes use of a standard android API feature that is designed to allow for data/file sharing between different apps that are normally sandboxed and thus separated by the OS. The specification of the data is done by providing a URI to the file to be shared. Permissions to this object are verified by the OS and have to be granted by the sharing app first, if a file should really be shared from one application to another. However, if the URI points to a regular file on the file system that already belongs to the target application (instead of a file that belongs to the issuing application), the target app has the rights to access this file.
The target app is told to share the information via its own communication channels (via email for an email app or via private chat for Threema, Signal, Telegram, or other messengers considered a secure way of communication, because they apply end-to-end encryption). This way, the authors could for example implement a malicious app that pretends to send a music file via Threema, but instead of some music file, the private encryption key or the entire chat history files of Threema have been sent out by Threema itself. In either case, the confidentiality of the messages that should have been protected is broken. The only obstacle for the attacker is that the user has to confirm/accomplish the send action. Therefor, the attacker has to tell some story (an error report has to be send / a music file can be sent / …) before.
Conclusion: App authors are advised to fix such issues in their apps and check incoming URIs before handling them. For users, as long as those problems are not fixed, we recommend to double-check which data is going to be sent via whatever application on android phones before confirming it – especially if the sharing procedure was initiated by another app (no matter what story was told there!).
A very different talk was held by Felix Schuckert, “Generating Security Vulnerabilities in Source Code”, who presented a tool to automatically modify existing source code by inserting vulnerable source code. He already used/evaluated it in course of the iCTF 2015 hacking contest. The tool might be interesting for training of human auditors on the one hand and automated security tools on the other hand.
Vincent Haupert and Tilo Müller revisited in their talk “Auf dem Weg verTAN: Über die Sicherheit App-basierter TAN-Verfahren” the issue that pushTAN, which performs (pseudo-)two-factor authentication for online banking via two separate apps on smartphones, is not secure as soon as an attacker gains root privileges on the device. While they already published the issue on the 32C3 congress, in their talk they argued against the banks’ follow-up arguments that this is a rather non-realistic scenario and the attack only succeeds under laboratory situations. To this end, the authors demonstrated that today there are still frequently occurring root exploits that could be used by malicious app authors to silently gain root privileges on the android device and manipulate banking transfers (i.e. replacing receiver and amount of money to be transferred) in a way that is fully transparent to both, the user and the bank and can thus not easily be detected.
Best, Andreas