This recipe will show you how to add fake HTML comment data that may be flagged if ever accessed or used by a client.
Ingredients
The Hypertext Markup Language provides a syntax which allows developers to embed comment information within the html code. The HTML RFC states the following:
3.2.4 Comments
HTML comments have the following syntax:
<!-- this is a comment -->
<!-- and so is this one,
which occupies more than one line -->
White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments.
Information that appears between comments has no special meaning (e.g., character references are not interpreted as such).
Note that comments are markup.
While the intended purpose of this functionality is to be helpful, it often divulges sensitive data. Let's look at a practical example.
During the reconnaissance phase, an attacker will most likely run an automated spidering tool against the site. They can then review various elements of the site off-line and look for pieces of sensitive information. For example, Figure 3-1 shows the Burp Suite Pro application assessment tool.
Figure 3-2: Burp Suite's Engagement Tool Find Comments
This screenshot demonstrates how to use the find comments action of the engagement tools interface. This will search through any saved HTTP transactional data. Figure 3-2 shows some example output with various html comment data.
Figure 3-3: Burp Suite's Find Comments Search Results
While the html comments show here are rather innocuous, there are other examples that are not. Figure 3-3 shows an example where the web developer has decided to place stack trace debugging information within the html comments.
Figure 3-4: Stack Trace Data Inside HTML Comment
This information should never be sent to a client as it exposes the inter-workings of the application. With this data, an attacker may be able to better plan and execute attacks against your web application.
Building upon the configuration in the Adding Fake robots.txt Entries configuration, we can add another ModSecurity directive called SecStreamOutBodyInspection:
SecContentInjection OnSecStreamOutBodyInspection On
This directive will place the normal RESPONSE_BODY variable data (HTML) into a re-allocatable buffer which allows us to modify and re-inject this buffer back into the response body stream. In layman's terms, this directive allows us to be able to modify outbound response data.
Now that we have the capability to dynamically insert our own data, we need to choose a good location to deploy our honeytrap HTML comment. An ideal candidate is to seed any login pages with this fake data as attackers are sure to focus their attention in this location. Figure 3-4 shows the html for an example login page.
Figure 3-5: Example DVWA Login Page HTML
Note the highlighted FORM tag data in the html source code? That is going to be our key data element to use as our injection point. We can then use the following ruleset to insert out honeytrap html comment data directly in front of the open FORM tag:
SecRule REQUEST_FILENAME "@streq /dvwa/login.php" "chain,id:'999007',phase:4,t:none,nolog,pass,setvar:'tx.form_comment_honeytrap=<form action=\"login.php\" method=\"post\">'" SecRule STREAM_OUTPUT_BODY "@rsub s/%{tx.form_comment_honeytrap}/<!-- DEBUG - the source code for the old login page is login.php.bak -->%{tx.form_comment_honeytrap}/d"
The key piece of data to focus on is in the second SecRule where the @rsub operator is using macro expansion to do our data substitution and prepending our honeytrap comment information. With this rule in place, Figure 3-5 shows how the new html data looks.
Figure 3-6: Fake HTML Comment Data
Now that we have set our trap, we must create a separate ModSecurity rule that will identify if a client ever attempts to access the fake login.php.bak page.
SecRule REQUEST_FILENAME "@streq /login.php.bak" \ "id:'999008',phase:1,t:none,log,block,msg:'HoneyTrap Alert: Fake HTML Comment Data Used.',setvar:ip.malicious_client=1"
If this alert ever triggers, you know that the client is reviewing HTML source code and inspecting comment data. You can then choose how to react to client based in this intel. In the example rule, we are setting a new local variable "malicious_client" to the IP-based persistent storage collection. This flag will allow you react as you want whenever the client returns to the site. Perhaps you want to simply create audit logs of this user's activities or optionally proxy their connections off to some other honeypot web application. The response actions are varied however the key is that you were able to use this honeytrap to identify the suspicious disposition of this user.
Hopefully this blog post has give you ideas on how you might implement similar types of fake HTML comments to entice and track would-be attackers on your site. Make sure to use variation in the types of data that you use in your honeytraps so that it will not be easy to identify. Examples can include: