Can Heartbleed be used in DDoS attacks?

With nearly every major threat to information security, it is not long before security experts ask the question, "Can the threat play a role in distributed denial of service (DDoS) attacks?" When it comes to Heartbleed, some people are screaming that the sky is falling, but it is more complicated than that.

Software vulnerabilities can cause an amplification condition that allows attackers to use unsecured systems in the commission of a DDoS attack. For instance, earlier this year a major vulnerability was discovered in the network time protocol (NTP) daemon, which allowed an attacker to spoof a request. This resulted in an amplification factor that caused as much as 400 times the data to be sent by the vulnerable server back to the spoofed IP address, the target of a DDoS attack.

+ ALSO ON NETWORK WORLD What you need to know about Heartbleed and OpenSSL +

This is more specifically known as a distributed reflection denial of service (DrDoS) attack. Any uniform datagram protocol (UDP) service, such as NTP or DNS, can be used in these types of attacks if the service is public facing, responds to requests by sending more data than was used in making the request, and does not have any other mechanism for detecting and discarding malicious requests.

How does this relate to Heartbleed?

The Heartbleed vulnerability, more appropriately called CVE-2014-0160, makes use of a flaw in OpenSSL 1.0.1 prior to the 1.0.1g revision, which allows an attacker to steal 64 kilobytes of data from server memory using a transport layer security (TLS) HeartbeatRequest message. This is accomplished by spoofing the size of the HeartbeatRequest message and causing the vulnerable server to make up the difference by pulling random data from memory. It is the digital equivalent of short-changing a cashier, only in this case it is confidential data, such as SSL private keys and login credentials that are stolen.

It would not be unreasonable to assume that spoofing the size of a HeartbeatRequest message would result in an amplified response that one could use in a DDoS attack. One person, for example, Tweeted: "Want more terrible #heartbleed news? Probably can be used as a massive DDoS amplification vector. Yay!"

Unfortunately, the poster did not expound on the threat, other than Tweeting a follow up that an amplification condition may exist with a factor of 3,000, leaving many to wonder about the possibilities while contemplating the devastation if such an attack were even remotely feasible.

Are we in danger?

Many have responded that this is not possible because TLS is used exclusively with the transport control protocol (TCP) that is stateful, meaning a session must be established between the client and server before the server can send data such as HeartbeatResponse messages.

Problem solved, right?

Not exactly, as there is a TLS variant called datagram transport layer security (DTLS) that is designed to emulate the behavior of TLS on UDP services, such as VPN tunnels. Fortunately, the standards community is generally on point and came up with a solution in RFC4347 eight years ago that prevents the use of DTLS in DDoS attacks.

As UDP is stateless, is it not possible to establish a session with the service using DTLS, so the protocol must validate the source of the ClientHello request. This is accomplished by transmitting HelloVerifyRequest back to the client, which includes a cookie. Before the client can receive the ServerHello message it must resend ClientHello with the same cookie, giving DTLS a higher degree of assurance that the message actually came from its declared source and was not spoofed.

In other words, the client must prove its identity before it can receive large amounts of data from the server. This DDoS protection not only prevents amplification attacks, but ensures the server is not overloaded by sending resource-intensive certificate responses to illegitimate users.

What if the stateless cookie defense were bypassed?

As we have seen this week, nothing is guaranteed to be secure or foolproof. What if an attacker found a way to bypass the stateless cookie defense? This seems unlikely. However, if it were to occur, there are two other conditions that would limit the damage of a DTLS reflection attack:

1. By design, DTLS closely resembles TLS, which is designed for TCP. This eliminates the benefits of using UDP for latency sensitive applications as it is essentially emulating a stateful connection. Without the performance benefit of statelessness, developers generally do not find it advantageous to use UDP when TCP would provide greater reliability. This means that DTLS is not nearly as popular as TLS, greatly reducing any opportunity that may exist to use DTLS-protected services in a reflection attack.

2. While it is theoretically possible to transmit a handshake message as large as 16.8 megabytes, typical handshake messages are generally much smaller to the order of several kilobytes. In the packet capture analysis above, this resulted in an amplification factor of only nine times, leaving DNS and NTP reflection substantially more viable for use as DrDoS attack vectors.

So everything is OK, right?

Not exactly. While it is extremely unlikely that Heartbleed or any associated protocol such as TLS or DTLS will be used in DDoS attacks, there are other pressing matters.

First, system administrators need to ensure the actual confirmed threat from Heartbleed is controlled and remediated. Several ethical hackers have recently confirmed that SSL private keys can be stolen using the TLS heartbeat vulnerability, contrary to the initial assumptions of experts at companies such as Google, Symantec and CloudFlare.

It's now matter-of-fact that SSL private keys, login credentials and other encrypted data can be stolen via Heartbleed. To remediate this threat, administrators must ensure that any systems operating OpenSSL are upgraded to 1.0.1g, change any passwords that may have leaked while systems were exposed, and continue to change passwords frequently as a matter of best practice.

Additionally, companies should revoke any SSL certificates derived from certificate signing requests (CSR) that may have had their keys compromised. Organizations can accomplish this by contacting the certificate authority that issued the SSL certificates. To make matters worse, this measure does not guarantee that the stolen keys will not be used, as many popular browsers do not check for revocation by default. As a result, side effects from Heartbleed will continue for many months or even years post-remediation.

In terms of DDoS attacks, the dominant threats observed by Black Lotus and reported in its Q1 2014 Threat Report are NTP DrDoS attacks, as well as traditionally dominant attacks against Web services, specifically SYN floods and HTTP application layer attacks. With NTP attacks waning in frequency and effectiveness, many attackers are resorting to tried-and-true methods of causing damage to their targets.

In the future, it is likely that attackers will discover new amplification vulnerabilities in UDP services, leading to more wide scale and severe DrDoS attacks that are expected to exceed 800Gbps in the next 12 to 18 months. While there is much to fret over in the wake of DrDoS and vulnerabilities like Heartbleed, DTLS reflection attacks do not rank among serious issues for which network operators and systems administrators need to be immediately concerned.

Jeffrey A. Lyon, CISSP-ISSMP, is the founder of Black Lotus Communications, a DDoS mitigation firm focusing on solutions for service providers and enterprises. He can be followed on Twitter @ddosguru.

Read more about wide area network in Network World's Wide Area Network section.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags cybercrimelegalendpoint securityanti-malwareNTPWide Area Network

More about CSRGoogleSymantec

Show Comments
[]