This blog post continues with the topic of setting "
HoneyTraps" within your web applications to catch attackers. Please review the previous posts for more examples:
Cookie Usage
The HTTP protocol has no built in session-awareness. This means that each transaction is independent from each other. The application, therefore, needs a method to track who a person is and what actions they have previously taken (for instance in a multi-step process). Cookies were created precisely for this purpose. The application issues Set-Cookie response header data to the client web browser. This cookie data instructs the browser to send back data to the web application on subsequent requests. For instance, upon an initial request to the Ebay main page you will receive the following response headers:
As you can see, there are six Set-Cookie response headers. When you make follow-up requests, these headers will now be included within the request headers:
Cookie Manipulation Attacks
Much in the same way that attackers take aim at parameter payloads, they also attempt to alter cookie data that is handed out by the application. Both parameter and cookie data is evaluated by the application upon each request. Cookie data may even be an even more attractive target for attackers as this information often controls authorization restrictions. If an attacker can alter cookie data, they may be able to become a completely new user, be presented with new user interface options or even gain higher privileges within the application. Due to this modus operandi of attackers, we want to set a honeytrap embedded within the normal application cookies in hopes that we will catch when attackers start to manipulate them.
Adding Fake Cookie Data with ModSecurity
Much in the same way that we added in fake hidden field honeytrap data in Recipe 3-4, we want to do the same with fake cookie data. There are two implementation considerations:
- When to issue the fake Set-Cookie data – we want our cookie honeytrap data to look innocuous so we only want to add it in when the application itself is legitimately issuing Set-Cookie response headers.
- What to name the fake Set-Cookie data – since we want our honeytrap data to blend in and look like it belongs, we should try to name our cookie something similar to existing cookie names.
The following ModSecurity/Apache directives addresses these two considerations:
These rules will capture the name of the last Set-Cookie header and then append the "-user_role" text to it. This is to try and trick the attacker into thinking that this cookie is controlling the user's role within the application. For the cookie payload, we put the enticing "Admin:0" data which would lead the attacker into thinking that by changing the 0 into a 1 might enable administrative privileges within the application. With these rules in place, the new response header data looks like this:
Notice the bolded Set-Cookie response header line holds our new honeytrap cookie data. Next, on subsequent requests, the client's browser will send back our fake cooke data along with all of the normal cookies:
Detecting Cookie Manipulations
We next need to add a rule that will catch if the client ever changes this cookie data.
This ruleset will check to see if the honeytrap cookie name is present and then will alert if the "Admin:0" value is ever altered. It will also set the malicious_client variable in the IP Collection to let us know that this client is up to no good.
Example Attack
In this example, the attacker has decided to change the honetrap cookie value from a 0 to a 1 in the hopes that this might change their level of access:
This request would then trigger the following ModSecurity event in the normal error log:
Conclusion
HoneyTraps are an extremely valuable defensive technique to use when defending your web applications. They offer a very high signal-to-noise ratio and allow defenders to quickly zero in on real attackers and take appropriate actions. Setting fake cookie data is a great way to identify malicious clients.
