Pavel
The Canary In The Coal Mine:
Implementing Web Based Canaries and other HoneyTokens
Read the paper !HERE!
The growing number and significance of web applications have led to the growth in attacks against networks, which imposes great vulnerability to information security. Therefore, more aggressive forms of defense techniques to supplement the existing security approaches have been brought to the table. One of these techniques, the Honey Token, involves the use of deception to collect information about attacks. A Honey Token is a security deception technique that leaves data intentionally to be probed, attacked, or compromised by attackers to collect information from the source of attackers.
Thanks to the simplicity, accuracy, and strength of Honey Tokens, they are especially useful for smaller organizations that do not have many resources to delegate to web security.
1 Zones
Honey Tokens can be implemented on many parts of the system. Each "Zone" represents a different part of the full Website. Placing Honey Tokens in the following Zones allows us to get a better understanding of how adversaries attempt to break into our system.
1.1.1 Zone 1, The Web Server.
Honey Tokens on the Web Server involve strategically placing sensitive information on the File System, letting us know where attackers are attempting to gain unauthorized access from. Some examples include
• text documents with access tokens
• Robots.txt
1.1.2 Zone 2, The Web Application.
Canary based Honey Tokens (Section 3.2) are a perfect example of a Web Application defense.
1.1.3 Zone 3, The Database Server.
Placing Honey Tokens in the Database Server allows us to defend and identify weaknesses in the database that adversaries will attempt to exploit.
2.1 Logging
The entire purpose of these Honey Tokens is so we can log these incidents. Whenever one of our Honey Tokens gets triggered, we record all of the following information into a database table as seen in figure 3
• Incident ID
• Page the incident occurred on, and updated value if applicable
• IP Address
• TimeStamp GMT
• Operating System
• Platform
• Scraper (boolean)
• Tablet (boolean)
• Mobile (boolean)
• Browser
Figure 1: Example of log Database Table
Figure 2: Visual example of the canary being changed2.2 Canary-based Parameters
One of our first Honey Token implementations was canary-based. These are parameters that should not ever be changed by the client, so when the values are updated, there is a high likelihood that someone with malicious intent is in our system. If the correct conditions are met we will log the incident. We use enticing names such as debug and admin to lure in hackers. If the parameters were something along the lines of ?lang=en, there wouldn’t be much of a reason for adversaries to play around with them. The canary in figure 2 is admin=false. This is a Zone 2 Honey Token. This parameter based canary is used in coordination with other Honey Tokens we set up in our system (2.4 and 2.6)
2.3 Robots.txt
The Robots.txt file (Zone 1 Honey Token) at the root of websites, is commonly used for indexing websites using web spiders. Often, attackers will try to use the Robots.txt file to their advantage to find places that they should not have access to.
• Disallow: /private
• Disallow: /debug
Our Robots.txt entry has two traps in it. There is no legitimate way to access /private and /debug.
2.3.1 private.
When an adversary would go to /private will log the incident, and redirect them to the CAS login screen, to make them believe that nothing happened.
2.3.2 debug.
The /debug route will redirect you to an access string. See 2.4
Figure 3: "Debug Mode enabled with Access token"2.4 Storing on the file system
Earlier in 2.2 we discussed the different parameters that we implemented, ?debug= is one of them. When an adversary enters the access token (discussed in 2.3) into this parameter, they will be in "debug mode" as seen in figure 3. This of course is not actually a debug mode, simply a red herring. (Zone 1)
2.5 SQL Injection
One common approach for adversaries to gain access to systems is by attempting an SQL Injection on vulnerable parts of websites. This Honey Token (Zone 3) was more of a proof of concept, as we only are checking for some of the more common Injection techniques. Such as setting the password field to "’ OR 1=1". If we detect someone attempting an SQL Injection to gain unauthorized access, we log the incident. In future implementations we would have liked to flesh out this Honey Token more, as SQL Injections are a staple.
2.6 Bogus Login Information
The last Honey Token (Zone 3) that we implemented in our system is storing dummy admin login information in the /adminmode route. The adversary could get to this route by setting the (Section 2.2) ?admin= parameter to true. This will display an "Admin Mode" button on the Web Page that would redirect the user to an administrative panel. On that panel is a downloadable CSV file that contains the login information for an admin account. When an adversary downloads this CSV file, the incident would be reported. When an adversary would attempt to log in using the information on the CSV file, this would also be reported.
Our Honey Tokens are an effective approach to catching and deceiving potential attacks due to the specific criteria it is targeting during the attacking process. The main objective for this project was the implementation and deployment, which we did successfully accomplish. Special thanks to the UC Davis Information Security Office for suggesting a testbed, and spinning up a server for us!