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.

IETF completed the SSL vulnerability fix in January this year and now in August – 10 months after the original release of the flaw – Microsoft has stepped up and fixed it.

The fix is labeled as MS10-049 and categorised as a Critical security vulnerability. Interestingly it also notes that it fixes both a publicly exposed vulnerability and a privately reported bug both in the Secure Channel (SChannel) security package in Windows.

Microsoft has updated a broad swath of products to fix a potentially serious spoofing vulnerability in the secure sockets layer (SSL) protocol that secures email, web transactions and other sensitive internet traffic.

The software company on Tuesday released MS10-049 to kill the bug in Windows Server 2008, Windows 7 and 12 other versions of Windows that are still under support. The patch updates a part of the operating system known as SChannel, or Secure Channel, which is responsible for implementing SSL, which is also referred to as TLS, or transport layer security.

The weakness first became public in November, when word leaked out that a vulnerability in the underlying protocol used by hundreds of companies allowed attackers to inject text into encrypted traffic passing between two endpoints. Researchers had been meeting in secret to develop an industry-wide fix before attackers could figure out a way to exploit it.

Microsoft’s update follows the revision in January of RFC 5246, the request-for-comments document that previously mapped out the technical specifications for the protocol. The new controlling blueprint for SSL/TLS communications is RFC 5746. Since then, other packages, including OpenSSL, RedHat Linux and Oracle’s Java, have also been patched.

The vulnerability is pretty widespread as it covers both Windows 7 – their latest OS and 12 other versions of Windows which Microsoft still supports. It’s marked as critical on 5 versions of Windows, which means it allows remote code execution and the rest it’s marked as important as it allows spoofing.

I’m guessing most large corporates running Windows systems will be pushing out this patch ASAP, especially those that rely on SSL for daily business – those in eCommerce would be the likeliest to find this kind of attack a real risk.

“Ten months after public disclosure the majority of the industry has a fix,” said Marsh Ray, a software developer at two-factor authentication service PhoneFactor and one of the researchers who first sounded the alarm. “I think it’s about as good a time as any to declare victory on that project.”

Microsoft rated the severity of the vulnerability as “important,” the second-highest classification on its four-tier scale. The bulletin correctly said the SSL vulnerability could be exploited only in concert with another attack – such as ARP spoofing or DNS cache poisoning – that allowed someone to perform a man-in-the-middle attack.

“It is important to note that this is still potentially a significant issue for certain deployments, and the update should be installed,” Maarten Van Horenbeeck, a program manager in the Microsoft Security Response Center, wrote here. “In particular, the vulnerability may affect other non-HTTP protocols that are less well understood.”

The vulnerability in the older protocol stems from the ability for either party in an SSL transaction to renegotiate the session, usually so one of them can refresh its cryptographic keys or change other parameters. That could allow man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL session.

The latest Patch Tuesday from Microsoft has been a bit of a record breaker with 14 security patches for at least 34 separate vulnerabilities.

This closely follows more disclosed bugs in Adobe PDF related products following their latest patches for other critical rated vulnerabilities.

Source: The Register

You should remember the SSL Renegotiation bug from last year that was used to successfully attack twitter.

Finally IETF have come out with a fix for the issue, it’s natural it has taken some time as it’s a flaw in the actual protocol itself not in any specific implementation (which is usually the case).

The bug was fairly serious as demonstrated by the Twitter-jacking that took place exploiting the flaw. The bug basically allowed an attacker to conduct a man-in-the-middle attack and insert some malicious data at the beginning of a vulnerable SSL/TLS connection.

A fix that addresses a security vulnerability that could threaten SSL-protected Websites has been given the greenlight. The Internet Engineering Task Force (IETF) has finished work on a fix to a vulnerability in the Secure Sockets Layer protocol security researchers uncovered last August.

The vulnerability partially invalidates the SSL lock and allows attackers to compromise sites that use SSL for security—including banking sites and back-office systems that use Web services-based protocols. The issue was uncovered by Steve Dispensa and Marsh Ray, who work for two-factor authentication provider PhoneFactor.

“The bug allows a man-in-the-middle to insert some malicious data at the beginning of a vulnerable SSL/TLS connection, but does not allow him to directly read the data sent by the legitimate parties,” explained Ray. “This capability is referred to as a ‘blind plaintext injection attack.’ Initially, it was hoped that this limited capability would offer some mitigation. Unfortunately, it seems that HTTPS is particularly strongly affected because of its design, and an effective attack on the Twitter HTTPS API was demonstrated shortly after the vulnerability was publicly disclosed.”

Some of the open source providers of SSL implementations have fixed the bug in their software and released publicly available patches. These however are not officially merged with the main development trees as they were waiting for the official fix from the IETF.

It will take a while for all the major vendors to roll this into their software I guess, I’d hope to see everyone rolling out fixes by the end of January latest.

Who knows how many sites/apps are quietly being owned out there due to this bug.

A copy of the IETF draft can be found here. After incorporating feedback from the TLS community, the proposed fix was approved by the IESG on Jan. 7, 2010. The IESG is responsible for the technical management of IETF activities and the Internet standards process. The decision means customers can now begin to deliver patches that implement IETF’s change.

“Because of the large number and variety of systems affected, substantial interoperability testing [for the SSL extension] will be conducted by many vendors before they feel comfortable releasing a patch,” Ray said. “Some interoperability testing has already been done with preliminary versions of the patch, but another round of testing is occurring now that the details of the fix have been finalized by the IETF.

“Some of the open-source TLS implementations (OpenSSL, GnuTLS) have fixes in their publicly visible repositories, but have not released a formal patch as of right now,” he added. “Most of the larger vendors (open source and otherwise) have been given several months’ head start on implementing the fix, so they should not be starting from zero at this point.”

I’m glad to see something has been done about this issue and it has been treated seriously, imagine what would have happened if this was an issue with a Microsoft product?

They’d point fingers and create some FUD story claiming it wasn’t critical and only effected a small amount of systems under very specific circumstances.

Source: eWeek

When this SSL Renegotiation bug hit the news, most people said it was a theoretical attack and was of no practical use in the real world.

But then people tend to say that about most things don’t they until they get pwned up the face.

It turns out the rather obscure SSL flaw can be used to take over user accounts from websites that use API’s and especially those utilizing 3rd party clients (Twitter being the biggest but a lot of people are accessing Facebook now using clients too).

A Turkish grad student has devised a serious, real-world attack on Twitter that targeted a recently discovered vulnerability in the secure sockets layer protocol.

The exploit by Anil Kurmus is significant because it successfully targeted the so-called SSL renegotiation bug to steal Twitter login credentials that passed through encrypted data streams. When the flaw surfaced last week, many researchers dismissed it as an esoteric curiosity with little practical effect.

For one thing, the critics said, the protocol bug was hard to exploit. And for another, they said, even when it could be targeted, it achieved extremely limited results. The skepticism was understandable: While attackers could inject a small amount of text at the beginning of an authenticated SSL session, they were unable to read encrypted data that flowed between the two parties

So even though the fella couldn’t decrypt or read the data in the session, he could manipulate it in such a way that it spat out the goodies using the Twitter API.

It’s a very neat attack if you ask me, especially if you executed it via DM (Direct Message) it’s pretty unlikely anyone would notice their account had been ‘hacked’.

Perhaps this is how the bad guys have been doing it for a while because I do see an awful lot of hijacked accounts on Twitter and the owners have no idea why (they hadn’t logged in to any dodgy sites with OAuth or their Twitter credentials).

Despite those limitations, Kurmus was able to exploit the bug to steal Twitter usernames and passwords as they passed between client applications and Twitter’s servers, even though they were encrypted. He did it by injecting text that instructed Twitter’s application protocol interface to dump the contents of the web request into a Twitter message after they had been decrypted.

“My point is I think that it’s not so hard to make it work,” said Kurmus, who lives in Zurich and recently completed his masters thesis at the Eurecom Institute. “Maybe some other people did the same thing and did not make it public, so this is why I think it’s important that people would take this bug more seriously.”

Twitter proved an ideal platform to carry out the attack for several reasons. First, every request sent over the microblogging site includes the account holder’s username and password. Second, the site’s API made it easy to post the contents of the intercepted data stream into a message that an attacker could then retrieve.

Twitter has apparently plugged the hole from their side, but as the flaw in SSL itself it seems only one vendor is near to issuing a patch (OpenSSL).

If you extrapolate a little though, this attack could work on anything with a POST/GET interface on the web running on SSL – like Gmail for example.

I hope companies get to patching and plug this hole as it can be carried out all too quietly and wreak a whole lot of havoc!

Source: The Register