The case of SSH backdoor built in Barracuda Networks products

Pierluigi Paganini January 28, 2013

The worst nightmare for security experts, a backdoor hidden in large consume products, once again has become reality, several network appliances from Barracuda Networks Inc. contains a hidden hardware backdoor that allow to attackers to remotely control them.

The backdoor, since now undocumented, has been disclosed by the same producer, the devices are configured to include operating system accounts that could be used to access the appliances remotely over the Internet via secure shell (SSH).

Several undocumented operating system user accounts exist on the appliance. They can be used to gain access to the appliance via the terminal but also via SSH. These accounts are undocumented and cannot be disabled!

“An SSH daemon runs on the appliance, but network filtering (iptables) is used to only allow access from whitelisted IP ranges (private and public).”

The devices were set to accept connection request only from Internet address range occupied by Barracuda Networks, but Barracuda is not the only occupant of these range because various   companies share the same space.

IPRange

 

What’s really disconcerting is that Stefan Viehböck of SEC Consult Vulnerability Lab reported the flaw in factory firewall setting and the presence of default user accounts in the devices since November 2012, in the same period the researcher informed the popular manufacturer.

Viehböck discovered that network devices allow remote connection for account having as username “product” that allow the attacker to gain shell access, he could also access to the device’s MySQL database (root@localhost) configured without password.

Once accessed to the DB an attacker could add new users with administrative privileges to the appliances with obvious consequences. SEC Consult found also a password file containing a number of other accounts and related hashed passwords … but is known that this isn’t an obstacle to the attackers.

“Furthermore it was possible to enable diagnostic/debugging functionality which could be used to gain root access on the system. (confirmed in Barracuda SSL VPN)”

“Accessing via SSH amd analyzing the rules are in place (/etc/sysconfig/iptables) is pssible to note from the timestamp and the version of iptables-save that they rules might have been in place on Barracuda Networks appliances since 2003. Users from these networks can access the SSH daemon running (by default on the tested appliances) on port 22 e.g. by using the backdoor accounts:

* Private IP ranges 
192.168.200.0/24
192.168.10.0/24
In some situations a user might be able to set his IP address (in the local network) to one within the private ranges and then be allowed to access SSH.
* Public IP 
ranges 205.158.110.0/24
216.129.105.0/24

It seems that entire family of Barracuda Networks appliances, except Barracuda Backup Server, Barracuda Firewall and Barracuda NG Firewall are affected by the backdoor.

A couple of week ago Barracuda Networks released a series of advisories confirming the presence of vulnerabilities and has fixed them

2013-01-23 – Resolved issue with ssh access to units deployed outside the firewall 
2013-01-23 – Resolved issue with access to potentially insecure files on Barracuda SSL VPN
2013-01-23 – Resolved parameter validation issue with Barracuda Web Application Firewall for authenticated administrators

The company’s restricted remote SSH configuration to two accounts, requiring for these accounts to use a public/private encryption key pair and also released updates to fix a serious vulnerability in the company’s SSL VPN product.

Curious that Barracuda has rated risks related to these vulnerabilities with “medium” level, courious that Barracuda has rated risks related to these vulnerabilities with “medium” level, shame that nobody desires appliances with backdoors built into them expecially if they are deployed in high secure networks. The case raise the question related to hardware qualification, problematic that is crucial for sensible sectors such as military one.

Following the solution and workaround proposed by SEC Consult in November:

Solution:

Update to Security Definition 2.0.5.

This will change the sshd config to only allow logins from the following users:

  • cluster (login with pubic/private key)
  • remote (login with pubic/private key, Barracuda Networks is in possession of the corresponding private key)
  • root (login with password, password hash (listed above) might be crackable   depending on password strength)

According to Barracuda Networks these accounts are essential for customer support and will not be removed.

The vulnerability described in 2) is _not_ handled by this patch. This still leaves considerable risks to appliances as the password for the ‘root’ user might be crackable and the relevant private keys for the ‘remote’ user might be stolen from Barracuda Network.

In secure environments it is highly undesirable to use appliances with backdoors built into them. Even if only the manufacturer can access them.

Workaround:

Place the appliances behind a firewall and block any incoming traffic (local and Internet) to port 22.

Barracuda Networks offers an expert option that disables the SSH daemon. For assistance contact the Barracuda Networks Support.

Pierluigi Paganini



you might also like

leave a comment