SSLsplit on WiFi Pineapple

Update: after this blogpost somebody made an Infusion for SSLSplit on the WiFi Pineapple. That’s great! You can still use the howto below, but the easier way is to install the Infusion via the Pineapple bar.

Recently I was asked by a client to do a penetration test on one of their mobile apps. Fun stuff. One of the things I always test is security of the communication channel. Often SSL over HTTP is used for that. The WiFi Pineapple is a great companion for this as it provides an easy way for setting up a wireless access point with some attacks on the communication, leaving your own pentest machine free for other attacks.

Default approach to analyze traffic is to become Man-in-the-middle between App and server it communicates with. This is easily done by configuring the mobile device with a proxy (if the App communicates via a proxy aware protocol and if it accepts the system proxy settings) or to redirect traffic using iptables on the Pineapple. Than have Burp or any other proxy tool run to intercept and modify the traffic. Nothing new here.

But what was special at this specific engagement was that Burp (or any other proxy tool I know) was unable to interpreter the traffic. Yes, the iptables redirection was working, yes the SSL-mitm worked without a prob. Burp showed the initial request, and wireshark showed the traffic being forwarded to the actual server the App wanted to communicate with. But nothing was happening after that. No data, nothing. After some tinkering the hypothesis was formed that the App used non HTTP traffic over SSL and our proxy tools don’t understand it.

This is where I learned about this great tool SSLsplit. Its a proxy tool able to do full SSL certificate forging, full HTTPS decode, but also able to just show the decoded TCP and SSL traffic if it cant decode it into HTTP. Exactly what I needed! I had some compiling issues getting it to run on my Kali pentest machine. Im sure these could be fixed but I just tried installing it directly on the Pineapple. Turned out it works like a charm. Here is what you need to do:

  • SSH to your Pinapple and update the packages using opkg update
  • Get the OpenWRT libevent2 packages (all 5) from the official mirror at http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages/
  • Download the unofficial OpenWRT build of SSLsplit for OpenWRT at project Ghost on Github: https://github.com/ShaPOC/ProjectGhost/blob/master/software/sslsplit/bin/sslsplit
  • generate the SSL certificate authority and key for SSLsplit to use.
    • openssl genrsa -out certificate.key 4096
    • openssl req -new -x509 -days 365 -key certificate.key -out certificate.crt
    • Depending on the config of the mobile App you may need to import the newly generated certificate.crt onto the device.
  • Know what non intuitive parameters SSLsplit requires:
    • mkdir /tmp/sslsplit (make a working directory)
    • mkdir /tmp/sslsplit/contentlog (make a directory for session logs inside the working directory)
    • ./sslsplit -k certificate.key -c certificate.crt -D -l connections.log -S /tmp/sslsplit/ -L contentlog ssl 0.0.0.0 8888
    • This starts sslsplit with:
      • using the cert authority we just created, used for certificate forging
      • debug output to the main screen (I found this useful, you may not)
      • working dir /tmp/sslsplit, duping the actual content of the connections to /tmp/sslsplit/contentlog/
      • decoding traffic that comes in a port 8888 as ssl
  • Redirect the traffic we want to analyze to port 8888, with a simple iptables script
    • root@Pineapple:~# cat pineburp_split.sh
      #!/bin/sh
      echo ‘1’ > /proc/sys/net/ipv4/ip_forward
      iptables -X
      iptables -F
      iptables -t nat -F
      iptables -P INPUT ACCEPT
      iptables -P FORWARD ACCEPT
      iptables -P OUTPUT ACCEPT
      iptables -t nat -A PREROUTING -p tcp -d @@SPECIFIC_DEST_IP@@ –dport 443 -j REDIRECT –to-ports 8888 (watch it, parameters –dport and –to-ports are double dashes but for some reason WordPress displays them as one).
      iptables -t nat -A POSTROUTING -j MASQUERADE
  • Start your app and see if it accepts the SSL certificate. In my case it did (bad for the App, good for the pentester) and the content was dumped on the pineapple in /tmp/sslsplit/contenlog with a file per TCP sessions.

Full SSL decode. Awesome!

Advertisements

7 Responses to “SSLsplit on WiFi Pineapple”

  1. drdinosaur Says:

    So I installed those packages, downloaded SSLsplit, made the key and certifcate, installed it on an Android device, made the two directories, ran the SSLsplit command, created and ran the script with my Android device’s IP as the destination IP, but nothing seems to be coming out of the logs. Am I missing something here? Thanks.

    • The destination IP in the iptables scripts is the dest address the app originally wants to communicate with. Its not your Android device’s address.

      Also make sure sslsplit starts up properly. Use debug output if needed.

      • drdinosaur Says:

        Hmm okay. Can I be more flexible and apply this to all IP addresses/applications?

      • Sure you can, leave out the “-d @@SPECIFIC_DEST_IP@@” part. But this is just iptables tinkering and does not have that much to do with sslsplit nor the pineapple.

        Do note that if you apply this to all ssl traffic your Android device will bork as Google properly implements certificate pinning for communication back to Google services.

  2. drdinosaur Says:

    Okay, I’m getting some content now. What do you mean my SSL traffic with bork? Everything seems to be working fine. I have an active internet connection and Google apps load like normal.

    • Nice, your SSLsplit is working then.

      Let me put it differently: any app that uses certificate pinning will bork as SSLsplit is unable to make the proper certificate. I am under the impression that all core Google services on Android make use of certificate pinning, since version 4.2 maybe even earlier.

      So Play Store, Gmail and others should not be working when SSLsplit comes in between. If they do work and you are able to fully intercept the SSL traffic than Im either wrong on Google implementing certificate pinning (possible) or we just found a major issue in the Android version you are running.

  3. If i want to use burp with this. I need to fill in the machine running burp at the destination IP right?

    So in my case using a pineapple with internet sharing.

    172.16.42.42

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: