Thinking about Onions By Jason Reed

Another security firm hacked. That’s the story coming out of Barracuda Networks where attackers successfully exploited a SQL injection bug in a PHP page and were able to dump the contents of the MySQL server supporting the content on the external site.

Exposed were customer names, logins, email addresses and phone numbers, Barracuda Network employee’s credentials, and credentials of the MySQL database itself.

The official word from Barracuda is that a web application firewall in front of the web app was accidentally placed in passive monitoring mode during a “maintenance period” and was not reactivated. The SQL injection allowed the attackers to gain access to at least 5 databases and their associated tables. Some of the table names shown in the release by the hackers: CHAT_ADMIN, MySQL’s USER, BUNIVERSITY_USERS, CMS_LOGINS, and DEAL_REG.

This would seem to be the year of security giants falling to attacks. With RSA’s well-publicized issues already, we stop and wonder that if these companies, who hopefully think about security often, can fall, what chance does the common .Com have?

Taking a look at the Barracuda attack helps us all learn lessons about the way we should do business on the Net. Let’s hit some of the highlights.

First, the WAF was disabled for maintenance, which left the web app behind it susceptible. What this means to me is that the application could of always had this issue, but the WAF masked it from the outside. Many will say to “let the firewall do its job”.

However, I think of onions.

We have all heard of defense-in-depth. The idea is that each service should protect itself in case of a failure in the next layer up. In Barracuda’s case, the PHP page was susceptible to SQL injection, which was blocked by the WAF up until Friday. The problem was, the PHP page should have protected itself by escaping the input, using parameterized queries, and applying a white-list to the input instead of relying on the WAF for all of these functions.

Security-based code reviews should be a part of everyone’s software development practices. Looking for dynamic SQL statements in code is easy. Looking for more complex vulnerabilities from user input takes a code review. As we often tell our customers, you could be one click away from being compromised if you don’t make security part of each layer.

The next issue was a violation of least privilege. This basic security tenant states that a principle (in this case a web application) should have the least amount of privilege needed to perform its functions. Some may say that a single application credential having access to all the databases simplifies development and deployment reducing the possibility of errors.

I, however, again think of onions.

From the hacker’s release, it is clear that the user ID used by the application had access to other databases, including the system table. Instead of using a powerful user ID for the application, the database should be configured to only allow access to the data that it requires for servicing its requests. This means, performing an analysis of the data contained in the system and what is needed for each application. Requiring multiple user IDs for access is a good way of segmenting access to the data. The attacker might have to break a couple of layers to get at anything important. At a minimum, this lengthens the time of the attack and hopefully it can be shutdown before an exploit is found.

Last, the failure of the WAF to block traffic exposed the issue with PHP. We always encourage our customers to test the periodic failure of their protections to see if the next layer down is secure. Test your systems without the benefits of your WAFs or Network Firewalls and see where your weaknesses truly lie. Take the time, at least annually, to discover if your onion has just one layer.

Bon Appétit.