A new old story
According to the original advisory, the bug was discovered on 2012-11-20 by Stefan Viehböck. Although Stefan did pretty interesting research in the past (e.g. WiFi WPS design bug), the Barracuda backdoor is really not a new story. Not only this issue was known, but it was even disclosed and discussed several times:
- http://packetstormsecurity.com/files/35358/Barracuda_Evil.txt.html - 2004
- http://archives.neohapsis.com/archives/fulldisclosure/2006-08/0110.html - 2006
- http://blog.shiraj.com/2009/09/barracuda-spam-firewall-root-password/ - 2009
Digital self-defense
In 2011, while helping a friend during the setup of his network, I came across the advisory from 2004 and I started investigating. After having confirmed the issue, I decided to patch the virtual appliance on my own. If you think that the mitigation provided by Barracuda in the security definition 2.0.5 is not adequate for your environment, keep reading. Hopefully, Barracuda will reconsider the situation and you won't need to manually patch your device.Disclaimer: Use this information at your own risk!
You may end up with a broken appliance and no more vendor warranty. Also, I am not a lawyer and I haven't reviewed the product EULA. Finally, note that this method has been tested against the Barracuda WebApp Firewall 660vxl (v7.5.0.x) virtual appliance only.
Patching your virtual appliance
Removing system accounts and changing iptables configuration require privileged shell access. As the original techniques for rooting the device are now deprecated (at least in the device I had), I started looking for other ways to get a root shell. Soon, I realized that it's possible to abuse the recovery partition in order to include arbitrary resources. This technique requires "physical" access to the appliance and multiple reboots thus I consider it better than disclosing the root password and suggest you to abuse the backdoor in order to patch the device.Rooting the Barracuda WebApp Firewall requires a multi steps process:
1) Boot the Barracuda virtual appliance with a standard Linux distribution (e.g. booting from the virtual CD) and mount the recovery partition (/dev/sda9) in order to copy the patcher script (rootme.sh).
rootme.sh can be downloaded here
$ mkdir /mnt/temp
$ mount /dev/sda9 /mnt/temp
$ cp rootme.sh /mnt/temp/
$ chmod 777 /mnt/temp/rootme.sh
$ /mtn/temp/rootme.sh
$ umount /mnt/temp
$ reboot
2) From the web console, revert the firmware to the factory installed version (Advanced-->Firmware Update-->Firmware Revert) and reboot again the appliance. If the factory Firmware Revert button is not available (it's gray and cannot be selected), you need to update the device to the newest firmware and repeat the entire process.
3) Visit https://barracuda_ip/cgi-mod/rootme.cgi. After that, you can connect via SSH to the device using a temporary root password. Removing the hardcoded system accounts and changing iptables is left as exercise.
A few more technical details:
- rootme.sh is simply used to copy rootme.cgi to the web console webroot in order to facilitate the rooting process
- rootme.cgi is used to escalate privileges from the Apache user (nobody) to root, change the root password and the firewall rules in order to allow external access
- Privileges escalation is possible due to an insecure sudoers configuration. Again, nothing fancy. Please note that I have reported this misconfiguration to Barracuda on 09/12/2011.
$ sudo ln -s /bin/bash /bin/ping
$ sudo ping -c whoami
$ sudo ping -c whoami
Hey,
ReplyDeleteDoes this still work with virtual devices? Thanks,
This comment has been removed by a blog administrator.
ReplyDelete