Saturday, 3 November 2012

Testing Android Apps for the ones doing SSL wrong

Recently there was a paper published that showed that a lot of Android Apps do SSL badly. The Register has good summary of the paper if want the highlights. In sentence Android Apps do SSL badly and there are security issue because of it.

This got me thinking what do the apps that I personally use do. I wanted to know if they did HTTP or HTTPS, hopefully they all do HTTPS when there is personal stuff, and if they do HTTPS what is their certificate handling like. When the apps gets a bad cert does it fail, prompt the user to tell them or just works and doesn't tell the user about the bad cert.

To test this for the Man in the Middle portion, dishing up bad certs and capturing of the data I was using the Burp Proxy. If you don't know about Burp it is an awesome Web Security tool that is very handing for testing web apps be that functionally or from the security angle.

The next step seeing most Android Apps don't respect/use the global proxy set up you have to get a little bit more cunning and have a little fun with the set up, to force all the traffic through Burp. So throw in a WiFi Pineapple as an access point, Backtrack and some iptables rules and you can do the testing I want to do. The physical set up looks like:
Photo showing the set up I am using

So the magic to make it all work and direct all the port 80 HTTP and port 443 HTTPS traffic from the phone through the Burp Proxy is: 
  1. On Backtrack download Burp
  2. Get Burp running java -jar burpsuite_free_v1.5.jar
  3. Set up the proxy in burp to listen on all interfaces and to be in invisible mode (my was listening on port 8080)
  4. Plug in the cables, Pineapple etc.
  5. Run wp4.sh to get the basic forwarding set up so data from eth1 gets forwarded onto eth0 for the internet
  6. I have to run ifconfig eth1 172.16.42.42 to get my laptop on the right IP for the Pineapple to do the forwarding right as it assumes that 172.16.42.42 the computer that is doing the internet connection sharing
  7. Connect the phone to the Pineapple's WiFi
  8. Ensure that internet on the phone is working and apps work normally etc
  9. Do some iptables magic to make port 80 and 433 go through Burp
    • iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8080
    • iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 443 -j REDIRECT --to-ports 8080
    • iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
    • iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080
  10. Run the app under test and you should see all the traffic being intercepted in Burp. If you get an SSL Cert warning it is because the app is seeing Burp's cert not the real cert
(That is my set up but I am sure you could adapt depending on the tools you have to hand. The hardest bit was find and figuring out the iptables bit)

So now onwards to test the apps I use to see how they behave. I see them falling into four categories:
  1. Seriously WTF!?! you are doing HTTP. Super easy to inject into, capture all data etc. Super Bad
  2. You are doing HTTPS but you never told me that you didn't get a valid cert. Issue here is someone could be Man in the Middling the connection and I will never know. Bad
  3. I get a dialog saying that there is a bad cert and asking me if I want to continue or not. This is good as at least I know that something isn't right but Joe Public will just click through and the malicious user will see everything that the app is sending password, tokens, personal info etc. Ok
  4. The app will just not work as it will only work with the expected cert or a valid cert. This is the best situation really as for end users they should only see valid certs. Non valid certs should really only show up in test or personal set ups. Sweet
So I will do some testing now. I will report back later and tell you all what I find.

If you need to clear out your iptables:
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT