Takeaway: Are we making dangerous assumptions about Android apps and SSL connections? It seems like it, but Michael Kassner asks the experts to be sure.
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.
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.
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
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.
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 Zscalar
Zscaler, a company interested in online security, needed a way to test mobile applications. So they created ZAP. Zscalar 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.
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 Certi?cate 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.
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 troubling. 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.
Source: http://www.techrepublic.com/blog/security/android-apps-and-ssl-wheres-the-padlock/8836
2016 Olympics TD Bank mountain lion hanley ramirez Christian Bale visits victims Perez Hilton national weather service
More Memory = A Faster Mac. OWC Has Memory Upgrades For All Mac Desktops & Laptops - Prices Dropped For The Holidays! Free Shipping on All Memory Orders Over $25! Macsales.com