Below is a more generic FAQ that answers some frequent questions we have been getting:
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 an 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. By sending repeatedly sending TLS heartbeatmessages , an attacker 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 is 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. They can thus exfiltrate a lot of information in the process.
Data Path (Services) - if you were offloading SSL for any service on to one of these products with the affected firmware, then the service private keys as well as the application data itself are at risk. An attacker could have stolen your private keys, the protected application’s user credentials, persistent cookies, session IDs and any other application data that was present in the requests or responses, including credit card data.
If communication or collaboration applications like OWA, SharePoint etc. were behind, say an HTTPS service on the WAF, then your emails and official documents could also have been leaked.
Management Path - if you were using HTTPS for management, then the management path may also be vulnerable, especially if it was exposed to the Internet (e.g. if management was enabled on the WAN port). If you did not have any SSL services on the data path and if management was restricted to the MGMT port that is connected to an internal private network, then the risk may be limited to insider attacks only.
In case you were only using HTTP for management, then Heartbleed does not apply to the management path.
We recommend using only the MGMT port for device management that is connected to an internal private network which is cut off from the Internet.
I seem to have an affected version; what do I do now?
You can either upgrade your firmware to the new GA release (see above) that fixes the vulnerability, or you can apply the security definition (secdef). Both are equally safe.
Is upgrading the firmware / applying the secdef enough?
Based on your risk analysis, you may have to do one or more of the following:
Data Path (for services with SSL)
- Revoke current certificates and discard their private keys. Generate a new certificate and apply it to the service(s)
- If the service has any form of authentication on the WAF/ADC or even justpasses authentication data through to the backend, then consider a forced renewal of all passwords
- Alert the users of your applications to not ignore revoked or mismatched certificate warnings from their browsers
Management Path (if using HTTPS)
- Generate a new certificate for the management web interface and apply it
- Change the admin passwords
- For WAF - change the Role Based Access (RBA) credentials for all admins
Are you saying that I will have to replace all my certificates?
Yes, all your signed or unsigned certificates for every SSL service should be replaced, including the certificate for the management web interface. If you were attacked then the private keys would definitely be sought after, since they are kept in memory for cryptographical operations and can be easily identified.
Should I change the real backend server's key and certificate as well?
No, unless it is the same private key which is imported into the WAF. WAF is a reverse proxy, so the exploit can only glean from WAF's process memory, not the backend server’s. However, if the backend servers use a vulnerable version of OpenSSL and are accessible to the internal network, it is recommended to update OpenSSL and change the keys on them as well to reduce insider threat.
Can I generate CSR again on the box? Will it be safe?
Not until 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 Application Firewall, the 7.8 EA firmware containing the vulnerable OpenSSL versions became available in May 2013.
For the Barracuda Load Balancer, the 4.2 EA firmware containing the vulnerable OpenSSL versions became available in September 2012.
The Barracuda Load Balancer ADC has used the vulnerable OpenSSL versions from inception.
How much data could have been stolen?
In one TLS heartbeat message, the maximum data theft could be up to 64 K. However, there is nothing to prevent the attacker from getting multiple chunks of 64K data in successive TLS heartbeats, until enough damaging information has been gathered.
Would I be safe if I had completely disabled TLS and was using only SSLv3?
No. The heartbeat code is shared by SSLv3 and TLS, hence the same vulnerability is exposed even with SSLv3.
What if I was not offloading SSL for any of the services?
Only your management path would be affected.
I use the virtual models of these products. What do I need to do?
The same steps as mentioned above.
Would PFS have saved me?
Perfect Forward Secrecy (PFS) would still leak data at the time of attack along with the ephemeral keys. However, once patched, the stolen keys cannot be used in future due to the nature of PFS. So the urgency to change the certificate would be reduced. However, the application’s user credentials and other data would still be at risk.
PFS was not available in prior releases but is now available in firmware version 7.8.1.016 of the Barracuda Web Application Firewall.
Do I need to clean my devices or servers?
This is not needed. The attack comes in from the network and exfiltrates data from the RAM, leaving no trace on the file system of the victims.
I was using FIPS module / authentication / client certificates / 2 factor authentication for my applications, am I still affected?
Yes. Moreover, all the authentication data is at risk for SSL enabled services.