Barracuda Web Application Firewall XSS vulnerability

Unfortunately this one is a bit late, but at the end of 2012 I came across a reflected XSS vulnerability within the Barracuda Web Application Firewall device.

This can be triggered by manipulating the ‘group_name’ URL parameter as follows:

http://192.168.0.31:8000/cgi-mod/index.cgi?&user=XXXXXXXXXXX&password=XXXXXXXXXXXXXXXXXX&et=XXXXXXXXX&auth_type=Local&locale=en_US&primary_tab=ADVANCED&secondary_tab=advanced_ip_config&group_name=%22%20style=%22xss:expression(alert(‘Cross Site Scripting on the WAF web interface !!!!!’))

Which results in the following:

A firmware patch was released (Version 7.7) to address this issue.

I would like to thank Barracuda for their good communication and turn around in resolving this vulnerability.

Advertisements

Redirect to SSH honeypot with iptables

Like most people I often see a lot of noise from the dark corners of the internet to my public SSH servers, often attempting a dictionary attack. There is a well known way to harden your system against these forms of attacks using a combination of iptables and the recent module as follows:

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 120 –hitcount 3 –rttl –name SSH -j DROP

These 2 rules track connection attempts and drop any new (TCP SYN) attempts to access the SSH server more than 3 times within 120 seconds. As long as your SSH password cannot be guessed with 3 attempts (it’s not password01 is it?) this is an effective way of stopping attackers from continually guessing passwords. Job Well Done you say?

Well yes, but sometimes it is useful to find out what the attacker is trying to do on your system, is this a precursor to a further attack or simply a script kiddie running the latest pwnssh tool? If we want to see what the attacker is trying to do we can always leverage honeypots.

PLEASE NOTE: Honeypots suffer from the same weaknesses as any other software, it is always safer to block the attacker at the lowest layer possible. If you choose to deploy a honeypot make sure that you understand and mitigate against any risks that allowing an attacker into your system may incur.

Using the iptables example above it may be worth explaining what is happening:

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH

This command adds a new rule to our INPUT chain, which matches any traffic coming in over the ‘eth0′ interface for TCP port 22. The state module (-m state) is used to allow connection tracking which in our case we are looking for new connections only (TCP SYN packets). If this matches we keep a record of the source host in a temporary location (usually /proc/net/xt_recent). Each time a new attempt is made to connect to TCP port 22, this rule is matched and the number of attempts is incremented.

The next rule is:

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 120 –hitcount 3 –rttl –name SSH -j DROP

Again this rule is added to our INPUT chain, it matches traffic coming in through eth0 interface for port 22 and only matches NEW connections. This time if the number of requests from the source has been seen 3 times (hitcount) within 120 seconds, we will drop the packet and therefore the bruteforce attempt.

But what if we don’t want to drop the packet, what if we want to simply shift the attacker to another service such as a honeypot for later analysis. Assuming that a honeypot has been set up to listen on port 2222 such as Kippo, we can utilise NAT along with the recent module to forward the attackers traffic to a honeypot:

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 120 –hitcount 3 –rttl –name SSH -j REDIRECT –to-port 2222

Using this instead of dropping the packet, we redirect to port 2222 on the local machine. If we have a honeypot listening (you may need to add your SSH host keys to the honeypot to stop the attacker becoming aware of the switch) we can capture the attacker and complete our analysis.

For a legitimate user they will experience the following flow:

Attempt to log into SSH server – INPUT rule matches and logs this as a new connection.
Enters correct password and connection is established – Neither of our rules match as this is now an established connection and the user can now continue with their SSH session.
However an attacker will experience a different flow:

Attempt to log into SSH server with Password 1 – INPUT rule is matched and logs this as a new connection attempt.
Attempt to log into SSH server with Password 2 – INPUT rule is matched and again logs this as a new connection attempt.
Attempt to log into SSH server with Password 3 – INPUT rule is matched and logs this as a further connection attempt.
Attempt to log into SSH server with Password 4 – NAT redirect rule is matched as attacker has made 3 requests within 120 seconds. The attackers requests are now forwarded to TCP port 2222.

The attacker successfully penetrates the honeypot and is now in a sandboxed environment for monitoring.
As you can see, this may be a useful addition to your existing security policy to study an attack on your system.