This recipe will show you how to add fake cookies and to alert if the data is ever manipulated.
Ingredients
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:
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.
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:
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:
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.
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:
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.
