www.securify.nl

How  we  steal  your  selfie

24/11/14

droidconNL  2014

www.securify.nl

You  may  have  heard  of  us

www.securify.nl

History

www.securify.nl

Software  Security  Testing

mobile  &  web

www.securify.nl

Build  Security  In

www.securify.nl

Agile  Security  Testing

www.securify.nl

We’re  happy  to  tell  you  more!

Securify  B.V.  Naritaweg  106  C  Amsterdam  Sloterdijk

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

Javascript  interface  -­‐  demo

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

Insecure  SSL  Error  Handler  -­‐  demo

Demo

www.securify.nl

Testing  1000  Dutch  apps  on  SSL  usage

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

Set-­‐up  in  a  nutshell?

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

63%  332

37%  199

We  continue  with  531.

SSL

No  SSL

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.

www.securify.nl

AppVer  (in  private  beta)

www.securify.nl

AppVer  (in  private  beta)

Thank  you!

we’re  hiring