From jonkman at bleedingthreats.net Tue Jan 2 18:44:26 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Tue Jan 2 18:45:30 2007 Subject: [Bleeding-sigs] Endian Firewall Now Using the Bleeding DNS-BlackHole List Message-ID: <459AA80A.6010700@bleedingthreats.net> We?re happy to announce that the Endian Firewall, a free security distro designed for easy install and use is now using the DNS BlackHole list here at Bleeding Edge Threats, maintained by David Glosser. If you?re not familiar you can learn more about the Endian Firewall here: http://www.endian.it/en/community/about/overview/ We also encourage you to learn more about and use the Bleeding DNS BlackHole List. David takes very good care of the list, it?s a very useful tool, especially in an environment where filtering or blocking are not feasible options. Matt -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From bleeding at bleedingthreats.net Tue Jan 2 20:00:03 2007 From: bleeding at bleedingthreats.net (bleeding@bleedingthreats.net) Date: Tue Jan 2 20:00:06 2007 Subject: [Bleeding-sigs] Bleeding Edge Threats Daily Signature Changes Message-ID: <20070102200003.D7C7422C08B@sb03.us.bleedingsnort.com> [***] Results from Oinkmaster started Tue Jan 2 20:00:03 2007 [***] [+++] Added rules: [+++] 2003240 - BLEEDING-EDGE MALWARE New.net Spyware updating (bleeding-malware.rules) 2003241 - BLEEDING-EDGE MALWARE New.net Spyware Checkin (bleeding-malware.rules) 2003242 - BLEEDING-EDGE Malware Websearch.com Cab Download (bleeding-malware.rules) 2003243 - BLEEDING-EDGE MALWARE Suspicious User Agent (Download Agent) Possibly Related to TrinityAcquisitions.com (bleeding-malware.rules) [///] Modified active rules: [///] 2400000 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400001 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400002 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400003 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400004 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2401000 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401001 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401002 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401003 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401004 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2402000 - BLEEDING-EDGE DROP Dshield Block Listed Source (bleeding-dshield.rules) 2403000 - BLEEDING-EDGE DROP Dshield Block Listed Source - BLOCKING (bleeding-dshield-BLOCK.rules) 2404000 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 1) (bleeding-botcc.rules) 2404001 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 2) (bleeding-botcc.rules) 2404002 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 3) (bleeding-botcc.rules) 2404003 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 4) (bleeding-botcc.rules) 2404004 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 5) (bleeding-botcc.rules) 2404005 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 6) (bleeding-botcc.rules) 2404006 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 7) (bleeding-botcc.rules) 2404007 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 8) (bleeding-botcc.rules) 2405000 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 1) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405001 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 2) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405002 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 3) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405003 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 4) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405004 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 5) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405005 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 6) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405006 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 7) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405007 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 8) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) [+++] Added non-rule lines: [+++] -> Added to bleeding-attack_response.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-botcc-BLOCK.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-botcc.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-dos.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-drop-BLOCK.rules (2): # Copyright (c) 2003-2007, Bleeding Edge Threats # VERSION 42 -> Added to bleeding-drop.rules (2): # Copyright (c) 2003-2007, Bleeding Edge Threats # VERSION 42 -> Added to bleeding-dshield-BLOCK.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-dshield.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-exploit.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-game.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-inappropriate.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-malware.rules (2): # Copyright (c) 2003-2007, Bleeding Edge Threats #Matt Jonkman, from spyware listening post data -> Added to bleeding-p2p.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-policy.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-scan.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-sid-msg.map (4): 2003240 || BLEEDING-EDGE MALWARE New.net Spyware updating || url,www.new.net 2003241 || BLEEDING-EDGE MALWARE New.net Spyware Checkin || url,www.new.net 2003242 || BLEEDING-EDGE Malware Websearch.com Cab Download || mcafee,131461 2003243 || BLEEDING-EDGE MALWARE Suspicious User Agent (Download Agent) Possibly Related to TrinityAcquisitions.com || url,www.bleedingthreats.net/index.php/about-bleeding-edge-threats/all-projects/spyware-listening-post/download-agent-user-agent-research/ -> Added to bleeding-virus.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-voip.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding-web.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding.conf (1): # Copyright (c) 2003-2007, Bleeding Edge Threats -> Added to bleeding.rules (1): # Copyright (c) 2003-2007, Bleeding Edge Threats [---] Removed non-rule lines: [---] -> Removed from bleeding-attack_response.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-botcc-BLOCK.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-botcc.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-dos.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-drop-BLOCK.rules (2): # Copyright (c) 2006, Bleeding Edge Threats # VERSION 38 -> Removed from bleeding-drop.rules (2): # Copyright (c) 2006, Bleeding Edge Threats # VERSION 38 -> Removed from bleeding-dshield-BLOCK.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-dshield.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-exploit.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-game.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-inappropriate.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-malware.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-p2p.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-policy.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-scan.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-virus.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-voip.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding-web.rules (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding.conf (1): # Copyright (c) 2006, Bleeding Edge Threats -> Removed from bleeding.rules (1): # Copyright (c) 2006, Bleeding Edge Threats From jonkman at bleedingthreats.net Thu Jan 4 20:44:22 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Thu Jan 4 20:45:17 2007 Subject: [Bleeding-sigs] Hacker Defender C&C Sig Message-ID: <459D6726.3040205@bleedingthreats.net> Noticed a pattern in the Hacker Defender C&C connection. Have been able to test this with a number of recent variants, but would appreciate it if anyone can test on other variants, and new stuff to come. alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: ?BLEEDING-EDGE TROJAN HackerDefender.HE Root Kit Control Connection?; flow: established,to_server; content:?|d0 84 ec 77 cf ec 60 e9|?; depth:8; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/backdoor.hackdefender.html; sid: 2003244; rev:1; ) alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg: ?BLEEDING-EDGE TROJAN HackerDefender.HE Root Kit Control Connection Reply?; flow: established,from_server; content:?|d0 84 ec 77 cf ec 60 e9|?; depth:8; classtype:trojan-activity; reference:url,securityresponse.symantec.com/avcenter/venc/data/backdoor.hackdefender.html; sid: 2003245; rev:1; ) Please let me know how it fares? -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Fri Jan 5 15:44:21 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Fri Jan 5 15:45:16 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted Message-ID: <459E7255.3030208@bleedingthreats.net> We?ve got adobe sigs for the XSS out. Forgot to update the list when I posted. alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:?BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter Javascript Attempt (URL Inbound)?; flow:established,from_server; content:?.pdf#?; nocase; pcre:?/.pdf#(.+=)javascript\:/im?; nocase; classtype:attempted-admin; sid:2003246; rev:2;) alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:?BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter Javascript Client Request?; flow:established,to_server; uricontent:?.pdf#?; nocase; pcre:?/.pdf#(.+=)javascript\:/iU?; nocase; classtype:attempted-admin; sid:2003247; rev:2;) These will catch them incoming or being requested via http. Malicious websites are the most likely vector we?ll see, but they may also come by email, instant messages, IRC, etc. However, most OSs will serve that request to a browser, so these will likely catch the request. I have references I?ll add to them shortly. Please let us know how these fare. Matt -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From frank at knobbe.us Fri Jan 5 19:04:29 2007 From: frank at knobbe.us (Frank Knobbe) Date: Fri Jan 5 19:05:23 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <459E7255.3030208@bleedingthreats.net> References: <459E7255.3030208@bleedingthreats.net> Message-ID: <1168023869.31391.24.camel@localhost> On Fri, 2007-01-05 at 10:44 -0500, Matt Jonkman wrote: > We?ve got adobe sigs for the XSS out. Forgot to update the list when I > posted. > > alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:?BLEEDING-EDGE > Exploit Adobe Acrobat Open Parameter Javascript Attempt (URL Inbound)?; > flow:established,from_server; content:?.pdf#?; nocase; > pcre:?/.pdf#(.+=)javascript\:/im?; nocase; classtype:attempted-admin; > sid:2003246; rev:2;) > > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:?BLEEDING-EDGE > Exploit Adobe Acrobat Open Parameter Javascript Client Request?; > flow:established,to_server; uricontent:?.pdf#?; nocase; > pcre:?/.pdf#(.+=)javascript\:/iU?; nocase; classtype:attempted-admin; > sid:2003247; rev:2;) Why are these focused on Javascript? This URL (http://www.wisec.it/vulns.php/page=9) lists other examples that don't use Javascript. It seems you can remotely include code, without using Javascript in the URI. Perhaps it would be worthwhile to have a generic sig for ".pdf#", or -- ignoring the DoS condition for a sec -- something like pcre:"/\.pdf#.*[http|https|ftp]:\//Ui". Thoughts? -Frank -- It is said that the Internet is a public utility. As such, it is best compared to a sewer. A big, fat pipe with a bunch of crap sloshing against your ports. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.bleedingthreats.net/pipermail/bleeding-sigs/attachments/20070105/54e0feed/attachment.pgp From jonkman at bleedingthreats.net Fri Jan 5 19:10:17 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Fri Jan 5 19:11:11 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <1168023869.31391.24.camel@localhost> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> Message-ID: <459EA299.3010102@bleedingthreats.net> You're exactly right frank (as frikkin always :) ) The existing sigs catch the javascript instance. These sigs are at this moment being discussed on another list. I was going to bring them over to here and post them shortly. by Mr Magic Pants: alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL (inbound)"; flow:established,to_server; uricontent:".pdf#"; nocase; pcre:"/'.pdf#(.+=)((.+\/)|(.+\.))/im"; nocase; classtype:attempted-admin; sid:XXXXXXXXX; rev:1;) alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL Client Request"; flow:established,to_server; uricontent:".pdf#"; nocase; pcre:"/'.pdf#(.+=)((.+\/)|(.+\.))/iU"; nocase; classtype:attempted-admin; sid:XXXXXXXX; rev:1;) The assumptions being debated are whether this can be used with just a raw IP and uri, assuming it'll be handed to a browser which will assume http://, thus making the above very load intensive pcre necessary. If we assume just http://, ftp://, tftp://, etc, we can make it relatively reasonable load and a lot fewer falses I think. Anyone able to test this and let us know if a straight IP or dns name without a leading uri indicator is handled? Matt Frank Knobbe wrote: > On Fri, 2007-01-05 at 10:44 -0500, Matt Jonkman wrote: >> We?ve got adobe sigs for the XSS out. Forgot to update the list when I >> posted. >> >> alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:?BLEEDING-EDGE >> Exploit Adobe Acrobat Open Parameter Javascript Attempt (URL Inbound)?; >> flow:established,from_server; content:?.pdf#?; nocase; >> pcre:?/.pdf#(.+=)javascript\:/im?; nocase; classtype:attempted-admin; >> sid:2003246; rev:2;) >> >> alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:?BLEEDING-EDGE >> Exploit Adobe Acrobat Open Parameter Javascript Client Request?; >> flow:established,to_server; uricontent:?.pdf#?; nocase; >> pcre:?/.pdf#(.+=)javascript\:/iU?; nocase; classtype:attempted-admin; >> sid:2003247; rev:2;) > > > Why are these focused on Javascript? This URL > (http://www.wisec.it/vulns.php/page=9) lists other examples that don't > use Javascript. It seems you can remotely include code, without using > Javascript in the URI. > > Perhaps it would be worthwhile to have a generic sig for ".pdf#", or -- > ignoring the DoS condition for a sec -- something like > pcre:"/\.pdf#.*[http|https|ftp]:\//Ui". Thoughts? > > -Frank > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From frank at knobbe.us Fri Jan 5 19:19:01 2007 From: frank at knobbe.us (Frank Knobbe) Date: Fri Jan 5 19:19:53 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <459EA299.3010102@bleedingthreats.net> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> <459EA299.3010102@bleedingthreats.net> Message-ID: <1168024741.31391.32.camel@localhost> On Fri, 2007-01-05 at 14:10 -0500, Matt Jonkman wrote: > The assumptions being debated are whether this can be used with just a > raw IP and uri, assuming it'll be handed to a browser which will assume > http://, thus making the above very load intensive pcre necessary. Don't forget https:// adn ftps://. Also, perhaps running strings over Acrobat might reveal other URI's like vbscript://... maybe :) Haha... I know! One URI that might still work without being detected is ... (** drumroll **)..... gopher:// ! Who still looks for that? Might still work as a request protocol and fly under everyone's radar!... lol Cheers, Frank -- It is said that the Internet is a public utility. As such, it is best compared to a sewer. A big, fat pipe with a bunch of crap sloshing against your ports. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.bleedingthreats.net/pipermail/bleeding-sigs/attachments/20070105/8699d85b/attachment.pgp From jonkman at bleedingthreats.net Fri Jan 5 19:22:07 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Fri Jan 5 19:23:33 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <1168024741.31391.32.camel@localhost> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> <459EA299.3010102@bleedingthreats.net> <1168024741.31391.32.camel@localhost> Message-ID: <459EA55F.7080709@bleedingthreats.net> You're not helping. :) Matt Frank Knobbe wrote: > On Fri, 2007-01-05 at 14:10 -0500, Matt Jonkman wrote: >> The assumptions being debated are whether this can be used with just a >> raw IP and uri, assuming it'll be handed to a browser which will assume >> http://, thus making the above very load intensive pcre necessary. > > Don't forget https:// adn ftps://. Also, perhaps running strings over > Acrobat might reveal other URI's like vbscript://... maybe :) > > Haha... I know! One URI that might still work without being detected > is ... > (** drumroll **)..... gopher:// ! Who still looks for that? Might still > work as a request protocol and fly under everyone's radar!... lol > > > Cheers, > Frank > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Fri Jan 5 19:33:32 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Fri Jan 5 19:34:24 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <1168024741.31391.32.camel@localhost> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> <459EA299.3010102@bleedingthreats.net> <1168024741.31391.32.camel@localhost> Message-ID: <459EA80C.80609@bleedingthreats.net> Independent test confirms that even telnet:// works. It did ask to open in an external app though, but still dangerous. I'll post this version: alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL (inbound)"; flow:established,to_server; uricontent:".pdf#"; nocase; pcre:"/'.pdf#(.+=)((.+\/)|(.+\.))/im"; nocase; classtype:attempted-admin; sid:XXXXXXXXX; rev:1;) alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL Client Request"; flow:established,to_server; uricontent:".pdf#"; nocase; pcre:"/'.pdf#(.+=)((.+\/)|(.+\.))/iU"; nocase; classtype:attempted-admin; sid:XXXXXXXX; rev:1;) Matt Frank Knobbe wrote: > On Fri, 2007-01-05 at 14:10 -0500, Matt Jonkman wrote: >> The assumptions being debated are whether this can be used with just a >> raw IP and uri, assuming it'll be handed to a browser which will assume >> http://, thus making the above very load intensive pcre necessary. > > Don't forget https:// adn ftps://. Also, perhaps running strings over > Acrobat might reveal other URI's like vbscript://... maybe :) > > Haha... I know! One URI that might still work without being detected > is ... > (** drumroll **)..... gopher:// ! Who still looks for that? Might still > work as a request protocol and fly under everyone's radar!... lol > > > Cheers, > Frank > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Fri Jan 5 19:37:03 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Fri Jan 5 19:38:58 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <1168024741.31391.32.camel@localhost> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> <459EA299.3010102@bleedingthreats.net> <1168024741.31391.32.camel@localhost> Message-ID: <459EA8DF.3010201@bleedingthreats.net> Actually, posting these: alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL (inbound)"; flow:e stablished,from_server; content:".pdf#"; nocase; pcre:"/'.pdf#(.+=)((.+\/)|(.+\.))/im"; nocase; classtype:attempted-admin; sid:20032 48; rev:1;) alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL Client Request"; f low:established,to_server; uricontent:".pdf#"; nocase; pcre:"/'.pdf#(.+=)((.+\/)|(.+\.))/iU"; nocase; classtype:attempted-admin; sid :2003249; rev;1;) Matt Frank Knobbe wrote: > On Fri, 2007-01-05 at 14:10 -0500, Matt Jonkman wrote: >> The assumptions being debated are whether this can be used with just a >> raw IP and uri, assuming it'll be handed to a browser which will assume >> http://, thus making the above very load intensive pcre necessary. > > Don't forget https:// adn ftps://. Also, perhaps running strings over > Acrobat might reveal other URI's like vbscript://... maybe :) > > Haha... I know! One URI that might still work without being detected > is ... > (** drumroll **)..... gopher:// ! Who still looks for that? Might still > work as a request protocol and fly under everyone's radar!... lol > > > Cheers, > Frank > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From security at brvenik.com Fri Jan 5 19:44:55 2007 From: security at brvenik.com (Jason) Date: Fri Jan 5 19:52:28 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <1168024741.31391.32.camel@localhost> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> <459EA299.3010102@bleedingthreats.net> <1168024741.31391.32.camel@localhost> Message-ID: <459EAAB7.9080102@brvenik.com> What about a file served as Application/pdf or whaddeva but with a different extension? Same result? Frank Knobbe wrote: > On Fri, 2007-01-05 at 14:10 -0500, Matt Jonkman wrote: >> The assumptions being debated are whether this can be used with just a >> raw IP and uri, assuming it'll be handed to a browser which will assume >> http://, thus making the above very load intensive pcre necessary. > > Don't forget https:// adn ftps://. Also, perhaps running strings over > Acrobat might reveal other URI's like vbscript://... maybe :) > > Haha... I know! One URI that might still work without being detected > is ... > (** drumroll **)..... gopher:// ! Who still looks for that? Might still > work as a request protocol and fly under everyone's radar!... lol > > > Cheers, > Frank > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs From bleeding at bleedingthreats.net Fri Jan 5 20:00:05 2007 From: bleeding at bleedingthreats.net (bleeding@bleedingthreats.net) Date: Fri Jan 5 20:00:05 2007 Subject: [Bleeding-sigs] Bleeding Edge Threats Daily Signature Changes Message-ID: <20070105200005.2FC9422C0DF@sb03.us.bleedingsnort.com> [***] Results from Oinkmaster started Fri Jan 5 20:00:05 2007 [***] [+++] Added rules: [+++] 2003244 - BLEEDING-EDGE TROJAN HackerDefender.HE Root Kit Control Connection (bleeding-virus.rules) 2003245 - BLEEDING-EDGE TROJAN HackerDefender.HE Root Kit Control Connection Reply (bleeding-virus.rules) 2003246 - BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter Javascript Attempt (URL Inbound) (bleeding-exploit.rules) 2003247 - BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter Javascript Client Request (bleeding-exploit.rules) [///] Modified active rules: [///] 2400000 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400001 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400002 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400003 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400004 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2401000 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401001 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401002 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401003 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401004 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2402000 - BLEEDING-EDGE DROP Dshield Block Listed Source (bleeding-dshield.rules) 2403000 - BLEEDING-EDGE DROP Dshield Block Listed Source - BLOCKING (bleeding-dshield-BLOCK.rules) 2404000 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 1) (bleeding-botcc.rules) 2404001 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 2) (bleeding-botcc.rules) 2404002 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 3) (bleeding-botcc.rules) 2404003 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 4) (bleeding-botcc.rules) 2404004 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 5) (bleeding-botcc.rules) 2404005 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 6) (bleeding-botcc.rules) 2404006 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 7) (bleeding-botcc.rules) 2404007 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 8) (bleeding-botcc.rules) 2405000 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 1) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405001 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 2) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405002 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 3) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405003 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 4) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405004 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 5) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405005 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 6) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405006 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 7) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405007 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 8) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) [+++] Added non-rule lines: [+++] -> Added to bleeding-drop-BLOCK.rules (1): # VERSION 45 -> Added to bleeding-drop.rules (1): # VERSION 45 -> Added to bleeding-sid-msg.map (4): 2003244 || BLEEDING-EDGE TROJAN HackerDefender.HE Root Kit Control Connection || url,securityresponse.symantec.com/avcenter/venc/data/backdoor.hackdefender.html 2003245 || BLEEDING-EDGE TROJAN HackerDefender.HE Root Kit Control Connection Reply || url,securityresponse.symantec.com/avcenter/venc/data/backdoor.hackdefender.html 2003246 || BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter Javascript Attempt (URL Inbound) || url,secunia.com/advisories/23483/ 2003247 || BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter Javascript Client Request || url,secunia.com/advisories/23483/ [---] Removed non-rule lines: [---] -> Removed from bleeding-drop-BLOCK.rules (1): # VERSION 42 -> Removed from bleeding-drop.rules (1): # VERSION 42 From bleeding at bleedingthreats.net Sat Jan 6 20:00:06 2007 From: bleeding at bleedingthreats.net (bleeding@bleedingthreats.net) Date: Sat Jan 6 20:00:08 2007 Subject: [Bleeding-sigs] Bleeding Edge Threats Daily Signature Changes Message-ID: <20070106200006.67A2622C0BE@sb03.us.bleedingsnort.com> [***] Results from Oinkmaster started Sat Jan 6 20:00:06 2007 [***] [+++] Added rules: [+++] 2003248 - BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL (inbound) (bleeding-exploit.rules) 2003249 - BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL Client Request (bleeding-exploit.rules) [+++] Added non-rule lines: [+++] -> Added to bleeding-exploit.rules (3): #by Mr Magic Pants #by mr Magic Pants #These are probably higher load, and may false. We should consider removing these arounf the middle of february 2007 if the vuln passes -> Added to bleeding-sid-msg.map (2): 2003248 || BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL (inbound) 2003249 || BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL Client Request From security at brvenik.com Mon Jan 8 02:24:22 2007 From: security at brvenik.com (Jason) Date: Mon Jan 8 02:25:32 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <459EAAB7.9080102@brvenik.com> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> <459EA299.3010102@bleedingthreats.net> <1168024741.31391.32.camel@localhost> <459EAAB7.9080102@brvenik.com> Message-ID: <45A1AB56.8000005@brvenik.com> http://www.brvenik.com/ucsrf/ Jason wrote: > What about a file served as Application/pdf or whaddeva but with a > different extension? Same result? > > Frank Knobbe wrote: >> On Fri, 2007-01-05 at 14:10 -0500, Matt Jonkman wrote: >>> The assumptions being debated are whether this can be used with just a >>> raw IP and uri, assuming it'll be handed to a browser which will assume >>> http://, thus making the above very load intensive pcre necessary. >> Don't forget https:// adn ftps://. Also, perhaps running strings over >> Acrobat might reveal other URI's like vbscript://... maybe :) >> >> Haha... I know! One URI that might still work without being detected >> is ... >> (** drumroll **)..... gopher:// ! Who still looks for that? Might still >> work as a request protocol and fly under everyone's radar!... lol >> >> >> Cheers, >> Frank >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Bleeding-sigs mailing list >> Bleeding-sigs@bleedingthreats.net >> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > From jonkman at bleedingthreats.net Mon Jan 8 14:32:41 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Mon Jan 8 14:33:40 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <45A1AB56.8000005@brvenik.com> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> <459EA299.3010102@bleedingthreats.net> <1168024741.31391.32.camel@localhost> <459EAAB7.9080102@brvenik.com> <45A1AB56.8000005@brvenik.com> Message-ID: <45A25609.5050904@bleedingthreats.net> Thanks for the examples Jason. Do they all work on a windows box? That really blows easy detection by url out of the water... Matt Jason wrote: > http://www.brvenik.com/ucsrf/ > > Jason wrote: >> What about a file served as Application/pdf or whaddeva but with a >> different extension? Same result? >> >> Frank Knobbe wrote: >>> On Fri, 2007-01-05 at 14:10 -0500, Matt Jonkman wrote: >>>> The assumptions being debated are whether this can be used with just a >>>> raw IP and uri, assuming it'll be handed to a browser which will assume >>>> http://, thus making the above very load intensive pcre necessary. >>> Don't forget https:// adn ftps://. Also, perhaps running strings over >>> Acrobat might reveal other URI's like vbscript://... maybe :) >>> >>> Haha... I know! One URI that might still work without being detected >>> is ... >>> (** drumroll **)..... gopher:// ! Who still looks for that? Might still >>> work as a request protocol and fly under everyone's radar!... lol >>> >>> >>> Cheers, >>> Frank >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Bleeding-sigs mailing list >>> Bleeding-sigs@bleedingthreats.net >>> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >> _______________________________________________ >> Bleeding-sigs mailing list >> Bleeding-sigs@bleedingthreats.net >> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >> > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From security at brvenik.com Mon Jan 8 14:38:32 2007 From: security at brvenik.com (Jason) Date: Mon Jan 8 14:39:24 2007 Subject: [Bleeding-sigs] Adobe Acrobat Exploit Sigs Posted In-Reply-To: <45A25609.5050904@bleedingthreats.net> References: <459E7255.3030208@bleedingthreats.net> <1168023869.31391.24.camel@localhost> <459EA299.3010102@bleedingthreats.net> <1168024741.31391.32.camel@localhost> <459EAAB7.9080102@brvenik.com> <45A1AB56.8000005@brvenik.com> <45A25609.5050904@bleedingthreats.net> Message-ID: <45A25768.1070006@brvenik.com> The .[doc|pdf|bogus] work perfectly. Andre had asked if it worked without an extension so I just added a file / link with no extension but have not had a chance to test it. Matt Jonkman wrote: > Thanks for the examples Jason. Do they all work on a windows box? > > That really blows easy detection by url out of the water... > > Matt > > Jason wrote: >> http://www.brvenik.com/ucsrf/ >> >> Jason wrote: >>> What about a file served as Application/pdf or whaddeva but with a >>> different extension? Same result? >>> >>> Frank Knobbe wrote: >>>> On Fri, 2007-01-05 at 14:10 -0500, Matt Jonkman wrote: >>>>> The assumptions being debated are whether this can be used with just a >>>>> raw IP and uri, assuming it'll be handed to a browser which will >>>>> assume >>>>> http://, thus making the above very load intensive pcre necessary. >>>> Don't forget https:// adn ftps://. Also, perhaps running strings over >>>> Acrobat might reveal other URI's like vbscript://... maybe :) >>>> Haha... I know! One URI that might still work without being detected >>>> is ... >>>> (** drumroll **)..... gopher:// ! Who still looks for that? Might >>>> still >>>> work as a request protocol and fly under everyone's radar!... lol >>>> >>>> >>>> Cheers, >>>> Frank >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Bleeding-sigs mailing list >>>> Bleeding-sigs@bleedingthreats.net >>>> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >>> _______________________________________________ >>> Bleeding-sigs mailing list >>> Bleeding-sigs@bleedingthreats.net >>> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >>> >> _______________________________________________ >> Bleeding-sigs mailing list >> Bleeding-sigs@bleedingthreats.net >> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > From bleeding at bleedingthreats.net Tue Jan 9 20:00:04 2007 From: bleeding at bleedingthreats.net (bleeding@bleedingthreats.net) Date: Tue Jan 9 20:00:05 2007 Subject: [Bleeding-sigs] Bleeding Edge Threats Daily Signature Changes Message-ID: <20070109200004.1D01422C088@sb03.us.bleedingsnort.com> [***] Results from Oinkmaster started Tue Jan 9 20:00:04 2007 [***] [+++] Added rules: [+++] 2404008 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 9) (bleeding-botcc.rules) 2405008 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 9) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) [///] Modified active rules: [///] 2003248 - BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL (inbound) (bleeding-exploit.rules) 2003249 - BLEEDING-EDGE Exploit Adobe Acrobat Open Parameter URL Client Request (bleeding-exploit.rules) 2400000 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2401000 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2402000 - BLEEDING-EDGE DROP Dshield Block Listed Source (bleeding-dshield.rules) 2403000 - BLEEDING-EDGE DROP Dshield Block Listed Source - BLOCKING (bleeding-dshield-BLOCK.rules) 2404000 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 1) (bleeding-botcc.rules) 2404001 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 2) (bleeding-botcc.rules) 2404002 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 3) (bleeding-botcc.rules) 2404003 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 4) (bleeding-botcc.rules) 2404004 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 5) (bleeding-botcc.rules) 2404005 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 6) (bleeding-botcc.rules) 2404006 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 7) (bleeding-botcc.rules) 2404007 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 8) (bleeding-botcc.rules) 2405000 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 1) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405001 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 2) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405002 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 3) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405003 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 4) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405004 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 5) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405005 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 6) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405006 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 7) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405007 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 8) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) [---] Removed rules: [---] 2400001 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400002 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400003 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400004 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2401001 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401002 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401003 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401004 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) [+++] Added non-rule lines: [+++] -> Added to bleeding-drop-BLOCK.rules (1): # VERSION 49 -> Added to bleeding-drop.rules (1): # VERSION 49 -> Added to bleeding-exploit.rules (1): #These are probably higher load, and may false. We should consider removing these around the middle of february 2007 if the vuln passes -> Added to bleeding-sid-msg.map (2): 2404008 || BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 9) || url,www.shadowserver.org 2405008 || BLEEDING-EDGE DROP Known Bot C&C Traffic (group 9) - BLOCKING SOURCE || url,www.shadowserver.org [---] Removed non-rule lines: [---] -> Removed from bleeding-drop-BLOCK.rules (1): # VERSION 45 -> Removed from bleeding-drop.rules (1): # VERSION 45 -> Removed from bleeding-exploit.rules (1): #These are probably higher load, and may false. We should consider removing these arounf the middle of february 2007 if the vuln passes -> Removed from bleeding-sid-msg.map (8): 2400001 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound || url,www.spamhaus.org/drop/drop.lasso 2400002 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound || url,www.spamhaus.org/drop/drop.lasso 2400003 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound || url,www.spamhaus.org/drop/drop.lasso 2400004 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound || url,www.spamhaus.org/drop/drop.lasso 2401001 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE || url,www.spamhaus.org/drop/drop.lasso 2401002 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE || url,www.spamhaus.org/drop/drop.lasso 2401003 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE || url,www.spamhaus.org/drop/drop.lasso 2401004 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE || url,www.spamhaus.org/drop/drop.lasso From jonkman at bleedingthreats.net Tue Jan 9 22:42:34 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Tue Jan 9 22:43:30 2007 Subject: [Bleeding-sigs] SSL Enabled Message-ID: <45A41A5A.60206@bleedingthreats.net> By popular demand, we've turned back on the SSL side of this site. That'll allow the download of rules that are not zipped or tar'd up, and other research without tripping your local snort install. Our forums especially tend to trip a number of sigs because of the exploit discussions. You can access all normal URLs at the https version. This will remain online, so feel free to move your autoupdates or scripts. The SSL Cert is self signed but valid, so there shouldn't be any major issues. Matt -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From gentoowally at gmail.com Wed Jan 10 16:51:09 2007 From: gentoowally at gmail.com (Gentoo-Wally) Date: Wed Jan 10 16:52:10 2007 Subject: [Bleeding-sigs] definition Message-ID: Hi, Someone asked me to describe the BleedingEdge signatures, and oddly even though I've been using them for a log time I didn't really have a good way to define them. I looked on the web site for a FAQ hoping for a solid answer but I did not see a FAQ. What would be the best way of describing the BleedingEdge signatures? I understand that they compliment the VRT and Community sets, but are they considered more experimental than the VRT and Community sets? At one point I thought someone said they were kind of a proving ground for signatures before being added to the Community set but I'm not sure this is accurate. What is it that makes them different? Wally From scheidell at secnap.net Wed Jan 10 16:56:07 2007 From: scheidell at secnap.net (Michael Scheidell) Date: Wed Jan 10 16:57:28 2007 Subject: [Bleeding-sigs] definition In-Reply-To: References: Message-ID: <45A51AA7.8010804@secnap.net> Gentoo-Wally wrote: > Hi, > > Someone asked me to describe the BleedingEdge signatures, and oddly > even though I've been using them for a log time I didn't really have a > good way to define them. I looked on the web site for a FAQ hoping for > a solid answer but I did not see a FAQ. > What would be the best way of describing the BleedingEdge signatures? > I understand that they compliment the VRT and Community sets, but are > they considered more experimental than the VRT and Community sets? At > one point I thought someone said they were kind of a proving ground > for signatures before being added to the Community set but I'm not > sure this is accurate. What is it that makes them different? > 'bleeding', as in pioneers with arrows in their backs. We use most if not all of these rules, and when we talk to clients about an event generated by one of these rules, we explain that these are 'on the bleeding edge', catch more bad guys, but are more prone to false alarms. -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com scheidell@secnap.net / 1+561-999-5000, x 1131 ---- This email has been scanned and certified safe by SpammerTrap(tm) For Information please see http://www.spammertrap.com From jonkman at bleedingthreats.net Wed Jan 10 17:34:17 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Wed Jan 10 17:35:23 2007 Subject: [Bleeding-sigs] Excluding Known IRC Nets from Shadowserver Bot C&C Rules Message-ID: <45A52399.5080809@bleedingthreats.net> The shadowserver.org lists of C&C servers occasionally contains servers from known public IRC nets like Freenode, undernet, etc. These are real bot channels, and they get cleaned up, but we don't want to necessarily block other legit traffic to these nets. I've added an exclusion for known Undernet and Freenode servers. The list will be maintained at http://www.bleedingthreats.net/rules/bleeding-botcc.excluded If you find others that are legitimate public IRC servers in the block list, please let us know at bleeding@bleedingthreats.net. We'll verify it and add to the list if appropriate. Matt -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Wed Jan 10 17:56:58 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Wed Jan 10 17:57:58 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A51AA7.8010804@secnap.net> References: <45A51AA7.8010804@secnap.net> Message-ID: <45A528EA.8000203@bleedingthreats.net> Good question, and that's a good start for a definition Michael. We've evolved past being just a testing ground, since the relationship with sourcefire never got to the point where we could move mature sigs out of our rulesets into theirs. Then the licensing changed to make that a legal impossibility. THEN.. it changed again so that you can't use VRT for at least 30 days, and have to pay for it regardless. Whats next with VRT I don't know. But regardless Sourcefire is not putting much into the community rulesets, they've no motivation to do so. They maintain an excellent ruleset, but it's NOT open source. It's for customers of Sourcefire only. So now we at Bleeding Edge are a full blown rules source, and intend to complement the old GPL rules and go from there. We can't say we have full coverage from that point on, nor do we have the resources the VRT guys do. But everything we do is free. A major issue that I think much of the community has forgotten with the VRT changes is that what we as the community come up with CANNOT be put into the VRT set. Licensing prohibits that, and it'd be too risky for Sourcefire to do so. So we are the only option to publish your rules where the community can benefit from and improve upon them, while remaining free for all to use. So, I'd describe us as the ONLY source of free and community contributed and maintained rules. We do have a lot of new and experimental signatures, as well as many niche rulesets specific to specific networks and industries. Overall, all of the rules are mature and stable, and built with performance in mind. We can go places that VRT can't or prefer's not to (i.e. sigs to catch classified material, bots, blocklists, etc) because we don't have an 'average' customer we're tailoring to. We cater to everybody, you need to choose which sigs apply to you. We move quickly, and we depend on the community. But we're not an unstable ruleset, or one for testing as we started out being. We're stable, we're mature, and we're here to stay! All thanks to the community. :) Matt Michael Scheidell wrote: > Gentoo-Wally wrote: >> Hi, >> >> Someone asked me to describe the BleedingEdge signatures, and oddly >> even though I've been using them for a log time I didn't really have a >> good way to define them. I looked on the web site for a FAQ hoping for >> a solid answer but I did not see a FAQ. >> What would be the best way of describing the BleedingEdge signatures? >> I understand that they compliment the VRT and Community sets, but are >> they considered more experimental than the VRT and Community sets? At >> one point I thought someone said they were kind of a proving ground >> for signatures before being added to the Community set but I'm not >> sure this is accurate. What is it that makes them different? >> > > 'bleeding', as in pioneers with arrows in their backs. > > We use most if not all of these rules, and when we talk to clients about > an event generated by one of these rules, we explain that these are 'on > the bleeding edge', catch more bad guys, but are more prone to false alarms. > > -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Wed Jan 10 18:00:07 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Wed Jan 10 18:01:52 2007 Subject: [Bleeding-sigs] definition In-Reply-To: References: Message-ID: <45A529A7.5060900@bleedingthreats.net> A FAQ is a good idea as well.... I'll put something out there. :) Matt Gentoo-Wally wrote: > Hi, > > Someone asked me to describe the BleedingEdge signatures, and oddly > even though I've been using them for a log time I didn't really have a > good way to define them. I looked on the web site for a FAQ hoping for > a solid answer but I did not see a FAQ. > What would be the best way of describing the BleedingEdge signatures? > I understand that they compliment the VRT and Community sets, but are > they considered more experimental than the VRT and Community sets? At > one point I thought someone said they were kind of a proving ground > for signatures before being added to the Community set but I'm not > sure this is accurate. What is it that makes them different? > > Wally > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Wed Jan 10 18:47:38 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Wed Jan 10 18:48:36 2007 Subject: [Bleeding-sigs] VML Sig Updates Message-ID: <45A534CA.1060104@bleedingthreats.net> # Submitted 2006-09-19 by Chris Harrington, updated 1/10/07 by Christian Siefert alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BLEEDING-EDGE EXPLOIT Possible MSIE VML Exploit"; flow:established,from_server; content:"xmlns"; nocase; content:"schemas-microsoft-com"; nocase; distance:0; content:"vml"; nocase; distance:0; pcre:"/\x3chtml\s*xmlns\x3a[\d\w]+\s*=\s*\x22\s*urn\x3aschemas-microsoft-com\x3avm l\s*\x22\s*\x3e/i"; reference:url,osvdb.org/31250; reference:bugtraq,21930; reference:cve,2007-0024; reference:url,sunbeltblog.blogspot.com/2006/09/seen-in-wild-zero-day-exploit-being.html; reference:cve,2006-4868; classtype:misc-attack; sid:2003106; rev:3;) Added a pcre and references from Christian. Also added the leading content matches to make this performance reasonable. Please sanity check me, but it appears good. Matt -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From bleeding at bleedingthreats.net Wed Jan 10 20:00:04 2007 From: bleeding at bleedingthreats.net (bleeding@bleedingthreats.net) Date: Wed Jan 10 20:00:05 2007 Subject: [Bleeding-sigs] Bleeding Edge Threats Daily Signature Changes Message-ID: <20070110200004.3320722C09C@sb03.us.bleedingsnort.com> [***] Results from Oinkmaster started Wed Jan 10 20:00:04 2007 [***] [+++] Added rules: [+++] 2400001 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400002 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400003 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2400004 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2401001 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401002 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401003 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2401004 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) [///] Modified active rules: [///] 2003106 - BLEEDING-EDGE EXPLOIT Possible MSIE VML Exploit (bleeding-exploit.rules) 2003208 - BLEEDING-EDGE TROJAN pBot (PHP bot) Commands (bleeding-virus.rules) 2400000 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound (bleeding-drop.rules) 2401000 - BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE (bleeding-drop-BLOCK.rules) 2402000 - BLEEDING-EDGE DROP Dshield Block Listed Source (bleeding-dshield.rules) 2403000 - BLEEDING-EDGE DROP Dshield Block Listed Source - BLOCKING (bleeding-dshield-BLOCK.rules) 2404000 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 1) (bleeding-botcc.rules) 2404001 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 2) (bleeding-botcc.rules) 2404002 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 3) (bleeding-botcc.rules) 2404003 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 4) (bleeding-botcc.rules) 2404004 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 5) (bleeding-botcc.rules) 2404005 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 6) (bleeding-botcc.rules) 2404006 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 7) (bleeding-botcc.rules) 2404007 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 8) (bleeding-botcc.rules) 2404008 - BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 9) (bleeding-botcc.rules) 2405000 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 1) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405001 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 2) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405002 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 3) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405003 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 4) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405004 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 5) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405005 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 6) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405006 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 7) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405007 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 8) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) 2405008 - BLEEDING-EDGE DROP Known Bot C&C Traffic (group 9) - BLOCKING SOURCE (bleeding-botcc-BLOCK.rules) [+++] Added non-rule lines: [+++] -> Added to bleeding-drop-BLOCK.rules (1): # VERSION 51 -> Added to bleeding-drop.rules (1): # VERSION 51 -> Added to bleeding-exploit.rules (1): # Submitted 2006-09-19 by Chris Harrington, updated 1/10/07 by Christian Siefert -> Added to bleeding-sid-msg.map (9): 2003106 || BLEEDING-EDGE EXPLOIT Possible MSIE VML Exploit || cve,2006-4868 || url,sunbeltblog.blogspot.com/2006/09/seen-in-wild-zero-day-exploit-being.html || cve,2007-0024 || bugtraq,21930 || url,osvdb.org/31250 2400001 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound || url,www.spamhaus.org/drop/drop.lasso 2400002 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound || url,www.spamhaus.org/drop/drop.lasso 2400003 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound || url,www.spamhaus.org/drop/drop.lasso 2400004 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound || url,www.spamhaus.org/drop/drop.lasso 2401001 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE || url,www.spamhaus.org/drop/drop.lasso 2401002 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE || url,www.spamhaus.org/drop/drop.lasso 2401003 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE || url,www.spamhaus.org/drop/drop.lasso 2401004 || BLEEDING-EDGE DROP Spamhaus DROP Listed Traffic Inbound - BLOCKING SOURCE || url,www.spamhaus.org/drop/drop.lasso [---] Removed non-rule lines: [---] -> Removed from bleeding-drop-BLOCK.rules (1): # VERSION 49 -> Removed from bleeding-drop.rules (1): # VERSION 49 -> Removed from bleeding-exploit.rules (1): # Submitted 2006-09-19 by Chris Harrington -> Removed from bleeding-sid-msg.map (1): 2003106 || BLEEDING-EDGE EXPLOIT Possible MSIE VML Exploit || cve,2006-4868 || url,sunbeltblog.blogspot.com/2006/09/seen-in-wild-zero-day-exploit-being.html From gentoowally at gmail.com Wed Jan 10 21:30:26 2007 From: gentoowally at gmail.com (Gentoo-Wally) Date: Wed Jan 10 21:31:34 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A528EA.8000203@bleedingthreats.net> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> Message-ID: I would have to agree that the changes (again) to SF's license is annoying. A 7 day wait, for unpaid subscriptions, is risky... a 30 day wait is IMO unacceptable. 30 days, from an IDS perspective, is a long time to have to wait for signatures. Quite frankly this is beginning to worry me. I was surprised that more people did not publicly complain about this change. My fear is that this could be a first step in the direction that Tenable made with Nessus and that would truly be a sad day in the world of IDS. However, there is still the Community set which is free and available without a wait, so unless I'm missing something I'm not sure that it is accurate to say that... "... we are the only option to publish your rules where the community can benefit from and improve upon them, while remaining free for all to use." "...I'd describe us as the ONLY source of free and community contributed and maintained rules." Isn't this what the Community set is for? The lack of activity with the community set shouldn't be blamed on the VRT team. If the community wants rules they should write them. I could understand the need for a place for the community to come for a place to exchange and improve on experimental rules, but why 2 community driven sets? I guess my concern is weather it is wise to create a second community driven signature set that is more or less in competition with each other. What prevents this from becoming a haven for duplicate signatures? If 2 different people post similar rules and one submits them to SF and one submits them here who is going to be the one to drop the rule from their set? With there being 11k+ rules in the combination of VRT/Community/Bleeding there should be some kind of agreements surrounding SIDs and duplicate rules. I was hoping this would come from http://ossrc.snort.org/ but it does not look like anything happened with this. Don't get me wrong I definitely support the bleedingedge set and use a lot of rules from it and have contributed to it. I would just hate to see two community driven sets get into a territorial pi$$ing match that ultimately results in degraded performance when using both signature sets. And what about the VRT set? Since it is now a 30 day wait will we include sigs that already exist in the VRT set in the BE set? Duplicate rules might not sound like a big problem now since the BE set is still new (compared to the community set) but what about 3 years from now? I guess the question is what procedures are in place to keep too many cooks from spoiling the soup? Wally On 1/10/07, Matt Jonkman wrote: > Good question, and that's a good start for a definition Michael. > > We've evolved past being just a testing ground, since the relationship > with sourcefire never got to the point where we could move mature sigs > out of our rulesets into theirs. Then the licensing changed to make that > a legal impossibility. THEN.. it changed again so that you can't use VRT > for at least 30 days, and have to pay for it regardless. > > Whats next with VRT I don't know. But regardless Sourcefire is not > putting much into the community rulesets, they've no motivation to do > so. They maintain an excellent ruleset, but it's NOT open source. It's > for customers of Sourcefire only. > > So now we at Bleeding Edge are a full blown rules source, and intend to > complement the old GPL rules and go from there. We can't say we have > full coverage from that point on, nor do we have the resources the VRT > guys do. But everything we do is free. > > A major issue that I think much of the community has forgotten with the > VRT changes is that what we as the community come up with CANNOT be put > into the VRT set. Licensing prohibits that, and it'd be too risky for > Sourcefire to do so. So we are the only option to publish your rules > where the community can benefit from and improve upon them, while > remaining free for all to use. > > So, I'd describe us as the ONLY source of free and community contributed > and maintained rules. We do have a lot of new and experimental > signatures, as well as many niche rulesets specific to specific networks > and industries. Overall, all of the rules are mature and stable, and > built with performance in mind. We can go places that VRT can't or > prefer's not to (i.e. sigs to catch classified material, bots, > blocklists, etc) because we don't have an 'average' customer we're > tailoring to. We cater to everybody, you need to choose which sigs apply > to you. > > We move quickly, and we depend on the community. But we're not an > unstable ruleset, or one for testing as we started out being. We're > stable, we're mature, and we're here to stay! All thanks to the > community. :) > > Matt > > Michael Scheidell wrote: > > Gentoo-Wally wrote: > >> Hi, > >> > >> Someone asked me to describe the BleedingEdge signatures, and oddly > >> even though I've been using them for a log time I didn't really have a > >> good way to define them. I looked on the web site for a FAQ hoping for > >> a solid answer but I did not see a FAQ. > >> What would be the best way of describing the BleedingEdge signatures? > >> I understand that they compliment the VRT and Community sets, but are > >> they considered more experimental than the VRT and Community sets? At > >> one point I thought someone said they were kind of a proving ground > >> for signatures before being added to the Community set but I'm not > >> sure this is accurate. What is it that makes them different? > >> > > > > 'bleeding', as in pioneers with arrows in their backs. > > > > We use most if not all of these rules, and when we talk to clients about > > an event generated by one of these rules, we explain that these are 'on > > the bleeding edge', catch more bad guys, but are more prone to false alarms. > > > > > > -- > -------------------------------------------- > Matthew Jonkman > Bleeding Edge Threats > 765-429-0398 > 765-807-3060 fax > http://www.bleedingthreats.net > -------------------------------------------- > > PGP: http://www.bleedingthreats.com/mattjonkman.asc > > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > From frank at knobbe.us Wed Jan 10 22:08:33 2007 From: frank at knobbe.us (Frank Knobbe) Date: Wed Jan 10 22:10:18 2007 Subject: [Bleeding-sigs] definition In-Reply-To: References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> Message-ID: <1168466913.30464.50.camel@localhost> On Wed, 2007-01-10 at 16:30 -0500, Gentoo-Wally wrote: > "...I'd describe us as the ONLY source of free and community > contributed and maintained rules." I think the emphasis is on maintained. We routinely go back and review existing rules and make them better. That doesn't seem to be happening to the Community rules. Folks contribute rules and *may* on occasion correct one, but there no diligent effort behind it. You'll find that Bleeding rules have far less false positives than Community rules, are developed quicker to current threats than Community rules, and get frequent reviews to further improve them which doesn't happen to the Community rules. Mainly because there are no "stewards" who maintain them. At Bleeding, we're a group of folks that continually improve things. While other contribute sigs, we improve them since we feel that's out duty as rule caretakers. > Don't get me wrong I definitely support the bleedingedge set and use a > lot of rules from it and have contributed to it. I would just hate to > see two community driven sets get into a territorial pi$$ing match > that ultimately results in degraded performance when using both > signature sets. No pissing contest. Mainly because no one forces you to use one or the other. Rules are available to you. Which rules you use (not rule sets, but individual rules) is up to you. I think some older Bleeding rules are a bit flaky, and have those disabled in my rule set. (I think we went back and fixed several of those old Bleeding sigs). However, I have far more Community rules disabled since...well... they just don't cut it for me. No contest. Use those rules that you like. > And what about the VRT set? Since it is now a 30 day wait will we > include sigs that already exist in the VRT set in the BE set? You don't have to. > Duplicate rules might not sound like a big problem now since the BE > set is still new (compared to the community set) but what about 3 > years from now? Again, no issue. You pick which rules you prefer. > I guess the question is what procedures are in place to keep too many > cooks from spoiling the soup? No spoilage. We cook our Bleeding sigs. You are free to use them or not. You don't have to decide between one or the other. Note that you should always review rules instead of blindly including them in your rule sets, regardless if these are VRT, Bleeding or Community rules. Hope that adds some insight. Cheers, Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.bleedingthreats.net/pipermail/bleeding-sigs/attachments/20070110/9b7eaea0/attachment.pgp From frank at knobbe.us Wed Jan 10 22:10:34 2007 From: frank at knobbe.us (Frank Knobbe) Date: Wed Jan 10 22:14:47 2007 Subject: [Bleeding-sigs] Excluding Known IRC Nets from Shadowserver Bot C&C Rules In-Reply-To: <45A52399.5080809@bleedingthreats.net> References: <45A52399.5080809@bleedingthreats.net> Message-ID: <1168467034.30464.53.camel@localhost> On Wed, 2007-01-10 at 12:34 -0500, Matt Jonkman wrote: > I've added an exclusion for known Undernet and Freenode servers. The > list will be maintained at > http://www.bleedingthreats.net/rules/bleeding-botcc.excluded I think DALnet hosts get frequently listed as well. It might be a good idea to either do a reverse name lookup, or an IRC server name check with a small script. Have a script use netcat to harvest the banner, then grep. Or your Perl-fu, or whatever you do your mad ninja scripting in. Cheers, Frank -- It is said that the Internet is a public utility. As such, it is best compared to a sewer. A big, fat pipe with a bunch of crap sloshing against your ports. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.bleedingthreats.net/pipermail/bleeding-sigs/attachments/20070110/fb60f7b4/attachment.pgp From jonkman at bleedingthreats.net Wed Jan 10 23:28:03 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Wed Jan 10 23:29:08 2007 Subject: [Bleeding-sigs] Excluding Known IRC Nets from Shadowserver Bot C&C Rules In-Reply-To: <1168467034.30464.53.camel@localhost> References: <45A52399.5080809@bleedingthreats.net> <1168467034.30464.53.camel@localhost> Message-ID: <45A57683.7040407@bleedingthreats.net> I'm fearful of auto-listing anything. I much prefer human review. It'd be easy for an attacker that owns his IP space to modify his reverse dns or something, or poison a dns cache... The number and frequency of change should be pretty low. Once we get over the initial hump that is... Any others that need adding? Matt Frank Knobbe wrote: > On Wed, 2007-01-10 at 12:34 -0500, Matt Jonkman wrote: >> I've added an exclusion for known Undernet and Freenode servers. The >> list will be maintained at >> http://www.bleedingthreats.net/rules/bleeding-botcc.excluded > > I think DALnet hosts get frequently listed as well. It might be a good > idea to either do a reverse name lookup, or an IRC server name check > with a small script. Have a script use netcat to harvest the banner, > then grep. Or your Perl-fu, or whatever you do your mad ninja scripting > in. > > Cheers, > Frank > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Wed Jan 10 23:52:08 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Wed Jan 10 23:53:15 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <1168466913.30464.50.camel@localhost> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> Message-ID: <45A57C28.8070904@bleedingthreats.net> Well put Frank. No one intends there to be a pissing contest between rulesets. VRT has gone commercial. They invest a great deal of cash to make it a very high quality ruleset. They should make something off of that. OSSRC was an attempt to build some cooperation, and I hope it does that one day. But since Jennifer Steffens left sourcefire nothing has happened despite some (minimal) effort on both sides of the fence. The major issue there came from the implied intention to avoid rule conflicts, but the obligation of the VRT team to not use open sigs, thus requiring them to write all of their own to distribute to clients. There's just not any space for the rulesets to coexist on a legal and licensing level. It's not for big egos or hatred or personal conflicts. They have to provide full coverage to their subscribers, they can't distribute our rules under their license. Sourcefire has to make money, bleeding edge doesn't. Frank put it well... there are many sources of rules. You have to choose those that work and are in the realm of accuracy that works for you. If you've got 20 IDS analysts on staff you can afford some falses. If you've got a half a full time slot, then you need to be more cautious. :) If you're writing rules or have new ideas, you'll get more traction, faster response, and probably more feedback if you submit them to bleeding rather than somewhere else. Plus you'll retain creative 'control' of that sig as we do our best to run future tweaks by the original authors. As to franks comment about some of our older sigs... yup. There's a bit of crap in there. :) Please point them out to us and we'll put the time into tweaking or removing them. We do on a semi-regular basis try to get through older sigs and kill the obsolete or bad ones. more of that will happen these days as I have much more free time to devote to the project. Bottom line: We appreciate the VRT guys, we get a lot of very good technical advice from them, they're the best in the business. But we all need to remember that they're writing sigs for their paying clients, not the open community. If you want to submit rules to and use a completely open source ruleset, I recommend looking here for the long term. But neither ruleset is complete without the other. Matt Bleeding edge is all community. Most of the time I spend on it is Frank Knobbe wrote: > On Wed, 2007-01-10 at 16:30 -0500, Gentoo-Wally wrote: >> "...I'd describe us as the ONLY source of free and community >> contributed and maintained rules." > > I think the emphasis is on maintained. We routinely go back and review > existing rules and make them better. That doesn't seem to be happening > to the Community rules. Folks contribute rules and *may* on occasion > correct one, but there no diligent effort behind it. You'll find that > Bleeding rules have far less false positives than Community rules, are > developed quicker to current threats than Community rules, and get > frequent reviews to further improve them which doesn't happen to the > Community rules. Mainly because there are no "stewards" who maintain > them. At Bleeding, we're a group of folks that continually improve > things. While other contribute sigs, we improve them since we feel > that's out duty as rule caretakers. > >> Don't get me wrong I definitely support the bleedingedge set and use a >> lot of rules from it and have contributed to it. I would just hate to >> see two community driven sets get into a territorial pi$$ing match >> that ultimately results in degraded performance when using both >> signature sets. > > No pissing contest. Mainly because no one forces you to use one or the > other. Rules are available to you. Which rules you use (not rule sets, > but individual rules) is up to you. > > I think some older Bleeding rules are a bit flaky, and have those > disabled in my rule set. (I think we went back and fixed several of > those old Bleeding sigs). However, I have far more Community rules > disabled since...well... they just don't cut it for me. > > No contest. Use those rules that you like. > >> And what about the VRT set? Since it is now a 30 day wait will we >> include sigs that already exist in the VRT set in the BE set? > > You don't have to. > >> Duplicate rules might not sound like a big problem now since the BE >> set is still new (compared to the community set) but what about 3 >> years from now? > > Again, no issue. You pick which rules you prefer. > >> I guess the question is what procedures are in place to keep too many >> cooks from spoiling the soup? > > No spoilage. We cook our Bleeding sigs. You are free to use them or not. > You don't have to decide between one or the other. > > Note that you should always review rules instead of blindly including > them in your rule sets, regardless if these are VRT, Bleeding or > Community rules. > > Hope that adds some insight. > > Cheers, > Frank > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Thu Jan 11 00:03:39 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Thu Jan 11 00:04:43 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A57C28.8070904@bleedingthreats.net> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> Message-ID: <45A57EDB.40102@bleedingthreats.net> Putting what Frank and I think aside, what do you all think of Bleeding Edge's place in the grand scheme of things? What place do these rules hold in your defense posture? More importantly, what do you expect or want from us as we continue to mature? Matt -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From david_glosser at yahoo.com Thu Jan 11 01:26:29 2007 From: david_glosser at yahoo.com (David Glosser) Date: Thu Jan 11 01:27:44 2007 Subject: [Bleeding-sigs] definition Message-ID: <20070111012629.14659.qmail@web52404.mail.yahoo.com> I think the name change says a lot.. Bleeding Edge Threats... Not just snort sigs, but the other projects: the user-agent project, spyware listening post, snort and oinkmaster sample config files, BlackHole DNS for spyware, etc. And I'm not just saying this because I suck at writing snort sigs ;) ----- Original Message ---- From: Matt Jonkman To: Bleeding Sigs Sent: Wednesday, January 10, 2007 7:03:39 PM Subject: Re: [Bleeding-sigs] definition Putting what Frank and I think aside, what do you all think of Bleeding Edge's place in the grand scheme of things? What place do these rules hold in your defense posture? More importantly, what do you expect or want from us as we continue to mature? Matt -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc _______________________________________________ Bleeding-sigs mailing list Bleeding-sigs@bleedingthreats.net http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs From andre.ludwig at gmail.com Thu Jan 11 02:44:15 2007 From: andre.ludwig at gmail.com (Andre Ludwig) Date: Thu Jan 11 02:45:14 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A57C28.8070904@bleedingthreats.net> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> Message-ID: <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> but the obligation of the VRT team to not use open sigs, thus > requiring them to write all of their own to distribute to clients. You should see their PDF signature... haha reminds me of my own ;) (they used |23| instead of # for the content match.. haha) I have since decided to try and write as many variations of the same signature as possible as quickly as possible so we can include all possible permutations of a sig (even if they are disabled). That way we make them reach for a god sig ;) haha im such a dick.. Dre From andre.ludwig at gmail.com Thu Jan 11 02:47:53 2007 From: andre.ludwig at gmail.com (Andre Ludwig) Date: Thu Jan 11 02:49:18 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> Message-ID: <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> For the record if you missed the ;) Im joking!!! but it does bring up a possible important point/vulnerability in their system. If someone was to submit a bunch of variations of signatures would VRT be up shits creek? They cant exactly copy sigs from what i understand. So there you have it folks.. simply create every possible permutation (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if your a real bastard leave only the really expensive pcre expressions as options. /ranty joke Dre On 1/10/07, Andre Ludwig wrote: > but the obligation of the VRT team to not use open sigs, thus > > requiring them to write all of their own to distribute to clients. > > > > You should see their PDF signature... > > haha reminds me of my own ;) > > (they used |23| instead of # for the content match.. haha) > > I have since decided to try and write as many variations of the same > signature as possible as quickly as possible so we can include all > possible permutations of a sig (even if they are disabled). That way > we make them reach for a god sig ;) > > haha im such a dick.. > > Dre > From jonkman at bleedingthreats.net Thu Jan 11 02:58:43 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Thu Jan 11 02:59:42 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> Message-ID: <45A5A7E3.9030703@bleedingthreats.net> I love the joke. And since you brought it up, you are a dick Andre. :) But you write good sigs, so we'll overlook that character flaw. When it comes to who made what sig first, if there ever were litigation as I understand it each side would just have to be able to show they came to the same conclusion independently. Pretty easy to show really, unless you have an email saying "no, lets just use their sig". :) Matt Andre Ludwig wrote: > For the record if you missed the ;) > > Im joking!!! but it does bring up a possible important > point/vulnerability in their system. If someone was to submit a bunch > of variations of signatures would VRT be up shits creek? They cant > exactly copy sigs from what i understand. > > So there you have it folks.. simply create every possible permutation > (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if > your a real bastard leave only the really expensive pcre expressions > as options. > > /ranty joke > > Dre > > On 1/10/07, Andre Ludwig wrote: >> but the obligation of the VRT team to not use open sigs, thus >> > requiring them to write all of their own to distribute to clients. >> >> >> >> You should see their PDF signature... >> >> haha reminds me of my own ;) >> >> (they used |23| instead of # for the content match.. haha) >> >> I have since decided to try and write as many variations of the same >> signature as possible as quickly as possible so we can include all >> possible permutations of a sig (even if they are disabled). That way >> we make them reach for a god sig ;) >> >> haha im such a dick.. >> >> Dre >> > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From andre.ludwig at gmail.com Thu Jan 11 03:13:50 2007 From: andre.ludwig at gmail.com (Andre Ludwig) Date: Thu Jan 11 03:14:44 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A5A7E3.9030703@bleedingthreats.net> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> Message-ID: <9d03f28f0701101913g7b6a7abaw1ab440018096b5eb@mail.gmail.com> Damn you and your legalspeak!!!! Given the amount of SF employees that are surfing these lists im sure it would be hard for them to deny they didnt have any knowledge. Lets face it.. I dont think anyone would/could execute such an attack and then be a big nuff cockbanger to try and sue (and win).. Just the sheer amount of signatures that would have to be created would be a PITA. But damn funny when you think about it.. Dre On 1/10/07, Matt Jonkman wrote: > I love the joke. And since you brought it up, you are a dick Andre. :) > But you write good sigs, so we'll overlook that character flaw. > > When it comes to who made what sig first, if there ever were litigation > as I understand it each side would just have to be able to show they > came to the same conclusion independently. Pretty easy to show really, > unless you have an email saying "no, lets just use their sig". :) > > Matt > > Andre Ludwig wrote: > > For the record if you missed the ;) > > > > Im joking!!! but it does bring up a possible important > > point/vulnerability in their system. If someone was to submit a bunch > > of variations of signatures would VRT be up shits creek? They cant > > exactly copy sigs from what i understand. > > > > So there you have it folks.. simply create every possible permutation > > (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if > > your a real bastard leave only the really expensive pcre expressions > > as options. > > > > /ranty joke > > > > Dre > > > > On 1/10/07, Andre Ludwig wrote: > >> but the obligation of the VRT team to not use open sigs, thus > >> > requiring them to write all of their own to distribute to clients. > >> > >> > >> > >> You should see their PDF signature... > >> > >> haha reminds me of my own ;) > >> > >> (they used |23| instead of # for the content match.. haha) > >> > >> I have since decided to try and write as many variations of the same > >> signature as possible as quickly as possible so we can include all > >> possible permutations of a sig (even if they are disabled). That way > >> we make them reach for a god sig ;) > >> > >> haha im such a dick.. > >> > >> Dre > >> > > _______________________________________________ > > Bleeding-sigs mailing list > > Bleeding-sigs@bleedingthreats.net > > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > > -- > -------------------------------------------- > Matthew Jonkman > Bleeding Edge Threats > 765-429-0398 > 765-807-3060 fax > http://www.bleedingthreats.net > -------------------------------------------- > > PGP: http://www.bleedingthreats.com/mattjonkman.asc > > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > From security at brvenik.com Thu Jan 11 03:38:35 2007 From: security at brvenik.com (Jason) Date: Thu Jan 11 03:39:39 2007 Subject: [Bleeding-sigs] definition In-Reply-To: References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> Message-ID: <45A5B13B.2080101@brvenik.com> Gentoo-Wally wrote: > I would have to agree that the changes (again) to SF's license is > annoying. A 7 day wait, for unpaid subscriptions, is risky... a 30 day > wait is IMO unacceptable. 30 days, from an IDS perspective, is a long > time to have to wait for signatures. Quite frankly this is beginning > to worry me. I was surprised that more people did not publicly > complain about this change. My fear is that this could be a first step > in the direction that Tenable made with Nessus and that would truly be > a sad day in the world of IDS. I think Marty says it best. http://securitysauce.blogspot.com/2006/08/kawasaki-interviews-mysql-ceo.html [snip many good observations and questions] From pepperjack at doctorunix.com Thu Jan 11 05:48:08 2007 From: pepperjack at doctorunix.com (Jack Pepper) Date: Thu Jan 11 05:59:22 2007 Subject: [Bleeding-sigs] rule morphing (was: definition) In-Reply-To: <45A5A7E3.9030703@bleedingthreats.net> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> Message-ID: <20070110234808.ac0wixmlgkg8gg4o@192.168.168.10> >> ... it does bring up a possible important >> point/vulnerability in their system. If someone was to submit a bunch >> of variations of signatures would VRT be up shits creek? They cant >> exactly copy sigs from what i understand. >> >> So there you have it folks.. simply create every possible permutation >> (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if >> your a real bastard leave only the really expensive pcre expressions >> as options. attached is a program that randomly converts characters inside the pcre statement to their hex equivalents. It has lots of bugs and I haven't testied that the rules still work, but hey, it's a start. Maybe tomorrow I'll have it tweak out the Content statements. Just for fun you understand. jp ------------------------------------------------- Email solutions, MS Exchange alternatives and extrication, security services, systems integration. Contact: services@doctorunix.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rulemorpher.tgz Type: application/x-compressed-tar Size: 35915 bytes Desc: not available Url : http://lists.bleedingthreats.net/pipermail/bleeding-sigs/attachments/20070110/d7872928/rulemorpher-0001.bin From jonkman at bleedingthreats.net Thu Jan 11 13:30:37 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Thu Jan 11 13:31:36 2007 Subject: [Bleeding-sigs] rule morphing In-Reply-To: <20070110234808.ac0wixmlgkg8gg4o@192.168.168.10> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> <20070110234808.ac0wixmlgkg8gg4o@192.168.168.10> Message-ID: <45A63BFD.8040300@bleedingthreats.net> You might have a bit too much time on your hands Jack. :) Matt Jack Pepper wrote: > >>> ... it does bring up a possible important >>> point/vulnerability in their system. If someone was to submit a bunch >>> of variations of signatures would VRT be up shits creek? They cant >>> exactly copy sigs from what i understand. >>> >>> So there you have it folks.. simply create every possible permutation >>> (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if >>> your a real bastard leave only the really expensive pcre expressions >>> as options. > > attached is a program that randomly converts characters inside the pcre > statement to their hex equivalents. It has lots of bugs and I haven't > testied that the rules still work, but hey, it's a start. > > Maybe tomorrow I'll have it tweak out the Content statements. Just for > fun you understand. > > jp > > ------------------------------------------------- > Email solutions, MS Exchange alternatives and extrication, > security services, systems integration. > Contact: services@doctorunix.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From gentoowally at gmail.com Thu Jan 11 15:04:35 2007 From: gentoowally at gmail.com (Gentoo-Wally) Date: Thu Jan 11 15:05:42 2007 Subject: [Bleeding-sigs] rule morphing (was: definition) In-Reply-To: <20070110234808.ac0wixmlgkg8gg4o@192.168.168.10> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> <20070110234808.ac0wixmlgkg8gg4o@192.168.168.10> Message-ID: God I hope I have not spawned a corporate war! hehe This brings a good question.... Does a sig with a hex content perform faster or more efficient than one with a plain text content string? Wally On 1/11/07, Jack Pepper wrote: > > >> ... it does bring up a possible important > >> point/vulnerability in their system. If someone was to submit a bunch > >> of variations of signatures would VRT be up shits creek? They cant > >> exactly copy sigs from what i understand. > >> > >> So there you have it folks.. simply create every possible permutation > >> (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if > >> your a real bastard leave only the really expensive pcre expressions > >> as options. > > attached is a program that randomly converts characters inside the > pcre statement to their hex equivalents. It has lots of bugs and I > haven't testied that the rules still work, but hey, it's a start. > > Maybe tomorrow I'll have it tweak out the Content statements. Just > for fun you understand. > > jp > > ------------------------------------------------- > Email solutions, MS Exchange alternatives and extrication, > security services, systems integration. > Contact: services@doctorunix.com > > > > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > > > > From security at brvenik.com Thu Jan 11 15:22:31 2007 From: security at brvenik.com (Jason) Date: Thu Jan 11 15:23:53 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <9d03f28f0701101913g7b6a7abaw1ab440018096b5eb@mail.gmail.com> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> <9d03f28f0701101913g7b6a7abaw1ab440018096b5eb@mail.gmail.com> Message-ID: <45A65637.8030603@brvenik.com> Maybe in that process someone will come up with a sig up front that catches the variations I pointed out here. I took my personal time on the weekend to assist bleeding with the effort and even honored your request to take it off list. I'm happy to become fully involved using my Sourcefire address if people are not willing to accept and acknowledge that we have always been and always will be part of the community regardless of where we post from. I've not looked at the VRT time lines but I can assure you they were thinking about it well before I got around to asking the question or posting samples for this list. If anyone in the bleeding community wants to try to come up with better detection I will post the samples again ( as if it is really needed ) HAHA im... People that live in stone houses shouldn't throw glass :P I'm quite annoyed by the positioning that goes on here. Sourcefire has always been and continues to be very supportive of the community and open source in general. Without Sourcefire Snort would not have the advances it has today and without Snort Sourcefire would not be where it is today. I think there is a very balanced relationship between Corporate viability and Community interest. The latest VRT changes are a example of this. The licensing was changed to make the rules more accessible to end users and more representative of the value they bring to the enterprise. Andre Ludwig wrote: > Damn you and your legalspeak!!!! > > Given the amount of SF employees that are surfing these lists im sure > it would be hard for them to deny they didnt have any knowledge. > > Lets face it.. I dont think anyone would/could execute such an attack > and then be a big nuff cockbanger to try and sue (and win).. Just the > sheer amount of signatures that would have to be created would be a > PITA. > > But damn funny when you think about it.. > > Dre > > On 1/10/07, Matt Jonkman wrote: >> I love the joke. And since you brought it up, you are a dick Andre. :) >> But you write good sigs, so we'll overlook that character flaw. >> >> When it comes to who made what sig first, if there ever were litigation >> as I understand it each side would just have to be able to show they >> came to the same conclusion independently. Pretty easy to show really, >> unless you have an email saying "no, lets just use their sig". :) >> >> Matt >> >> Andre Ludwig wrote: >> > For the record if you missed the ;) >> > >> > Im joking!!! but it does bring up a possible important >> > point/vulnerability in their system. If someone was to submit a bunch >> > of variations of signatures would VRT be up shits creek? They cant >> > exactly copy sigs from what i understand. >> > >> > So there you have it folks.. simply create every possible permutation >> > (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if >> > your a real bastard leave only the really expensive pcre expressions >> > as options. >> > >> > /ranty joke >> > >> > Dre >> > >> > On 1/10/07, Andre Ludwig wrote: >> >> but the obligation of the VRT team to not use open sigs, thus >> >> > requiring them to write all of their own to distribute to clients. >> >> >> >> >> >> >> >> You should see their PDF signature... >> >> >> >> haha reminds me of my own ;) >> >> >> >> (they used |23| instead of # for the content match.. haha) >> >> >> >> I have since decided to try and write as many variations of the same >> >> signature as possible as quickly as possible so we can include all >> >> possible permutations of a sig (even if they are disabled). That way >> >> we make them reach for a god sig ;) >> >> >> >> haha im such a dick.. >> >> >> >> Dre >> >> >> > _______________________________________________ >> > Bleeding-sigs mailing list >> > Bleeding-sigs@bleedingthreats.net >> > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >> >> -- >> -------------------------------------------- >> Matthew Jonkman >> Bleeding Edge Threats >> 765-429-0398 >> 765-807-3060 fax >> http://www.bleedingthreats.net >> -------------------------------------------- >> >> PGP: http://www.bleedingthreats.com/mattjonkman.asc >> >> >> _______________________________________________ >> Bleeding-sigs mailing list >> Bleeding-sigs@bleedingthreats.net >> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >> > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > From security at brvenik.com Thu Jan 11 15:26:02 2007 From: security at brvenik.com (Jason) Date: Thu Jan 11 15:28:09 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A528EA.8000203@bleedingthreats.net> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> Message-ID: <45A6570A.2010401@brvenik.com> Matt Jonkman wrote: > > A major issue that I think much of the community has forgotten with the > VRT changes is that what we as the community come up with CANNOT be put > into the VRT set. Licensing prohibits that, and it'd be too risky for > Sourcefire to do so. So we are the only option to publish your rules > where the community can benefit from and improve upon them, while > remaining free for all to use. > > So, I'd describe us as the ONLY source of free and community contributed > and maintained rules. We do have a lot of new and experimental > signatures, as well as many niche rulesets specific to specific networks > and industries. Overall, all of the rules are mature and stable, and > built with performance in mind. We can go places that VRT can't or > prefer's not to (i.e. sigs to catch classified material, bots, > blocklists, etc) because we don't have an 'average' customer we're > tailoring to. We cater to everybody, you need to choose which sigs apply > to you. A point of order is due. Last time I checked the BSD style license is incompatible [0] with the GPL. Snort has always been GPL, Community rules have always been GPL, when will others go GPL and become truly free? [0] - http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses From andre.ludwig at gmail.com Thu Jan 11 15:37:46 2007 From: andre.ludwig at gmail.com (Andre Ludwig) Date: Thu Jan 11 15:38:46 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A65637.8030603@brvenik.com> References: <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> <9d03f28f0701101913g7b6a7abaw1ab440018096b5eb@mail.gmail.com> <45A65637.8030603@brvenik.com> Message-ID: <9d03f28f0701110737v7b3b5d47i8f085af4548c981f@mail.gmail.com> I can vouch for jason. He not only helps out a bunch but he always has a lot to contribute (and thanks for that!). I still am curious about the legalities of publishing every possible permutation of a signature into a public signature set. Would that mean that VRT could not publish a sig (assuming every possible permutation was actually created) but it could be incorporated into the community set? Oh forgot the disclaimer.. I am not a lawyer, I don't play one on tv, I don't write a legal blog, or a even a Law and Order fan podcast. And I didn't sleep at a holiday inn last night... Dre On 1/11/07, Jason wrote: > > > Maybe in that process someone will come up with a sig up front that > catches the variations I pointed out here. I took my personal time on > the weekend to assist bleeding with the effort and even honored your > request to take it off list. I'm happy to become fully involved using my > Sourcefire address if people are not willing to accept and acknowledge > that we have always been and always will be part of the community > regardless of where we post from. > > I've not looked at the VRT time lines but I can assure you they were > thinking about it well before I got around to asking the question or > posting samples for this list. > > If anyone in the bleeding community wants to try to come up with better > detection I will post the samples again ( as if it is really needed ) > > > > > > HAHA im... > > People that live in stone houses shouldn't throw glass :P > > > > I'm quite annoyed by the positioning that goes on here. Sourcefire has > always been and continues to be very supportive of the community and > open source in general. Without Sourcefire Snort would not have the > advances it has today and without Snort Sourcefire would not be where it > is today. I think there is a very balanced relationship between > Corporate viability and Community interest. The latest VRT changes are a > example of this. The licensing was changed to make the rules more > accessible to end users and more representative of the value they bring > to the enterprise. > > Andre Ludwig wrote: > > Damn you and your legalspeak!!!! > > > > Given the amount of SF employees that are surfing these lists im sure > > it would be hard for them to deny they didnt have any knowledge. > > > > Lets face it.. I dont think anyone would/could execute such an attack > > and then be a big nuff cockbanger to try and sue (and win).. Just the > > sheer amount of signatures that would have to be created would be a > > PITA. > > > > But damn funny when you think about it.. > > > > Dre > > > > On 1/10/07, Matt Jonkman wrote: > >> I love the joke. And since you brought it up, you are a dick Andre. :) > >> But you write good sigs, so we'll overlook that character flaw. > >> > >> When it comes to who made what sig first, if there ever were litigation > >> as I understand it each side would just have to be able to show they > >> came to the same conclusion independently. Pretty easy to show really, > >> unless you have an email saying "no, lets just use their sig". :) > >> > >> Matt > >> > >> Andre Ludwig wrote: > >> > For the record if you missed the ;) > >> > > >> > Im joking!!! but it does bring up a possible important > >> > point/vulnerability in their system. If someone was to submit a bunch > >> > of variations of signatures would VRT be up shits creek? They cant > >> > exactly copy sigs from what i understand. > >> > > >> > So there you have it folks.. simply create every possible permutation > >> > (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if > >> > your a real bastard leave only the really expensive pcre expressions > >> > as options. > >> > > >> > /ranty joke > >> > > >> > Dre > >> > > >> > On 1/10/07, Andre Ludwig wrote: > >> >> but the obligation of the VRT team to not use open sigs, thus > >> >> > requiring them to write all of their own to distribute to clients. > >> >> > >> >> > >> >> > >> >> You should see their PDF signature... > >> >> > >> >> haha reminds me of my own ;) > >> >> > >> >> (they used |23| instead of # for the content match.. haha) > >> >> > >> >> I have since decided to try and write as many variations of the same > >> >> signature as possible as quickly as possible so we can include all > >> >> possible permutations of a sig (even if they are disabled). That way > >> >> we make them reach for a god sig ;) > >> >> > >> >> haha im such a dick.. > >> >> > >> >> Dre > >> >> > >> > _______________________________________________ > >> > Bleeding-sigs mailing list > >> > Bleeding-sigs@bleedingthreats.net > >> > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > >> > >> -- > >> -------------------------------------------- > >> Matthew Jonkman > >> Bleeding Edge Threats > >> 765-429-0398 > >> 765-807-3060 fax > >> http://www.bleedingthreats.net > >> -------------------------------------------- > >> > >> PGP: http://www.bleedingthreats.com/mattjonkman.asc > >> > >> > >> _______________________________________________ > >> Bleeding-sigs mailing list > >> Bleeding-sigs@bleedingthreats.net > >> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > >> > > _______________________________________________ > > Bleeding-sigs mailing list > > Bleeding-sigs@bleedingthreats.net > > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > From jonkman at bleedingthreats.net Thu Jan 11 15:48:45 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Thu Jan 11 15:49:48 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A65637.8030603@brvenik.com> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> <9d03f28f0701101913g7b6a7abaw1ab440018096b5eb@mail.gmail.com> <45A65637.8030603@brvenik.com> Message-ID: <45A65C5D.5080500@bleedingthreats.net> Jason wrote: > > > Maybe in that process someone will come up with a sig up front that > catches the variations I pointed out here. I took my personal time on > the weekend to assist bleeding with the effort and even honored your > request to take it off list. I'm happy to become fully involved using my > Sourcefire address if people are not willing to accept and acknowledge > that we have always been and always will be part of the community > regardless of where we post from. Your help is always appreciated (and I think Andre did get a pcre that covers what you mentioned, it's posted). Your help is invaluable, before you were employed by SF and since. But that's not a refkection of what sourcefire does for the community, that's what you do, and again it's very appreciated and I hope it continues. > > I've not looked at the VRT time lines but I can assure you they were > thinking about it well before I got around to asking the question or > posting samples for this list. > > If anyone in the bleeding community wants to try to come up with better > detection I will post the samples again ( as if it is really needed ) > I don't think the conversation ever came to whether what VRT does is better or worse than what the community has. As I mentioned, VRT is the best in the business. But what they produce is not free. That's the only point here. > > I'm quite annoyed by the positioning that goes on here. Sourcefire has > always been and continues to be very supportive of the community and > open source in general. Without Sourcefire Snort would not have the > advances it has today and without Snort Sourcefire would not be where it > is today. I think there is a very balanced relationship between > Corporate viability and Community interest. The latest VRT changes are a > example of this. The licensing was changed to make the rules more > accessible to end users and more representative of the value they bring > to the enterprise. I definitely agree that SF makes snort development go around. 100%. But the rules ain't free anymore, nor open. A change from a 5 day delay to 30 didn't do a thing to help the community. It just has moved them to begin to rely on us more. The conversation was about what bleeding edge has become though, it wasnt begun to put SF down, and I don't think it has done so. Matt > > Andre Ludwig wrote: >> Damn you and your legalspeak!!!! >> >> Given the amount of SF employees that are surfing these lists im sure >> it would be hard for them to deny they didnt have any knowledge. >> >> Lets face it.. I dont think anyone would/could execute such an attack >> and then be a big nuff cockbanger to try and sue (and win).. Just the >> sheer amount of signatures that would have to be created would be a >> PITA. >> >> But damn funny when you think about it.. >> >> Dre >> >> On 1/10/07, Matt Jonkman wrote: >>> I love the joke. And since you brought it up, you are a dick Andre. :) >>> But you write good sigs, so we'll overlook that character flaw. >>> >>> When it comes to who made what sig first, if there ever were litigation >>> as I understand it each side would just have to be able to show they >>> came to the same conclusion independently. Pretty easy to show really, >>> unless you have an email saying "no, lets just use their sig". :) >>> >>> Matt >>> >>> Andre Ludwig wrote: >>>> For the record if you missed the ;) >>>> >>>> Im joking!!! but it does bring up a possible important >>>> point/vulnerability in their system. If someone was to submit a bunch >>>> of variations of signatures would VRT be up shits creek? They cant >>>> exactly copy sigs from what i understand. >>>> >>>> So there you have it folks.. simply create every possible permutation >>>> (doesnt that sound like fun!)of a sig and SF is up shits creek. Or if >>>> your a real bastard leave only the really expensive pcre expressions >>>> as options. >>>> >>>> /ranty joke >>>> >>>> Dre >>>> >>>> On 1/10/07, Andre Ludwig wrote: >>>>> but the obligation of the VRT team to not use open sigs, thus >>>>>> requiring them to write all of their own to distribute to clients. >>>>> >>>>> >>>>> You should see their PDF signature... >>>>> >>>>> haha reminds me of my own ;) >>>>> >>>>> (they used |23| instead of # for the content match.. haha) >>>>> >>>>> I have since decided to try and write as many variations of the same >>>>> signature as possible as quickly as possible so we can include all >>>>> possible permutations of a sig (even if they are disabled). That way >>>>> we make them reach for a god sig ;) >>>>> >>>>> haha im such a dick.. >>>>> >>>>> Dre >>>>> >>>> _______________________________________________ >>>> Bleeding-sigs mailing list >>>> Bleeding-sigs@bleedingthreats.net >>>> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >>> -- >>> -------------------------------------------- >>> Matthew Jonkman >>> Bleeding Edge Threats >>> 765-429-0398 >>> 765-807-3060 fax >>> http://www.bleedingthreats.net >>> -------------------------------------------- >>> >>> PGP: http://www.bleedingthreats.com/mattjonkman.asc >>> >>> >>> _______________________________________________ >>> Bleeding-sigs mailing list >>> Bleeding-sigs@bleedingthreats.net >>> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >>> >> _______________________________________________ >> Bleeding-sigs mailing list >> Bleeding-sigs@bleedingthreats.net >> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs >> > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From jonkman at bleedingthreats.net Thu Jan 11 15:51:07 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Thu Jan 11 15:54:56 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <45A6570A.2010401@brvenik.com> References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <45A6570A.2010401@brvenik.com> Message-ID: <45A65CEB.3030700@bleedingthreats.net> Jason wrote: > A point of order is due. > > Last time I checked the BSD style license is incompatible [0] with the GPL. > > Snort has always been GPL, Community rules have always been GPL, when > will others go GPL and become truly free? I don't understand your point. The GPL is NOT a license that makes software more usable to the community. It protects the rights of the author more, but does not make the product more distributable. What it does is force companies that need to make an internal change for local compatibility into a bad spot. Take clamav for example. There are many companies that cannot use the clamav engine because minor modifications that they would have to make for it to work in their architecture would be too revealing of other internal secrets. Thus they cannot make the change and keep it private without violating the GPL. Thus they can't use that GPL software, when the change would not benefit the community, other than to reveal company secrets. So many companies have to write their own detection engine. I don't know if the same thing goes on in snort, but it's certainly possible that it does. Note: GPL does not apply to databases, so many folks use the clam database and their own engine. The BSD license allows the community to do anything they want with these sigs. And I believe that's the right thing to do because the community wrote these sigs. Can you elaborate on your point? I don't think I understood. Matt > > [0] - > http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs -- -------------------------------------------- Matthew Jonkman Bleeding Edge Threats 765-429-0398 765-807-3060 fax http://www.bleedingthreats.net -------------------------------------------- PGP: http://www.bleedingthreats.com/mattjonkman.asc From pepperjack at doctorunix.com Thu Jan 11 15:12:22 2007 From: pepperjack at doctorunix.com (Jack Pepper) Date: Thu Jan 11 15:55:33 2007 Subject: [Bleeding-sigs] rule morphing (was: definition) In-Reply-To: References: <45A51AA7.8010804@secnap.net> <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> <20070110234808.ac0wixmlgkg8gg4o@192.168.168.10> Message-ID: <20070111091222.vbjvzydb5wock4ok@192.168.168.10> Quoting Gentoo-Wally : > God I hope I have not spawned a corporate war! hehe > > This brings a good question.... Does a sig with a hex content perform > faster or more efficient than one with a plain text content string? > > Wally It makes no difference. The difference in only in the sig parser. Once the sig is loaded, its all hex anyway. jp ------------------------------------------------- Email solutions, MS Exchange alternatives and extrication, security services, systems integration. Contact: services@doctorunix.com From jonkman at bleedingthreats.net Thu Jan 11 15:59:21 2007 From: jonkman at bleedingthreats.net (Matt Jonkman) Date: Thu Jan 11 16:03:31 2007 Subject: [Bleeding-sigs] definition In-Reply-To: <9d03f28f0701110737v7b3b5d47i8f085af4548c981f@mail.gmail.com> References: <45A528EA.8000203@bleedingthreats.net> <1168466913.30464.50.camel@localhost> <45A57C28.8070904@bleedingthreats.net> <9d03f28f0701101844sce065a9yc773c7f7cc068791@mail.gmail.com> <9d03f28f0701101847w7e0470a0g8654f411120773a3@mail.gmail.com> <45A5A7E3.9030703@bleedingthreats.net> <9d03f28f0701101913g7b6a7abaw1ab440018096b5eb@mail.gmail.com> <45A65637.8030603@brvenik.com> <9d03f28f0701110737v7b3b5d47i8f085af4548c981f@mail.gmail.com> Message-ID: <45A65ED9.8070209@bleedingthreats.net> Andre Ludwig wrote: > I can vouch for jason. He not only helps out a bunch but he always > has a lot to contribute (and thanks for that!). I second that! I still am curious > about the legalities of publishing every possible permutation of a > signature into a public signature set. Would that mean that VRT could > not publish a sig (assuming every possible permutation was actually > created) but it could be incorporated into the community set? > I don't think there's an issue there. It's not like writing a song or a story. In many cases if a signature is written correctly, everyone that writes it will do it the same way. As long as they do their own work to get to that point, then the product is their own. There isn't a conflict between BE and VRT in that regard. The only overlap issue is in making sure that the community can figure out which signature is best (ie most accurate and least load) for each issue so they can not have double detection for the same thing. That's an issue we tried to solve in ossrc, but there are problems. VRT can't NOT publish a sig because we have it because they owe their customers a sig. The community (i.e. us) cannot drop a sig because it's in the VRT because the VRT set is not free, and many folks don't want to pay for it. There are other things the OSSRC could solve, but there's a lack of resource/interest to make it run. I hope it gets going again, but for now there hasn't been any progress. I don't know where the contention came from in this conversation. It was about Bleeding Edge, not SF. :) Matt > Oh forgot the disclaimer.. I am not a lawyer, I don't play one on tv, > I don't write a legal blog, or a even a Law and Order fan podcast. > And I didn't sleep at a holiday inn last night... > > Dre > > On 1/11/07, Jason wrote: >> >> >> Maybe in that process someone will come up with a sig up front that >> catches the variations I pointed out here. I took my personal time on >> the weekend to assist bleeding with the effort and even honored your >> request to take it off list. I'm happy to become fully involved using my >> Sourcefire address if people are not willing to accept and acknowledge >> that we have always been and always will be part of the community >> regardless of where we post from. >> >> I've not looked at the VRT time lines but I can assure you they were >> thinking about it well before I got around to asking the question or >> posting samples for this list. >> >> If anyone in the bleeding community wants to try to come up with better >> detection I will post the samples again ( as if it is really needed ) >> >> >> >> >> >> HAHA im... >> >> People that live in stone houses shouldn't throw glass :P >> >> >> >> I'm quite annoyed by the positioning that goes on here. Sourcefire has >> always been and continues to be very supportive of the community and >> open source in general. Without Sourcefire Snort would not have the >> advances it has today and without Snort Sourcefire would not be where it >> is today. I think there is a very balanced relationship between >> Corporate viability and Community interest. The latest VRT changes are a >> example of this. The licensing was changed to make the rules more >> accessible to end users and more representative of the value they bring >> to the enterprise. >> >> Andre Ludwig wrote: >> > Damn you and your legalspeak!!!! >> > >> > Given the amount of SF employees that are surfing these lists im sure >> > it would be hard for them to deny they didnt have any knowledge. >> > >> > Lets face it.. I dont think anyone would/could execute such an attack >> > and then be a big nuff cockbanger to try and sue (