Testing Mobile apps for Heartbleed

What is Heartbleed?

Heartbleed is the name of a Security flaw (CVE-2014-0160) that was mistakenly written into OpenSSL and is thought to affect nearly two thirds of the web’s secure webpages. This flaw can potentially leak logon info or massive amounts of data thought to be secured by SSL encryption. This data could potentially include the SSL private key itself allowing an attacker to middle all SSL traffic and read the data in the clear! But Websites are not the only things effected by this. This Flaw also exists in SSL Clients such as those included in Mobile apps. So how can you tell if your apps can be exploited by this flaw ?? Easy Test it !

The N00B Method.

Shortly after the public announcement of the OpenSSL Hearbleed a set of tools to test webpages and apps for this flaw. One of those tools was https://reverseheartbleed.com/ . This tool allows you to generate a URL to use in testing your website or app by forcing it to connect to the site and generate a report based on the way the app responds to SSL Heartbeats. To quickly test your apps with this method do the following.

1. Open https://reverseheartbleed.com/ in your browser and generate a URL.

2. Set the Proxy on your Mobile Device or Mobile Device Simulator
to point to the generated URL for SSL traffic

3. Launch your mobile app and attempt a process that would normally generate SSL traffic.

4. Open the https://reverseheartbleed.com/ results link to view the reports in near real time.

5. …

6. Profit?

This is an easy test method however it doesn’t show us the practical exploit methods that these apps may be exploited with utilizing the heartbleed flaw. So were going to dive a little deeper and use a few tools to do the same test with a more advanced testing method using python and some additional tools included in the typical security analyst’s toolkit.

The Advanced method

Method 1: ARP Spoofing over wifi

In this case we will be utilizing a set of python scripts written by Lekensteyn available on GitHub called Pacemaker (https://github.com/Lekensteyn/pacemaker.git) We will also be utilizing MITMProxy and CAIN. Other tools can be used to accomplish the same outcome however this is the method I used.

1. Bootup a pen test framework (in my test I used a Customized Kali Linux Image on VM along with my Windows 8 box running Cain )

2. Clone pacemaker Github project

3. Launch Pacemaker.

CODE :


4. Launch mitmproxy from terminal using this:

CODE :

where the https://hostname is the pacemaker server if running on the same box you can use https://127.0.0.1:443

5. Set up CAIN for ARP Cache poisoning on the Network redirecting SSL traffic to MITMProxy

6. Run some apps

7. …

8. Profit ?

This method simulates the Starbucks Hack where an attacker redirects network traffic to a rogue host for traffic interception and monitoring.

Method 2: Directed Attack Utilizing ChefDNS

In this method we will continue to use MITMProxy and Pacemaker, and CAIN. In this case rather than redirecting all SSL traffic we will be directly targeting a specific app known to have the have the Heartbleed flaw by adding in ChefDNS to intercept all DNS requests for the target Host URL used by the app and replacing the IP address response with the IP of our MITM proxy. The Setup process is the same as above but rather than setting CAIN to redirect all traffic we will run the following command after cloning the Github project.

CODE :

Conclusion

The important takeaway is that it's not enough to patch your perimeter hosts - you need to purge bad OpenSSL versions from your entire infrastructure. I’m also not responsible for how you use the above info this info is provided as a testing method so you may validate that the apps you use on a daily basis are Safe from Heartbleed. If you do identify a vulnerable app or webpage please practice responsible disclosure.