First, your Dell SonicWALL firewall itself is not vulnerable and, if Intrusion Prevention was active, has been protecting your network from the Heartbleed vulnerability since April 8th.
Now that this is out of the way, let’s look at what a Dell SonicWALL firewall can do to defend your network against the Heartbleed attack
A quick background on Heartbleed
On April 7th, 2014, the Heartbleed vulnerability (CVE-2014-0160) was publically disclosed in the widely used OpenSSL library at the same time as a patch release to OpenSSL 1.0.1 was made available. The vulnerability existed in the heartbeat code of the TLS protocol (hence the “Heart” part of the name), which was added to the OpenSSL codebase more than two years ago. The relevant heartbeat code did not perform proper length validation of the payload field, allowing an attacker to trick a vulnerable server into returning, and thus leaking, sensitive memory information in chunks up to 64Kbytes at a time (the “bleed” part of the name), leaving absolutely no trace of the attack on the server.
Why is this leakage of 64Kbytes at a time such a big deal? The chunks of server memory, which an attacker could request an indefinite number of times, have a high probability of containing sensitive information such as usernames, passwords, as well as private server keys. For example, if a user “Bob” with a password “cake” unknowingly logs into a vulnerable web server, the attacker can get lucky and obtain a piece of memory containing “username=bob&password=cake”, thus leaking Bob’s password. This type of data is encrypted and protected by the SSL/TLS protocol while it is in transit over the internet between a browser and the server. However, once it is on the server, it is decrypted so that it can be interpreted by the web application (e.g. webmail, shopping form, admin interface). Since the decryption occurs in the memory of the OpenSSL library, this data remains in memory local to the OpenSSL decryption code and becomes vulnerable to an attack that is able to steal the contents of server memory. That’s how the Heartbleed vulnerability came into existence.
The vulnerability affects servers and appliances that used OpenSSL 1.0.1 for secure communication with a client application, web browsers being the most common example of such an application.
Much has been written on the topic, so I’ll just point you to heartbleed.com, Bruce Schneier’s blog, NIST, and my favorite explanation at xkcd.
Preventing the attack at the perimeter with Intrusion Prevention
The good news is that this attack can be stopped at the network perimeter (or at an internal boundary) with a capable next-generation firewall (NGFW) or Unified Threat Management (UTM) firewall, buying you valuable time during which you can patch vulnerable servers and other infrastructure. All Dell SonicWALL firewalls with an active Intrusion Prevention service have been serving as the first line of defense against the Heartbleed vulnerability since April 8th, dropping the malicious traffic at the network boundary before it has a chance to hit webservers or exposed appliances. The Intrusion Prevention protection analyzes SSL/TLS traffic entering the network and drops connections that contain:
- Malicious standard TLS heartbeats
- Malicious encrypted TLS heartbeats
It is not necessary to enable SSL Decryption (DPI SSL) on the firewall in order to block Heartbleed attacks, as the malicious heartbeat packets are in the SSL/TLS headers that can be observed without decrypting the SSL/TLS payload. The attacks are covered by the following IPS signatures in the WEB-ATTACKS category, which are enabled automatically if you have prevention enabled for “High Priority” attacks:
- 3616 OpenSSL Heartbleed Information Disclosure 1
- 3638 OpenSSL Heartbleed Information Disclosure 2
- 3652 OpenSSL Heartbleed Information Disclosure 3
- 3653 OpenSSL Heartbleed Information Disclosure 4
- 3661 OpenSSL Heartbleed Information Disclosure 5
- 3663 OpenSSL Heartbleed Information Disclosure 6
- 3744 OpenVPN Heartbleed Information Disclosure
It is important to understand that “encrypted” heartbeats are a way of obfuscating the heartbeat payload, and do not refer to TLS encryption, nor the SSL/TLS payload.
![]()
More details and statistics on these countermeasures can be found in the SonicAlert posted on April 9th: https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=668 as well as the SonicAlert posted on April 18th: https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=671
TLS Heartbeats – Are they even necessary?
I could argue that SSL/TLS heartbeats are not necessary at all.
Heartbeats may be useful in SSL/TLS implementations over connectionless protocols such as UDP (DTLS). In such protocols, the heartbeat can help with more efficient communication by reducing the number of unnecessary session terminations/re-establishments.
However, given that a significant majority of SSL/TSL traffic is over TCP, these heartbeats are not essential to SSL/TLS performance over TCP. There are very few applications that rely on TLS heartbeats, and they can only be utilized when both the server and the client are using a version of OpenSSL that supports them. In the absence of heartbeat support on the server, the SSL/TLS specification mandates a backoff to a heartbeat-less operation which covers the majority of SSL/TLS operation in the real world.
Therefore, we’re also providing the ability to completely disable SSL/TLS heartbeats with the following signatures in the IPS engine:
- 3706 OpenSSL Heartbeat 1
- 3734 OpenSSL Heartbeat 2
- 3735 OpenSSL Heartbeat 3
The bad guys don’t sit still – Heartbleed Malware
Immediately after a newsworthy event, malware writers usually capitalize on people seeking information by creating malicious webpages and malware that are likely to be found in common search queries. In this particular case, it only took a few days for a piece of malware to surface that masquerades as the Heartbleed testing tool. Fortunately, it was quickly caught by the Dell security research teams and on Friday, April 11th, we added protection against this malware.
The malware is, predictably, called heartbleed.exe and upon execution, registers with a Command and Control (C&C) server and runs a Trojan on the infected systems. ![]()
These are covered with the following Anti-Malware signatures, but I’m sure that this list will continue to grow:
- GAV: Zacom.A (Trojan)
- GAV: Zacom.A_2 (Trojan)
- IPS: 3686 Zacom heartbleed malware activity 1
- IPS: 3688 Zacom heartbleed malware activity 2
More details can be found at https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=669 and in the April 18th update https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=671
Advice on testing whether you’re vulnerable
As always, be very wary of running any executables that you download from the internet, especially small utilities that are not code-signed by a well-known organization.
WARNING: There are many convenient websites that allow you to quickly test whether your externally facing servers (whether websites or appliances) are vulnerable. I recommend strongly *against*using those sites for testing since, you’re effectively self-declaring yourself as vulnerable to an entity that makes no guarantees of what it will do with that information.
I’m certain well-meaning testing sites exist, but, as with the malware mentioned above, it doesn’t take long for tools with malicious intent to show up. For example, it is not a difficult project to set up a website that tests for the Heartbleed vulnerability and logs submitted sites that it finds to be vulnerable.
Therefore, think twice of what you leak about your public web presence.
The correct way to test whether you’re vulnerable is by using one of the many python scripts that are available on the internet as source code. Even if you’re not a Python expert, a quick scan of the code can tell you whether the results of a scan are either logged or sent off somewhere. You can use these scripts against publically facing sites and internal servers with full confidence that your findings are not leaked or shared. When using these Python scripts, make sure to get the source code and execute the source code as a script. Never run pre-compiled code downloaded from the web.
Dell SonicWALL Customers: Checking for history of attacks:
If you’re running Dell SonicWALL GMS or Analyzer, you can check for attacks caught by your firewall by selecting
- Ø Firewall in question
- Ø Intrusions (Detected or Blocked)
- Ø Appropriate date range
You will be presented with a view similar to the following
![]()
Dmitriy Ayrapetov
Director, Product Management, Network Security
PS: There were some non-firewall Dell SonicWALL products that were vulnerable and have been patched. If these appliances were behind a Dell SonicWALL firewall with Intrusion Prevention, the risk was significantly lower. Please see the security bulletin for more details.
![]()
