Hacking

On SSL

Adrian Birsan
February 5, 2013 by
Adrian Birsan

In this article you will find useful information about SSL, Certificates Chaining and the best tricks about defeating SSL (with SSL Sniff, SSL Strip, BEAST, THC-SSL-DOS).


What Is SSL and how does it work?

Earn two pentesting certifications at once!

Earn two pentesting certifications at once!

Enroll in one boot camp to earn both your Certified Ethical Hacker (CEH) and CompTIA PenTest+ certifications — backed with an Exam Pass Guarantee.

The Secure Sockets Layer (SSL) is a protocol used by millions of websites to protect data as it moves between the user's computer and the server the website is hosted on. SSL provides secure communication between client and server, following three main goals: Privacy, Integrity and Authentication. To make this possible, SSL uses : -Encryption - Hiding what is sent from one computer to another by changing the content using cryptography - based on a public-Key encryption. -Identification - Making sure the computer you are speaking is the one you trust.

Originally invented in the 1990s, it has been upgraded many times and is often referred by its newer name Transport Layer Security (TLS).

Figure1


Certificate Chaining

When people think about certificates, they usually think about certificates coming in pairs. Actually instead of just 2 certificates, there could be more. You can have a certificate chain as there are no standard that says how many the maximum is.

Let's see how we verify them:

-Verify that the name of the leaf is the same as the site you're connecting to

-Verify that the leaf certificate has not expired

-Check the signature

-If the signing CA's is in our list of trusted root CA's, STOP. Otherwise move one up the chain, and repeat.

Figure2

So we can observe the verification is made using a simple recursive function, focused on signature validation.

The results of a naive attempt at validation is a chain that is complete and nothing more.

Let's say we have this scenario:

Figure3

What will stop me of doing this ?:

Figure4

Creating another Certificate, for some other website, paypal.com for example, signing it with our leaf certificate (infosecinstitute.com) and then pass this chain to any client. So, if we go back and look how to validate, everything will look like normal:

-All signatures are valid;

-Nothings has expired;

-The chain is intact;

-The root CA is embedded in the web browser and trusted.

But we just created a valid certificate for Paypal, and we are not Paypal.

The missing piece is a somewhat obscure field, called basicConstraints.

The Basic Constraints idea is that not all certificates should do everything. If you have an end entity certificate to identify a website, that certificate should be used just to identify your website. It shouldn't be used to sign other certificates, for key revocation or any other reason.

Figure5

Back in the day, the problem was that most CA's (SSL implementations) didn't bother to check this, leaving basicConstraints field blank. So anyone with a valid leaf node certificate for a domain could create and sign a leaf node certificate for any other domain and presented with a complete chain; IE, Outlook, Konqueror, OpenSSL and others, considered it valid.

SSLSNIFF - A tool for automated MITM attacks on SSL connections

Figure 6

On the client side:

-Intercept a connection from the client side;

-Generate a certificate for the site it is connecting to;

-Sign it with any random valid leaf node certificate;

-Pass the certificate chain to the client.On server side:

-Make a normal connection to server;

-Pass the data between client and server decrypting and encrypting at each end.

Quick How To:

Setting up iptables

-Flip your machine into ip_forward mode

echo 1 > /proc/sys/net/ipv4/ip_forward

-Add a rule to intercept SSL traffic

iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-ports <$listenPort>

-Run arpspoof

arpspoof -i <eth1> -t <targetIP> <gatewayIP>

SSLSNIFF Post Disclosure

The question becomes: Is this tool still useful? You'd be surprised who still doesn't check basicConstraints. Even after the browsers have been patched, this tool is still useful because most people who get SSL warning dialogues, they ignore them and just click through them.

So it is still useful as a general man-in-the-middle tool for SSL and for deploying other vulnerabilities as well.

After the latest updates, sslsniff supports modes for hijacking auto-updates from Mozilla products, as well as for Firefox/Thunderbird add-ons. Attackers can specify payloads of their choice, which will be delivered to the targets being the man-in-the-middle.

==================================================================================

Get SSLSNIFF - https://github.com/moxie0/sslsniff

SSL Stripping - The concept of bridges

In the content of web browsing, SSL is almost never encountered directly. Very few people type HTTPS:// when they are going on a webpage, most just use the name of the website directly. The secured protocol is encountered as result of a 302 redirect form from a http:// url to a https:// url and mostly on links that users clicks on (shopping, checkout, sign-in, etc…) Both of these points are like bridges between insecure and secure protocols.

Basically, sslstrip performs a MITM attack on all http connections on the network. Then it watches the traffic go by and it's looking for two forms, links and 302 redirects from http:// to https://.

-When finds a https:// link, it swaps it to an identical http:// link and it keeps a map of what is changed.

-When finds a 302 redirect, it looks for the location header, which is where the redirect URL will be, and if see a https:// link in there, it will swap it for an identical http:// link and keeps a map of what is changed.

Then it will continue to watch http traffic go by and if will see a request for a URL that was stripped, it will send SSL to the server. So the server will not get something wrong, it's getting the SSL connection as it expect but on the client side, it still happens to be HTTP://.

Let's take a quick look over SSL Strip Features:

-ARP spoofing, the attacker can intercept all network traffic of the target host;

-The attack will turn all HTTPS connections to HTTP instead;

-Meanwhile, the target server will receive a normal HTTPS connection as expected;

-HTTP traffic is transmitted in clear, so an attacker can easily implement sniffing.

Quick How To:

-Enable kernel packet forwarding

echo "1" > /proc/sys/net/ipv4/ip_forward

-port forwarding, (I will use port 10000 as listening port);

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port <$listenPort>

-ARP spoofing (get arpspoof from here http://sourceforge.net/projects/arpspoof/files/arpspoof/arpspoof/);

arpspoof -i <eth1> -t <targetIP> <gatewayIP>

-Run sslstrip.

sslstrip.py -l <$listenPort>

================================================================================

Get SSL STRIP - https://github.com/moxie0/sslstrip

Convergence

Back in 2011, after Comodo Company got hacked several times, Moxie figured out what we actually really need in order to browse securely. He called it Trust Agility, and pointed 2 properties that are the essence of what's Certificate Authorities have missed:

-Individual users can decide where to anchor their trust;

-A trust decision can be easily revised at any time.

After creating 2 deadly tools to defeat SSL (SSLSniff and SSLStrip), Moxie Marlinspike came with his solution for replacing SSL Certificate Authorities, Convergence.

Moxie advertises the project as a way of dispensing with certificate authorities ("An agile, distributed, and secure strategy for replacing Certificate Authorities"). At the first glance that's true. You get a Firefox add-on that, once activated, completely replaces the existing CA infrastructure. Whenever you visit an SSL site, your browser will talk to two or more remote parties (notaries) and ask them to check the site's certificate for you. If they both see the same certificate, you decide to trust the site.

The approach is great in its simplicity: if you can see the same certificate from several different locations you conclude that it must be the correct certificate.

-Convergence home page - http://convergence.io/index.html

-A complete list of notaries you can choose to trust - https://github.com/moxie0/Convergence/wiki/Notaries

BEAST - Browser Exploit Against SSL/TLS

Description: The SSL protocol encrypts data by using CBC mode with chained initialization vectors. This allows an attacker, who has gotten access to an HTTPS session via man-in-the-middle (MITM) attacks or other means, to obtain plain text HTTP headers via a blockwise chosen-boundary attack (BCBA) in conjunction with JavaScript code that uses the HTML5 WebSocket API, the Java URLConnection API, or the Silverlight WebClient API. This vulnerability is more commonly referred to as Browser Exploit against SSL/TLS or "BEAST".

"BEAST" was debuted at the Ekoparty security conference in Buenos Aires, Argentina.

According to the researchers, the exploit, if used by criminal hackers, could leave highly sensitive financial, online banking, and ecommerce transaction data exposed to interception and harvesting.

The exploit attack impacts TLS 1.0 and SSL 3.0, but does not work for TLS versions 1.1 and 1.2.

The Beast creators, Duong and Rizzo, created a video that demonstrate the attack

http://www.youtube.com/watch?v=BTqAIDVUvrU

SSL/TLS Renegotiation - Denial of Service

The premise of the attack is simple: "An SSL/TLS handshake requires at least 10 times more processing power on the server than on the client. The handshake is only performed at the beginning of a secure connection to establish it. When SSL/TLS Renegotiation is enabled on the server, a user is allowed to send a renegotiation request which initiates a new handshake. Since it takes much less resources for a client to perform a handshake, requesting multiple handshakes per second could cause a denial of service on the server side SSL/TLS interface. Therefore, if a malicious user on one host requests multiple renegotiation requests it will exhaust the server's resources and not allow any other user to establish a connection".

Check if SSL/TLS Renegotiation is enabled:

# openssl s_client -connect ip:port

R

A few weeks after ietf.org made public this vulnerability, a German hacking group called "The hackers choice" released a new DDOS tool, presented at DC4420, called TLS/SSL DOS. "This proof of concept tool exploits a vulnerability in SSL. It can knock of a server off the internet by exhausting its CPU power. This tool is by far not complete and can be greatly enhanced to further the impact." they said.

THC-SSL-DOS exploits the renegotiation property of SSL by overloading the server and knocking it off the Internet.

The tool can be found in 2 versions, binary and source, so it can be used on both, windows and linux.

Download

www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4-win-bin.zip

www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz

Use "./configure; make all install" to build.

Usage:

./thc-ssl-dos 127.3.133.7 443

Handshakes 0 [0.00 h/s], 0 Conn, 0 Err

Secure Renegotiation support: yes

Handshakes 0 [0.00 h/s], 97 Conn, 0 Err

Handshakes 68 [67.39 h/s], 97 Conn, 0 Err

Handshakes 148 [79.91 h/s], 97 Conn, 0 Err

Handshakes 228 [80.32 h/s], 100 Conn, 0 Err

Handshakes 308 [80.62 h/s], 100 Conn, 0 Err

How to defend:

A short time after thc-ssl-dos tool release, Jason Rahm created 20 beautiful code lines under the iRule name that elegantly defeats the attack. Its premise is simple:

If a client connection attempts to renegotiate more than five times in any 60 second period, that client connection is silently dropped.

By silently dropping the client connection, the iRule causes the attack tool to stall for long periods of time, fully negating the attack. There should be no false-positives dropped, either, as there are very few valid use cases for renegotiating more than once a minute.

The iRule

when RULE_INIT {


set static::maxquery 5



set static::seconds 60


}

when CLIENT_ACCEPTED {


set rand [expr { int(10000000

* rand()) }]


}

when CLIENTSSL_HANDSHAKE {


set reqno [table incr "reqs$rand"]



table set -subtable "reqrate:$rand" $reqno "ignored" indefinite $static::seconds



if { [table keys -count -subtable "reqrate:$rand"] > $static::maxquery } {



after

5000


drop

}

}

when CLIENT_CLOSED {


table delete reqs$rand



table delete –subtable reqrate:$rand –all


}

With the iRule in place, you can see its effect within a few seconds of the test restarting.

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err

Jason also provided a visual workflow to elucidate its mechanics.

Figure 7

As a conclusion, I would like to share Calum MacLeod of Venafi words "Ultimately it is not SSL that's broken, but the management of SSL in large enterprises."

Note: I avoided to talk more about BEAST ("Browser Exploit against SSL/TLS") in this article, but I will cover that in my next article.

References:

1. Wikipedia - Secure sockets layer -http://en.wikipedia.org/wiki/Secure_Sockets_Layer

2. IBM - Digital certificate authority (CA) - http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtps7%2Fs7dca.html

3. Moxie Marlinspike - SSL Sniff http://www.thoughtcrime.org/software/sslsniff/

4. Moxie Marlinspike - SSL Strip http://www.thoughtcrime.org/software/sslstrip/

5. Convergence - http://convergence.io/index.html

6. BEAST - http://vnhacker.blogspot.ro/2011/09/beast.html

7.[TLS] SSL Renegotiation DOS - http://www.ietf.org/mail-archive/web/tls/current/msg07553.html

8. The Hackers Choice - http://www.thc.org/thc-ssl-dos/

What should you learn next?

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

9.SSL Renegotiation DOS attack – an iRule Countermeasure - https://devcentral.f5.com/blogs/us/ssl-renegotiation-dos-attack-ndash-an-irule-countermeasure

Adrian Birsan
Adrian Birsan

Adrian Birsan is a freelance web developer and pentester. Says he: "Technology has always been something which captivates me; I like computer security and software development. I am a pentester on my free time and also own a blog where I post useful information. I am a big supporter of Freedom of Speech and ... I play the guitar m/ " His blog can be found at http://softpill.eu/