web application firewall

Last weekend, the northern United States was covered with a wintery blanket of snow causing trapped commuters to hack back at the frosty accumulation with shovels to clear a path. Meanwhile Saturday, out of an Ann Arbor, Michigan office building lobby a hand selected team of Information Security professionals were hacking back with their computers in an International Capture The Flag (CTF).

On May 17, 2013, I published a primer article titled Security War Games for Dark Reading highlighting the value for an organization to encourage their technologists to partake in security war games for a stronger defensive team.

The team of ethical hackers is called MiSec, short for Michigan Security, and were testing their metal against 173 teams spread across the planet. The team captain, Wolfgang Goerlich, Vice President of Consulting Services for VioPoint, asked if I would join the MiSec team to deploy a Barracuda Web Application Firewall (WAF) and Barracuda NG Firewall in front of a highly vulnerable Linux server.

The CTF was an attack and defend style competition. This means Mr. Goerlich assigned team leads to organize the attack, known as Red Team, on competitive vulnerable servers while the defensive, Blue Team, was looking to protect their nine services from attacks. That's where the Barracuda WAF and Barracuda NG Firewall came into the mix.

Mr. Goerlich dubbed the Barracuda layers of protection as project “SHIELD”. When asked about the strategy behind using Barracuda technologies, Mr. Goerlich respond, “The goal of project SHIELD was to reduce the number of flags we lose per application, thus increase our total points.”

Unfortunately, once we established the lay of the land, as soon as points were earned they were quickly captured by competitors before the tuning can be applied. Mr. Goerlich continued, “We employed a strategy of putting the technology in place, monitoring, and selectively enabling IPS for specific applications.”

As shown in the rules graphic, competitive team traffic was restricted from being filtered out, additionally, all hostile activity originated from a single IP address. Not being able to differentiate the hostile connections from the organizers connections made it impossible to enforce traffic shaping or firewall rules specific to the attackers. We were forced us to look deeply at the traffic going through the NG Firewall and WAF. The organizers of the CTF monitored the health of our services and would periodically change the flags. As Mr. Goerlich stated, “The RuCTFE uses a unique scoring algorithm where the flag points are the total flags captured less the total flags lost. If we capture three flags and yet lose three flags to other teams, our score is zero.”

Adding to the complexity of earning points, if your team submits a flag while the flag for that service is down, then no points are earned for that flag.

As a countermeasure to losing data, a.k.a CTF points, “Virtual patching was a capability that we relied heavily upon. Once our defense determined a particular tactic was being used to capture our flags, we were able to block that tactic using a combination of rules on the Web application firewall and next generation firewall,” stated Mr. Goerlich. He continued to say, “This bought our developers time to develop a patch. In one particular application, we relied solely on the virtual patching capability until the end of the game.”

The MiSec team also included a small army of developers and operationally skilled individuals to keep the system running after getting attacked. Every team within the team focused on a task while trying to feed as much useful data to the other teams. Mr. Goerlich made a valid point that, “The RuCTFE is like the corporate environment on a caffeine-fueled fast-forward. The size of our CTF team is comparable to many organization’s IT, developer, and security staff. The primary difference is that it is all accelerated into a ten hour window.”

All the more reason for having the layers of protection in a corporate environment. Fortunately, corporations have more time to respond to the incidents. Unfortunately, delaying until it happens, the cost of a data breach will be much higher than implementing a security solution, depending upon the regulation and size of breach.

For example, a simple looking HTTP request like this one was revealing a large amount of sensitive flags in a vulnerable LDAP address book.

http://<ip_address>:8000?action=info&name=*&surname=*)(%7c+(userPassword=*&password=q)

Once this attack was detected, the Barracuda Web Application Firewall was tuned to identify that this was an attack (in the context of the RuCTFE) and not a harmless HTTP request exposing a password. “The flag values are recognizable and consistent, like credit cards or social security numbers, and this makes them ideal for DLP,” stated Mr. Goerlich.

There are several stories and lessons learned to tell about the MiSec team's experiences this year, but not enough room in this article. I hope to provide a follow up article with some in-depth analysis of the web attacks once we sift through the data.

In closing, Mr. Goerlich felt, “The Barracuda equipment stood up to hundreds of highly trained and highly motivated attackers. These attackers had inside knowledge of the services and applications we were running. (All teams share the same services and code base.) The equipment withstood the attack and stemmed the loss of data. That speaks very highly for the level of protection a standard corporate environment can expect from using Barracuda.”

Well put Mr. Goerlich and I intend to be at the ready the next time you need Barracuda and me to protect MiSec's assets, sans the shovel.

No security, no privacy. Know security, know privacy.