Networking

Android apps and SSL: Where's the padlock?

Are we making dangerous assumptions about Android apps and SSL connections? It seems like it, but Michael Kassner asks the experts to be sure.

At the urging of security-conscious IT managers, we became aware of Secure Socket Layer (SSL) encryption, and how important it was. I'll bet Do not provide any private or financial information unless you see a closed padlock and HTTPS sounds familiar?

Exact details weren't important for most; we just knew when both were present in the web browser, it was safe for digital traffic to traverse the unforgiving internet. When cell phones became smart, those same managers dutifully reminded us that mobile web browsers also use SSL -- for example, Chrome's mobile web browser.

So, we're still safe traversing the internet using either the cellular network, or a Wi-Fi connection, as long as a closed padlock and HTTPS are visible.

What about apps?

That takes care of web browsers, but what about computer applications -- many advertise using SSL, for example Skype:

When you sign into your account on our site all the information is sent over SSL. SSL encrypts all the information before it leaves your computer, and can only be decrypted by our server.

For some reason, computer applications using SSL do not show if SSL is enabled -- no sign of a padlock or HTTPS. I've been all over the Skype app, and there is no mention of SSL anywhere. If I missed it, please let me know.

No problem, I'll test whether Skype is encrypting their traffic by using a packet sniffer. And, it sure looks like it according to the following gibberish.

When it comes to the Skype mobile application, we have a different story. Like the computer application, the mobile app does not give any indication SSL is enabled and working correctly. To make matters worse, there is no easy way to test whether the app is encrypting traffic or not.

I asked fellow TechRepublic writer and Android developer, William Francis, if applications could be altered to inform the user about the condition of the SSL connection:

Not exactly, as you could have multiple SSL connections at the same time. Monitoring all the incoming traffic would require channeling all traffic through a proxy, or a lower level (kernel) privileged application. The Android app/permission system runs interference, keeping apps from spying on network traffic being sent to other installed applications.

I received an almost identical answer from Kurt Huwig, the creator of SSL Verify, an Android app that verifies popular SSL certificates:

There is a way. One could write an HTTP proxy that verifies SSL connections. Then display an icon in the taskbar when SSL is active. Still, there are usually several apps running in the background on Android, making it difficult to associate traffic with the correct application.

It seems assuming is not a good idea

According to a German research team from Leibniz University of Hannover and Philipps University of Marburg, led by Dr. Bernd Freisleben (top picture) and Dr. Matthew Smith, a significant share of Android applications are not using SSL correctly. The introduction to the team's research paper, "Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security" mentions:

Our analysis revealed 1,074 (8.0%) of the apps examined contain SSL/TLS code that is potentially vulnerable to Man in the Middle (MitM) attacks. Various forms of SSL/TLS misuse were discovered during a further manual audit of 100 selected apps that allowed us to successfully launch MitM attacks against 41 apps, and gather a large variety of sensitive data.

Professor Freisleben wanted me to point out that although the researchers only tested free apps, one should not assume purchased apps are free of any SSL problems.

One section of the paper particularly interested me. It was where the researchers provided details about how developers would incorrectly incorporate SSL into their applications:

  • Trusting all Certificates: The TrustManager interface can be implemented to trust all certificates, irrespective of who signed them or even for what subject they were issued.
  • Allowing all Hostnames: It is possible to forgo checks of whether the certificate was issued for this address or not. For example, when accessing the server example.com, a certificate issued for some other domain.com is accepted.
  • Trusting many Certificate Authorities (CA): This is not necessarily a flaw, but Android 4.0 trusts 134 CA root certificates by default.
  • Mixed-Mode/No SSL: App developers are free to mix secure and insecure connections in the same app, or not use SSL at all. This is not directly an SSL issue. But it is relevant to mention there are no outward signs, and no possibility for a common app to check whether a secure connection is being used or not.

I now have three sources saying it's next to impossible for a user to determine if an Android application is using SSL, and using SSL correctly. If that's true, what's the research team's secret?

How do they know then?

The research team created an Androguard extension called MalloDroid, a tool that facilitates static code analysis of Android applications. Details specific to MalloDroid are:

  • Analyze the networking API calls, and extract valid HTTP(S) URLs from the decompiled apps.
  • Check the validity of the SSL certificates of all extracted HTTPS hosts.
  • Identify apps containing API calls that differ from Android's default SSL usage, e.g., contain non-default trust managers, SSL socket factories or hostname verifiers with permissive verification strategies.

Professor Freisleben explains what happens after MalloDroid has flagged apps with likely SSL problems:

We conducted a manual study of 100 cherry-picked apps to find out what sort of information is actually sent via the potentially broken SSL communication channels by installing these apps on a real phone, and executing an active MitM attack against the apps.

I'm glad they're checking apps; I don't have time to check each mobile app manually. In my digital travels, I found another group of people interested in making sure traffic from mobile devices is secure.

ZAP by Zscaler

Zscaler, a company interested in online security, needed a way to test mobile applications. So they created ZAP. Zscaler Application Profiler (ZAP) is:

[A] web-based tool designed to streamline the capture and analysis of HTTP(S) traffic from mobile applications. ZAP is capable of analyzing traffic from both iOS and Android applications.

I'm familiar with Zscaler. Three years ago, Michael Sutton, Vice-President of Security Research at Zscaler, was my expert source when I wrote about multifunction printers acting as spy tools. I called Michael, asking him to explain ZAP:

ZAP employs dynamic analysis (no code is inspected). We set up a proxy server that allows you to send traffic through our system and we analysis what is being transmitted.

Michael further explained:

Our main concern is user privacy and making sure that personally-identifiable information is encrypted. To that end, we have the user setup a fake account within the app for testing. Then when traffic from application is analyzed, we check to see if any of the fake-user data is sent in the clear.

ZAP checks the following:

  • Authentication: Username/password sent in clear text or using weak encoding methods.
  • Device Metadata Leakage: Data that can identify an individual device, such as the Unique Device Identifier (UDID).
  • Personally Identifiable Information Leakage: Data that can identify an individual user, such as an email address, phone number or mailing address.
  • Exposed content: Communication with third parties such as advertising or analytics sites.

So, with ZAP, we have one way of checking mobile applications. It sounds like the research team will have their MalloDroid website up and running soon. Together, the tools should provide a good idea of what's wrong with a mobile application.

But what then?

What are our options?

The research paper went on to list what could be done to eliminate faulty SSL implementation:

  • Enforced Certificate Checking: Force developers to use the standard library implementations provided by Android's APIs.
  • HTTPS Everywhere: A solution to improve a fair number of the vulnerabilities discovered in our sample set would be an Android version of HTTPS-Everywhere, integrated into the communication APIs.
  • Improved Permissions and Policies: Instead of a general permission for Internet access, a more fine-grained policy model could allow for more control.
  • Visual Security Feedback: Reasonable feedback to the user about the security status of the currently running application is undoubtedly a valuable countermeasure.
  • MalloDroid Installation Protection: MalloDroid could be integrated into app installers or App Markets to perform static code analysis.

The problem with each of the above suggestions, they are not something we can do. The research team did hint at something though:

[I]ntroducing policies like GSM_ONLY, NO_OPEN_ WIFI or TRUSTED_NETWORKS could help to protect apps from some MitM attacks. Despite the fact cellular networks such as GSM/3G/4G do not provide absolute security, they still require considerably more effort to execute an active MitM attack.

That's interesting; cellular networks are more secure than Wi-Fi connections. I needed confirmation, so I checked with Dr. Denis Foo Kune. He is my go-to-expert for cellular technology. You may remember my article, "Locating cell-phone owners the non-GPS way," where I explained how Denis could track people without using the phone's GPS. Denis had this to say:

The vulnerability can be exploited by anyone on the path between the device, and the server. Having the device on the cellular network makes it a little harder. An attacker needs to either be in control of a node between the service provider and the internet server, or use an off-path attack to divert traffic to a node under its control. Zhiyun Qian had a couple of papers about that.

I would say using the cellular network instead of the Wi-Fi network is slightly better (assuming you trust your cellular service provider more than people on your Wi-Fi network), but it should not be considered a final solution.

Final thoughts

That mobile applications are having trouble with SSL is disconcerting. Professor Freisleben had an interesting comment regarding this:

We got different reactions from developers we contacted; some were not aware of the issues, some switched off SSL validation checks during development (and apparently forgot to switch them on afterwards), and some argued their customers wanted them to avoid using SSL certificates.

Once again, it boils down to Buyer Beware. Check mobile apps at installation, every time the application is updated, and consider using cellular connections if there is the slightest concern about security or privacy.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

7 comments
weeasle
weeasle

 Hi,

Great article. I do some mobile app making in my spare time.The three sources you mention were probably not developers... It is almost trivial to de-compile source code Android (and especially Win Store Apps). To get the binaries one must root the Android device and then just google de-compiling Android apps.. its all ready available and not too hard.. Basically if you are an app-maker just accept the reality that like it or not, your source code is open-sourced.. Plan for it and mitigate accordingly..


Also Android OS by default rejects SSL handshakes for self-singed Certs. This is an inbuilt security feature of the OS. However, programmatic methods allow bypassing this check.. I do see why Android allowed it - Perhaps some apps only want to send performance or analytics data not containing financial/personal details and developers shouldn't be forced to shell out to a trusted Cert provider...


Thanks again,


Chris

JCitizen
JCitizen

One of my big concerns with mobile SSL is session riding - maybe Trusteer will come up with something; but quite frankly, I have no idea whether Chrome can mitigate that problem or not; or even if it has a sandbox in mobile versions.

JCitizen
JCitizen

I've been concerned about this for a while - now my concerns are validated! Thanks Michael!

Michael Kassner
Michael Kassner

They have been up front about SSL/TLS. It's the apps that are not.

Michael Kassner
Michael Kassner

It also begs the question about computer apps and SSL -- the more I think about it. I just assumed...

Wunderbarb
Wunderbarb

The listed problems are not limited to Android apps using SSL. They are also present on non browser apps using SSL for many platforms. See the recent paper from M. GEORGIEV et al. [1] Furthermore, SSL has been seriously challenged by the community in the last year. This is a good thing as SSL/TLS becomes dominant and thus an interesting target. It is important to discover the vulnerabilities of the protocol and of the different implementations and use. We have made a review of the latest discovered issues of SSL in our security newsletter 22. (http://eric-diehl.com/wp-content/uploads/2012/05/Security-Newsletter-22.pdf) [1] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V. Shmatikov, “The most dangerous code in the world: validating SSL certificates in non-browser software,” Proceedings of the 2012 ACM conference on Computer and communications security, New York, NY, USA: ACM, 2012, pp. 38–49.

Michael Kassner
Michael Kassner

It is always good to get input from you and your team. That is quite a newsletter. The cover is neat. A recent article of mine was about side-channels and VMs. Also congratulations on the book.

Editor's Picks