security

Android Security: Dangers of hybrid frameworks (XDA:Devcon14 write-up)

At the end of September I gave a presentation at xda:devcon14 which gave an overview of attack surfaces in Android and security issues in web-based applications. I have put my slides online on slideshare, and a lot of people were asking questions, so I decided to post a write-up.

Attack Surfaces

A big part of the presentation covers attack surfaces in Android, what are they?

Attack surfaces are pieces of code which are executable by everyone who has access to a system. They are called the open flanks of a system and allow input or code execution, not necessarily from a malicious user. A hacker will usually search in these places as these are the most interesting to manipulate.

In order to decide which attack surfaces an attacker will try to attack some properties of the surface are considered, as mentioned in the slides. These properties determine what the gain is for an attacker once he successfully compromises the surface entirely or just the code behind the surface. The general rule here to follow, is that an attacker will try to gain as much privileges as possible with the least amount of investment of resources and time.

I will not cover all the attack surfaces but only the one that is interesting for web-based applications. This is called the remote attack surface, more specific the WebView component. This is a class which offers functionality to render web content using the webkit render engine. This is a broad attack surface as a lot of web technologies and protocols need to be supported. These all represent an attack surface on their own, with their own vulnerabilities and security models which can be in conflict with the Android security model. Which is the case when we consider hybrid frameworks.

To be on the same page, I define a web-based Android application as an application who uses the Webview class to render web content.

JavaScript-Java Bridges, burn them

Security issues arise when you use a JavaScript-Java bridge in your web-based application. Android allows in the Webview class to call Java native code from Javascript, you can register the native code that can be called by using addJavaScriptInterface(). The security issues become apparent when you don’t know which content you are loading.

What happens with JavaScript being loaded in an iFrame? Or more general with JavaScript coming from a third party source?

Basically there is nothing stopping them from calling your Java native code associated with the JavaScript bridge. Android uses a permissions model to allow apps to do certain actions. Third-party JavaScript can call the same public methods associated with the JS bridge. This is because the Same-Origin-Policy is not applied to the bridge. It is in conflict with at one side native code running in a permissions security model and on the other side web content, which is bound to the SOP. These two security models do not interleave perfectly and thus allows attackers to use functionality the user never granted permissions for.

Hybrid Frameworks (Apache Cordova, Sencha Touch, …)

Hybrid frameworks are frameworks who let you develop a web application using HTML5, CSS and JavaScript for example. They allow you to pack your application to run cross-platform. Benefits of this approach is the fact you only need to develop your application once and you can pack it for the different platforms. This saves you time and money if you need to pay the developers.

When packing your application for Android, the following happens. Your web application is nothing more than web-content running in a Webview class. These frameworks come default with a Java-JS bridge which are publicly available. The same problems arise as mentioned here above with simple Webview applications. There are however solutions to these problems.

Domain Whitelisting

Just implement your own origin policy! You decide which third parties you trust. For hybrid frameworks it is fairly easy, just use the domain whitelisting functionality. The funny part here, is the fact that default this is implemented as allow every domain. Yeah, you’re welcome.

In applications using a Webview-component the solution is to just intercept pageloads and resource loading requests and implement whitelist logic to deny loading if you don’t trust the origin. The slides give you the two interesting methods which you need to override in the Webview class: shouldOverrideUrlLoading() and shouldInterceptRequest()

When a third-party ad-network is used the same vulnerabilities are present as ad-networks can inject third-party content. Recent study of MWRLabs discovered the following numbers:

A script was then crafted to automatically download Android applications, decompile them and identify if an ad network was in use, and if so determine if it is vulnerable. Out of the 1,000 top applications 570 were found to be vulnerable.

This means that over 50% of the Top 1000 web-based Android applications are vulnerable. Makes you think, if security is a key aspect and concern, stay away from web-based applications. It is very tricky to get it right, and in the end native coding is more fun 😉

H4

PS: Those who want to see the talk, it was filmed, but is not yet online. Keep an eye on this blog or my twitter feed 😉

I am hacked, so what ?

Often I hear people say they don’t really bother with security on their computers or smartphones. Very often those people use arguments as “I don’t have important information” or “I know what I do, I don’t need protection”.

Now, what truly bothers me is the fact that people don’t look beyond their own interest. They don’t know that once one of your accounts is hacked, your friends are vulnerable for cyber crimes too. Since the uprising of social networks, a certain hack is widely used and has always been the most exploited, it’s called social engineering.

Proof of concept : Imagine your Facebook account gets hacked. The attacker controls your login and can use your entire account. At this point, if you got no personal information on your account because you’re just using it to browse Facebook, you’re lucky. But the chances of that being true is, well let’s face it, very small. Everybody that has a Facebook account puts certain private information online, for (hopefully if you used the correct settings) all of your friends to see.

The cracker has now enough information to take over your identity, combined with other information coming from search engines. He monitors your Facebook account and sees your friend updating his status “Excited, just bought a new laptop online”. Chances are the attacker will sent your friend an e-mail, impersonating the staff of PayPal or some creditcard company. A lot of people are fooled to give up their CC info by this method called ‘phishing’. In particular your friend is vulnerable as he as just bought something online, so for him it’s easy to assume something went wrong with his payment, and hence answers the mail.

The attacker goes on and sends something to your friend. ‘Hi man, check out this photo from you, took it last night at the party.’ Chances are your friend is now infected with a trojan horse or a keylogger.

Hope the bigger picture becomes clear, once an account of yours gets compromised, you don’t only risk your own identity and safety but also the ones you’re connected to. As the attacker has now the ability to use your trusted reputation to perform his attacks.

Some tips :

– Never, ever, ever, …. , surf to unencrypted sites when using a public AP. Always use the https:// prefix when supported. This gives some protection against sniffing your passwords.
– Never, ever, ever, …. , give up CC info in mails. Company’s will never ask you that. The same holds for login credentials.
– Never, ever, ever, …. , follow a link without checking the URL. A link like http://fcebook.com is probably a trap.
– Always use a firewall. Experience crackers can circumvent this, but at least you’re protected against script kiddies.
– Always use anti-virus in the unfortunate event you’re bound to use a Windows system ( :p ).

Maybe a more technical post is coming in the future that explains how crackers can circumvent your firewalls and anti-virus systems.

Cheers,

H4

Android systems , secure or not ?

By the end of this current year, 1.4 billion smartphones will be in use: 798 million of them will run Android, 294 million will run Apple’s iOS, and 45 million will run Windows Phone, according to a new study by ABI Research.

Source: BusinessInsider

This is an incredible number of smartphone users which are connected to the big wide web. But how secure are they ? Is it possible for a mobile operating system to be secure ? Or is it insecure from the roots up ?

As you already might guess I will only be covering the Android part, not surprisingly they have the bigger marketshare. So, how do you ‘test’ a secure mobile system ?

A system can be locked down extremely but this can have an impact on the user friendliness, where do you draw the line ? How do we test if a given Android system is secure. Do we forget the user friendliness or are we considering the bigger picture : a secure , user friendly, Android system. I think considering the bigger picture is a more realistic impact as it includes the user’s behavior, which makes up a great part of the system’s security.

Let’s take a look at the security mechanisms Android has implemented for save distribution of applications. Android applications are shared through the Google Play Store. Android has two important security mechanisms which involve distribution and installation of apps in order to protect the installing user from malicious actions.

  • applications need to be signed
  • applications need permissions to access phone functions

Applications need to be signed with a special unique key that a developer can obtain. The signing of an application can be thought of as providing the application of a digital certificate. With this certificate Android aims on establishing trust relationships between applications. For example consider an app which we call “AppX”. If “AppX” is first installed, it is signed with a specific private key. If the developer upgrades “AppX” to “AppX2”, he needs to use the same key which he used to sign “AppX”. This creates a trusted relationship between “AppX” and “AppX2”, because only the developer that holds the key for “AppX” can develop an upgrade for the app. But is this waterproof ?

Probably u know the answer already because else I wouldn’t have hinted it. Well, no this is not waterproof. A rather invasive bug was found in the signing process.

The core issue is that Android package (APK) files are parsed and verified by a different implementation of “unzip a file” than the code that eventually loads content from the package: the files are verified in Java, using Harmony’s ZipFile implementation from libcore, while the data is loaded from a C re-implementation.

The way that these two implementations handle multiple files with the same name occurring in the zip file differs. The way the Java implementation reads the file is that it goes through the “central directory” and adds each entry to a LinkedHashMap. The key the entry is stored using is the name of the file.

Later, the PackageParser goes through each entry in the zip file, verifying that the file was signed with a consistent signature. This code iterates over the LinkedHashMap. The result is that only the last entry with a given name is considered for signature verification: all previous duplicates are discarded.

Source : Saurik

This is a rather technical explanation of the bug, so a more noob explanation follows. As .APK files are nothing more than JAR files, this is where the problem lies. Where a JAR stands for Java ARchive, a sort of folder with all your Java code. If you want to ensure the integrity of a JAR as a self-contained entity such as an Application then the ability to sign individual files is not a requirement. In fact it is difficult to see in what circumstances the ability to sign individual files and only individual files could be a requirement.

Because it is only possible to sign individual files, a signed JAR is really nothing more than a collection of files which may or may not be signed and the verification of a signed JAR is a very convoluted way of determining into which category each file belongs. All of which leads us to question of what signed JARs are actually for ?

The ability to package files in this way was presumably considered useful when the specification was produced but it is clear that it is a decidedly sub-optimal way of attempting to ensure the integrity of an Application made up of a number of files which have been packaged as a ZIP file.

While signed JARs undoubtedly constitute a flexible mechanism for doing something, its just not clear what, they do so at a cost.

As we have seen the cost is the complexity of the verification process and the inconclusiveness of the result.

The process of verification is ridiculously complicated and consequently dangerously error-prone which is not what you want from something which is a key part of ensuring the security of your platform. (Source : Simon Lewis)

Now, what can a user do about this ? Nothing much actually. The bug is known for some time now, the only actions Google has taken so far was to change something in the .APK submission in the play store. A fix to the devices is coming with Android 4.3 . Older devices need to install the CyanogenMod custom ROM. They have included the 4 LINE BUGFIX, which google failed to deliver OTA.

Next up on the list was “Permissions”. Every app needs specific permissions to access phone functions. As an example I will include permissions my currently developing app needs :


<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_INTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_LOGS"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.WAKE_LOCK" />
<uses-permission android:name="com.google.android.c2dm.permission.RECEIVE" />

These permissions look like they’re asking a lot, but the only access they give to the phone are :

  • The use of internet
  • Ability to write to SD card(= caching images) and internal memory (= for settings)
  • Read error log on crash to send back a detailed error log to me
  • Google Cloud Messaging service
  • Accessing the network state , to check if there’s an internet connection
  • And wake lock, my app uses a service that needs to run with or without the app running , so the services needs a wake lock

These permissions will be shown to the user upon install. So this is the part where the user’s common sense plays a big part. If you want to play a game and the game asks for a whole list of permissions, the game is usual spyware. It will collect as much info as it can and will send it back to a server. The maintainers of this server will use the information to sell to advertising companies. So reading through the permissions is not time lost, as they can be pretty invasive on the privacy of the phone user.

So I did not reach a conclusion, as it as a whole research on its own (maybe a master thesis ? 😉 ). But I hope I gave some pointers that there’s a huge gap between user friendliness and optimal security of a mobile system. Any comments or questions, shoot !