This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiations via single TCP connection.

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
Handshakes 390 [81.10 h/s], 100 Conn, 0 Err
Handshakes 470 [80.24 h/s], 100 Conn, 0 Err

Comparing flood DDoS vs. SSL-Exhaustion attack

A traditional flood DDoS attack cannot be mounted from a single DSL connection. This is because the bandwidth of a server is far superior to the bandwidth of a DSL connection: A DSL connection is not an equal opponent to challenge the bandwidth of a server.

This is turned upside down for THC-SSL-DOS: The processing capacity for SSL handshakes is far superior at the client side: A laptop on a DSL connection can challenge a server on a 30Gbit link. Traditional DDoS attacks based on flooding are sub optimal: Servers are prepared to handle large amount of traffic and clients are constantly sending requests to the server even when not under attack.

The SSL-handshake is only done at the beginning of a secure session and only if security is required. Servers are _not_ prepared to handle large amount of SSL Handshakes. The worst attack scenario is an SSL-Exhaustion attack mounted from thousands of clients (SSL-DDoS).

Tips & Tricks for Whitehats

1. The average server can do 300 handshakes per second. This would require 10-25% of your laptops CPU.
2. Use multiple hosts (SSL-DOS) if an SSL Accelerator is used.
3. Be smart in target acquisition: The HTTPS Port (443) is not always the best choice. Other SSL enabled ports are more unlikely to use an SSL Accelerator (like the POP3S, SMTPS, … or the secure database port).

Counter measurements

No real solutions exists. The following steps can mitigate (but not solve) the problem:

1. Disable SSL-Renegotiation
2. Invest into SSL Accelerator

Either of these countermeasures can be circumventing by modifying THC-SSL-DOS. A better solution is desireable. Somebody should fix this.

You can download THC-SSL-DOS here:

Windows: thc-ssl-dos-1.4-win-bin.zip
Linux: thc-ssl-dos-1.4.tar.gz

Or read more here.

I guess most people have been led to believe this new generation of ePassports or biometric passports are more secure, will help us keep our privacy intact and help us mitigate against identity theft.

Well how wrong the propaganda is! THC (famous for their tools and research in security) has just released some technical information, tools and a video which shows their cloned passport being read and verified by a passport reader.

The government plans to use ePassports at Immigration and Border Control. The information is electronically read from the Passport and displayed to a Border Control Officer or used by an automated setup. THC has discovered weaknesses in the system to (by)pass the security checks. The detection of fake passport chips does not work. Test setups do not raise alerts when a modified chip is used. This enables an attacker to create a Passport with an altered Picture, Name, DoB, Nationality and other credentials.

The manipulated information is displayed without any alarms going off. The exploitation of this loophole is trivial and can be verified using thc-epassport. Regardless how good the intention of the government might have been, the facts are that tested implementations of the ePassports Inspection System are not secure.

The passport reader appears to be in the Netherlands from my guise, but all the passports in use are the same just the templates slightly different.

Nice to see you again Mr Presley…imagine what could be done with this flaw in the sytem? I wonder if anything will be done about this or it’ll just be brushed under the carpet and remain knowledge of the security community.

Source: freeworld.thc

I have to agree with their sentiment, I’m all for open hardware standards.

Even if you don’t open it, people will copy it anyway (See the mass of Cisco knock-offs in China for a fraction of the price with almost exactly the same functions and IOS)

So why not open it, let us play with it.

At least let us know how the hardware we are paying for works.

The following webpage contains ROM images from various mobile phone operating systems. Our intention is to motivate other reverse engineers to take a look at the images and to discover other hidden secrets. Other reasons are that it is said to be hard to extract the ROM. Certainly another reason is that Nokia does not release any technical information about the hardware and I find this rather disappointing. (It’s my strong believe that when I buy hardware that I should also be allowed to know what’s in it and how to use it.)

There are ROM images from various models such as NOKIA 6630, NOKIA n70, NOKIA N-GAGE and also from SE the SonyEricsson P900 ROM image.

Mobile Phone ROM Image and Reverse Engineering Invitation