securify - how we steal your selfie - droidconnl 2014
TRANSCRIPT
www.securify.nl
Agenda•Introduction •Common flaws Android apps
•Javascript interface •SSL/TLS
•Demo •Test results 1000 NL apps
www.securify.nl
Common flaws Android apps•Insecure Javascript interface •Insecure SSL/TLS (or worse no SSL)
These two issues combined allows for remote compromise of your selfies -‐ for example via a public WiFi hotspot
www.securify.nl
Javascript interface (bridge)•Used in combination with WebViews •Allows Javascript to call Java methods •The interface can be any Object •The Object’s public methods are exposed (with some limitations)
public void addJavascriptInterface (Object object, String name)
www.securify.nl
Javascript interface -‐ example class JsObject { public String toString() { return "injectedObject"; } }
webView.addJavascriptInterface(new JsObject(), "injectedObject");
webView.loadData("", "text/html", null); webView.loadUrl(
"javascript:alert(injectedObject.toString())");
www.securify.nl
Javascript interface -‐ the flaw•On Android < API lvl 17 (4.2) ANY public method can be invoked •Including Reflection API exposed through Object (!)
•Object.getClass()
www.securify.nl
Javascript interface -‐ the fix•On Android >= API lvl 17 access to public methods not allowed •UNLESS the method is annotated
•@JavascriptInterface •Problem: you’ll need to build against API 17 (target SDK) •Build against a lower API level and you’re still vulnerable •Also old devices will still remain vulnerable!
•If possible disable Javascript interfaces on old devices
www.securify.nl
Javascript interface -‐ fixed example class JsObject { @JavascriptInterface public String toString() { return "injectedObject"; } }
webView.addJavascriptInterface(new JsObject(), "injectedObject");
webView.loadData("", "text/html", null); webView.loadUrl(
"javascript:alert(injectedObject.toString())");
www.securify.nl
Insecure SSL/TLS•SSL/TLS provides integrity, confidentiality & authentication •Default SSL implementation provides security similar to web browsers
•Various ways to screw this up, including: •Insecure Trust Manager •Insecure Host Name Verifier •Insecure SSL Error Handler (WebView)
www.securify.nl
Insecure Trust Manager•The default X509 Trust Manager performs basic checks like:
•Server certificate signed by trusted CA •Validity of server certificate •Revocation status
•You can create your own Trust Manager •Your Trust Manager is insecure if you:
•Fail to call default Trust Manager (no basic checks) •Create empty check* methods like checkServerTrusted()
www.securify.nl
Insecure Trust Manager -‐ examplepublic class InsecureX509TrustManager implements X509TrustManager {
@Override public void checkClientTrusted(X509Certificate[] x509Certificates, String s)
throws CertificateException { }
@Override public void checkServerTrusted(X509Certificate[] x509Certificates, String s)
throws CertificateException { }
@Override public X509Certificate[] getAcceptedIssuers() { return null; }
}
www.securify.nl
Insecure Host Name Verifier•Java does not check whether the server’s certificate matches the domain name it is connecting to
•This check must be implemented via a Host Name Verifier •Apache HttpClient has solved this by providing default Host Name Verifiers
•An insecure Host Name Verifier accepts any valid certificate for any domain name •Example a certificate for google.com is valid for apple.com
www.securify.nl
Insecure Host Name Verifier -‐ flaws•An Insecure Host Name Verifier can exists if:
•Apache HttpClient is not used and a Host Name Verifier is not implemented
•ALLOW_ALL_HOSTNAME_VERIFIER of HttpClient is used
An attacker can purchase a valid certificate for any domain and use it to attack your app.
www.securify.nl
Insecure SSL Error Handler•WebViews have an onReceivedSslError() method •This method is invoked for invalid certificates •By default is calls cancel() •You can call proceed() •Doing so makes your WebView insecure!
www.securify.nl
Testing 1000 Dutch apps on SSL usage
FireEye, Aug 2014:
tested 1,000 most-‐downloaded free applications in the Google Play store.
•73% have broken SSL
www.securify.nl
Testing 1000 apps on SSL usage
Will Dormann -‐ US CERT researcher, Aug 2014:
List of 350 Android Apps that fail to validate SSL certificates.
www.securify.nl
But how are we doing?
Research question:
How are Dutch apps handling private data on the wire?
www.securify.nl
Challenges?
• Get 1000 Dutch Android apps. • What is private data? “personally identifiable information” • Scope on public traffic only. (sign-‐on/in). • Static analysis (RE) has high false-‐positive rate. • Generating traffic for free (trigger events) -‐ work to do. • Human interaction needed :-‐(
www.securify.nl
Set-‐up in a nutshell?
1. Static check 2. Install app 3. Launch 4. Generate traffic 5. Inspect traffic 6. Uninstall
www.securify.nl
What did we see on the wire?
.. name, address, date of birth, e-‐mail, phone, username, password, secrets, insurance policy number, bank account, creditcard, pictures, medicine prescriptions, diary, BSN, political preference, FB credentials, appointments, tickets ..
www.securify.nl
The numbers
531469
We started with 1000 apps
No network or no private data
Sends private data
www.securify.nl
The numbers
55% 289
45% 242
We continue with 531.
SSL
No SSL + broken SSL (unknown CA)
www.securify.nl
Responsible disclosure
• This is not about naming and shaming • Main goal to increase awareness amongst app-‐builders
• Time needed to fix things properly (client/server updates) • Large number is not informed yet (time consuming)
www.securify.nl
What can you do?
• Does your app put private data on the wire? • Is this data protected (e.g. SSL) while in transit? • Test your SSL (it is not that hard). • Does your company have a responsible disclosure point?
www.securify.nl
Is your app tested?
https://www.securify.nl/1000apps
Just and experiment and to speed up things. We will not use your data commercially!
www.securify.nl
AppVer (in private beta)
• Self check your app on issues like this • Semi automated static and dynamic testing • Upload or link your app (binary) • Free
• Needs work, but making progress.