04-19-2011 01:01 PM
Hello,
Basically, I need to know how to interpret the incident events in the event log so I can determine what parts are being flagged as illegal characters, TFTP system commands, etc., because none of the web application's functions are actually trying to do things like perform a TFTP system command. They look like false positives.
More detail - I am seeing several unsual incidents in my WAF logs (sanitized below), to include things such as:
SysCommandInj_s.tftp via rule CommandInject.sParamAll
RestrictedChars.x1A via rule RestrictedChars.charsParamAll
FileName.illegalChars via rule FileSystem.fileSubmit
which are appearing within several different POST functions of our custom web application.
1. I need a reference that will help me determine how the WAF is interpreting the data as a TFTP attempt, when it is nothing more than a _VIEWSTATE POST parameter, and nowhere within the value is there anything related to the regex pattern tftp(?:\s|$), which is what the WAF is indicating that it has found. For instance, the WAF interprets the following (extracted from the reactor logs) as a TFTP attempt:
Apr 18 20:36:57 ACE WAF reactor[30169]: 1303159017579 [reactor /waf/incident FD0A3201000075D96A54900238D0398E W] Matched signature SysCommandInj_s.tftp via rule CommandInject.sParamAll in request from ##.##.##.## for application 'id:831c9c242fbda48b'. Match was in REQUEST_POSTPARAM['__VIEWSTATE'], which had value eqy+5/D2PxManK86+k1DISTWb96w6oeXLb/ln+q9shij47H7SZVyO2Cgda3hS6vFMyN7tmXmwBr4RRKWBtDBf4lKI22NxLjOf8by. Request path was: /XXXX/XX/Users.aspx. inc:{{{831c9c242fbda48b,CommandInject.sParamAll:SysCommandInj_s.tftp:REQUEST%5FPOSTPARAM%5B%27%5F%5FVIEWSTATE%27%5D,/XXXX/XX/Users.aspx}}}
2. How it is interpreting the data as restricted characters (when it is not using \x1A, but \%1A, nor is it using \x0E, but \%0E), and how the illegal characters in a filename are being discovered when POST'ing a .png image file. For example:
Apr 18 19:55:06 ACE WAF reactor[30198]: 1303156506480 [reactor /waf/incident FD0A3201000075F66A2E3F5E43EA1C0C W] Matched signature RestrictedChars.x1A via rule RestrictedChars.charsParamAll in request from ##.##.##.## for application 'id:831c9c242fbda48b'. Match was in REQUEST_POSTPARAM['ctl00$MainContent$FrmPhotoUploa, which had value ‰PNG . Request path was: /XXXX/XXXXXXXX/PhotoUpload.aspx. inc:{{{831c9c242fbda48b,RestrictedChars.charsParamAll:RestrictedChars.x1A:REQUEST%5FPOSTPARAM%5B%27ctl00%24MainContent%24FrmPhotoUpload%24frmFileUploadPhoto%27%5D,/XXXX/XXXXXXXX/PhotoUpload.aspx}}}
(the filename was actually something simple like "george.png".)
3. How it is interpreting the data as illegal characters (when it is nothing more than a filename for an image being uploaded):
Apr 18 19:49:51 ACE WAF reactor[30193]: 1303156191789 [reactor /waf/incident FD0A3201000075F16A29706C5F1ADF3D W] Matched signature FileName.illegalChars via rule FileSystem.fileSubmit in request from ##.##.##.## for application 'id:831c9c242fbda48b'. Match was in REQUEST_MULTIPART_DISPOSITION_FILENAMES, which had value C:\Documents and Settings\<USER>\Desktop\filename.JPG. Request path was: /XXXX/XXXXXXXXXXX/PhotoUpload.aspx.
(This one seems like it could be because of the \'s in the filename's local location.)
Please advise on how to interpret the part that says "Match was in..." when there is nothing in there that matches the signature for an attack.
Thanks,
George
04-21-2011 10:34 AM
After reviewing and comparing the log entries from the GUI and the log entries directly within the /var/log/reactivity/user log file, I discovered that the log file in the "user" file is easier to interpret.
For example, the below is from the GUI:
Matched signature SysCommandInj_b.id via rule CommandInject.bParamAll in request from ##.##.##.## for application 'XXXXX SSL'. Match was in REQUEST_GETPARAM['strURL'], which had value http://XXX.XXXXX.XXXXXXXXXX.edu/KView/CustomCodeBehind/Customization/RouterPage.aspx?Type=Link&ID=52. Request path was: /XXXX/login.aspx.
Notice that the "which had value" part does not include anything from the regular expression for the "id" signature, whereas the "Match was in" part does.
And the below was from the "user" log file:
CommandInject.bParamAll:SysCommandInj_b.id:REQUEST%5FPOSTPARAM%5B%27%5F%5strURL%27%5D,/XXXX/Login.aspx
Notice that within the "user" log entry, the id value includes the %27%5D, which is interpreted as `] by the firewall.
The SysCommandInj_b.id regular expression is as follows:
[;|&`] id SysCommandInj_b.id | Quick Pattern id Regex Pattern [;|&`]\W*?\bid |
So, although the expression seems to require [;| AND '] , the firewall is flagging just the '] , so it is not using a logical AND to see the signature. This appears to be a problem with the firewall's capability of requiring multiple parts within a data string being pushed through it to be identified and caught within a regular expression. If that is indeed the case, then this may be a case for a bug report. Can anyone else say the same is happening for them?
Regardless of all of that, my suggestion would be to use the command line to review the audit logs when something interesting comes up, instead of relying on the GUI to show enough detail for you to be able to figure out exactly what is happening.
R/S,
George Sypsomos
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide