The effect of the Heartbleed Bug was, to put it lightly, widespread. In fact, Security Affairs calls it “probably the most serious menace to the modern Internet.” Heartbleed is a loophole in OpenSSL that enables an intruder to see as much as 64 kB of unencrypted data that has been transferred by users into systems including Facebook and Google.
Any organization using OpenSSL may have been impacted by the bug. What’s most devastating about Heartbleed is that the vulnerability – discovered by Google’s Neel Mehta — has existed for two years. Mashable released a list of major sites that require password changes by all users to secure their accounts – critically important now that the bug is common knowledge.
Many users and IT security professionals are interested in the broad ramifications of Heartbleed. Specifically, worry is rising that the bug could be used to facilitate DDoS (distributed denial of service) attacks. By spoofing a request to a server that is not properly secured, hackers are able to direct a large amount of data at their target.
For example, a bug discovered in the network time protocol (NTP) daemon in early 2012 instructed the server to send hundreds of times the data to a fraudulent IP address which served as the recipient of the brute-force attack. Site security tool and content delivery network (CDN) powerhouse CloudFlare reported the largest distributed denial of service pummeling ever recorded in February – which at its peak hit 400 gigabytes per second (Gbps).
The attack directed toward CloudFlare is considered a subcategory of DoS called distributed reflection denial of service (DrDoS). NTP, domain name service (DNS), and any other tools based on uniform datagram protocol (UDP) are vulnerable to these reflection barrages if they meet the following criteria:
Heartbleed is the household name for CVE-2014-0160, its designation within the Common Vulnerabilities and Exposures catalog. It exploits the code of the incredibly popular open source security certificate software OpenSSL (version 1.0.1 without the patch provided in 1.0.1g) so that 64 kB of data held in memory on a server is obtained through a dysfunction in the TLS/DTLS (transport layer security/datagram transport layer security) heartbeat.
By spoofing a HeartbeatRequest so that it seems larger than it actually is, the server essentially is stumped by the situation. Rather than failing to deliver the amount of data ordered by the fraudulent HeartbeatRequest, the server meets the needs of the spoof by drawing on random data that exists in its memory. Our founder, Jeffrey A. Lyon, referred to this process in Network World as “the digital equivalent of short-changing a cashier.”
The data retrieved could include such information as passwords, allowing malicious parties to access user accounts. Private SSL keys could be obtained as well. Note that private keys were initially not considered vulnerable but that their exposure was since confirmed by numerous parties.
To thicken the plot, security industry publication SC Magazine reports that another rendition of Heartbleed has been discovered. In Reverse Heartbleed (also exploiting CVE-2014-0160), rather than a client device stealing information from a server, a server steals information from a client device. Login credentials and other sensitive data can be taken from PCs and smartphones. These client machines use OpenSSL to encrypt communication in some browsers and other applications that run within the local system.
Because this process creates a larger response than the size of the request – as enabled via spoofing – it makes sense that amplification could occur, which in turn could be used by DrDoS instigators. Matthew Prince, founder of CloudFlare (a huge name in the security industry, as mentioned above), tweeted the below note, for example.
Prince’s comment was a bit oversimplistic and hasty, though, as is often true of tweets.
One major argument criticizing the possibility of a Heartbleed DDoS – offered by various security professionals – is that TLS only operates through stateful transport control protocol (TCP). The stateful nature of the interaction describes a communication agreement between client and server: a session must be enacted before the server could inundate any machine with data.
That line of thinking, unfortunately, is only half true. Note the type of TLS mentioned in passing above: datagram transport layer security (DTLS). DTLS is architected to perform identically to TLS through UDP instances, including VPNs (virtual private networks). The good news is that there is a standardized defense for distributed denial of service via DTLS – RFC4347, which was released by the Internet Engineering Task Force (IETF) in April 2006.
Because UDP is stateless, a session cannot occur through it with DTLS. Instead, the service has to make sure the request is legitimate by responding to ClientHello with HelloVerifyRequest and a cookie. The cookie must then be sent back to the server in a new ClientHello in order for the client to receive ServerHello. This form of validation makes malicious activity much less possible.
Regardless of the distributed denial of service implications of Heartbleed – which are minimal compared to other threats – this vulnerability should be remediated immediately by system administrators:
The real concern with DDoS right now is DrDoS utilizing NTP, along with the standard methods used by attackers in previous years (which are rising again now that many vulnerable NTP daemons have been patched). Our Q1 2014 Threat Report details attacks for the first three months of the year.
Any organization using OpenSSL may have been impacted by the bug. What’s most devastating about Heartbleed is that the vulnerability – discovered by Google’s Neel Mehta — has existed for two years. Mashable released a list of major sites that require password changes by all users to secure their accounts – critically important now that the bug is common knowledge.
NTP & DrDoS
Many users and IT security professionals are interested in the broad ramifications of Heartbleed. Specifically, worry is rising that the bug could be used to facilitate DDoS (distributed denial of service) attacks. By spoofing a request to a server that is not properly secured, hackers are able to direct a large amount of data at their target.
For example, a bug discovered in the network time protocol (NTP) daemon in early 2012 instructed the server to send hundreds of times the data to a fraudulent IP address which served as the recipient of the brute-force attack. Site security tool and content delivery network (CDN) powerhouse CloudFlare reported the largest distributed denial of service pummeling ever recorded in February – which at its peak hit 400 gigabytes per second (Gbps).
The attack directed toward CloudFlare is considered a subcategory of DoS called distributed reflection denial of service (DrDoS). NTP, domain name service (DNS), and any other tools based on uniform datagram protocol (UDP) are vulnerable to these reflection barrages if they meet the following criteria:
- public facing (as opposed to outward facing or intranet/internal);
- one or more of its default commands sends a sizable packet in response to a small request;
- isn’t outfitted with monitoring capabilities to filter out unwanted traffic.
Understanding Heartbleed & Reverse Heartbleed
Heartbleed is the household name for CVE-2014-0160, its designation within the Common Vulnerabilities and Exposures catalog. It exploits the code of the incredibly popular open source security certificate software OpenSSL (version 1.0.1 without the patch provided in 1.0.1g) so that 64 kB of data held in memory on a server is obtained through a dysfunction in the TLS/DTLS (transport layer security/datagram transport layer security) heartbeat.
By spoofing a HeartbeatRequest so that it seems larger than it actually is, the server essentially is stumped by the situation. Rather than failing to deliver the amount of data ordered by the fraudulent HeartbeatRequest, the server meets the needs of the spoof by drawing on random data that exists in its memory. Our founder, Jeffrey A. Lyon, referred to this process in Network World as “the digital equivalent of short-changing a cashier.”
The data retrieved could include such information as passwords, allowing malicious parties to access user accounts. Private SSL keys could be obtained as well. Note that private keys were initially not considered vulnerable but that their exposure was since confirmed by numerous parties.
To thicken the plot, security industry publication SC Magazine reports that another rendition of Heartbleed has been discovered. In Reverse Heartbleed (also exploiting CVE-2014-0160), rather than a client device stealing information from a server, a server steals information from a client device. Login credentials and other sensitive data can be taken from PCs and smartphones. These client machines use OpenSSL to encrypt communication in some browsers and other applications that run within the local system.
Use of Heartbleed for DDoS
Because this process creates a larger response than the size of the request – as enabled via spoofing – it makes sense that amplification could occur, which in turn could be used by DrDoS instigators. Matthew Prince, founder of CloudFlare (a huge name in the security industry, as mentioned above), tweeted the below note, for example.
Want more terrible #heartbleed news? Probably can be used as a massive DDoS amplification vector. Yay!
— Matthew Prince (@eastdakota) April 11, 2014
Prince’s comment was a bit oversimplistic and hasty, though, as is often true of tweets.
One major argument criticizing the possibility of a Heartbleed DDoS – offered by various security professionals – is that TLS only operates through stateful transport control protocol (TCP). The stateful nature of the interaction describes a communication agreement between client and server: a session must be enacted before the server could inundate any machine with data.
That line of thinking, unfortunately, is only half true. Note the type of TLS mentioned in passing above: datagram transport layer security (DTLS). DTLS is architected to perform identically to TLS through UDP instances, including VPNs (virtual private networks). The good news is that there is a standardized defense for distributed denial of service via DTLS – RFC4347, which was released by the Internet Engineering Task Force (IETF) in April 2006.
Because UDP is stateless, a session cannot occur through it with DTLS. Instead, the service has to make sure the request is legitimate by responding to ClientHello with HelloVerifyRequest and a cookie. The cookie must then be sent back to the server in a new ClientHello in order for the client to receive ServerHello. This form of validation makes malicious activity much less possible.
Response to Heartbleed & shifting focus back to NTP
Regardless of the distributed denial of service implications of Heartbleed – which are minimal compared to other threats – this vulnerability should be remediated immediately by system administrators:
- All OpenSSL instances should be updated;
- All passwords that may have been stolen should be changed; and
- Passwords should continue to be modified on a regular basis.
- SSL certificates that may have been stolen should be revoked (via the certificate authority, which is typically the brand of the certificate).
