Application security represents a major paradigm shift for the security community. In the past, security was about turning on or off a specific port. Done! Application security is much more complex today, and for good reason: hackers have concerted tremendous effort to attack applications. According to a recent Verizon Data Breach Investigation Report, 58% of attack vectors are Web applications.
The cyber crime industry trades in data. Similar to corporate business models, hackers are looking for ways to optimize their return on investment (ROI) by increasing revenue (data) while decreasing costs (attack resources). What is the main way to increase ROI? Automation. From the beginning of the industrial revolution through today, automation means efficiency.
For hacking, automatic tools enable an attacker to attack more applications and exploit more vulnerabilities, and to use resources (e.g., compromised servers) more efficiently. It’s easy for hackers to pick a set of automatic attack tools from the ones that are freely available online, install them and reap the results. What’s more, automatic tools open new avenues for evading security defenses, making an attacker’s job even easier.
Just how much have hackers automated application attacks? Security vendor Imperva reports in its latest Web Application Attack Report, July 2012, that the median annual attack incidents on the 50 Web applications observed was 274 times a year, with one target experiencing more than 2,700 attack incidents. Further, according to the report, the average attack incident for the observed Web applications lasted seven minutes and 42 seconds, but the longest attack incident lasted an hour and 19 minutes. SQL Injection remains the most popular attack vector.
Other findings listed in July’s report include:
- SQL injection remains the most common attack vector: Imperva reviews and summarizes the cumulative characteristics of Web application attack vectors, including SQL injection, cross-site scripting (XSS), remote file inclusion (RFI) and local file inclusion (LFI), and observes that SQL injection is the most commonly used attack for the 50 observed Web applications.
- Intensity of attacks is increasing: Applications will typically see only some serious attack action roughly every third day, for a few minutes, but the attacks may overwhelm the application if the defenses are prepared for only the average intensity of attack.
I talked with Rob Rachwald, director of security strategy at Imperva, to get his thoughts on how security professionals can detect an automated attack and defend against such attacks. He suggested three ways to identify an automated attack:
- Look for site interaction at inhuman speeds
- Look for missing or unique headers
- Use the reputation of automated attack sources
Let’s explore each of those suggestions and how they are relevant to Web application attacks.
Look for site interaction at inhuman speeds
When an automated tool is trying to break into a system, or worse, when it is downloading a bunch of sensitive information, it’s doing so in a very inhuman fashion. Automated tools will scan your website much, much faster than legitimate human interaction will. Typically when a human goes through your site, he might click something every couple of seconds. It takes time for a person to read what’s on the screen and recognize its meaning. How quickly someone – or something – scans through your website is called the click rate.
Also, a person isn’t going to click on every single link on a website; he’ll only look at what interests him. In contrast, an automated tool that is scanning for vulnerabilities will try to evaluate as close to 100% of the website as possible. A scan that is looking at 98% to 100% of your website is clearly coming from some automated tool.
Look for missing or unique headers
When a Web browser or some other tool interacts with your website, it performs a handshake that comes with an introduction that says who it is. For example, a browser will reveal the source IP address, or a legitimate tool will say, for instance, “I am an Acunetix scanner.” Acunetix was written by white hat people to be a legitimate Web tool, so the handshake is a normal thing for this software to do. This introductory information is called a header.
Some hackers are getting sophisticated and they remove or spoof their automated tool’s header in order to hide their identity. A defensive tool should check the header and block traffic from suspicious sources. Even if a header appears to be legitimate, you can use click rate controls and other fingerprints to determine if it’s an automated attack.
Use the reputation of automated attack sources
If we look at the RSA breach that occurred some time ago, we see that the attack originated from 30 different IP addresses. 26 of those addresses were known attack sources; they launched attacks on targets besides RSA. If RSA had had that information, then the company could have blocked that traffic or monitored it to see what was going on.
Imperva finds that about 40% attack traffic comes from typically 10 IP addresses. Just by blocking 10 addresses, you can block a lot of barbarians at your gate. Don’t even let them into your Web app at all.
There are services and consortiums that collect and distribute information about these malicious IP addresses.
Fight fire with fire
Hacker attacks are becoming more sophisticated and relentless as automated tools do their dirty work. Unfortunately, many traditional defensive tools do not detect attacks on Web applications because they are “application dumb.” An IPS or even a nextgen firewall may not detect this type of attack. A Web application firewall may be needed to identify that incoming traffic is generated by a software tool as described above. If the suspect traffic can be identified, it can be blocked