Am I affected?
The following versions of the Barracuda Web Filter products are affected:
Barracuda Web Filter version 7.x and above.
What’s the risk?
The attack exploits a weakness in TLS heartbeats, where the attacker could fetch 64K chunks of memory near the memory allocated for the SSL heartbeat packet. The memory in question here is managed by OpenSSL. For a SSL service, every incoming request and response is sent to OpenSSL and anything that it decrypts or encrypts is in memory at some point of time. If the attacker sends the TLS heartbeat message repeatedly, he will keep getting 64K of data near the memory allocated for the SSL heartbeat packet every time. 64K in itself is a large chunk of data in the address space of the process.
The attacker cannot really guess what they are going to get, but it’s really easy to brute force the attack several times in quick succession as the protocol does not place any restrictions on the number of times that the attacker can send TLS heartbeats.
Data Path (SSL Inspection) – This vulnerability only affects you if you had SSL inspection enabled. Using this exploit an attacker could gain access to any user information that was inspected. For example, typically Web Filter customers inspect the domain google.com. This could have exposed information transmitted or received during these sessions including usernames, passwords or any text data.
Management Path - if you were using HTTPS for management, then the management path may also be vulnerable, from internal attacks only.
In case you were only using HTTP for management, then Heartbleed does not apply to the management path.
I seem to have an affected version, what do I do now?
You can either upgrade your firmware to the new GA release that fixes the vulnerability or you can apply the secdef. Both are equally safe.
Is upgrading the firmware / applying the secdef enough?
You may have to do one or more of the following as well:
Data Path (If SSL inspection is used)
- Revoke or delete current client certificates. Generate a new certificate and redeploy to all clients
- It would be wise to consider a forced renewal of all the passwords as well since users tend to use the same password in many places
- Alert your users to not ignore revoked or mismatched certificate warnings from their browsers
Management Path (if using HTTPS)
- Generate a new certificate for the management UI and apply it
- Change the admin passwords
Can I generate CSR again on the box? Will it be safe?
Not unless you upgrade the firmware or apply the secdef
How can I know if I was attacked?
Unfortunately, the attacks do not leave a trace in any of the logs. Data is stolen from the system memory and exfiltrated via the TLS heartbeats which are a part of the protocol.
What is the window of the vulnerability for me?
This depends on when you upgraded to the vulnerable firmware versions.
For the Barracuda Web Filter, the 7.0.022 EA firmware containing the vulnerable OpenSSL versions became available in October, 2013
How much data could have been stolen?
In one TLS heartbeat message, the maximum data theft could be upto 64 K. However, there is nothing to prevent the attacker from getting multiples of 64K data in successive TLS heartbeats, till enough damage has been done.
I use the virtual models of these products. What do I need to do?
The same steps as mentioned above.
Do I need to clean my devices or servers?
This is not needed. The attack comes in via the network and exfiltrates data from the RAM, leaving no trace on the file system of the victims.
Just to be sure, should I REALLY ask all my users to change their passwords? That’s a bit extreme!
Unfortunately this may be needed if your risk assessment warrants it. If you were indeed attacked, assume that password data may have leaked.
Note that a lot of big http://www.digitaltrends.com/computing/heres-a-list-of-websites-allegedly-affected-by-the-heartbleed-bug/#!Dz5bu on the Internet were vulnerable. Which means if your users had common passwords on any of those sites, they might have leaked out from those sites. It is better to be safe than sorry.