By Zach Levow – Co-Founder & Chief Technology Officer
As a co-founder and Chief Technology Officer, I have spent many hours over the last week investigating the recently raised security and remote access issues.
First, I appreciate the thoroughness of the investigation and the detailed feedback we have received from the security and user community. I understand there are no more important issues than system security and access controls, and the need for third parties to take an objective, independent look at security practices.
Second, I am struck by the patience and support our customers and resellers have shown as we worked to resolve the concerns raised by a security researcher. Thank you, and I want you to know that Barracuda is working with urgency to show you that your support in us was not misplaced.
The recent days have only increased my resolve as an avid supporter of those who help us make our products better and protect our customers, including the white hat security researchers, open source projects, and other contributors to our efforts. I recognize the need to be vigilant and continue to build on those investments to protect our customers and their data across our product lines.
Finally, I have spent time struggling with the problem of how to best balance the need for security with the need to provide the highest level and fastest support to our customers. Over the years, we’ve made support our main focus, doing as much as possible to provide the best support to our customers. However, I realize that in doing so, we missed the balance required in today’s security and network environment. We overlooked the importance of not putting support controls front and center in the user interface, and the issues related to making support access opt-out rather than opt-in if certain appliances are not behind a firewall. I regret now some of the choices we made and apologize to our customers and partners who feel misled or deceived by the way it was implemented. I assure you we are working day and night to make further changes that integrate the feedback and expectations you have shared with us.
So my focus, and that of Barracuda, is to get the balance right and to do it now. The security and remote access functionality recently reported by a security researcher were implemented years ago, and were not diligently updated as our network evolved.
Below is a quick recap including additional details around what we’ve done to initially mitigate associated risk and our plans for further improvements.
A security researcher recently identified two issues that could allow unauthorized access to certain Barracuda appliances without explicit permission from the appliance administrator:
- The first concern was an access point that could allow Barracuda’s Technical Support department access to Barracuda appliances without explicit permission from the appliance administrator.
- The second concern was that a non-Barracuda employee could potentially gain access to the target device with the following:1) specific internal knowledge of the appliance operating system configuration
2) knowledge of the passwords used on the appliance
3) access to a set of specific IP addresses, a limited subset of which are controlled by our Internet Service Provider and not specifically assigned to Barracuda, but do exist within our local subnet
The affected appliances include the Barracuda Spam & Virus Firewall, Barracuda Web Filter, Barracuda Message Archiver, Barracuda SSL VPN, Barracuda Web Application Firewall version 7.6.4 and earlier, and CudaTel appliances.
It was initially incorrectly reported that the issues impacted some of the other product lines, but I want to reassure you that the issues are isolated to the products listed above, and not Barracuda Backup, Barracuda NG Firewall, Barracuda Firewall, Barracuda Load Balancer, Barracuda Link Balancer, and Barracuda Web Application Firewall (versions 7.7 and later).
Additional Details of the Issues / Solutions
Existence of System Accounts
There were several user accounts present on the appliances that were no longer in use, and could potentially be accessed remotely.
To be exposed, the appliance must either have been deployed directly on the Internet with a public IP address or the attacker must be on the same private network as the appliance.
All remote access to non-essential accounts was disabled in Security Definition 2.0.5 provided to our customers on 1/23/2013.
Allowed Inbound IP Addresses for Support
Since Barracuda shipped the original appliances, the local firewall rules on each appliance were configured to restrict customer authorized remote access to Barracuda-owned IP addresses. To ensure our ability to support these units, the firewall was configured such that new support servers could be added without requiring updates to the appliances in the field.
An attacker with access to a machine on any of the IP ranges in the vulnerability report, and with knowledge of the above accounts, could gain access to an exposed appliance.
However, in order to actually breach the system, the appliance must either have been deployed directly on the Internet with a public IP address or the attacker must have been on the same private network as the appliance in order for it to be exposed. To our knowledge, no system was breached as a result of this vulnerability.
We have removed unauthorized IP ranges in Security Definition 2.0.7 provided to our customers on 2/4/2013.
Opting into Remote Support by Deployment on a Public IP
Remote support is a key value proposition for our Barracuda products. It’s something we discuss in every sale and many customers choose us because of our deep commitment in this area. Our support infrastructure is designed to require the customer to opt in by opening a support tunnel back to our support server when they need help.
In some cases, customers who have deployed their units behind a firewall have problems configuring their firewalls to allow the support tunnel to be established. In these cases, a support technician will ask the customer to move the appliance to a public IP address and the technician will then establish a connection from the Barracuda support server to resolve the problem. When the problem is resolved, the customer is advised to move the appliance back behind a firewall.
An unintended consequence of this ability to support customers is that customers deploying an appliance outside of the firewall implicitly opt into allowing remote support access. While we speak openly about our ability to remotely support customer boxes, the implications of this type of deployment are not explicitly documented. We encourage customers to deploy their appliances behind a firewall that is configured to pass only traffic intended for the appliance.
We are currently analyzing ways for Barracuda to change the support tunnel infrastructure to require customer interaction to open a support tunnel even when a unit is deployed outside the firewall.
Before making major changes within our architecture, we want to ensure we have solid solutions in place to minimize impact to our customers. Because we have not had any incidents reported or detected due to these reported vulnerabilities, we do not want to rush changes that could make the situation worse for our customers.
I welcome your comments and questions. Improved security will be an ongoing dialog from Barracuda. More to come.