From mike at gotroot.com Sun Sep 2 22:13:27 2007 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] iframe filtering rules Message-ID: <1188785607.1661.2.camel@localhost.localdomain> I put together a method for filtering out bad iframes from websites. Output filtering, for websites that become infected. You can read on for the details here: http://www.gotroot.com/tiki-read_article.php?articleId=278 Rules update is in testing now, will be putting out a major overhaul this week. The major performance improvements will require modsec 2.5. -- Michael Shinn From hexstar at gmail.com Mon Sep 3 19:13:55 2007 From: hexstar at gmail.com (Hex Star) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Gotroot mod_security rules not working with Apache 1.3.37 Message-ID: <5dc6fd9e0709031613m72a6d242p1a25ee27e7d21f79@mail.gmail.com> Hello, I downloaded the full Apache 1 ruleset from gotroot.com and set it up, Apache starts and everything but when trying to access any page at all on the server a 500 Internal Error is displayed and the following is found in the error_log: [Mon Sep 3 16:00:43 2007] [error] [client 127.0.0.1] mod_security: Access denied with code 500. Pattern match "((select|grant|delete|insert|drop|alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\\\\*| |\\\\,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[A-Z|a-z|0-9|\\\\*| |\\\\,]|\\\\'|UNION.*SELECT.*FROM)" at ARG("art_id") [severity "EMERGENCY"] [hostname "127.0.0.1"] [uri "/"] Why is this happening and how can I fix this? Thanks! :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20070903/7590381b/attachment.html From mike at gotroot.com Mon Sep 3 23:33:16 2007 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Gotroot mod_security rules not working with Apache 1.3.37 In-Reply-To: <5dc6fd9e0709031613m72a6d242p1a25ee27e7d21f79@mail.gmail.com> References: <5dc6fd9e0709031613m72a6d242p1a25ee27e7d21f79@mail.gmail.com> Message-ID: <1188876796.4794.0.camel@localhost.localdomain> Thank you for the report. Can you send me your audit_log entry for this? Without that information, I can't debug your problem. On Mon, 2007-09-03 at 16:13 -0700, Hex Star wrote: > Hello, I downloaded the full Apache 1 ruleset from gotroot.com and set > it up, Apache starts and everything but when trying to access any page > at all on the server a 500 Internal Error is displayed and the > following is found in the error_log: > > [Mon Sep 3 16:00:43 2007] [error] [client 127.0.0.1] mod_security: > Access denied with code 500. Pattern match "((select|grant|delete| > insert|drop|alter|replace|truncate|update|create|rename| > describe)[[:space:]]+[A-Z|a-z|0-9|\\\\*| |\\\\,]+[[:space:]]+(from| > into|table|database|index|view)[[:space:]]+[A-Z|a-z|0-9|\\\\*| |\\\ > \,]|\\\\'|UNION.*SELECT.*FROM)" at ARG("art_id") [severity > "EMERGENCY"] [hostname " 127.0.0.1"] [uri "/"] > > Why is this happening and how can I fix this? Thanks! :) > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity From hexstar at gmail.com Tue Sep 4 00:05:29 2007 From: hexstar at gmail.com (Hex Star) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Gotroot mod_security rules not working with Apache 1.3.37 In-Reply-To: <1188876796.4794.0.camel@localhost.localdomain> References: <5dc6fd9e0709031613m72a6d242p1a25ee27e7d21f79@mail.gmail.com> <1188876796.4794.0.camel@localhost.localdomain> Message-ID: <5dc6fd9e0709032105m55776fedw62d5c487adf53fb6@mail.gmail.com> On 9/3/07, Michael Shinn wrote: > > Thank you for the report. Can you send me your audit_log entry for > this? Without that information, I can't debug your problem. > > > Sure, here is its contents: ==b620372a============================== Request: 127.0.0.1 127.0.0.1 - - [03/Sep/2007:21:02:32 -0700] "GET / HTTP/1.1" 500 609 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)" - "-" ---------------------------------------- GET / HTTP/1.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding: gzip,deflate Accept-Language: en-us,en;q=0.5 Connection: keep-alive Host: localhost Keep-Alive: 300 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty) mod_security-action: 500 mod_security-message: Access denied with code 500. Pattern match "((select|grant|delete|insert|drop|alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\\*| |\\,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[A-Z|a-z|0-9|\\*| |\\,]|\\'|UNION.*SELECT.*FROM)" at ARG("art_id") [severity "EMERGENCY"] HTTP/1.1 500 Internal Server Error Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 --b620372a-- ==ed56221b============================== Request: 127.0.0.1 127.0.0.1 - - [03/Sep/2007:21:03:09 -0700] "GET / HTTP/1.1" 500 609 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)" - "-" ---------------------------------------- GET / HTTP/1.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding: gzip,deflate Accept-Language: en-us,en;q=0.5 Cache-Control: max-age=0 Connection: keep-alive Host: localhost Keep-Alive: 300 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty) mod_security-action: 500 mod_security-message: Access denied with code 500. Pattern match "((select|grant|delete|insert|drop|alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\\*| |\\,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[A-Z|a-z|0-9|\\*| |\\,]|\\'|UNION.*SELECT.*FROM)" at ARG("art_id") [severity "EMERGENCY"] HTTP/1.1 500 Internal Server Error Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 --ed56221b-- ==0767020c============================== Request: 127.0.0.1 127.0.0.1 - - [03/Sep/2007:21:03:10 -0700] "GET / HTTP/1.1" 500 609 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)" - "-" ---------------------------------------- GET / HTTP/1.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding: gzip,deflate Accept-Language: en-us,en;q=0.5 Cache-Control: max-age=0 Connection: keep-alive Host: localhost Keep-Alive: 300 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty) mod_security-action: 500 mod_security-message: Access denied with code 500. Pattern match "((select|grant|delete|insert|drop|alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\\*| |\\,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[A-Z|a-z|0-9|\\*| |\\,]|\\'|UNION.*SELECT.*FROM)" at ARG("art_id") [severity "EMERGENCY"] HTTP/1.1 500 Internal Server Error Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 --0767020c-- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20070903/369a6521/attachment.html From mike at gotroot.com Tue Sep 4 10:39:02 2007 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Gotroot mod_security rules not working with Apache 1.3.37 In-Reply-To: <5dc6fd9e0709032105m55776fedw62d5c487adf53fb6@mail.gmail.com> References: <5dc6fd9e0709031613m72a6d242p1a25ee27e7d21f79@mail.gmail.com> <1188876796.4794.0.camel@localhost.localdomain> <5dc6fd9e0709032105m55776fedw62d5c487adf53fb6@mail.gmail.com> Message-ID: <1188916742.9046.6.camel@localhost.localdomain> Thank you for the additional information. So is this happening for any and every query? This appears to be triggering for a localhost query, which is pretty strange itself. Do you have some kind of unique proxy query going on? On Mon, 2007-09-03 at 21:05 -0700, Hex Star wrote: > > > On 9/3/07, Michael Shinn wrote: > Thank you for the report. Can you send me your audit_log > entry for > this? Without that information, I can't debug your problem. > > > > Sure, here is its contents: > > ==b620372a============================== > Request: 127.0.0.1 127.0.0.1 - - [03/Sep/2007:21:02:32 -0700] "GET / > HTTP/1.1" 500 609 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv: > 1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)" - "-" > ---------------------------------------- > GET / HTTP/1.1 > Accept: text/xml,application/xml,application/xhtml+xml,text/html;q= > 0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Accept-Encoding: gzip,deflate > Accept-Language: en-us,en;q=0.5 > Connection: keep-alive > Host: localhost > Keep-Alive: 300 > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) > Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty) > mod_security-action: 500 > mod_security-message: Access denied with code 500. Pattern match > "((select|grant|delete|insert|drop|alter|replace|truncate|update| > create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\\*| |\ > \,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[A-Z| > a-z|0-9|\\*| |\\,]|\\'|UNION.*SELECT.*FROM)" at ARG("art_id") > [severity "EMERGENCY"] > > HTTP/1.1 500 Internal Server Error > Connection: close > Transfer-Encoding: chunked > Content-Type: text/html; charset=iso-8859-1 > --b620372a-- > > ==ed56221b============================== > Request: 127.0.0.1 127.0.0.1 - - [03/Sep/2007:21:03:09 -0700] "GET / > HTTP/1.1" 500 609 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.8.1.6 ) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)" - "-" > ---------------------------------------- > GET / HTTP/1.1 > Accept: text/xml,application/xml,application/xhtml > +xml,text/html;q=0.9,text/plain;q=0.8 ,image/png,*/*;q=0.5 > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Accept-Encoding: gzip,deflate > Accept-Language: en-us,en;q=0.5 > Cache-Control: max-age=0 > Connection: keep-alive > Host: localhost > Keep-Alive: 300 > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) > Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty) > mod_security-action: 500 > mod_security-message: Access denied with code 500. Pattern match > "((select|grant|delete|insert|drop|alter|replace|truncate|update| > create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\\*| |\ > \,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[A-Z| > a-z|0-9|\\*| |\\,]|\\'|UNION.*SELECT.*FROM)" at ARG("art_id") > [severity "EMERGENCY"] > > HTTP/1.1 500 Internal Server Error > Connection: close > Transfer-Encoding: chunked > Content-Type: text/html; charset=iso-8859-1 > --ed56221b-- > > ==0767020c============================== > Request: 127.0.0.1 127.0.0.1 - - [03/Sep/2007:21:03:10 -0700] "GET / > HTTP/1.1" 500 609 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.8.1.6 ) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)" - "-" > ---------------------------------------- > GET / HTTP/1.1 > Accept: text/xml,application/xml,application/xhtml > +xml,text/html;q=0.9,text/plain;q=0.8 ,image/png,*/*;q=0.5 > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Accept-Encoding: gzip,deflate > Accept-Language: en-us,en;q=0.5 > Cache-Control: max-age=0 > Connection: keep-alive > Host: localhost > Keep-Alive: 300 > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) > Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty) > mod_security-action: 500 > mod_security-message: Access denied with code 500. Pattern match > "((select|grant|delete|insert|drop|alter|replace|truncate|update| > create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\\*| |\ > \,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[A-Z| > a-z|0-9|\\*| |\\,]|\\'|UNION.*SELECT.*FROM)" at ARG("art_id") > [severity "EMERGENCY"] > > HTTP/1.1 500 Internal Server Error > Connection: close > Transfer-Encoding: chunked > Content-Type: text/html; charset=iso-8859-1 > --0767020c-- > > From hexstar at gmail.com Tue Sep 4 10:43:09 2007 From: hexstar at gmail.com (Hex Star) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Gotroot mod_security rules not working with Apache 1.3.37 In-Reply-To: <1188916742.9046.6.camel@localhost.localdomain> References: <5dc6fd9e0709031613m72a6d242p1a25ee27e7d21f79@mail.gmail.com> <1188876796.4794.0.camel@localhost.localdomain> <5dc6fd9e0709032105m55776fedw62d5c487adf53fb6@mail.gmail.com> <1188916742.9046.6.camel@localhost.localdomain> Message-ID: <5dc6fd9e0709040743s25ad6477v6330e5b3082e37fb@mail.gmail.com> On 9/4/07, Michael Shinn wrote: > > Thank you for the additional information. > > So is this happening for any and every query? This appears to be > triggering for a localhost query, which is pretty strange itself. Do > you have some kind of unique proxy query going on? > > Yes this is weird, I am not aware of any proxy being used. I simply compiled from source apache with php and mod_security, installed these rules and this is where I'm at. It's on Kubuntu 7.04 and is a internal testing machine so this isn't mission critical. Just curious why this is happening? Apache is 1.3.37... Thanks! :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20070904/4f160d53/attachment.html From mike at gotroot.com Tue Sep 4 15:33:40 2007 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Gotroot mod_security rules not working with Apache 1.3.37 In-Reply-To: <5dc6fd9e0709040743s25ad6477v6330e5b3082e37fb@mail.gmail.com> References: <5dc6fd9e0709031613m72a6d242p1a25ee27e7d21f79@mail.gmail.com> <1188876796.4794.0.camel@localhost.localdomain> <5dc6fd9e0709032105m55776fedw62d5c487adf53fb6@mail.gmail.com> <1188916742.9046.6.camel@localhost.localdomain> <5dc6fd9e0709040743s25ad6477v6330e5b3082e37fb@mail.gmail.com> Message-ID: <1188934420.4309.54.camel@localhost.localdomain> Offhand, not sure... the IP is weird, the box is connecting from itself to itself. Are you running your tests on the box to itself? If so, that explains it. In the meantime, try commenting the SQL injection rule out to see if that stops the false positive. Also, what application(s) are you running on the box? On Tue, 2007-09-04 at 07:43 -0700, Hex Star wrote: > > > On 9/4/07, Michael Shinn wrote: > Thank you for the additional information. > > So is this happening for any and every query? This appears to > be > triggering for a localhost query, which is pretty strange > itself. Do > you have some kind of unique proxy query going on? > > > Yes this is weird, I am not aware of any proxy being used. I simply > compiled from source apache with php and mod_security, installed these > rules and this is where I'm at. It's on Kubuntu 7.04 and is a internal > testing machine so this isn't mission critical. Just curious why this > is happening? > > Apache is 1.3.37... > > Thanks! :) From hexstar at gmail.com Tue Sep 4 19:15:22 2007 From: hexstar at gmail.com (Hex Star) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Gotroot mod_security rules not working with Apache 1.3.37 In-Reply-To: <1188934420.4309.54.camel@localhost.localdomain> References: <5dc6fd9e0709031613m72a6d242p1a25ee27e7d21f79@mail.gmail.com> <1188876796.4794.0.camel@localhost.localdomain> <5dc6fd9e0709032105m55776fedw62d5c487adf53fb6@mail.gmail.com> <1188916742.9046.6.camel@localhost.localdomain> <5dc6fd9e0709040743s25ad6477v6330e5b3082e37fb@mail.gmail.com> <1188934420.4309.54.camel@localhost.localdomain> Message-ID: <5dc6fd9e0709041615t1231cf66y495d80d775144aae@mail.gmail.com> On 9/4/07, Michael Shinn wrote: > > > Offhand, not sure... the IP is weird, the box is connecting from itself > to itself. Are you running your tests on the box to itself? > > If so, that explains it. In the meantime, try commenting the SQL > injection rule out to see if that stops the false positive. Also, what > application(s) are you running on the box? > > > Yeah, I have apache running on the test machine and I'm accessing the apache server via localhost in a web browser running on the test machine which is running apache. I'm not accessing apache via another machine. Are the gotroot rules set to deny accessing apache via localhost? I would try commenting out the SQL injection rule but I don't know where it is, do you know by chance? I find it weird that it's catching an attempt to browse / via localhost as a SQL injection attack though.... While I do have other servers such as pureftpd installed on the server they do not start up on boot and I have not invoked them at the same time as apache. The only other applications running besides apache 1.3.37 with php 4 and mod_security is kde, firefox, and whatever system binaries are required to be loaded on boot by the system. If you'd like a more precise answer I am more than willing to paste the output of ps -A for you. Thanks! :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20070904/1146e1de/attachment.html From stevewest15 at gmail.com Fri Sep 7 21:36:39 2007 From: stevewest15 at gmail.com (Steve West) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] iframe filtering rules In-Reply-To: <1188785607.1661.2.camel@localhost.localdomain> References: <1188785607.1661.2.camel@localhost.localdomain> Message-ID: <46E1FCA7.3040807@gmail.com> Hi Michael, Thank you for the great tool! We've had a few customers web sites have their web pages altered by hackers to add iframe tags, etc. The customers gave out their ftp credentials to the wrong ppl so we can't always protect against that. But I do have a few questions: 1. Is there any tool we can use if we are running apache 1.3.x? 2. You should also add some filtering for obfuscated javascript which I'm seeing some recent hacks employ to get around security countermeasures on the server side. thx, SW Michael Shinn wrote: > I put together a method for filtering out bad iframes from websites. > Output filtering, for websites that become infected. You can read on > for the details here: > > http://www.gotroot.com/tiki-read_article.php?articleId=278 > > Rules update is in testing now, will be putting out a major overhaul > this week. The major performance improvements will require modsec 2.5. > > From mike at gotroot.com Sat Sep 8 07:41:42 2007 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] iframe filtering rules In-Reply-To: <46E1FCA7.3040807@gmail.com> References: <1188785607.1661.2.camel@localhost.localdomain> <46E1FCA7.3040807@gmail.com> Message-ID: <46E28A76.5000206@gotroot.com> Steve West wrote: > Hi Michael, > > Thank you for the great tool! We've had a few customers web sites have > their web pages altered by hackers to add iframe tags, etc. The > customers gave out their ftp credentials to the wrong ppl so we can't > always protect against that. But I do have a few questions: > > 1. Is there any tool we can use if we are running apache 1.3.x? I'll look into. I'm not positive if apache 1.x supports external filters. If it does, then it should be easy enough to put this together for 1.3.x too. A quick look doesn't seem to show mod_ext_filter is supported in 1.3.x, so I'll have to look for other options. > 2. You should also add some filtering for obfuscated javascript which > I'm seeing some recent hacks employ to get around security > countermeasures on the server side. Thanks for the suggestion. I'll see what I can put together for that too. If you have some examples, please send them my way I'll see what I can put together this weekend. And for anyone wondering where the big update is, I'm almost finished with it finally. I'm just debugging a final problem with phase 2 transforms, which was stopping chained rules from working entirely. So many rules, so many dependencies... > thx, > > SW > > > Michael Shinn wrote: >> I put together a method for filtering out bad iframes from websites. >> Output filtering, for websites that become infected. You can read on >> for the details here: >> >> http://www.gotroot.com/tiki-read_article.php?articleId=278 >> >> Rules update is in testing now, will be putting out a major overhaul >> this week. The major performance improvements will require modsec 2.5. >> >> > From rcbarnett at gmail.com Sat Sep 8 12:55:49 2007 From: rcbarnett at gmail.com (Ryan Barnett) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] iframe filtering rules In-Reply-To: <46E28A76.5000206@gotroot.com> References: <1188785607.1661.2.camel@localhost.localdomain> <46E1FCA7.3040807@gmail.com> <46E28A76.5000206@gotroot.com> Message-ID: I would recommend mod_publisher - http://apache.webthing.com/mod_publisher/ It is more efficient performance-wise vs. using mod_ext_filter to spawn command line sed for each outbound response. It is also more accurate for updating html. I actually described using mod_ext_filters and sed to remove html comments, etc... in my book "Preventing Web Attacks with Apache." I wanted to present this concept to users to show how to use them for security, however there can be some severe performance problems if you attempt to use it in production. There is a great article here that compares mod_ext_filter, mod_line_edit and mod_publisher for these types of security purposes - http://www.apachetutor.org/security/information-leak. One question for Michael - why just silently remove the malicious iframe? Wouldn't it be better to implement these RegExs into ModSecurity rules that monitor outbound traffic and then block and alert in such situations? -- Ryan C. Barnett ModSecurity Community Manager Breach Security: Director of Application Security Training Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache On 9/8/07, Michael Shinn wrote: > > Steve West wrote: > > Hi Michael, > > > > Thank you for the great tool! We've had a few customers web sites have > > their web pages altered by hackers to add iframe tags, etc. The > > customers gave out their ftp credentials to the wrong ppl so we can't > > always protect against that. But I do have a few questions: > > > > 1. Is there any tool we can use if we are running apache 1.3.x? > > I'll look into. I'm not positive if apache 1.x supports external > filters. If it does, then it should be easy enough to put this together > for 1.3.x too. A quick look doesn't seem to show mod_ext_filter is > supported in 1.3.x, so I'll have to look for other options. > > > 2. You should also add some filtering for obfuscated javascript which > > I'm seeing some recent hacks employ to get around security > > countermeasures on the server side. > > Thanks for the suggestion. I'll see what I can put together for that > too. If you have some examples, please send them my way I'll see what I > can put together this weekend. > > And for anyone wondering where the big update is, I'm almost finished > with it finally. I'm just debugging a final problem with phase 2 > transforms, which was stopping chained rules from working entirely. So > many rules, so many dependencies... > > > thx, > > > > SW > > > > > > Michael Shinn wrote: > >> I put together a method for filtering out bad iframes from websites. > >> Output filtering, for websites that become infected. You can read on > >> for the details here: > >> > >> http://www.gotroot.com/tiki-read_article.php?articleId=278 > >> > >> Rules update is in testing now, will be putting out a major overhaul > >> this week. The major performance improvements will require modsec 2.5. > >> > >> > > > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20070908/bebe0646/attachment.html From mike at gotroot.com Sat Sep 8 16:10:20 2007 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] iframe filtering rules In-Reply-To: References: <1188785607.1661.2.camel@localhost.localdomain> <46E1FCA7.3040807@gmail.com> <46E28A76.5000206@gotroot.com> Message-ID: <46E301AC.4000607@gotroot.com> Ryan Barnett wrote: > One question for Michael - why just silently remove the malicious > iframe? Wouldn't it be better to implement these RegExs into > ModSecurity rules that monitor outbound traffic and then block and alert > in such situations? As you know, better ultimately depends on whats important to the site owner (I mean, how many people still share default passwords for critical systems because its "easier"?) :-) Whereas, I certainly don't see logging/alerting as mutually exclusive to filtering out the content, blocking and filtering do have very different outcomes for a site so in some cases blocking may not be better. Blocking is certainly more reliable and secure (what if you miss something in the filtering method?), whereas filtering prevents you from carrying out an availability attack against your own security model - you know your content still gets to your user, and if its can be reasonably assured to be malicious-free, win-win. Either case works to varying levels of assurance, so I wouldn't say one is better a priori than the other, they each have trade offs and serve different goals, but in some cases one can be better than the other. To that end, I'm going to be putting out OUTPUT rules that block malicious content as well, but I've found that some sites can't use them at all. Blocking any of their own content is worse for them than getting their users infected (Newspapers, Weather sites, Government systems, etc.) Ultimately, I think it depends on whats more important to each site owner. In some cases, yes blocking outright is going to be the best answer, for others, blocking your own content for your users might be worse than letting them get infected. It might be more important to say "Tornado Warning" and accept the risk that a trojan might get thru, than risk someone not being able to pull up the Tornado Warning site. :-) In any case, its certainly important to know that you get infected which you could do in parallel with stripping out the iframes, output filtering I think has a special place for those cases where availability is of critical importance to the site. I'll take a look at mod_publisher next to see how it scales. Thanks for the tip Ryan. > > -- > Ryan C. Barnett > ModSecurity Community Manager > Breach Security: Director of Application Security Training > Web Application Security Consortium (WASC) Member > CIS Apache Benchmark Project Lead > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC > Author: Preventing Web Attacks with Apache > > > On 9/8/07, *Michael Shinn* > > wrote: > > Steve West wrote: > > Hi Michael, > > > > Thank you for the great tool! We've had a few customers web sites > have > > their web pages altered by hackers to add iframe tags, etc. The > > customers gave out their ftp credentials to the wrong ppl so we can't > > always protect against that. But I do have a few questions: > > > > 1. Is there any tool we can use if we are running apache 1.3.x? > > I'll look into. I'm not positive if apache 1.x supports external > filters. If it does, then it should be easy enough to put this > together > for 1.3.x too. A quick look doesn't seem to show mod_ext_filter is > supported in 1.3.x, so I'll have to look for other options. > > > 2. You should also add some filtering for obfuscated javascript which > > I'm seeing some recent hacks employ to get around security > > countermeasures on the server side. > > Thanks for the suggestion. I'll see what I can put together for that > too. If you have some examples, please send them my way I'll see > what I > can put together this weekend. > > And for anyone wondering where the big update is, I'm almost finished > with it finally. I'm just debugging a final problem with phase 2 > transforms, which was stopping chained rules from working entirely. So > many rules, so many dependencies... > > > thx, > > > > SW > > > > > > Michael Shinn wrote: > >> I put together a method for filtering out bad iframes from websites. > >> Output filtering, for websites that become infected. You can > read on > >> for the details here: > >> > >> http://www.gotroot.com/tiki-read_article.php?articleId=278 > >> > >> Rules update is in testing now, will be putting out a major overhaul > >> this week. The major performance improvements will require > modsec 2.5. > >> > >> > > > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity > From wolfgang at klaer.com Sun Sep 9 23:48:02 2007 From: wolfgang at klaer.com (Wolfgang Klaer) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Modsecurity 2.0 compatible rules released Message-ID: <46E4BE72.6020101@klaer.com> Hello Michael, we have installed a new Centos Box for production envoirement. Can i use the Modsecurity 2.0 compatible rules now? Is the testing done or is it beta quality (Website gotroot Oct 2006)? On my old box i use Modsecurity 1.9. Thank you Kind regards Wolfgang From admin at efastservers.com Thu Sep 13 13:43:23 2007 From: admin at efastservers.com (admin@efastservers.com) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Shellbot installation via lynx -lp Message-ID: There seems to a new way of installating shellbots into the /tmp directory on the server and im not positive on how it's being done. I'v noticed this on 2 of my client's servers in the past few weeks. What strange about it is mod_security has not caught it. Now we install a fairly complicated version of the rules on our client's servers. It include lynx, at least 3 variations and in /usr/bin/lynx is chmod 750 yet it seems that this is how its being installed at the moment. I cant understand how lynx -lp is being executed. If its chmod 750 nobody from the internet can execute the command. Why do I think its lynx -lp? Because I killed a pid that was executing lynx -lp as the user nobody. They did not get far. The firewall denies all outbound connections and these bots usually try to make a connection outbound on port 6667. Even so, im frustrated as hell trying to find out how it's being done. I searched all the user logs using egrep and could not find an occurrence of lynx -lp but it was definitely there and the firewall did tell me that it was a suspicious process running. I'm also surprised that our mod_sec rules which is about 57k did not catch it. If it was used as a cmd= or whatever both cmd and lynx does exist in the rules and the fact that lynx, wget, scp etc is all chmod 750 is a mystery too me. Unless its being installed some other way other than via a malicious url I have no idea how its getting dumped to /tmp. Anyone? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20070913/1765fd78/attachment.html From michal at sabren.com Fri Sep 14 11:10:09 2007 From: michal at sabren.com (Michal Wallace) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Shellbot installation via lynx -lp In-Reply-To: <200709131744.l8DHiIjB027773@hydrogen.sabren.com> References: <200709131744.l8DHiIjB027773@hydrogen.sabren.com> Message-ID: On Thu, 13 Sep 2007 admin@efastservers.com wrote: > I cant understand how lynx -lp is being executed. If its chmod 750 nobody > from the internet can execute the command. Why do I think its lynx -lp? > Because I killed a pid that was executing lynx -lp as the user nobody. I bet it's not lynx. I bet the app just changes the name of the running process to make it LOOK normal. If you freeze it with kill -STOP and poke around in the /proc dir for the process, you'll probably see it started from another directory. Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: michal@sabren.com hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ ------------------------------------- From mike at gotroot.com Fri Sep 14 15:40:51 2007 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Shellbot installation via lynx -lp Message-ID: <1189798851.2540.22.camel@shrike.gotroot.com> Its an interesting one. Do you have all the other download clients covered? (wget, ftp, ncftp, rsync, curl, scp, rcp, etc.) It could also just be an internal function call in php (furl_open, etc.). Do you have all the bad HP functions turned off? (system, exec, etc.) Also, if you have the outbound firewall setup, why not stop all connections to ports 80 and 443 outbound? On Thu, 2007-09-13 at 13:43 -0400, admin@efastservers.com wrote: > There seems to a new way of installating shellbots into the /tmp > directory on the server and im not positive on how it?s being done. > > I?v noticed this on 2 of my client?s servers in the past few weeks. > > > > What strange about it is mod_security has not caught it. Now we > install a fairly complicated version of the rules on our client?s > servers. It include lynx, at least 3 variations and in /usr/bin/lynx > is chmod 750 yet it seems that this is how its being installed at the > moment. > > > > I cant understand how lynx ?lp is being executed. If its chmod 750 > nobody from the internet can execute the command. Why do I think its > lynx ?lp? Because I killed a pid that was executing lynx ?lp as the > user nobody. > > > > They did not get far. The firewall denies all outbound connections and > these bots usually try to make a connection outbound on port 6667. > Even so, im frustrated as hell trying to find out how it?s being done. > I searched all the user logs using egrep and could not find an > occurrence of lynx ?lp but it was definitely there and the firewall > did tell me that it was a suspicious process running. > > > > I?m also surprised that our mod_sec rules which is about 57k did not > catch it. If it was used as a cmd= or whatever both cmd and lynx does > exist in the rules and the fact that lynx, wget, scp etc is all chmod > 750 is a mystery too me. > > > > Unless its being installed some other way other than via a malicious > url I have no idea how its getting dumped to /tmp. > > > > Anyone? > > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 SANS Advisory Board Member Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From mike at gotroot.com Fri Sep 14 15:41:50 2007 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:33 2008 Subject: [Modsecurity] Shellbot installation via lynx -lp In-Reply-To: References: <200709131744.l8DHiIjB027773@hydrogen.sabren.com> Message-ID: <1189798910.2540.24.camel@shrike.gotroot.com> Also what are the groups that can execute lynx? On Fri, 2007-09-14 at 11:10 -0400, Michal Wallace wrote: > On Thu, 13 Sep 2007 admin@efastservers.com wrote: > > > I cant understand how lynx -lp is being executed. If its chmod 750 nobody > > from the internet can execute the command. Why do I think its lynx -lp? > > Because I killed a pid that was executing lynx -lp as the user nobody. > > I bet it's not lynx. I bet the app just changes the > name of the running process to make it LOOK normal. > If you freeze it with kill -STOP and poke around in > the /proc dir for the process, you'll probably see > it started from another directory. > > Sincerely, > > Michal J Wallace > Sabren Enterprises, Inc. > ------------------------------------- > contact: michal@sabren.com > hosting: http://www.cornerhost.com/ > my site: http://www.withoutane.com/ > ------------------------------------- > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 SANS Advisory Board Member Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com