Chủ Nhật, 16 tháng 3, 2014

Use SSLsplit to transparently sniff TLS/SSL connections – including non-HTTP(S) protocols

SSLsplit is a generic transparent TLS/SSL proxy for performing man-in-the-middle attacks on all kinds of secure communication protocols. Using SSLsplit, one can intercept and save SSL-based traffic and thereby listen in on any secure connection.
Contents
  1. 1. How it works
  2. 2. Install & run SSLsplit
    1. 2.1. Redirect traffic
    2. 2.2. Installation
    3. 2.3. Create and install root CA certificate
    4. 2.4. Enable IP forwarding and NAT engine (iptables)
    5. 2.5. Run SSLsplit
  3. 3. Examples
    1. 3.1. Sniffing HTTPS (google.de & facebook.com)
    2. 3.2. Sniffing IMAP over SSL (imap.gmail.com)
    3. 3.3. Sniffing SMTP over SSL (smtp.gmail.com)

1. How it works

SSLsplit works quite similar to other transparent SSL proxy tools: It acts as a middle man between the client and the actual server. Provided that traffic is being redirected to the server on which SSLsplit is running (by changing the default gateway, ARP spoofing or other means, see below), SSLsplit picks up SSL connections and pretends to be the server the client is connecting to. To do so, it dynamically generates a certificate and signs it with a the private key of a CA certificate that the client must trust.
If, for example, a client wants to send an e-mail using the secure Gmail SMTP server (smtp.gmail.com on port 465), SSLsplit creates a certificate for “smtp.gmail.com” and thereby pretends to be the Gmail mail server towards the client. In the upstream direction (towards the actual Gmail mail server), SSLsplit connects to the server just like a normal client — forwarding all the traffic the actual client writes on the SSL socket.

2. Install & run SSLsplit

After explaining the basic concept of how SSLsplit works, this section will describe how to actually use it to intercept SSL (and non-SSL) traffic.

2.1. Redirect traffic

This tutorial assumes that you have already placed your attacker system somewhere in between the victim machine and the server. This can be done in many different ways — here are some examples:
  • Use ARP spoofing to redirect the traffic of the victim by publishing false mappings from the standard gateway MAC address to the attacker’s IP address. You do not need physical access to the victim’s device to do that. Check out the arpspoof tool.
  • Change the default gateway address in the victim’s network settings. This is the easiest method if you have access to the victim’s device.
  • Forging DNS entries with a DNS server that returns the attacker’s IP address for certain (or all) domains. See my tutorial about DNS spoofing with Dnsmasq to learn how to do that.
  • Redirect traffic for individual domains by modifying entries in the /etc/hosts file of the victim’s machine.
  • …
As mentioned above, the easiest way is to just change the default gateway address in your victim’s device to the attacker’s IP address. That makes sure that all the traffic goes through your machine. And since we later need to install a CA certificate, we need physical access to the victim’s machine anyway.

2.2. Installation

As of now, there is no Debian package in the repositories for SSLsplit. The code is hosted on different mirrors, managed by the author Daniel Roethlisberger, as well as on Github.
To download and compile SSLsplit, run the following commands:
These commands download and extract the source code (wget, bunzip2, tar), install necessary dependencies (apt-get), and then compile it using make.
The temporary directory created at /tmp/sslsplit is later used to dump the connection log file and the raw data of the incoming and outgoing SSL sockets.

2.3. Create and install root CA certificate

For SSLsplit to act as a middle man for SSL connections, it needs to be able to generate and sign certificates that the victim trusts. In order to do so, the victim must have the attacker’s root CA certificate in its trust store. Depending on the type of client (desktop browser, mobile phone), installing root certificates differs a bit (see here for Firefox, Windows,Android, …)
If you don’t already have a self-signed CA private key and certificate, you can generate one using the following commands:
The first command generates an 4096-bit RSA private key in PEM format (ca.key), and the second command uses this private key to generate a self-signed root CA certificate (ca.crt). Both are needed by SSLsplit later, but only the certificate file needs to be installed in the browser or operating system of the victim.

2.4. Enable IP forwarding and NAT engine (iptables)

In this example, SSLsplit will be running on two ports: 8080 for non-SSL TCP connections such as HTTP, SMTP or FTP, and 8443 for SSL connections such as SMTP over SSL, HTTPS, etc. In order to forward packets arriving at the attacker’s machine to these internal ports, the NAT engine in iptables can be used.
The commands above first enable IP forwarding (sysctl ...) to enable the system’s router functionality. After running this command, Linux will forward IP packets not meant for the local machine to its standard/default gateway, thereby acting as a router.
To prevent Linux from forwarding everything right away, NAT rules can be defined. In this example, certain packets are redirected to the local port 8080 and 8443. Packets for the plain text traffic on ports HTTP (80) and WhatsApp (5222) are redirected to port 8080, and packets for SSL-based traffic on ports HTTPS (443), IMAP over SSL (993), SMTP over SSL (465 and 587) are redirected to port 8443.

2.5. Run SSLsplit

Once the IP forwarding is active and packets are being forwarded to the relevant ports, you can start SSLsplit. That sounds easier than it actually is, because SSLsplit is a very powerful tool and therefore very flexible. Check out the short documentation on the SSLsplit website, as well as the more verbose SSLsplit man page.
For the use case described above, a sensible parameter configuration would be something like this:
This command starts SSLsplit in debug mode (-D, runs in foreground, no daemon, verbose output) and outputs connection attempts in the log file “connections.log” (-l ..). The actual content of the connections is written to the “/tmp/sslsplit/logdir/” (-j .. and -S ..) — each incoming/outgoing TCP stream of each connection in a separate file.
This is it. Assuming you have configured your clients correctly, you can now start browsing and send/receive e-mails. SSLsplit will output connection details on the console:
In addition to the console output, SSLsplit will write the TCP socket conversations to the above mentioned log directories. After running SSLsplit for a while, there will be quite a few files in the log directory — one for each connection or TCP socket between client and server:
Each file indicates the exact time the TCP socket was opened as well as the source and destination IP address and port. You can take a peek in the file using head ..., or use your favorite text editor:

3. Examples

You can listen into many different protocols using SSLsplit. Below are a few examples for HTTPS, IMAP over SSL and SMTP over SSL.

3.1. Sniffing HTTPS (google.de & facebook.com)

Once the SSLsplit is running, all communication between the client and the actual servers goes through SSLsplit. Using the -D option, SSLsplit prints connections and certificate forgeries on STDOUT. In addition to that, the content is written to the logdir (“/tmp/sslsplit/logdir/”). Using something like tail -f /tmp/sslsplit/loggdir/20130804T162301Z-*.log, you can follow the communication between server and client.

In the screenshot above, the upper console window shows the output of SSLsplit. It shows the real upstream Facebook certificate (with the fingerprint f5:6b:f2:44:...), and the forged certificate by SSLsplit — naturally with a different fingerprint, because it was signed by a different certificate authority.
The lower console window shows the content of the HTTPS communication between the browser and the Facebook server. The example screenshot shows the HTTPS POST request to “https://www.facebook.com/login.php?login_attempt=1″, including my username (&email=...) and the password (&pass=...).
If one were to click on the little lock icon on any SSL/TLS encrypted site whilst redirecting traffic through SSLsplit, the certificate would be issued to the real common name (CN), organization (O) and organizational unit (OU), but not issued by the real CA.

The example above shows the fake certificate for “www.google.de”, issued by my previously generated “Fake CA Certificate”.
Note:: If you’re interested in sniffing into HTTPS only (not: SMTP over SSL, IMAP over SSL, or any other non-HTTPS traffic), be sure to check out mitmproxy and my mitmproxy tutorial. It is much more convenient to use than SSLsplit.

3.2. Sniffing IMAP over SSL (imap.gmail.com)

In the second example I used Thunderbird to connect to my Gmail account. Unlike a web based mail client, Thunderbird connects to the Google/Gmail server via IMAP on port 143 or via IMAP over SSL on port 993. While the communication on port 143 is unencrypted and can be read with other tools (Wireshark, tcpdump, etc.), IMAP over SSL requires a man-in-the-middle proxy to split the SSL communication.

The screenshot above captures the initial connection of Thunderbird to the Gmail IMAP server (normally imap.gmail.com, here: imap.googlemail.com) on port 993. Like in the first example, the upper console shows the SSLsplit debug output (showing how SSLsplit forged the certificate), and the lower console shows the bytes exchanged over the SSL socket.
As you can see in the screenshot, the IMAP communication includes an exchange of client and server capabilities (1 capability) with a little inside joke from the developers of the server (1 OK That's all she wrote ...), as well as the authentication (3 login "e-mail@gmail.com" "password"). The latter part is probably most interesting to attackers.
After the authentication, client and server both agree to continue the conversation using compression (4 COMPRESS DEFLATE), so the rest of the message is naturally not human readable anymore. However, since it’s only compressed and not encrypted, it can be made readable using simple Linux tools.

3.3. Sniffing SMTP over SSL (smtp.gmail.com)

As you might have guessed by now, this method also works for SMTP over SSL: In this example, I used Thunderbird to send an e-mail to myself using the Gmail SMTP server on port 465.

Like in the two other examples, the screenshot shows the SSLsplit output in the upper console window and the conversation output in the bottom console. The SMTP conversation shows a humorous greeting of the Gmail server (250-mx.google.com at your service ...), as well as the initial login of the Thunderbird client using SMTP AUTH (AUTH PLAIN ...). It then starts drafting the mail using standard SMTP commands (MAIL FROM, RCPT TO, …).
Again, the most interesting part is the plain text authentication: Since the transport is secure, the password is sent in plain text — only encoded using Base64. So if the line above was something like AUTH PLAIN Qml0ZSBtZSBpZiB5b3UgY2FuISEhISEhIQo=, it could be easily decoded with the one-liner:
echo 'Qml0ZSBtZSBpZiB5b3UgY2FuISEhISEhIQo=' | base64 --decode.
I’ll leave it to you to decode this :-).

Download: https://github.com/droe/sslsplit
Người đăng: vào lúc

Không có nhận xét nào:

Đăng nhận xét

Đăng ký: Đăng Nhận xét (Atom)