Stopping Active Attacks with Penalty Box

Unfortunately, today's sophisticated web application threats have gained some advantages over typical WAFs:

• Favorable odds -- WAFs must correctly identify attacks 100% of the time, whereas attackers have the luxury of only needing to find a single bypass or evasion
• Temporary fixes -- Many WAFs use a "whack-a-mole" response tactic by only denying the individual attack request, allowing the attacker to make repeated attempts
• Persistence -- If left unimpeded, attackers may eventually find some type of payload obfuscation that minimizes detection effectiveness

The confluence of these advantages should concern WAF customers. Let's take a closer look at the typical web attacker methodology to see why.

Typical web attacker methodology

We can reference the popular Cyber Kill Chain framework and apply it to web application attacks.

The first four steps in the approach are usually consistent regardless of the end goals of threat actors. During the Reconnaissance, Weaponization, and Delivery phases, web attackers use extensive automation to identify likely exploitation vectors in a target web application. As an example, for Structured Query Language injection (SQLi) attempts, attackers will often use open source or commercial tools such as:

• Sqlmap
• Burp Suite
• Havij
• Netsparker

These tools quickly send thousands of attack variations to the target web application. Depending on the application's response, these tools will flag potential attack vectors and report them to the threat actor.

Web security analytics: attack session view

During this initial attack phase, the WAF is dutifully identifying and blocking attack requests. Let's take a look at this web security analytics (WSA) attack session view:

As this dashboard shows, an attacker sent 478 SQLi attempts within a five-minute time frame and the WAF denied all of the requests. Random opportunistic threat actors may indeed conduct an initial attack scan like this and, if blocked, give up and move on to another target. However, targeted threat actors will not give up so easily -- they will move on to the next phase of the attacks and attempt to obfuscate payloads to avoid detection.

Trial and error: payload obfuscation testing

Targeted threat actors who are incentivized to continue to attack will normally shift to a manual attack session in order to develop a working WAF evasion payload. This consists of an iterative process of trial and error similar to the following:

1. Send SQL payload and inspect the HTTP response payload for database error responses
2. Use obfuscation techniques
3. Send modified attack payload and observe the response
4. Repeat steps 2 and 3

Here are some example SQLi attack payload permutations taken from a past public hacking challenge as an attacker attempts to identify a bypass in the OWASP ModSecurity Core Rule Set:

Blocked -> div 1 union%23%0Aselect 1,2,current_user 
Blocked -> div 1 union%23foo*/*bar%0Aselect 1,2,current_user
Blocked -> div 1 union%23foofoofoofoo*/*bar%0Aselect 1,2,current_user
Blocked -> div 1 union%23foofoofoofoofoofoofoofoofoofoo*/*bar%0Aselect 1,2,current_user

... hundreds more permutations ...

Not Blocked -> div 1 union%23foofoofoofoofoofoofoofoofoofoofoofoof oofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo*/*bar%0Aselect 1,2,current_user

Hacking resistance (time to hack)

In my book, Web Application Defender's Cookbook, I discuss an important topic as it relates to WAF usage. WAFs should make your web applications significantly more difficult to hack. In other words, it should take attackers significantly more time to find and exploit a vulnerable website with a WAF in front in blocking mode versus a website with no WAF at all. The goal should be to substantially increase the time-to-hack metric associated with compromising a site in order to allow operational security to identify the threat and take appropriate actions.

In the past, I ran a public SQLi evasion challenge with the community as part of the OWASP ModSecurity Core Rule Set (CRS) Project. The challenge analyzed the data for any participant who found a rule bypass in the CRS logic and identified the following metrics:

This data shows that having active monitoring and response capabilities of ongoing web attacks is paramount as it may only be a matter of hours before a determined attacker finds a way through your defenses.

I realize that there are a multitude of variables and conditions for which people can say that these numbers are off (either too high or too low), depending on your defenses and attacker skill level. The point of presenting this data, however, is to have some form of metric available for active web application monitoring and defense discussions related to exploitation time lines.

Penalty box: immediate active defense

How can organizations use their WAF to significantly improve their time-to-hack metric? With the new Penalty Box capability provided by Akamai App & API Protector, WAF customers can implement an immediate, persistent block against an active attack session. If customers are using automated attack groups, they can protect their site or API from abusive clients by using the Penalty Box.

When WAF customers turn the Penalty Box on, any client whose request violates an attack group set to the action "Deny," will be placed in the penalty box. There, the action selected for the penalty box (either "Alert" or "Deny") continues to apply to any requests from that client for the next 10 minutes. After 10 minutes, the client moves out of the penalty box, and its requests are no longer denied, unless another request triggers a "Deny" action again and sends the client back to the penalty box for another 10 minutes. The main advantage of the Penalty Box feature is that it is able to quickly identify an active attack session and initiate a block, thus decreasing the effectiveness of automation used by the attacker.

Let's take a look at a real-world example as displayed in the WSA dashboard.

In this screenshot, we can see a threat actor originating from Russia has initiated an attack session that lasted approximately one hour. During that time frame, the App and API Protector WAF denied several hundred attacks across multiple attack categories. Additionally, with Penalty Box enabled, the WAF also automatically blocked more than 9,000 requests that were part of the active attack session. Using the WSA Samples View, we can dig deeper into the analysis details to identify which individual requests were initially denied by default WAF attack logic.

In this screenshot, we can see that the attacker sent an SQLi attack inside a query_string and the App and API Protector WAF properly blocked it. Additional analysis of the User-Agent header data reveals that the attacker is using the Nuclei framework scanner. This data confirms our attacker methodology model where attackers utilize automation tools to help them quickly identify vulnerabilities. Once this attack was identified, however, the Penalty Box feature was activated and any further requests from this attack session were subsequently blocked.

Penalty box benefits

Increasing attacker costs

The benefits of utilizing the Penalty Box include:

1. Significantly increasing the time it takes for attackers to complete their reconnaissance and initial attack probes
2. By automatically blocking the attacking clients, the attacker is forced to funnel their attacks through other systems; therefore, they can no longer attack from a stationary location

Both of these elements demonstrate that Penalty Box dramatically increases the costs for attackers to continue to attack any web applications that Akamai is protecting.

Trap-and-trace audit logging

While the Penalty Box "Deny" action is valuable for stopping active attack sessions, there is an added benefit beyond the action defined that creates a trap-and-trace audit log of the attacker's actions. From a forensics and incident response perspective, it is ideal to have as much logging enabled as possible.

Full audit logging is ideal, but many organizations opt to log only security-relevant transactions with their WAF. This configuration reduces the amount of audit log data collected, but it is less than ideal from an incident response perspective. Penalty Box logging is a middle-ground logging configuration we use to dynamically increase audit logging for suspicious clients.

Rather than setting a static global configuration for the amount of data, we will audit log for all clients, then use Penalty Box for conditional increased logging. For example, the default WAF audit logging configuration is "alert-centric" and generates an audit log entry only if the client triggers one of our negative security rules. This is not ideal from a security perspective, because we do not have a full view of the client's activities within the web application. What we can do instead is use a trap-and-trace configuration with the initial security alert as a trigger to place the client on a "watch list." Doing so initiates full audit logging for this client, regardless of whether they trigger any alerts on subsequent requests.

Payload obfuscation analysis

An additional benefit of the Penalty Box is that this data set is a treasure trove of information for techniques used by attackers to obfuscate their payloads, which informs Akamai threat research. Due to the fact that the Penalty Box action is applied after the normal WAF attack group logic, it means that any data showing up there did not exceed the anomaly scoring thresholds. Monitoring the Penalty Box data feed allows us to identify which vulnerabilities are actively being scanned for by threat actors and to prioritize WAF logic updates.

For the latest security intelligence, visit Akamai's threat research blogs. To learn more about Akamai's web application and API security solution, visit App and API Protector.