Practical SSL/TLS Attacks and Decrypting Web Traffic

Introduction: Practical SSL/TLS Attacks and Decrypting Web Traffic  Chang Tanchangtan@listerunlimited.comFor 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.  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 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.  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  Then generate the mandatory browser-installable client certificate and then distribute this certificate to your victims, or install it covertly.   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.  Now compile Squid with our special options  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.  Then add a new launcher command by creating a symbolic link to Squid 4.5's binary.     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.  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.  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.  Now start up Squid on the attacker machine.   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.    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.