|
From: Jose P. V. L. <pab...@gm...> - 2014-02-03 16:48:35
|
It´s not so easy :p. I´m finding problems with content fields. I have two hex to ascii parser (bash and python) and I found that there are some contents wich are hard to parse: root|3a|x|3a|0|3a|0|3a|root|3a|/root|3a|/ I guess that content example has hexadecimal values inside ascci normal characters. My bash script works with strings like |2E|2F|sogou but still I don´t know why does not work with example content at the begining of the mail: #!/bin/bash # CADENA is string but in spanish :) #CADENA="|2e|2f|sogou" #CADENA="|2E|2F|sogou" CADENA="|2A02|" # String parsing not working on: #CADENA="root|3a|x|3a|0|3a|0|3a|root|3a|/root|3a|/" #CADENA="|00 00 00 04|ftp|3a|//" ASCII=`echo -n $CADENA | xxd -r -p -u` # With this variable I would want to get sogou string but finally I understand that no hexadecimal parts could be mixed through different string places as: # root|3a|x|3a|0|3a|0|3a|root|3a|/root|3a|/ NOHEX=`echo "$CADENA" | rev | cut -d'|' -f1 | rev` echo "$ASCII$NOHEX" echo "$NOHEX" echo "$ASCII" I´m testing different patterns to check if it right works. Thanks anyway for your help!!! 2014-02-03 Jose Pablo Valcárcel Lázaro <pab...@gm...>: > Thanks Ryan for your help!! > > I was looking for perl cpan modules to convert pcre and from that point > convert to mod_security regular expression. > > Now, I should only grep on http directives and tell parser script how to > act against each http directive (I will ignore length suricata directives) > and look the phase where the rule should be developed and manage what > should it happen if I detect several phases due to directives should be > written in different phases (I guess this never should happen but...) > > Kind regards, > > > 2014-01-31 Ryan Barnett <RBa...@tr...>: > >> Jose, >> ModSecurity uses PCRE with its @rx operator - >> https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-rx >> >> Yes, Snort and Suricata IDS also have pcre actions/operators however >> the format of specifying the actual expression is slightly different. They >> use the syntax - /REGEX_PATTERN/[optional pcre compilation flag(s)]. The >> PCRE compilation flags in the example you show below are [si] and mean - >> >> http://www.pcre.org/pcre.txt >> >> "s" flag - PCRE_DOTALL >> >> If this bit is set, a dot metacharacter in the pattern matches a char- >> acter of any value, including one that indicates a newline. However, it >> only ever matches one character, even if newlines are coded as CRLF. >> Without this option, a dot does not match when the current position is >> at a newline. This option is equivalent to Perl's /s option, and it can >> be changed within a pattern by a (?s) option setting. A negative class >> such as [^a] always matches newline characters, independent of the set- >> ting of this option. >> >> >> "i" flag - PCRE_CASELESS >> >> If this bit is set, letters in the pattern match both upper and lower >> case letters. It is equivalent to Perl's /i option, and it can be >> changed within a pattern by a (?i) option setting. In UTF-8 mode, PCRE >> always understands the concept of case for characters whose values are >> less than 128, so caseless matching is always possible. For characters >> with higher values, the concept of case is supported if PCRE is com- >> piled with Unicode property support, but not otherwise. If you want to >> use caseless matching for characters 128 and above, you must ensure >> that PCRE is compiled with Unicode property support as well as with >> UTF-8 support. >> >> >> In ModSecurity, the PCRE expression is defined within the OPERATOR >> location of the SecRule between double quotes - "@rx REGEX_PATTERN". You >> can add similar optional compilation flags directly to the beginning of the >> expression. Example, to add PCRE_CASELESS matching using "@rx >> (?I)REGEX_PATTERN". >> >> Now, for your specific question below about that Snort/Suricata regex. >> ModSecurity already uses the PCRE_DOTALL (s) flag when compiling the >> REGEX_PATTERN so you don't need to convert that. You would need to apply >> the PCRE_CASELESS flag (I) however. Something like this - >> >> SecRule RESPONSE_BODY "@rx >> (?I)<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*E2883E8F-472F-4fb0-9522-AC9BF37916A7.+offer-(ineligible|preinstalled|declined|accepted)" >> "phase:response,t:none,id:2010665,log,deny,msg:'ET ACTIVEX Possible NOS >> Microsystems Adobe Reader/Acrobat getPlus Get_atlcomHelper ActiveX Control >> Multiple Stack Overflows Remote Code Execution Attempt'" >> >> >> *Ryan Barnett* >> >> Lead Security Researcher, SpiderLabs >> >> >> >> *Trustwave* | SMART SECURITY ON DEMAND >> >> www.trustwave.com >> >> >> From: Jose Pablo Valcárcel Lázaro <pab...@gm...> >> Reply-To: "mod...@li..." < >> mod...@li...> >> Date: Wednesday, January 29, 2014 5:38 AM >> To: "mod...@li..." < >> mod...@li...> >> Subject: Re: [mod-security-users] Question about pcre and how to convert >> into mod_security rules >> >> How is it possible that suricata and mod_security use different values >> to evaluate insensitive expressions? >> >> Within mod_security equivalent pcre for insensitive should be (as we >> can see on rx directive): "@rx (?i)nikto" >> >> while in suricata should be /nikto/i >> >> So if both are using pcre software and libraries, how is it possible >> that insensitive searchs perform in different way for each software? >> >> If I want to parse a pcre to match a vulnerability, not exploit, should >> I parse all the pcre into normal content and finally convert it again into >> pcre for mod_security? >> >> Which pcre does modsecurity uses? Is there any manual reference? >> >> Kind regards, >> >> >> 2014-01-29 Jose Pablo Valcárcel Lázaro <pab...@gm...> >> >>> Good morning. >>> >>> I was wondering if someone could advice me how to convert regular >>> expression as >>> >>> /<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*E2883E8F-472F-4fb0-9522-AC9BF37916A7.+offer-(ineligible|preinstalled|declined|accepted)/si >>> >>> into mod_security compatible regular expression. >>> >>> Looking at the exploit exploit<http://www.exploit-db.com/exploits/11172/> vulnerability >>> string is >>> <objectid=TestObjclassid="CLSID:{E2883E8F-472F-4fb0-9522-AC9BF37916A7}" >>> >>> So I understand that using the pcre you should be able to stop any >>> variation of the exploit? >>> >>> Kind regards, >>> >> >> >> ------------------------------ >> >> This transmission may contain information that is privileged, >> confidential, and/or exempt from disclosure under applicable law. If you >> are not the intended recipient, you are hereby notified that any >> disclosure, copying, distribution, or use of the information contained >> herein (including any reliance thereon) is strictly prohibited. If you >> received this transmission in error, please immediately contact the sender >> and destroy the material in its entirety, whether in electronic or hard >> copy format. >> >> >> ------------------------------------------------------------------------------ >> WatchGuard Dimension instantly turns raw network data into actionable >> security intelligence. It gives you real-time visual feedback on key >> security issues and trends. Skip the complicated setup - simply import >> a virtual appliance and go from zero to informed in seconds. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk >> _______________________________________________ >> mod-security-users mailing list >> mod...@li... >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: >> http://www.modsecurity.org/projects/commercial/rules/ >> http://www.modsecurity.org/projects/commercial/support/ >> >> > |
