Details of a Real Databreach

It took a breach at Barracuda Networks to prove the necessity of continuous Barracuda Web Application Firewall™ security

Download PDF


In the era of automated Web attacks, the time when an administrator could leave a Web site unguarded for even a few hours has passed into history. On Saturday, April 9, 2011, an unusual set of conditions aligned that resulted in some bad actors successfully breaching a marketing database at Barracuda Networks through an SQL injection attack. A Barracuda Web Application Firewall that had been put into Passive Mode recorded a detailed audit trail of the probe and the subsequent successful attack. This logging gave us the forensic data we needed to quickly analyze the breach, contain the damage and reach out to the people whose names and email addresses had been exposed. Analysis revealed that the attack was most likely launched by “gray hat” hackers with limited criminal intent. This paper will explore how the breach happened, what we learned, and how we unintentionally demonstrated the effectiveness of our own Barracuda Web Application Firewall in preventing further damage and stopping an actual applicationlayer attack in progress.

Why Bad Actors Attack Web Applications

Web application traffic is designed to move transparently through network firewalls. Traditional layer 4 network firewalls are ineffective in detecting and blocking layer 7 (application layer) attacks. However, many organizations – regardless of size – haven’t recognized that layer 4 security measures are outdated. This leaves these organizations vulnerable to application layer attacks from a variety of bad actors whose motives range from professional organized crime, government-sponsored cyber warfare and corporate espionage to interest-oriented political activists and amateurs seeking “street creds” among a loosely knit community of security hacking enthusiasts. The data breach at Barracuda Networks was most likely performed by “gray hat” not-for-profit enthusiasts looking to score points with their peers. How we came to this conclusion is discussed below.

Regardless of the motive, attacks against Web applications and specifically SQL injection attacks have proven to be the most effective way to penetrate networks for stealing data.

  • Web application attacks account for only 54 percent of all data breaches, but 92 percent of stolen records
  • SQL injection attacks account for only 25 percent of Web application attacks, but 89 percent of stolen records1

1. Verizon and US Secret Service Breach Study, 2009

Conditions at Barracuda Networks that Resulted in a Breach

Barracuda Networks employs redundant security procedures to prevent attacks on Web applications. Despite this, a series of events occurred that resulted in the data breach:
  • An error writing PHP code on our Web Site
  • A planned code vulnerability scan was not performed in a timely manner on the part of the Web site that contained the PHP code error
  • The Barracuda Web Application Firewall responsible for safeguarding the Web site was placed in passive mode through human error during a maintenance window

With vulnerable code and the Barracuda Web Application Firewall in passive mode, it was only a matter of time before an attack occurred. Based on the Barracuda Web Application Firewall’s logging and reporting features, here is how the attack occurred:

The Attack Timeline

Analysis of the Attack

Barracuda Web Application Firewall logs allowed us to determine that our bad actors used two clients to probe and attack the Web site:
Note: The Web server logs use Greenwich Mean Time (GMT) whereas the Web Application Firewall uses Pacific Daylight Time (PDT)
Using the information reported by the Barracuda Web Application Firewall, we were able to quickly filter and find the corresponding entries on our Web server logs:
Drilling down into each log entry on the Barracuda Web Application Firewall gave us clues about the attackers and the tools they used in the attack:

The first attack started at 5:07pm PDT on April 9. The attackers’ IP address resolved to the area of Kuala Lumpur, Malaysia. This log entry confirmed online reports that the attacks originated from Malaysia. We also noticed that the attackers used a modified version of a pentest tool designed by “white hats” to probe Web sites for SQL injection vulnerabilities. This log entry correlated with reports that the hacking team responsible for this attack frequented “white hat” online communities. We also found the same entries on our Web server logs. These log entries let us trace what types of attacks were attempted and which attacks succeeded on our backend systems.

Note: The Web server logs use GMT whereas the Web Application Firewall uses PDT
It became clear that the first attacker used an automated tool to recursively crawl through the Web site and blindly inject a series of SQL commands against each input parameter to find potential vulnerabilities. The SQL injection tool found the first vulnerability at 5:16pm PDT but continued to probe the Web site. At 8:10pm PDT a second client using the IP address of joined the attack. The second IP address resolved to a server in Germany. It is unclear at this time if the server was a relay point or if it was a second attacker. The Barracuda Web Application Firewall also recorded and logged activities from the second IP address.

From the logs captured in the Barracuda Web Application Firewall, it seems that the attacker used the second client to launch manual attacks against the discovered vulnerability while the primary attack script continued to scan the Web site to find other vulnerabilities. Ultimately, the attackers focused their efforts on a single line of weak code in a peripheral Web page where the input parameters had not been properly sanitized. Here is the pseudo-code of the underlying vulnerability:

<?=Foo_Function( $_GET[‘parameter’] )?> //Takes user input

By not sanitizing the input value, this code error let attackers inject SQL commands into the HTML input parameter to attack the underlying database.

Developers are taught to never trust user inputs; all inputs must be sanitized before sending them to underlying servers. However, you can see from the example above that it is not often obvious to the naked eye that something is wrong with the code. This is why, in addition to defensive coding, Barracuda Networks uses code scanners and our Barracuda Web Application Firewall to guard against possible vulnerabilities. Because of automated attacks, in a Web site of tens of thousands of lines of code, all it takes is a single mistake for an attack to succeed. We have since added a line of code that sanitizes inputs on the affected page to protect against future attacks:

$parameter = @is_sanitized($_GET[‘parameter’]) ? $_GET[‘ parameter ‘] : 0;
<?=Foo_Function( $parameter)?>

From Vulnerability to Breach

After the attackers found the vulnerable page, they attempted to steal database user accounts. Over the next ten hours, the attackers tried several methods to break into the underlying database, but failed each time. At 3:06am PDT, the attackers changed strategy to focus on the underlying database schema. This proved to be the correct strategy. By 3:19am PDT the attackers had stolen the first email accounts.

A Barracuda Networks’ systems administrator discovered the breach at 10:30am PDT and re-enabled the Barracuda Web Application Firewall to active mode at 10:39am PDT. The Barracuda Web Application Firewall immediately blocked all subsequent attacks from the IP address. The attackers continued to cycle through attacks against the remaining Web pages for the next few hours with the Barracuda Web Application Firewall blocking all of the attacks. This attack profile supports our conclusion that the attackers used an automated pentest tool to blindly inject SQL commands. In all, the attackers sent a total of 110,892 SQL injection commands from both attacking IP addresses against 175 URLS at a rate of 42 per minute.

In tracing the Web Firewall and Access logs on the Barracuda Web Application Firewall, we determined that the attackers compromised a marketing database and stole two sets of records. A total of 21,861 names and emails were stolen from the database. Since there were a number of duplicates in the two sets and many of the entries were from users who are no longer with their original organizations, the number of affected users is substantially lower than the total stolen records.

Any breach is a serious issue. Although the team executing this attack appears to be fairly benign, data breaches like this one have been used to enable spearphishing attacks against affected users. We have already reached out to affected users with documentation and have advised of possible precautions they may wish to take. We believe that the users affected by the breach are at minimal risk. We do not store any sensitive information in our marketing database other than names and email addresses. Moreover, since Barracuda Networks primarily uses this customer data to send emails on upcoming events, Webinars, or corporate news updates, the risk of spearphishing is low as the all of communications are one-directional and informational in nature. Finally since most users are existing Barracuda Spam & Virus Firewall customers, the vast majority of potential spam would likely be blocked.


In what would be called a before-and-after experimental design — had we been doing an intentional field experiment — we found that our Barracuda Web Application Firewall provided complete protection against SQL injection attacks for our Web site which contained a PHP code vulnerability, until we unintentionally turned off the active protection mode. Upon detection of the attack, resetting the Barracuda Web Application Firewall to active protection mode stopped subsequent attacks within seconds. The Barracuda Web Application Firewall’s logging and reporting capabilities helped in forensic analysis of the attack and in simplifying responses for contacting the affected parties as well as handling inquiries from the media, research and analyst communities. While careful coding and vulnerability testing are important parts of current network defense postures, Barracuda Web Application Firewalls should be the first line of defense against layer 7 attacks.

Barracuda Web Application Firewall Features:

  • SQL injection flaws
  • Cross Site Scripting (XSS)
  • OS command injections
  • Site reconnaissance
  • Session hijacking
  • Application denial of service
  • Malicious probes/crawlers
  • Cookie/session tampering
  • Path traversal
  • Outbound filtering to prevent information leakage (DLP)
Barracuda Web Application Firewalls also have features that organically optimize network performance:
  • SSL Offloading
  • SSL Acceleration
  • Load Balancing

Contact a representative at Barracuda Networks today at: 1-888-ANTI-SPAM or visit:

Also available as virtual appliances.