UPDATE: THE POSITION HAS BEEN FILLED!

Is this for you?

The following code uses the symmetric encryption scheme AES, for instance to store some application data encrypted on disk. The code contains at least four different severe API-usage mistakes that may cause the code to crash or to be insecure:

String secretKey = "x$&78_;:$%$ä0$%=$%4352";
byte[] keyBytes = secretKey.getBytes();
SecretKeySpec secretKeySpec = new SecretKeySpec(keyBytes, "AES");
Cipher cipher = Cipher.getInstance("AES");

Can you spot these mistakes? The more you can find, and the more you enjoy finding them, the more likely the position might be the right one for you.

The CROSSING Collaborative Research Center

The Secure Software Engineering Group is currently looking for a Research Assistant in the area of static code analysis and code generation. The position is for a doctoral researcher within the new collaborative research center CROSSING which will commence operation at TU Darmstadt in October in which the researcher will interact with many researchers from IT-Security, mostly with a focus on cryptography. Collaborative Research Centers are institutions funded by the German Research Foundation (DFG) and are established at universities to pursue a scientifically ambitious, complex, long‐term research program. The goal of the center CROSSING is to provide cryptography-based security solutions enabling trust in new and next generation computing environments. In the center researchers from different areas such as cryptography, IT security, computing hardware, quantum physics, and software engineering will collaborate. The available doctoral positions are distributed over the aforementioned areas, and will be affiliated with the research training school of the center.

Project Secure Integration of Cryptographic Software

As part of its research program CROSSING will develop an open-source software called OpenCCE which will allow users to deploy the developed solutions in a secure and easy way. This particular position is one of three within project E1 – Secure Integration of Cryptographic Software, which will coordinate, among other things, the development of OpenCCE:

Cryptography-based security solutions and cryptographic primitives/algorithms can only support trust if sound implementations exist and users and developers are supported in integrating them into their applications. Thus, the goal of this project area is to develop methods and technologies that allow for secure implementation of cryptography and enable users and developers who may not be cryptography experts in properly applying cryptography.

Cross-posted from SEEBlog

Stephan, Steven and Me have been added to the list of Android Security Acknowledgements:

http://source.android.com/devices/tech/security/acknowledgements.html

Thanks Android Security Team!

Cross-posted from SEEBlog

We are proud that our paper “DROIDFORCE: Enforcing Complex, Data-Centric, System-Wide Policies in Android” has been accepted at this year’s ARES conference. It was a collaborative paper together with Enrico Lovat (TU Munich) from the group of Prof. Dr. Alexander Pretschner. The abstract of the paper:

The complete paper can be downloaded from here (note: it is only a preprint, the final version will be published at ARES in September).

Cross-posted from SEEBlog

Max Kolhagen (bachelor student) and Siegfried Rasthofer demonstrate how a malicious application with no permission can be used to read incoming messages from WhatsApps, Hangouts, etc. and even “encrypted” messages sent through Threema, TextSecure or Chadder with ease.

Many messaging apps, such as WhatsApp or Hangouts have this nice feature of getting notifications when an SMS or message is received. The notification contains the full message including the name of the sender. Besides these “standard” messaging apps, there are also apps which support an end-to-end encryption for a secure communication between two users. The most common end-to-end encryption apps are: Threema, TextSecure and Cheddar. Also these apps support this nice feature. The image on the right shows an example of an incoming “encrypted” messages from Threema and TextSecure.

But wait a second… Aren’t these message supposed to be encrypted? This was the point where it got interesting to us and we tried to find out whether it is possible and how can we extract a text from the notification bar.

How can one programmatically access the notification bar?

Well, there may be many different possibilities for extracting data from the notification bar. We will introduce two in the following, one method which works only on Android version greater than 4.3 and one which works for 4.2 and below.

Up until Android 4.3 every developer who wanted to get information from the notification bar, needed to use an AccessibilityService. This particular service was originally intended to help developers build services that enable users with limited perception to engage with Android OS.

In order to being able to access notifications you need to tell the service what kind of events you want to subscribe to:

@Override
protected void onServiceConnected() {
  super.onServiceConnected();

  AccessibilityServiceInfo info = new AccessibilityServiceInfo();
  info.flags = AccessibilityServiceInfo.DEFAULT;
  info.eventTypes = AccessibilityEvent.TYPE_NOTIFICATION_STATE_CHANGED;
  info.feedbackType = AccessibilityServiceInfo.FEEDBACK_GENERIC;

  this.setServiceInfo(info);
}

In our case we are subscribing to notification events only (TYPE_NOTIFICATION_STATE_CHANGED). Now every time a notification is posted, updated or removed the following method is called in which we can extract the desired data:

@Override
public void onAccessibilityEvent(AccessibilityEvent event) {
  if (event.getEventType() != AccessibilityEvent.TYPE_NOTIFICATION_STATE_CHANGED)
    return;

  Notification notification = (Notification) event.getParcelableData();

  Log.d(TAG, "Incoming notification!");
  Log.d(TAG, "App: " + event.getPackageName());
  Log.d(TAG, "Ticker: " + notification.tickerText);
}

This was always considered a “hacky” solution, so with Android Jelly Bean (4.3), accessing notification became a lot easier. In order to do that, a service called NotificationListenerService was introduced. This service’s only purpose is to provide access to all notifications with a much simpler interface.

@Override
public void onNotificationPosted(StatusBarNotification sbn) {
  Log.d(TAG, "Incoming notification!");
  Log.d(TAG, "App: " + sbn.getPackageName());
  Log.d(TAG, "Ticker: " + sbn.getNotification().tickerText);
}

This example does exactly the same as the AccessibilityService but without the event registration process and the usage of Parcelable objects.

To sum it up, with either of these services we gain access to all notifications on the device. The alarming part about this is, that we do not need any permission to do so.

As you can see in the image, the installation of an app that implements both of the previously mentioned services does not outline a single permission!

Extracting the notifications’ content.

Up to this point we are able to access the notifications, but how do we access the messages of different messaging apps?

You probably already noticed that one of the log statements included the package name of the app that posted the corresponding notification. We can use that information to differ if a certain notification belongs to a known messaging app or not.

Extracting the actual content then depends on how the messaging app displays their messages in the notification bar. Some, like the Stock Android SMS/MMS app, already display the whole message content inside the ticker text. Therefore, we are able to extract the message without further effort:

int indexDelimiter = ticker.indexOf(':');

if (indexDelimiter == -1)
  return null;

String sender = ticker.substring(0, indexDelimiter);
String message = ticker.substring(indexDelimiter + 2);

For others, though, this is a bit trickier since they only show the message in the real notification itself (see first image).

In order to access their content you have to understand how notifications are displayed on the system level. They are built using a sequence of reflective actions that are performed on a blank notification view. Furtunately we are able to access these actions by also using reflections:

RemoteViews views = notification.contentView;
Class<?> rvClass = views.getClass();

// access private list mActions
Field field = rvClass.getDeclaredField("mActions");
field.setAccessible(true);

Then we can browse that list of actions for the ones that are responsible for posting text. Since we know exactly how each messaging app displays their notifications, we are now able to precisely locate and extract the content that we are interested in.

Cool, so let’s try it on different messaging apps!

For that purpose we developed an app called NotiReader which, as mentioned, does not require any permission. It is able to extract and store incoming messages, displayed in the notification bar.

The following image shows an example of NotiReader:

The fact that this application does not require any permission causes a serious problem, because an attacker is able to extract sensitive information from incoming SMS messages such as the TAN of a banking transaction without being detected. If one would extend this app with a single permission, the Internet-permission, she would be able actually steal all these sensitive data. Other research has already shown some approaches were data can be sent over the Internet without any permission. This shows, that it is even worse and this application could steal your personal data with zero permissions.

Is it really as bad as it sounds?

Fortunately NO due to two reasons:

1) SMS/MMS (stock app), Hangouts, Facebook Messenger, Threema and TextSecure have the ability to disable information shown in the notification bar. Unfortunately, in all of these apps, these settings are NOT activated by default! A user has to find this setting in the app and then disable it.

Other apps we examined, like WhatsApp and Cheddar, do currently not support such features. Threema and SMS/MMS furthermore allow only showing a notification that does not reveal anything about the message’s content itself, which is a good trade-off.

2) The extraction of information from the notification bar requires an additional manual activation of either the NotificationListenerService (which can be activated under Settings – Security – Notification access) or the AccessibilityService (Settings – Accessibility). In both cases the user gets a security alert from the Android OS:

These are good news, but one has to think about apps, which have to activate these services for their internal functionality. Can we trust these apps that they do not steal our personal data?

Cross-posted from SEEBlog

Cross-posted from SEEBlog

The program for the third ACM SIGPLAN International Workshop on the State Of the Art in Java Program Analysis  (SOAP 2014)  is now available at http://www.sable.mcgill.ca/soap/program.html. The workshop will take place on June 12th, 2014, and is co-located with PLDI in Edinburgh, Scotland.

Besides invited talks by Mayur Naik and Eric Bodden, the workshop features paper presentations on static analyses for software product lines, novel points-to-analyses, slicing approaches, typestate analyses, and taint flow analyses for mobile operating systems. This year’s SOAP workshop is organized by Raul Santelices from the University of Notre Dame and Steven Arzt from the Secure Software Engineering Group.

Cross-posted from SEEBlog

We are happy to announce IccTA, a new tool for tracking data flows between Android components and even between Android applications. IccTA is a joined work together with Li Li, Alexandre Bartel, Jacques Klein, Yves Le Traon from the University of Luxembourg, Damien Octeau and Patrick McDaniel from the Pennsylvania State University, Steven Arzt, Siegfried Rasthofer and Eric Bodden from EC SPRIDE. IccTA is a tool performing static taint analysis for one or multiple Android applications. It leverages Epicc to connect Android components and FlowDroid to model the life-cycles of components and perform the taint analysis.

The taint analysis is performed intra- and inter-components, which improves the precision of the analysis. IccTA outperforms all other available tools (FlowDroid and AppScan) by reaching a precision of 95.0% and a recall of 82.6% on DroidBench.
When analyzing multiple applications, IccTA first merges them into one then performs the analysis.

Almost exactly the same moment, there came up an additional tool call DidFail from the Carnegie Mellon University, which is a similar approach to IccTA.
IccTA and DidFail both rely on Epicc and FlowDroid to find data leaks between components of Android applications. They can both detect intra- and inter-component leaks within a single application or between multiple applications. Even though they leverage the same tools to compute links between components and perform data-flow analysis, implementation differences result in differences in term of precision.

In the following we would like to do a rough comparison of both tools:

IccTA vs. DidFail:

Currently, FlowDroid does not support callbacks for bound services. DidFail does not support these either since it relies on FlowDroid. On the other hand, IccTA does add its own implementation for bound services callbacks. This can quickly be fixed in FlowDroid, but at the moment lowers the precision of DidFail.

DidFail uses a “path matching” approach. This means that leaks between components cannot be computed in a single step but in two steps. In the first step, partial paths are computed in components (that is from “source” to an “inter-component-method” such as “startActivity” in the first component and from “getIntent()” to “sink” in the second component).
In the second step, partial paths are combined using the path matching approach.
The combinations yield full data flow paths from sources to sinks. The problem is that in some situations the path matching approach over-approximates the number of possible paths. Take the following example:

First, let’s start with the intra-component flows:

– ButtonOnClickListener: FlowDroid detects a flow from “getDeviceId()” to “startActivityForResult()” which is an “inter-component-method” (red arrows)

– Activity 3: FlowDroid detects a flow from “getIntent()” to “setResult()” which is also an “inter-component-method” (green arrow)

– Activity 2: FlowDroid detects a flow from “getStringExtra()” to “Log.i()” (blue arrow)

– Activity 1: FlowDroid detects a flow from “getStringExtra()” to “Log.i()” (blue arrow)

Well, this are no news. The news are the ability to track inter-component flows in a really precise way. There are two privacy leaks through inter-component flows:

– (a1) -> (c1)

– (a2) -> (c2)

This is the result of IccTA. Instead, DidFail may produce four privacy leaks (two false positives) since they have a “path matching” approach:

– (a1) -> (c1)

– (a2) -> (c2)

– (a1) -> (c2), false positive

– (a2) -> (c1), false positive

For future work, we will intensive compare both tools to get a better understanding about precision and recall.

(This article was written by Li Li, Alexandre Bartel and Siegfried Rasthofer)

Cross-posted from SEEBlog

Die aktuelle Heartbleed-Schwachstelle zeigt, wie wichtig es ist, die Sicherheit von Software zu verbessern. Konkrete Handlungsempfehlungen dazu diskutierten IT-Experten im Eberbacher Gespräch zu Software Security. Neben der Entwicklung besserer Testwerkzeuge fordern die Teilnehmer, die Sicherheit von Software bei öffentlichen Ausschreibungen stärker zu berücksichtigen sowie eine Diskussion der Haftungsfragen. Das Fraunhofer-Institut für Sichere Informationstechnologie SIT hat die Ergebnisse jetzt in einem Bericht veröffentlicht, der die wichtigsten Herausforderungen und passende Lösungsansätze beschreibt. Hier lässt sich das Positionspapier kostenlos herunterladen.

Software ist heute so komplex, dass Menschen selbst schwerwiegende Fehler trotz intensiver Prüfung nicht erkennen können. So bemerkte auch der Prüfer im Heartbleed-Fall den Fehler nicht. Dabei handelte es sich um Open-Source-Software, deren Programmcode sogar öffentlich einsehbar und nachprüfbar ist. Wie bei vielen Open-Source-Projekten nutzten Unternehmen den kostenlosen Code und sorgten so unabsichtlich für eine Verbreitung des Fehlers. „Das Beispiel zeigt, wie wichtig es ist, die Sicherheitsqualität von Programmcode vor dem Einsatz besser zu prüfen, und wie gefährlich die Nutzung von fremdem Code ist“, sagt Prof. Michael Waidner, Leiter des Fraunhofer SIT und Direktor des European Center for Security and Privacy by Design (EC SPRIDE). „Auch wenn noch nicht klar ist, welche Schäden durch die Schwachstelle entstanden sind, zeigt das Beispiel doch erneut, dass es wesentlich teurer ist, Softwarefehler nachträglich zu beheben, als sie in der Entwicklungsphase zu beseitigen.“

Um die Entwicklung sicherer Software zu fördern, erarbeiteten die Teilnehmer des Eberbacher Gesprächs sieben konkrete Empfehlungen: Dazu zählt neben der Beantwortung der Haftungsfrage die Entwicklung von flexiblen Sicherheitsprozessen, die sich auch für kleine und mittlere Softwarehersteller eignen. Neben einer verbesserten Ausbildung von Programmierern sollten auch die Vergaberichtlinien für Behörden so geändert werden, dass Mindestanforderungen hinsichtlich der IT-Sicherheit erfüllt werden. Um Unternehmen Anreize zu geben, die Sicherheit eingesetzter Software zu erhöhen, müssen Manager die Kostenvorteile von sicherer Software berechnen können, etwa mit Hilfe von neuen quantitativen Modellen. Darüber hinaus braucht es nach Meinung der Teilnehmer auch neue Zertifizierungsmethoden, die dem rasanten Tempo der Softwareentwicklung entsprechen, sowie neue Tools zur Schwachstellen-Aanalyse. „Gerade im Bereich der automatisierten Testwerkzeuge ist die deutsche Forschung besonders stark“, sagt Michael Waidner. „Neue Methoden erlauben es zum Beispiel, Fehler im Programmcode schneller und besser zu finden. Diese Ansätze gilt es jetzt, in Produkte zu verwandeln.“ Auf lange Sicht könnte sich auch eine Haftungsklärung positiv auf IT-Sicherheit und Datenschutz auswirken. (Oliver Küch, Fraunhofer SIT)

Cross-posted from SEEBlog

Our taint-analysis framework FlowDroid was awarded the Artifact Evaluation Award at PLDI 2014. This year, out of 20 submitted artifacts, only 12 were found to meet or exceed the expectations and awarded accordingly. For FlowDroid, apparently the expectations of all three reviewers were exceeded. Thanks a lot to Christian Fritz for the initial implementation and to Steven Arzt for making this a nice and round distribution!

Cross-posted from SEEBlog

The slides as well as the paper about SuSi (NDSS 2014) are online.

Cross-posted from SEEBlog