Jump to content


Photo

New GA release with fix for OpenSSL Heartbleed vulnerability

openssl 7.8.016 heartbleed

  • Please log in to reply
2 replies to this topic

#1 Neeraj

Neeraj
  • Product Managers
  • 72 posts

Posted 12 April 2014 - 12:31 AM

Barracuda Web Application Firewall firmware version 7.8.1.016 is now available as a GA release. This includes a fix for the OpenSSL Heartbleed bug disclosed recently. 
 
For details on the Heartbleed security advisory see :
http://www.openssl.org/news/secadv_20140407.txt
http://heartbleed.com/

 
While the primary purpose of this GA is to address the OpenSSL Heartbeat vulnerability, it also includes a few other fixes and enhancements. The release notes can be found here:

 

http://updates.cudasvc.com/cgi-bin/view_release_notes.cgi?type=bwsware&version=7.8.1.016&platform=2

 
A notable enhancement is the availability of new PFS (Perfect Forward Secrecy) cipher suites for fronted SSL support.


#2 Neeraj

Neeraj
  • Product Managers
  • 72 posts

Posted 12 April 2014 - 02:59 AM

Additional details on how this affects Barracuda Web Application Firewall:

 

Barracuda Web Application Firewall makes use of the popular OpenSSL cryptographic software library to encrypt the data path as well as the management UI. The versions of OpenSSL shipped with Barracuda Web Application Firewall in 7.8.x release may be vulnerable to the above mentioned security advisory (see below). This firmware release fixes this by updating the OpenSSL Version to 1.0.1g which fixes the vulnerability.

 

Note that the certificate information or authentication data (for the backend applications and the management UI) may have leaked due to this vulnerability.

 

First ascertain if you are affected. The affected firmware versions are 7.8 - 7.8.1.015. If you are on a firmware version that precedes this range, you are not affected. 
 
In case you have not turned off automatic Security Definition Updates on the ADVANCED::Energize Updates page, we have released a new security definition (secdef) version 2.1.12177, that patches this vulnerability. You can confirm if the secdef has already applied on the Energize Updates page. You would also have seen an email or notice to reboot the unit. Post the reboot, your patching process is complete. However, you still need to replace your certificates and authentication credentials to rule out any prior data leakage; see steps 2 onwards below. 
 
 

 

  1. The secdef would not apply automatically, if Automatic Updates under Security Definition Updates was set to Off. In this case, you can either chose to upgrade the firmware to 7.8.1.016, or apply the secdef manually. The later could be more convenient in case of large deployments where it may not be possible to upgrade the firmware across several units or in the case you wish to stay on the existing version of the firmware.
  2. On the BASIC::Certificates page, identify all the certificates under Saved Certificates:
    • For each of these, create a new certificate. This can be done from the Certificate Generation module on the same page. This might be a good opportunity to use 2048 bit certificates, in case you were still using 1024 bit certificates. 
    • Download the CSR (certificate signing request) and get it signed from your trusted CA
    • Apply the CA signed certificate to the respective services. 
    • Note: Intermittent service outage will occur during the step above, but this should not last longer than a few seconds.
  3. If you were using end-to-end SSL with the same private key for a service on the WAF and the backend application, then change the certificate on the backend as well. Also, 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 to reduce insider threat.
  4. After upgrading, on the ADVANCED::Secure Administration page in the section SSL Certificate Configuration, do not use the “Default ( Barracuda Networks) “ SSL certificate any longer (if you were indeed using it).  Instead, create a new certificate for Secure Administration, refer to the online help for details
  5. If you created a Private (Self-Signed) or Trusted (Signed by a Trusted CA) certificate for the management UI, make sure to also replace these on ADVANCED::Secure Administration page after the upgrade.
  6. Ensure that all admin password(s) are renewed. 
  7. If you were using Role Based Access (RBA), navigate to the ADVANCED::Admin Access Control page and ensure a forced renewal of all the admin credentials. If you were using External Authentication Services, e.g. LDAP for RBA, then consider changing the LDAP credentials for all admins as well, as they may have leaked. 
  8. If the protected SSL services required authentication, either on the WAF or the backend application, there is a possibility that the user credentials may have leaked, since these would have been decrypted by OpenSSL in the RAM. To be safe, advise the application users to change their passwords.  
  9. Alert the users of your applications to NOT ignore revoked or mismatched certificate warnings from their browsers. 


#3 Neeraj

Neeraj
  • Product Managers
  • 72 posts

Posted 14 April 2014 - 04:33 AM

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.