Using nogotofail to Find Issues with Your HTTPS Connections.
As the Internet moves to HTTP 2.0, all traffic on the Internet will be encrypted. From a security perspective, this is good, as HTTPS is encrypted and harder to read than HTTP (which is clear text). However, HTTPS is not without its faults. Just this month (March 2015), another HTTPS vulnerability FREAK Attack was announced. In 2014, other HTTPS vulnerabilities (with equally catchy names of POODLE, Heartbleed, and ShellShock) were uncovered. These exploits have shown us that, while HTTPS connections can still be secure, they still may have vulnerabilities to hacking. It is essential that any connection you use to transmit HTTPS data is protected against these (and other common) HTTPS attacks.
The Android security team realized this importance, and last November they launched nogotofail (named to block the gotofail exploit). It establishes a man in the middle server and attempts to inject attacks into the connections your mobile application makes between the server and the device. This is a really powerful tool, so I thought it would be useful to walk you through the steps to set up a nogotofail testing instance. Some of the attacks that nogotofail detects are:
* Warn for all connections on HTTP (rational is HTTPS is more secure for all)
* Authorization headers in HTTP (sending credentials in headers that are not encrypted)
* Image replacement
* Attempt to strip HTTPS and force connection on HTTP
* Detect weak and insecure TLS ciphers
* Potential Heartbleed, POODLE and gotofail SSL vulnerabilities.
Even though this tool was built by the Android security team, you can connect any device to test for SSL vulnerabilities.
The testing setup described in this post is based on the Google Compute Engine setup described in the docs. The instructions to set up the Google Cloud Instance are clear and straightforward. To work in the Cloud SDK, you need to download the tools: https://cloud.google.com/sdk/. You basically set up a Cloud Compute Instance, set up the VPN rules, copy the nogotofail files:
gcloud compute copy-files nogotofail ngtf1:~/
Then run the install script (docs/gce/setup.sh) to add the VPN, man in the middle and all of the software you need. Once this is completed, you must copy the VPN token to your computer:
gcloud compute copy-files ngtf1:/etc/openvpn/nogotofail.ovpn nogotofail.ovpn
Then copy onto your Android device. Using OpenVPN (available in Google Play), you import the VPN profile, and connect to the cloud instance.
There are 2 Android apps in the Github repository. Open them in Android Studio and build them onto your Android device. The nogotofail app will connect automatically to the Cloud server (assuming the VPN connection is up and running).
The cool thing is that you can use the mitm.conf file on the server to set up the attack vectors (you can see them all with the command nogotofail-mitm –help) so that multiple devices can face the same attacks. Or you can control the attacks for your device from the app allowing for multiple testers to use different attack configurations simultaneously.
To start the server and stop the nogotofail service, you connect to the instance (by ssh) and:
sudo /etc/init.d/nogotofail-mitm startsudo /etc/init.d/nogotofail-mitm stop || true
When you first connect your device, you’ll need to authorize the connection:
You can also see in this menu that you could connect to a local nogotofail server by modifying the host field. From the device settings, click a few of the attacks and begin testing your mobile app (in this case the Heartbleed attack). The nogotofail server will attempt one of the attacks at the probability chosen in the settings (we have chosen default in the screenshot).
If the nogotofail server successfully finds a fault, the phone will vibrate, and you’ll get an alert in the notifications bar (a goofy smileyface). This will tell you details about which app and what issue caused the problem. You can also get details of the issue in the log:by following the log in realtime:
ssh <vm name>.<zone>.<project ID>logs you into your instance, andtail -f /var/log/nogotofail/mitm.log
It will play the log in realtime for you. If you wish to download for later analysis:
gcloud compute copy-files ngtf1:/var/log/nogotofail/mitm.log mitm.log
Here are sample outputs from the nogotofail log report:
2015-02-27 17:36:48,541 [INFO] [10.8.0.2:55400<=>220.127.116.11:443 clientheartbleed](client=google/shamu/shamu:5.0.1/LRX22C/1602158:user/release-keys application=”com.amazon.mShop.android.shopping” version=”502030″) Selected for connection
In the log file, you can see the date and time. The [info] tells me that nothing bad happened here, and the data is just informational. We can see the IP endpoints of the connection, and the attack that was attempted in this connection (clientheartbleed – attempting to see if the app client is susceptible to the hearbleed security flaw). If no attack is made, this will read ‘logging.’ The phone is the Nexus6 (codenamed Shamu) running Android 5.0.1, and the app that was attacked was the Amazon Shopping app. In this case, the attack failed, as the next entry closed the connection:
2015-02-27 17:36:48,610 [INFO] [10.8.0.2:55400<=>18.104.22.168:443 clientheartbleed](client=google/shamu/shamu:5.0.1/LRX22C/1602158:user/release-keys application=”com.amazon.mShop.android.shopping” version=”502030″) Connection closed
The Amazon app also failed to run – the app was smart enough to see an attack was underway, and it loaded nothing. (You can see the smileyface notifications for other issues that did succeed in this screenshot.)
When an issue occurs, the [INFO] label is replaced by [ERROR] or [CRITICAL] warnings:
2015-02-26 18:47:49,124 [ERROR] [10.8.0.2:39887<=>22.214.171.124:443 weaktlsversiondetection](client=samsung/t0lteatt/t0lteatt:4.1.2/JZO54K/I317UCALL1:user/release-keys application=”<appname>” version=”28″) Client enabled SSLv3 protocol without TLS_FALLBACK_SCSV
This application allows a connection via SSLv3 without the TLS fallback – potentially exposing the application to a POODLE attack.
Finally, here is an example of a CRITICAL attack:
2015-03-02 22:03:03,592 [CRITICAL] [10.8.0.3:56720<=>REMOTE IP selfsigned](client=google/shamu/shamu:5.0.1/LRX22C/1602158:user/release-keys application=”<another app name>” version=”224″) MITM Success! Cert file: /tmp/.cert_-4211112275101874746.pem2015-03-02 22:03:03,594 [ERROR] [10.8.0.3:56720<=>REMOTE IP httpdetection](client=google/shamu/shamu:5.0.1/LRX22C/1602158:user/release-keys application=”<another app name>” version=”224″) HTTP request GET <url accessed>
In this attack, the nogotofail MITM proxy used a random (see below) self-signed certificate and provided it to the application (whose name I have redacted). The application accepted this certificate and allowed the connection to be established and transmit data. This is a potential attack vector into the mobile application, as now a hacker knows that they can use any key they want to gain access to the data stored by this application. In the subsequent request, the application used HTTP over HTTPS to transmit data.
[EDIT: Chad Brubaker from the Android security team pointed out that the cert is not random: “Not quite ‘random’, it is a self-signed cert for the domain the client is trying to connect to. Ngtf copies the CN and subject alt names returned by the actual server and generates a self signed cert with the same.”]
Setting up an HTTPS connection and assuming that everything is ok is not enough to ensure that your data is being sent over the air securely. In order to verify that you have set up HTTPS connections correctly, it is a good idea to test your application with tools like nogotofail to ensure that you are not vulnerable to one of the many HTTPS weakpoints.
I cover usage of nogotofail, other security tools, and lots of performance tuning in my book High Performance Android, available as a pre-release from O’Reilly.