Openssl renegotiation DoS attack is still an issue

Openssl renegotiate would causes DoS attack was disclosured in 2011，then THC released their DoS attack tools. This issue what we called CVE-2011-1473 until now the openssl upstream community doesn't give any solution.  So, it seems they've been leaving this issue to the application developers( suck this shit in mind), such as Apache2 provide a optional config that you can disable renegotiation.

Let's see what Apache2 server would do in most cases:

shawn@fortress / $ openssl s_client -connect build.opensuse.org:443

..............................

..............................

Timeout   : 300 (sec)  

Verify return code: 20 (unable to get local issuer certificate) ---

R   // Press R, then enter

RENEGOTIATING 140722018514592:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:592:


According to Vincent Bernat, a server will require 15 times the processing power of a client, which means an Intel i7 CPU laptop can kick a bunch of servers's ass. Plz take a look at my test data:

Test environment：SLES 11 SP2 , assigned 2 cores + 1GB memory in virtual machine

Case I:

Server: openssl s_server -key server-key.pem

Client: thc-ssl-dos 192.168.0.1 4433 --accept -l 10000

The worst case:

Cpu0 : 1.3%us, 1.7%sy, 0.0%ni, 97.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu1 : 53.1%us, 5.1%sy, 0.0%ni, 37.1%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st

Case II:  Vincent Bernat provided us an open source hardening/mitigation solution, which add some rate-limit/fixed hex data for filtering on the netfilter.

#sh iptables.sh

#iptables -A INPUT -d 192.168.0.1 -p tcp --dport 4433 -j LIMIT_RENEGOCIATION

Server: openssl s_server -key server-key.pem

Client: thc-ssl-dos 192.168.0.1 4433 --accept -l 10000

The worst case:

Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu1 : 0.0%us, 0.7%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Well done, Vincent! Your solution works. But I'm not sure this may cause the side-effect. Vincent added some fixed hex data as filtering policy on the netfilter. What if the same hex data occurs? Is false positive possible?

possible ways to exploit CVE-2012-1663

CVE-2013-1663 is a possible remote DOS attack issue. This issue has
been fixed in >=GNUTLS-3.0.14. I hacked on it for hours and figure out
a few prerequisites could make it vulnerable:

=============================
REQUIRED:

 - prior to GNUTLS 3.0.14
 - crafted certificate

=============================
Attacking SCENES

 - a client import a crafted cert file for sending req to server( CA?)

 - a "server" import a crafted cert file for sending req to other
   server( CA?)

---> With high frequency uses above manipulations

Stand on the client side, the attacker should try to construct a
crafted certificate for triggering the below function fails:

ret = gnutls_pubkey_import_x509(pcert->pubkey, crt, 0);
  if (ret < 0)
    {
      gnutls_pubkey_deinit(pcert->pubkey);
      /* pcert->pubkey should be NULL now */
      ret = gnutls_assert_val(ret);
      goto cleanup;
    }

I made up two crafted cert files( client.pem, client2.pem) seems would
trigger the double free issue in client's side.

Warning: Don't try it on your host machine because it would cost too
much memory then makes your machine very slow. I highly recommend you guys use vm for testing.

shawn@sl13:~/gnutls_compile_uses/CVE-2012-1663$ ./ex-serv-x509
processing server set to null?
Server ready. Listening to port '5556'.

shawn@sl13:~/gnutls_compile_uses/CVE-2012-1663$ ./attack.sh
................
.................
...................

Another terminal: killall client

Test platform: Slackware 13.37 + GNUTLS-3.0.13

How to compile GNUTLS-3.1.9 on Slackware 13.37

Before you dive into the detail source code of GNUTLS, you'd better compile/install it manually. But you known, hacker is always one of laziest type of person around the world. We want everything automatically. We did functional testing at first place, then we want to tranform its boring shit to automation testing. Even in security field, there are a bunch of guys( not lamer ones;-)) are trying to make the pentest/exploit shits automatically. I used to be an open source security QA guy and tried some automation tools( like ctcs) to satisfy my "lazy" requirement. Then I've starting maintain some security packages and fixing/backporting CVEs issues for "some" GNU/Linux distro. I've been doing this type of work for months but haven't compile the packages I'm maintaining with. What a shame;-)

I wrote a simple script today and it will help if you wanna compile GNUTLS in manual:

./get_repos.sh
Usage: [ Compile packages automatically: yes/no]

Type:
./get_repos.sh no  ===> only download the packages without compiliation
./get_repos.sh yes ===> download the packages then compiliation

If you choose "yes", you can check if it's really work:
Open two terminals: T1, T2

T1: Run the anonymous server with TLS
john@sl13:~/gnutls_uses$ ./anonymous_serv
Server ready. Listening to port '5556'.

- connection from 127.0.0.1, port 59923
- Handshake was completed

- Peer has closed the GnuTLS connection

T2: Run the client
john@sl13:~/gnutls_uses$ ./anonymous_cli
- Handshake was completed
- Received 18 bytes: GET / HTTP/1.0

That's it! Have fun with it!

May L0rd's hacking spirit guide us!!!