What Is SSL and how does it work? 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. 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

-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 -t 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 -t –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
  7. The Hackers Choice – http://www.thc.org/thc-ssl-dos/ 9.SSL Renegotiation DOS attack – an iRule Countermeasure – https://devcentral.f5.com/blogs/us/ssl-renegotiation-dos-attack-ndash-an-irule-countermeasure