This week's installment of Detecting Malice with ModSecurity will discuss how to implement HoneyTraps in order to detect malicious activity on your website. HoneyTrap excerpt section of Robert "Rsnake" Hansen's book "Detecting Malice" -
Booby Trapping Your Application
I briefly mentioned honeytokens in a previous chapter, but there are lots of other tools available to the paranoid, you just haven't built them yet. Bad guys follow a certain set path of tricks, and if you can anticipate those, there's a good chance you can catch one in the act. Creating fake cookies that look particularly tempting like "admin=false" is a great way to detect that someone is tampering with cookies and trying to gain higher privileges. Think of this as the application equivalent of a honeypot – you don't want to make yourself hack-able, and you may not care about robots, but you probably care a lot about bad guys manually hacking your website. This too may alert a bad guy to the fact you are monitoring them, so use techniques like this sparingly.
Other ideas that are less likely to let an attacker know they are being tracked might revolve around creating admin directories on your server that have login pages that cannot log the person in, but instead simply monitor what the user is doing. These kinds of tricks can cost you development time, but the nice thing is it can often help locate people who are simply out to hack you. While this is sort of the virtual equivalent of entrapment in some ways, users should never inadvertently tamper with cookies, or try to hack an admin login page, so creating a function that is specifically designed to never be touched or tampered with by any normal user will reduce the operational overhead of looking at the traffic to those functions. You'll find yourself looking at the worst of the worst. The goal here is not to take direct action but to begin monitoring everything that user does – these are the bad guys and you want to keep your eye on them.
Use these ideas, and create your own. The more false paths you create for your determined bad guys, the more likely it is that you can identify them and identify if they have caused any other types of harm on your site. Who knows, you may even be able to mitigate the risk of an attack that might end up working eventually, like brute force, if you proactively identify a malicious user before it is too late.
We recently added new AppSensor HoneyTrap Detection Points. Example:
| id |
HT1 |
| title |
Alteration to Honey Trap Data |
| category |
HoneyTrap |
| description |
Fake (not otherwise needed by the application) data sent to the user and returned (e.g. as form, URL, cookie values or in the path or HTTP header) is modified. This is usually combined with making the name or value a tempting item for an attacker to try modifying. |
| consideration |
Similar techniques can also be used for the creation of accessible CAPTCHA. See also ideas at http://blogs.sans.org/appsecstreetfighter/2009/06/04/my-top-6-honeytokens/ |
| examples |
Example 1: Otherwise useless hidden fields, which look like potential vulnerabilities, added to some forms are sent back to the server modified (e.g. <input type="hidden" name="admin" value="false" />). Example 2: An additional URL parameter, which is not used by the application, is modified by the user (e.g. www.example.com/account.jsp?debug=0). Example 3: An additional fake cookie is added and is modified by the user. Example 4: URL rewriting is used and a fake directory name is added; this is modified by the user (e.g. www.example.com/orders/normaluser/display.php). |
| code |
We recently added an example HoneyTrap rules file to the CRS which implements a fake debug HIDDEN form field parameter.
## -=[ HT1: Alteration to Honey Trap Data ]=-## - https://www.owasp.org/index.php/AppSensor_DetectionPoints#HT1:_Alteration_to_Honey_Trap_Data #SecRule ARGS:DEBUG "!@streq false" "phase:2,id:'981131',t:none,block,msg:'Tampering of Hidden Parameter Honeytrap Data.',logdata:'%{matched_var}',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.error_anomaly_score},setvar:tx.profiler_score=+%{tx.error_anomaly_score},tag:'HONEYTRAP/HIDDEN_DATA_TAMPERING',tag:'OWASP_AppSensor/HT1',tag:'https://www.owasp.org/index.php/AppSensor_DetectionPoints#HT1:_Alteration_to_Honey_Trap_Data'"## Add a fake "debug" hidden parameter to forms.## Here are some examples of parameter names/values that could be used:## - debug=false# - debug=0# - role=user# - role=1# - admin=false # - admin=0## Make sure that your settings here match the detection rules above.#SecRule STREAM_OUTPUT_BODY "@rsub s/<\/form>/<input type=\"hidden\" name=\"debug\" value=\"false\"><\/form>/" "phase:4,id:'981132',t:none,nolog,pass"
This example ruleset uses the ModSecurity @rsub data modification operator to inject our new HIDDEN form field data right before the closing HTML </form> tag. The result of this ruleset is that the page form will now include a new parameter "debug=false" when sending data to the app. The SecRule at the beginning of the file then validates that the debug parameter value is always set to "false". If not, then this means that a client has manipulated this HIDDEN parameter value and is most likely attempting some type of bypass attempt.
This is just one example of implementing the HoneyTrap concept within ModSecurity. We have plans to implement many more in the near future. If you have any ideas, please let us know. If you are attending DefCon in Las Vegas this week-end, and you like the HoneyTrap concept, then I suggest you attend "Traps of Gold" which is being presented by a SpiderLabs colleague Andrew Wilson.