Barracuda Networks SSHd Backdoor Accounts

2013-01-24T00:00:00
ID PACKETSTORM:119817
Type packetstorm
Reporter S. Viehbock
Modified 2013-01-24T00:00:00

Description

                                        
                                            `SEC Consult Vulnerability Lab Security Advisory < 20130124-0 >  
=======================================================================  
title: Critical SSH Backdoor in multiple Barracuda Networks  
Products  
vulnerable products: Barracuda Spam and Virus Firewall  
Barracuda Web Filter  
Barracuda Message Archiver  
Barracuda Web Application Firewall  
Barracuda Link Balancer  
Barracuda Load Balancer  
Barracuda SSL VPN  
(all including their respective virtual "Vx" versions)  
vulnerable version: all versions < Security Definition 2.0.5  
fixed version: Security Definition 2.0.5  
impact: Critical  
homepage: https://www.barracudanetworks.com/  
found: 2012-11-20  
by: S. Viehböck  
SEC Consult Vulnerability Lab  
https://www.sec-consult.com  
=======================================================================  
  
Vendor/product description:  
-----------------------------  
URL: https://www.barracudanetworks.com/products/  
  
  
Vulnerability overview/description:  
-----------------------------------  
1) Backdoor accounts  
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. (see 2)  
These accounts are undocumented and can _not_ be disabled!  
  
2) Remote access via SSH  
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 public ranges include servers run by Barracuda Networks Inc. but also  
servers from other, unaffiliated entities - all of whom can access SSH on all  
affected Barracuda Networks appliances exposed to the Internet.  
  
The backdoor accounts from 1) can be used to gain shell access.  
This functionality is entirely undocumented and can only be disabled via a  
hidden 'expert options' dialog (see Workaround).  
  
  
Proof of concept:  
-----------------  
URLs and other exploit code (passwords) have been removed from this advisory.  
A detailed advisory will be released within a month including the omitted  
information.  
  
  
1) Backdoor accounts  
The passwd and shadow file show that the following accounts exist.  
Some passwords could be recovered (short attack with tiny wordlist):  
  
root:x:0:0:root:/root:/bin/bash <-- UID: 0!  
<hash removed>  
NOT CRACKED during given time (confirmed static in tested appliances)  
  
build:x:0:0:Build User:/root:/boot/os_tools/clone_interactive.pl <-- UID: 0!  
<hash removed>  
NOT CRACKED during given time  
  
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown -h now  
<hash removed>  
CRACKED <password removed>  
  
product:x:700:100::/home/product:/bin/bash  
<hash removed>  
CRACKED <password removed>  
  
ca:x:704:65534:ACL reset user:/home/ca:/home/emailswitch/code/firmware/current/bin/clear_acls.sh  
<hash removed>  
CRACKED <password removed>  
  
support:x:705:705::/home/support:/home/product/code/firmware/current/bin/request_support.pl  
<hash removed>  
CRACKED <password removed>  
  
websupport:x:706:706::/home/websupport:/home/emailswitch/code/firmware/current/bin/request_web.pl  
<hash removed>  
CRACKED <password removed>  
  
qa_test:x:707:707::/home/qa_test:/root/qa_test1.pl  
<hash removed>  
NOT CRACKED during given time  
  
The following users have public keys added to their authorized_keys  
file:  
  
remote:x:0:0:Remote Access:/home/remote:/bin/bash <-- UID: 0!  
# cat /home/remote/.ssh/authorized_keys2  
ssh-dss AAAAB3NzaC1kc3MAAACBAM3angjOeIjCePKw8a/zTugPKK+hoYkpQhyXY8+BN  
q14nCInlcrzhavCiQCVKNTVtpW0A2hs75/QGslwrTpulsX89ZQL0Wx915iNbaf0P5sXoU  
rA0iPoPoL3nIXWskjc6xj+x66svIVHxiBYpnTSaBNaJhxU5/3eK+/3sSPrAR0NAAAAFQD  
u09YU0d2eG63v+zHmSIKCMZ8vnwAAAIAPaB34rhWjIRE5hz6YxU8jeEnPZPr3ZX8hbshk  
asrrcQG+L0UeTGKoL7JTYQ2vu/549xXBpheiTAKunYES6RwURziz11vq6oWix3Wo6GGOb  
yS53MIbyyc4DrB4zLDUI4PJFLBxwKTOBOSU7OuCH7sQ6rzaMrsDZIf6GxeTrDIN1gAAAI  
AlkA1hEFFmRh7SfOkN4oGFcvZl/71PTEXnK3HZZopYW5WIqueTl6NALiq6FobY+U8b/NQ  
ibvXXEinLP6dgqd/xnYYhwoUMuP5GPDhUkl+xKoBjAd+33yT4AN1ymWx/LZZ+9uQXt08k  
Q3sgpXBhW6YT+rqrJLgc9l3Y2/exVGJjYA== manager@support01.barracudanetwo  
rks.com  
  
cluster:x:1000:1000::/home/cluster:/bin/bash  
# cat /home/cluster/.ssh/authorized_keys2  
ssh-dss AAAAB3NzaC1kc3MAAACBAJ5O8UhVP3lb0Mff66uHMkvcZlxPJF/7pgtcq5Qd/  
7cuwqv65/BiDU2oNOWAIfaO89K+kLvrt+VY3TdemTrcRGiTZfzXeRASB9wWVI7rPPsIYs  
S47lBEp7PYJANWXd6rYgfTw3fr1PYHpUBDgxOcHshmL469lDDbx6CodrwgK4e/AAAAFQD  
a/pjlqnKmBtWNqBXB89J3qhb06QAAAIAiQCodsX5QqA8TBP6scOYIckkHiUbIireamxVa  
U587P7uthFiMVnKrj9MTzwgFebTQQ02B9LQpXfmMdQdZi2Hb8FCwP1cuxp0yAHKqYh3ss  
hCzhDq2lrw1NrAVlrkp4dqj0lvwEUp3BYf9VnveylrfiHA45hyXdXdzfxdn7/CDQQAAAI  
AOtKcLIsZ30Y4HG0Qk4cYqKw8QryvS36xbvywX7Tq8/7N5D0LrjaCzBYo8cBIBxHjpePT  
D7pOSgUiuXk16y8ffTYzLexSqL0wFLV5GIIxAeXhtCtIUPVXRZzTm97NiErikbfjDRx0P  
PZKcOH8A1LX4Y0nLoBbnNnPvhcIXfElkow==  
  
At least the user "product" can be used to login and get a shell on the  
appliance.  
  
It was confirmed that this user can access the MySQL database (root@localhost  
with no password) eg. to add new users with administrative privileges to the  
appliance configuration.  
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)  
  
  
2) Remote access via SSH  
An /etc/sysconfig/iptables file shows which rules are in place:  
  
# Generated by iptables-save v1.2.7a on Thu Oct 9 16:39:19 2003  
*nat  
:PREROUTING ACCEPT [4012:488438]  
:POSTROUTING ACCEPT [641:40599]  
:OUTPUT ACCEPT [641:40599]  
COMMIT  
# Completed on Thu Oct 9 16:39:19 2003  
# Generated by iptables-save v1.2.7a on Thu Oct 9 16:39:19 2003  
*filter  
:INPUT ACCEPT [42408:13197223]  
:FORWARD ACCEPT [0:0]  
:OUTPUT ACCEPT [49685:7341128]  
-A INPUT -s localhost -p tcp -m tcp --dport 22 -j ACCEPT   
-A INPUT -s 192.168.200.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT   
-A INPUT -s 192.168.200.0/255.255.255.0 -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT   
-A INPUT -s 192.168.10.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT   
-A INPUT -s 192.168.10.0/255.255.255.0 -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT   
-A INPUT -s 205.158.110.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT   
-A INPUT -s 205.158.110.0/255.255.255.0 -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT   
-A INPUT -s 216.129.105.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT   
-A INPUT -s 216.129.105.0/255.255.255.0 -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT   
-A INPUT -p tcp -m tcp --dport 22 -j REJECT --reject-with icmp-port-unreachable   
COMMIT  
# Completed on Thu Oct 9 16:39:19 2003  
  
Note:  
The timestamp and the version of iptables-save suggest that these 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  
  
These ranges include some servers run by Barracuda Networks eg.  
spam04.barracuda.com (216.129.105.22)  
forum.barracudanetworks.com (216.129.105.38)  
barracudacentral.org (216.129.105.40)  
repsrv.barracuda.com (216.129.105.42)  
mirror01.barracudacentral.com (216.129.105.94)  
...  
  
but also servers from other entities:  
mail.totalpaas.com (205.158.110.135) - Domain registered by: Domains By Proxy, LLC ...  
frmt1.boxitweb.com (205.158.110.132) - Domain registered by: Thor Myhrstad  
static.medallia.com (205.158.110.229) - Domain registed by: Medallia Inc.  
utility.connectify.net (205.158.110.171) - Domain registered by: Connectify Networks, Inc.  
everest.address.com (216.129.105.202) - Domain registed by: WhitePages, Inc.  
mail.tqm.bz (216.129.105.205) - Domain registered by: Total Quality Maintenance, Inc  
outbound.andyforbes.com (216.129.105.212) - Domain registered by: HM hosting  
...  
  
More information about the hosts in these /24 networks can be found at:  
http://cnet.robtex.com/205.158.110.html  
http://cnet.robtex.com/216.129.105.html  
  
A breach of any server in the whitelisted ranges enables an attack against all  
affected Barracuda Networks appliances on the web.  
  
Note:   
The credentials from 1) (eg. "product" user) can be used to get a shell  
on a appliance.  
  
  
Vulnerable / tested versions:  
-----------------------------  
The vulnerability has been verified to exist in Barracuda SSL VPN version   
2.2.2.203, which was the most recent version at the time of discovery.  
  
Barracuda Networks confirmed that _all_ of their appliances with the exception  
of the Barracuda Backup Server, Barracuda Firewall, and Barracuda NG Firewall  
are affected as well in _all_ available versions.  
  
  
Vendor contact timeline:  
------------------------  
2012-11-29: Contacting vendor.  
2012-11-29: Sending advisory and proof of concept exploit via encrypted  
channel.  
2012-12-04: Vendor confirms receipt and provides BNSEC IDs.  
2012-12-05: Requesting further coordination (conference call).  
2012-12-13: Sending reminder regarding SEC Consult disclosure policy.  
2012-12-15: Vendor responds - arranging conference call.  
2012-12-18: Conference call: Addressing the risks the discovered  
vulnerabilities pose to customers and release schedule.  
2013-01-14: Vendor sends listing of reported vulnerabilities and release   
schedule.  
2013-01-21: Conference call - discussing implemented solutions.  
2013-01-21: Vendor provides information about some questions which came up.  
2013-01-22: Asking for definitive listing of affected appliances.  
2013-01-23: Barracuda Networks releases alert & secdef  
2013-01-24: SEC Consult releases coordinated security advisory.  
  
  
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 Networks.  
  
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.  
  
  
Advisory URL:  
--------------  
https://www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm  
  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
SEC Consult Unternehmensberatung GmbH  
  
Office Vienna  
Mooslackengasse 17  
A-1190 Vienna  
Austria  
  
Tel.: +43 / 1 / 890 30 43 - 0  
Fax.: +43 / 1 / 890 30 43 - 25  
Mail: research at sec-consult dot com  
www.sec-consult.com  
  
  
EOF S. Viehböck / @2013  
`