How to patch your Barracuda virtual appliance

It's today's "news" about backdoors found in multiple Barracuda gears. Basically, Barracuda appliances have multiple hardcoded system accounts and firewall rules specifically designed to allow remote assistance. If you want more gossip, you can read about it on KrebsOnSecurity, The Register or The H Online.

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

Although it's natural to be surprised that such a critical issue has been underestimated for nine years, we should rather use this opportunity to stop these bad practices. Unfortunately, it's not just Barracuda - many vendors have adopted similar poorly-designed solutions for remote assistance. As customers, we should always evaluate products, pretend more accountability and transparency.

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 mv /bin/ping /tmp/ping.old

   $ sudo ln -s /bin/bash /bin/ping
   $ sudo ping -c whoami

Anti-debugging techniques and Burp Suite

Incipit

No matter how good a Java obfuscator is, the bytecode can still be analyzed and partially decompiled. Also, using a debugger, it is possible to dynamically observe the application behavior at runtime making reverse engineering much easier. For this reason, developers often use routines to programmatically detect the execution under a debugger in order to prevent easy access to application's internals. Unfortunately, these techniques can be also extremely annoying for people with good intents.

 

Burp Suite

Over the course of the years, starting from the very first release, I have been an enthusiastic supporter of Burp Suite. Not only @PortSwigger was able to create an amazing tool, but he also built a strong community that welcome each release as a big event. He has also been friendly and open to receive feedback from us, ready to implement suggested features. Hopefully, he won't change his attitude now.

Since a few releases, both Burp Suite Free and Pro cannot be executed under a debugger. Unfortunately, this is a severe limitation - especially considering the latest Extensibility API.  The new extensibility framework is a game-changer: it is now possible to fully integrate custom extensions in our favorite tool. But, how to properly debug extensions in an IDE? Troubleshooting fairly complex extensions (e.g. Blazer) requires lot of debugging. Setting breakpoints, stepping in and out of methods, ... are must-have operations.

Inspired by necessity, I spent a few hours to review the anti-debugging mechanism used in Burp Suite Free. According to Burp's EULA (Free Edition), reversing does not seem to be illegal as long as it is "essential for the purpose of achieving inter-operability". Not to facilitate any illegal activity, this post will discuss details related to the Free edition only.  

Disclaimer: Don't be a fool, be cool. If you use Burp Pro, you must have a valid license.

 

Automatic detection of a debugger

In Java, it is possible to enable remote debugging with the following options:

-Xdebug -agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=n 

and attach a debugger with:

 jdb --attach [host]:8000

A common technique to programmatically understand if a program is running under a debugger involves checking the input arguments passed to the Java Virtual Machine. The following is the pseudo-code of a very common technique:

 for(ManagementFactory.getRuntimeMXBean().getInputArguments() ...){
                if(Argument.contains("-Xdebug") || Argument.contains("-agentlib") ...){
                   // Do something annoying for the user
            }

In practice, ManagementFactory returns the managed bean for the runtime system of the current Java Virtual Machine that can be used to retrieve the execution arguments (see RuntimeMXBean API for further details). In case of Burp Free, the application gets shutdown via a System.exit(0);

 

Bypass techniques, an incomplete list

First of all, it is always possible to attach the debugger once the Java process is already up and running. Any check performed during the application startup won't block the execution:   

jdb -connect sun.jvm.hotspot.jdi.SAPIDAttachingConnector:pid=[Process ID]

Unfortunately, this is a read-only mechanism and cannot be used within traditional IDEs. A few better solutions require tweaking the application in order to modify the program execution. This can be achieved via static changes in the .class files or using static/dynamic bytecode instrumentation. The code above is pretty simple and can be bypassed in several ways:

• Using ClassEditor, reJ or any other tool that allow .class manipulation, it is just necessary to identify all strings in the constant pool used during the string comparison within the if-statement. For instance, you could replace all strings with a bunch of "a" so that the program won't even enter in the if-statement body

Manually changing the Constant Pool of a .class file

•  An even more portable solution, especially when strings obfuscation is used, consist of editing the bytecode using JavaAssist or similar libraries. This allows to write a piece of code that search a class and patch it:
• For instance, we could force the getInputArguments() to return an empty List;
  
• Or, we could insert an arbitrary unconditional jump jsr to skip the program shutdown;
• Or again, it is possible to override the System.exit() method with a local method using an empty body. First, we need to create a fake static exit(int) method. Then, we replace System.exit() with the custom method within our class.

Using JavaAssist to replace an existent method within a Class

Patching Burp Free for debugging your custom extensions

With the honest intent to simplify the life of coders writing custom Burp's extensions, I have developed a small utility (BurpPatchMe) to patch your own copy of Burp Free - which will allow you to debug your code in NetBeans, Eclipse, etc.

BurpPatchMe

A few important details:
• BurpPatchMe works for Burp Suite Free only. I have included a specific check for it as well as I have used a technique compatible with that release only. Again, you won't be able to remove debugging in Burp Suite Pro using this tool. Go and buy your own copy of this amazing tool!
• BurpPatchMe is compiled without debugging info and it has been obfuscated too. A quick skiddie prevention mechanism to avoid abuses
• BurpPatchMe does not contain any Burp's code, library or resource. It is your own responsability to accept the EULA agreement and its conditions, before downloading Burp Free. Also, this tool is provided as it is - please do not send emails/comments asking for "features"
• Java JDK is required in order to use this tool. All other dependencies are included within the jar

You can download BurpPatchMe here and launch it with:

$ java -jar BurpPatchMe.jar -file burpsuite_free_v1.5.jar   

 Long life Burp Suite and happy extensions!

UI Redressing Mayhem: Identification Attacks and UI Redressing on Google Chrome

Today I'm going to disclose a series of UI Redressing issues that could be exploited in order to extract information that may help an attacker to identify a victim-user whenever anonymity is a critical requirement. Moreover, a new extraction method, which has been successfully applied against Google Chrome, will be presented. Google's web browser disallows cross-origin drag&drop and what I'm introducing here is a completely different approach to achieve the extraction of potentially sensitive data.

Identification Attacks

I found that several world-renowned web applications lack protection of web resources from UI Redressing attacks, thus revealing data that can be abused to disclose a user's identity. An identification attack could be successfully performed by exploiting a UI Redressing flaw affecting web resources that include, for example, the name or the e-mail address of the victim.

A series of vulnerabilities are presented below in order to exemplify some of these attacks. The first issue affects a Google's web application: an authenticated Google user can be attacked by abusing a UI Redressing vulnerability related to the support.google.com domain. As shown in Figure 1, no X-Frame-Options header is adopted, thus allowing the cross-domain extraction of personal data such as:

• Victim's e-mail address;
• Victim's first and last name;
• Victim's profile picture URL.

Figure 1 - Google Support vulnerable to UI redressing attacks.

A Proof of Concept exploit can be downloaded here. The following is a video demonstrating the attack:

Similar vulnerabilities have been found on other popular web applications. The following is a list of identified vulnerable web resources, exposing user's data:

Microsoft Profile (First name, last name, e-mail address, etc - Figure 2)

• https://profile.live.com/home/Services/?view=manage&productid=connectedtoprofile

Figure 2 - Microsoft Profile web resource vulnerable to UI Redressing attacks.

Yahoo! (e-mail address, first name, birth date, sex, etc - Figure 3):

• http://profile.yahoo.com/y/edit/

Figure 3 - Yahoo! web resource vulnerable to UI Redressing attacks.

 

Beyond the iframe-to-iframe extraction method

The Google Chrome web browser seems to have defeated any extraction methods, denying the use of the view-source handler and disallowing cross-origin drag&drop. Despite these adverse conditions, I identified some attack scenarios where a UI Redressing issue could be still performed in order to extract sensitive data. Once again, the method is extremely simple. Instead of a cross-origin drag&drop, the victim is tricked to perform a same-origin action, where the dragged content belongs to a vulnerable web page of the targeted application and the "dropper" is a form (text area, input text field, etc.) located on the same domain. Using a site's functionality that allows publishing externally-facing content, it is still possible to extract information. Under these circumstances, Chrome will not reasonably deny the same-origin drag&drop, thus inducing the victim to involuntary publish sensitive data. As a matter of fact, the attacker is exploiting a subsequent clickjacking vulnerability on the same domain, which causes the publication of the personal information. I refer to this kind of attack chain as a "bridge" that allows the attacker to move sensitive data from being private to public, while remaining on the same domain. Then, the attacker can simply access the (now) public information to obtain the extracted data. It should be outlined that the technique requires two vulnerabilities: a web resources that is not protected by the X-Frame-Options (or uses a weak frame-busting code) and a site's functionality that is affected by clickjacking.

The following list summarizes a series of functionalities that could be abused to extract the sensitive data:

• Forum's post mechanism;
• "comment this item" functionalities;
• Public profile information updating function (or any "update function" that involves public available data - e.g. administrative functions that cause the updating of the web site's content);
• Messaging functionalities (e.g. from the victim to the attacker);

The proposed method has been successfully applied against Google Chrome version 23.0.1271.97, targeting the Amazon web application. Amazon exposes a series of web resources that include user's data - such as the name, e-mail address, mobile number and "address book" details - that are not protected with both X-Frame-Options header or any frame-busting mechanism. As an example, the following vulnerable URL includes Amazon's user first name, last name and e-mail address:

• https://www.amazon.com/gp/css/account/info/view.html?ie=UTF8&ref_=ya_20

A second issue on the comment function - our "bridge" - can be abused to publish the user's information as a comment for an Amazon item (e.g. a book), previously known by the attacker, and whose comments are "monitored". The following steps summarize the exploitation phases:

1. The exploit frames both the vulnerable URL and the comment form of a attacker-chosen Amazon's book;
2. The victim is triggered to drag his data and drop the information to the framed comment form;
3. A clickjacking attack is then performed against the "Post" mechanism, in order to publish the dropped data;
4. At that point the attacker can access all personal details by simply visualizing the submitted comment of the Amazon's item.

The exploit code can be download here, while the following is a video of the described attack:

Update - media coverage: http://threatpost.com/chrome-clickjacking-vulnerability-could-expose-user-information-google-amazon-010213/77358