-[ Web Application Traps -[ Application-Specific Intrusion Detection Technique -[ Meder Kydyraliev , http://o0o.nu/~meder -[ 08 Jan 2005 1. Introduction With today's trend in deploying web-based applications and conversion from thick to thin clients, more and more companies and organizations have increased their web presence. Hackers haven't missed this trend either. They realized that instead of breaking in through the traditional network services, which can be very noisy at times and not reliable, it is a lot easier, stealthier and more effective to "come in" through the custom web application. There are several reasons for this shift in focus of attacks, one of the most important one being the lack of intrusion detection technologies currently available to detect web application-specific suspicious activities. This is where web application traps (WATs) can fill the gap. By introducing WATs into the custom web applications, it is possible for an organization to, not only detect suspicious activities performed on web application, but also classify the skill level of the potential attacker, with ability to gauge seriousness of the attacker's intentions. 2. What is a Web Application Trap (WAT)? The idea behind WATs is simple: enable the application to detect and alert the appropriate support staff whenever someone is tampering with the application transactions. Besides this, application has to be able classify the skill level of the attacker and trigger the appropriate severity alert level. The proposed solution to enable the application to do these is to introduce several traps into web application design. These are decoy components and parameters which normally an attack will focus on. These traps will then be monitored by the application for any modifications (to the traps). The following components of HTTP request can serve as traps: - GET parameters - POST parameters as hidden fields - Cookies General concept is that each of the above mentioned components will contain a certain value that would be checked by the application upon seeing the HTTP request. If the expected value isn't there, this means that the HTTP request has been tampered with and the application will alert the appropriate user on the attack taking place and giving the approximate skill level of the attacker. Of course the name of the component (GET/POST parameter, cookie name) must attract attacker's attention (for example, PREPROCESSOR_PATH, CONFIGFILE, UID, etc) in order for WAT to be effective and the value should correspond to the name. The skill level of the attacker can be determined by the level of expertise required to modify a particular trap. For example, it doesn't require much knowledge to modify the GET parameter, while it may require special software and knowledge to modify the cookies. Additionally, the values of the traps could be encoded (for example, base64) or encrypted (for example, XORed with a key that is also passed in the request) to detect a more skillful attacker. The only limit is the imagination of the web application developer. NOTE: WATs are meant to be used solely for the intrusion detection purposes, that is, if the parameter contains path, you should never attempt to open/read/write to that PATH. WATs are not to be used in any other ways except for the intrusion detection purposes!!! 2.1 GET parameters Application could employ HTTP GET WATs to implement an early alert system, where organization would be warned on early stages of the web application attack. The reason for calling it an early alert system is that the WAT is visible to an attacker right away, in the address bar and would most likely attract her attention first. Example #1: PATH is a WAT, application would check to make sure that the value of the GET parameter PATH always equals articles/about.html: ABOUT Example #2: MAILCMD is a WAT. Could be included on a 'contact us' page, application has to make sure MAILCMD equals /usr/bin/mail, otherwise, someone is playing games with us: ... 2.2 Cookies Implementing another WAT as a cookie would be useful to detect a more skilled attacker, who knows what a cookie is and how to modify it, possibly using some proxy tools like WebScarab or BurpSuite to perform manipulations (some of the modern browsers also allow user to change cookie values). Some of the names that would be appropriate for cookies and yet would not ring a bell in the attacker's mind could be: USERID - value set to some random positive integer, attacker will attempt to change the value to '0' (root); ROLE - value set to 'user' for example, attacker will attempt to set it to 'admin'; HOMEDIR - value set to '~www', attacker will attempt to set value to various system paths; ISADMIN - value set to 'false', attacker will attempt to set the value to 'true'; Example #1: ISADMIN cookie is a WAT that could be sent back to the user after successful login. The following request shows sample response: HTTP/1.1 200 OK Content-Type: text/html Server: Apache Date: Sun, 08 Jan 2006 04:57:51 GMT Set-Cookie: ISADMIN=0; SESSID=0b7957d4c6b0502944a704eff1fc0bf9; path=/ Connection: Close ... 2.3 POST parameters as hidden fields Another possibility for the WAT lies in hidden POST form parameters, which could be effectively used to detect skilled attackers, as it would require the attacker to either manually review the HTML sources(attacker that knows HTML, fear!!!) or use special software, such as WebScarab, to reveal hidden fields. Example #1: SAVEPATH is a WAT, supposedly pointing to the path where data will be saved after submission:
...
Example #2: DBNAME, TBLNAME and FLDNAME are WATs, supposedly pointing to the database name, table name and field name where to perform search:
...
Example #3: SRCHCMD (search command) is a slightly more advanced WAT, supposedly pointing to the command to be used to perform search. Look at the value, it is Base64 encoded, which, once decoded, is '/bin/grep':
...
2.4 Choosing names for WATs Developers who decide to implement such an IDS should take into consideration application specific component names, which would make the WATs look even more realistic. For banking applications, some of the WAT names that would attract attention can be, BANK_ACC_NO (bank account number), CURRENT_ACC_BAL (current account balance), etc. You can bet that these will be the first ones to be "poked" at if anyone is after your application. 3. Detecting skill level First of all if you implement WATs using the above mentioned components, there will already be specific skill requirements to tamper with the values, that is, it would require more knowledge to modify cookie value than to modify the GET parameter. But there are more ways to check the skills of the attacker, one being some sort of obfuscator/encoder/encryptor of the values. The idea is to have the WAT with name that would interest the attacker and have the value obfuscated/encoded/encrypted, so in order to see the value or properly modify the attacker would have to spend some time or do it right away (depending on the skillset). The application, however, must perform additional check to evaluate the skillset. It must see whether or not the new value was properly obfuscated/encoded/encrypted or was it just some random junk. Obviously, properly supplied value would raise the skill level of an attacker. There's also an opportunity in using javascript to assess the level of an attacker, putting in the values as hidden form parameter and performing checks at client side on the value using javascript, on the application side. It would require a check on the parameter value and if the value is different it would mean that attacker either used special proxying software to modify the request, after it was send by browser, or response from the server containing the javascript check, which of course tells about relatively high level skills of the attacker. 4. Reacting So what steps should be taken after you know that the attacker is skilled and serious about testing/breaking your application? There are several options available and they would be highly dependent on the architecture of the application and your intentions. In general, there are two options: - spit out an error or block the attackers IP as soon as WAT raised an alert. This option does not bring that much value except for temporarily safeguarding your application from an attacker, who will be more cautious next time. - redirect the attacker to a development/testing/honeypot version of your application or database and that's where you could get a free "security assessment" of your application. Once WAT raised an alert, application could tag either the session or all requests from attackers IP as suspicious and would redirect the requests to either a development/testing/honeypot version of the exactly the same application or, if architecture allows, to a development/ testing/honeypot back-end (database server, soap server, etc), to make sure integrity of the production data is not compromised in any way. The activities would have to be closely monitored to see if attacker identified any vulnerabilities, if so, the bugs are fixed in the production environment and everyone is happy, you because you just made your application more secure, attacker, because she thinks she broke the application. Once again, the reaction to the alerts raised by WATs would purely depend on what you are trying to achieve and are only limited by your creativity. 5. Limitations Obviously it would be impossible to implement WATs in an open-source project as WATs would be uncovered right away, however, implementing WATs in custom applications could be a very effective intrusion detection system with nearly 0 false positives. 6. Feedback I would love to hear about real world implementation of the web application traps and how they performed. Please feel free to contact me and send in your suggestions/corrections/ideas to meder@o0o.nu 7. Acknowledgements Thanks to Rogan Dawes, Kan Shik Kiong, Fyodor Yarochkin and Oleg Puzanov for reviewing and giving valuable feedback.