Share

Related Links

  • Qualys
  • Reed Exhibitions Ltd is not responsible for the content of external websites.

Related Stories

  • Qualys extends free BrowserCheck service to businesses
    Cloud security specialist Qualys has extended its free BrowserCheck service into the business space, adding a number of extra features to the browser service for IT security admins.
  • RSA 2011: Qualys announces open source firewall project
    It's day one of RSA Security in San Francisco and Qualys has announced an open source firewall project called Project IronBee. The gameplan with the collaborative project is to have the first open source code published by the end of the year.
  • Sourcefire links up with Qualys with Qualysguard collaboration/support
    Sourcefire, the company that created the Snort open source firewall software, has announced it is collaborating with Qualys to make its software fully integrated with the QualysGuard platform.
  • Free web browser and plug-in security service launched
    Cloud security specialist Qualys has launched an interactive and online web browser checking service. Known as BrowserCheck, the service has been in development for almost 18 months and under active beta test internally for some three months, Wolfgang Kandek, Qualys' chief technology officer told Infosecurity.
  • Qualys launches free web browser/plug-in security checking service
    Cloud security specialist Qualys has launched an interactive and online web browser checking service. Known as BrowserCheck, the service has been in development for almost 18 months and under active beta test internally for some three months, Wolfgang Kandek, Qualys' chief technology officer told Infosecurity.

Top 5 Stories

News

The antidote to THC's DoS hacking software

04 November 2011

Ivan Ristic, Qualys director of engineering has been doing some analysis of the denial-of-service software that was released late last month by The Hacker's Choice (THC) group and come up with some interesting observations.

According to Ristic, the THC group has released the DoS utility that works at the SSL/TLS layer. The tool, he says, exploits the fact that, when a new secure sockets layer (SSL) connection is being negotiated, the server will typically spend significantly more CPU resources than the client.

In this way, he notes, if anyone requests a large number of new SSL connections in a short period of time, the server starts to become overloaded.

“The issue abused by the tool is not new, but what is new is that we now have a well publicised working exploit, and that always makes you pay attention. In addition, the tool uses the renegotiation feature, which means that it can force a server to perform many expensive cryptographic operations over a single TCP connection”, he says in his latest security posting.

Interestingly, Ristic notes that it is not clear that relying on a TCP/IP session renegotiation helps with the DoS attack, but he adds that since any external DoS mitigation tools – such as a per-session rate-limiting application – being used as a security screen would only see one TCP session, this helps to avoid detection.

But this, he says, is only if your server supports client-initiated renegotiation. If it does not, he adds, anyone wishing to perform a DoS attack against the SSL layer will have to fall back to using one TCP connection for every SSL connection.

Microsoft IIS, he notes, does not support client-initiated renegotiation and, while Apache used to, it changed its behavior when implementing RFC 5746, which fixed the TLS authentication gap problem.

“Even if you depend on a product that does support client-initiated renegotiation, chances are you can easily disable that feature. And, when you do, you are not going to miss it - unlike server-initiated renegotiation, which some sites that require client certificates might need”, he argues.

Ristic goes on to say that, in order to assist anyone assessing their systems for this weakness, Qualys has updated the SSL Labs assessment tool to test not only if secure renegotiation is supported – which he says his team has been testing for some time now - but also to check if secure client-initiated renegotiation is enabled.

“Previously we only tested for insecure client-initiated renegotiation”, he explained.

“The sensible thing to do is to check for client-initiated renegotiation support in your servers, and disable it where possible. Although that won't substantially help you overall (defending against DoS attacks is notoriously difficult and expensive), it will harden your defences against this particular technique”, he concludes.

This article is featured in:
Internet and Network Security  •  Malware and Hardware Security

 

Comment on this article

You must be registered and logged in to leave a comment about this article.

We use cookies to operate this website and to improve its usability. Full details of what cookies are, why we use them and how you can manage them can be found by reading our Privacy & Cookies page. Please note that by using this site you are consenting to the use of cookies. ×