Prof. Dr. Eric Bodden

(This article is only available in German. It is about the legal aspects of approaches that try to protect the privacy in mobile apps, with respect to German law).

Zusammen mit Prof. Dr. Alexander Roßnagel und Dr. Philipp Richter (beide juristische Fakultät an der Universität Kassel) haben wir einen Artikel in der DuD (Datenschutz und Datensicherheit) veröffentlicht, der technische Möglichkeiten für den Privatsphärenschutz auf mobilen Geräten auf rechtliche Aspekte hin untersucht.

Abstract:

Cross-posted from SEEBlog

Today I gave my tutorial on instrumenting Android applications at CCS. The tutorial slides are available here. Enjoy!

Cross-posted from SEEBlog

We are happy to announce that an updated version of our paper on SuSi was accepted for publication at NDSS’14! We hope to see you all there.

Cross-posted from SEEBlog

FlowDroid is our taint analysis tool to automatically scan Android applications for privacy-sensitive data leaks. While we have already shown FlowDroid to be highly precise and effective for explicit data flows through assignments and method calls, the tool now also supports the detection of leaks through control-flow dependencies. This protects against malware trying to disguise data flows through conditionals. If an app for instance does not directly send out the number 123, but sends 123-times the word “hello”, the attacker gains the same information as if the app had directly sent the value directly. The new version of FlowDroid derives that the “hello” message depends on the secret numeric value and therefore treats it as a leak as well though the data being sent does not directly contain any sensitive characters. To use this support for implicit flow, check out the develop branch on GitHub.

Cross-posted from SEEBlog

One week ago, Trustlook publised a blog post about the addJavascriptInterface Code execution Vulnerability in Android’s WebView. Accordingly to that post, we describe the attack in detail and also show Android’s changes in the OS in order to mitigate this JavaScript attack.

The usage of WebViews in Android apps is a widely-used approach because of its OS independent development of apps. If an app is developed in form of a web-GUI, it can be easily integrated in any OS-specific app, such as Android, iOS or Blackberry. For instance, Chin et al. [1] analyzed 864 different Android apps in their research, where 608  (70%) of those contained WebViews. This shows that the integration of WebViews is common in Android apps.

Last week, Trustlook published a blog post about a WebView vulnerability in Android that allows an attacker to execute arbitrary code in an application (e.g., install new application on the device) just via a drive-by attack. In this post we want to describe the attack in detail and explain Google’s mitigation against it.

The general idea of this attack is described with the following picture:

1. A benign application creates a WebView for displaying web pages.
2. These web pages are also allowed to contain JavaScript in it. Therefore the WebView enables the execution of JavaScript.

3. addJavascriptInterface(): By calling this Android API method, an object (in this case: JsInvokeClass) gets injected into the JavaScript context. This allows the Java object’s methods to be accessed from JavaScript. The second argument of that method (“Attack”) is used to expose the object in JavaScript.

4. In our example, we directly call an html code via the loadUrl() method. The URL is hard-coded here, but there are other use cases (e.g., browser) where the string is inserted by the user. The html code contains some JavaScript, which is shown in the “JavaScript”-box.
5. After 4. the user accesses the web page and the JavaScript gets executed. The JavaScript method execute() accesses the getClass() method of the JsInvokeClass (Attack.getClass()). Since JsInvokeClass is extended from Object, we can call getClass via the supplied name “Attack”. After that we are using reflections to call any Java method. In this case the getRuntime() method in order to execute any command (args). The command in the example is responsible for writing the text “THIS_IS_JUST_A_TEXT” into output.txt (sdcard). Trustlook described a different attack where an app gets built via string concatenation of the app’s binary code  that is written into a new file (apk) and gets installed afterwards. If the mobile device is in debug mode, the installation of that new app happens in the background without any user recognition. Quite sexy!

What are the countermeasures and how can a developer mitigate this attack ? Google is aware of this Problem (see API-description) that’s why they introduced the Java Annotation @JavaScriptInterface in Android 4.2. All applications declaring targetsdk >= 17 in the AndroidManifest.xml file that need the interaction between JavaScript and Java have to explicitly annotate those methods that are accessed by the JavaScript. In our case this would cause the annotation of the returnHelloWorld() method in order to call it via JavaScript:

@JavaScriptInterface
public String returnHelloWorld()

All other methods are not able to be access. This is also the reason why our example is no longer working, since the getClass() method is not annotated.

We recommend to declare the targetsdk of their application to version 17 or higher if the interaction between JavaScript an Java is necessary in an app. For older version try to avoid remote injection possibilities by loading JavaScript from remote. Store the JavaScript local in the application or simple try to avoid declaring such interfaces JS calling android API code.

Stephan Huber and Siegfried Rasthofer

[1] Chin, Erika, and David Wagner. “Bifocals: Analyzing WebView Vulnerabilities in Android apps.”

Cross-posted from SEEBlog

Today Steven Arzt and Eric Bodden are releasing a Technical Report on Reviser, our novel tool for automatically and Efficiently updating IDE-based data-flow analyses in response to incremental program changes. I think the title pretty much speaks for itself. Reviser is available as an open-source extension to Heros. Enjoy!

Cross-posted from SEEBlog

On Wednesday I will be presenting an invited paper which I wrote together with Ben Hermann, Johannes Lerch and Mira Mezini for a special session at this year’s Future Security Conference. In this work, we give a retrospective survey about the different software security architectures that come with common current programming-language runtimes.The more we learned about these models the less it came as a surprise to us that the world is now seeing the problems and vulnerabilities that it is seeing. In retrospect it is often simple to blame “stupid developers” for including a programming mistake that leads to an exploitable vulnerability. In practice, however, this is just a too simple answer. To truly understand what causes the inclusion of such code one must understand the development history of the respective projects, the organizational structure in which development happens and also the number of constraints a developer has to keep in mind to avoid such mistakes. We argue that, at first, simpler security models are preferable because in such models mistakes are less likely to occur. The trick is then to retain a security model that is restrictive enough. We discuss object capabilities as one mechanism to support models that can be relatively expressive and maintainable at the same time.

Reducing human factors in software security architectures
In the recent past it has become clear that there are inherent problems with the security models of popular programming platforms such as Java, Android, and so forth. In this work we pinpoint sources of those problems, and explain the relative strengths and weaknesses of the security models for C/C++, Java, .NET, Android and JavaScript. As it turns out, many problems are caused by the fact that the models are so complex that they overstrain not only end-users but even expert developers. Out of this experience we argue that a new line of security models, based on object-capabilities, can help reduce the inherent complexity, preparing the ground for software that is secure by design. 

Cross-posted from SEEBlog

As Golem and Heise are writing today, Google has updated its rules for advertisement in Android Apps. Earlier this year, researchers from the SSE group and from Fraunhofer SIT have found that almost one third of the top apps in Google’s Play store use advertising services that in many instances violate the store’s content policy. The result is annoying for users, as these apps will plague them with very intrusive forms of advertisement that can be very hard to eliminate even for expert users. Early on, we have shared these results with Google and Google. The change by Google now obligates app developers to ensure that the ad frameworks they include in their app do not use any ad services violating Google’s policy.

Currently, the Google Play Store contains nearly 700000 apps . Most of them can be downloaded for free. These apps are developed by different kinds of developer, like hobby or semiprofessional developers or by actual software companies. To make some profit or get an allowance developers can augment these free apps with advertisement.

Advertising companies, such as leadbolt or airpush provide ready made ad libraries that developers can easily include in an application. Read the rest of this entry »

Today at USENIX Damien Octeau presented our joint work on a new analysis of Android Inter-Component Communication. This is joint work with Penn State University and the University of Luxembourg in the context of our Google Award on creating a map of Android inter-component communication.

We are still in the process of improving the implementation and integrating it with FlowDroid. Once this is done, we will make our tool Epicc open source. The paper is available for download, here’s the abstract:

Many threats present in smartphones are the result of interactions between application components, not just artifacts of single components. However, current techniques for identifying inter-application communication are ad hoc and do not scale to large numbers of applications. In this paper, we reduce the discovery of inter-component communication (ICC) in smartphones to an instance of the Interprocedural Distributive Environment (IDE) problem, and develop a sound static analysis technique targeted to the Android platform. We apply this analysis to 1,200 applications selected from the Play store and characterize the locations and substance of their ICC. Experiments show that full specifications for ICC can be identified for over 93% of ICC locations for the applications studied. Further the analysis scales well; analysis of each application took on average 113 seconds to complete. Epicc, the resulting tool, finds ICC vulnerabilities with far fewer false positives than the next best tool. In this way, we develop a scalable vehicle to extend current security analysis to entire collections of applications as well as the interfaces they export.

Cross-posted from SEEBlog

At CCS 2013, we will be giving a tutorial on instrumenting Android apps to enhance their security. You are most welcome to attend! From the abstract:

Novel types of malware on mobile devices have raised researchers interest in implementing static and dynamic techniques for detecting and mitigating malicious behavior of mobile applications. In this hands-on tutorial we will demonstrate and explain different techniques for instrumenting Android applications using the Aspect Bench Compiler (abc) and the program analysis and transformation tool Soot. Through high-level abstractions such as AspectJ aspects and Tracematches, abc supports a declarative style of instrumentation that lends itself to the rapid prototyping of at least simple instrumentation schemes. Soot supports instrumentation in an imperative style, which requires more work but allows more fine-grained control. Both abc and Soot are inter operable, as they instrument the same intermediate program representation. Furthermore, as we show, both can be easily integrated with static program analyses that can be used to specialize instrumentation schemes based on additional information extracted from the static structure of the instrumented app.

In September, Steven Arzt and Siegfried Rasthofer will be giving a similar tutorial also at RV 2013.

Cross-posted from SEEBlog