?Order? e-mails and how to block them
The guys behind the Haxdoor Trojan we wrote about two days ago (http://isc.sans.org/diary.php?storyid=1508) are not giving up easy. It looks like they are constantly spamming new downloader binaries, which are modified just enough to evade detection with current signatures and/or heuristics.
These downloaders are pretty small, usually only about 3kb, and are obfuscated a bit to make analysis more difficult. The latest downloader we've received comes in exactly the same message as those previous, notifying you about the order you've placed and it's summary in the attachment.
Once executed, the downloader tries to download a file from http:// 81.95.146.133 / [removed].exe. At the time of writing this diary the file was not available.
Anti virus vendors are slowly updating definitions and starting to detect this downloader properly.
While we're on the subject of malware being spammed, one of our readers, Rick, wrote earlier to ask as about a resource which specifies filetypes/file extensions that are assumed to be dangerous and should be blocked.
Microsoft has a nice list of unsafe extensions that we would definitely recommend to be blocked at the gateway. Microsoft Outlook actually automatically blocks these attachments, so if you block them at the gateway, it should *not* impact your users a lot. You can find the list at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q262631.
One thing we have to stress out is that you can't rely on extensions ? sure, you should block these obviously unsafe ones, but don't rely on this. A lot of Unix/Linux mail programs can use the "file" utility, which is a much better choice in this case as it can detect what the file really is by examining the magic headers.
This is not a silver bullet as there ways for evading the detection by using utilities which don't rely on the magic bytes used by the "file" utility. Besides this, the "file" utility would have to be able to use the same "magic" (from the /etc/magic file) that Microsoft uses to determine which program will be used to open a file. Also, depending on the environment, there are cases when some file formats just have to be allowed (like Microsoft Word or Excel documents), which can carry other malware (just remember all 0-day vulnerabilities in Office applications that have been published lately).
This being said, blocking executables and other "unsafe" extensions and file types is still a good first line of defense.
Update (07/27/06): Today we saw another downloader being spammed, by the same group. It behaves completely same as the one detected yesterday, but it has been (again) modified to evade the AV detection. The md5sum is:
3a3a4fe61c9a0a511624cde88bcd2abe WC2905036.exe
It again tries to connect to the same web server as above, to download the second stage executable, which (luckily) wasn't there when we checked last time.
One of our readers, Simon, reminded us on white lists for extension/file type blocking. Indeed, if you can afford to implement white lists, they are the way to go - just block everything and allow only extensions/file types that you know are needed for your organizations.
These downloaders are pretty small, usually only about 3kb, and are obfuscated a bit to make analysis more difficult. The latest downloader we've received comes in exactly the same message as those previous, notifying you about the order you've placed and it's summary in the attachment.
Once executed, the downloader tries to download a file from http:// 81.95.146.133 / [removed].exe. At the time of writing this diary the file was not available.
Anti virus vendors are slowly updating definitions and starting to detect this downloader properly.
While we're on the subject of malware being spammed, one of our readers, Rick, wrote earlier to ask as about a resource which specifies filetypes/file extensions that are assumed to be dangerous and should be blocked.
Microsoft has a nice list of unsafe extensions that we would definitely recommend to be blocked at the gateway. Microsoft Outlook actually automatically blocks these attachments, so if you block them at the gateway, it should *not* impact your users a lot. You can find the list at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q262631.
One thing we have to stress out is that you can't rely on extensions ? sure, you should block these obviously unsafe ones, but don't rely on this. A lot of Unix/Linux mail programs can use the "file" utility, which is a much better choice in this case as it can detect what the file really is by examining the magic headers.
This is not a silver bullet as there ways for evading the detection by using utilities which don't rely on the magic bytes used by the "file" utility. Besides this, the "file" utility would have to be able to use the same "magic" (from the /etc/magic file) that Microsoft uses to determine which program will be used to open a file. Also, depending on the environment, there are cases when some file formats just have to be allowed (like Microsoft Word or Excel documents), which can carry other malware (just remember all 0-day vulnerabilities in Office applications that have been published lately).
This being said, blocking executables and other "unsafe" extensions and file types is still a good first line of defense.
Update (07/27/06): Today we saw another downloader being spammed, by the same group. It behaves completely same as the one detected yesterday, but it has been (again) modified to evade the AV detection. The md5sum is:
3a3a4fe61c9a0a511624cde88bcd2abe WC2905036.exe
It again tries to connect to the same web server as above, to download the second stage executable, which (luckily) wasn't there when we checked last time.
One of our readers, Simon, reminded us on white lists for extension/file type blocking. Indeed, if you can afford to implement white lists, they are the way to go - just block everything and allow only extensions/file types that you know are needed for your organizations.
Keywords:
0 comment(s)
Security patches for Mozilla Firefox/Thunderbird/SeaMonkey
The Mozilla Foundation released new versions of Firefox, Thunderbird and SeaMonkey products.
New versions fix numerous security vulnerabilities, of which some are rated critical. Here's a short overview of the vulnerabilities that have been fixed:
MFSA 2006-44 (http://www.mozilla.org/security/announce/2006/mfsa2006-44.html): Code execution through deleted frame reference.
This vulnerability allows remote execution and affects only Firefox 1.5 and SeaMonkey 1.0. As Thunderbird uses the same browser engine as Firefox it is vulnerable to this as well, but the JavaScript parsing function in e-mails is not turned on by default (and we recommend that it stays turned off).
MFSA 2006-45 (http://www.mozilla.org/security/announce/2006/mfsa2006-45.html): Javascript navigator Object Vulnerability.
Another remote execution vulnerability, affects Firefox 1.5 and SeaMonkey.
MFSA 2006-46 (http://www.mozilla.org/security/announce/2006/mfsa2006-46.html): Memory corruption with simultaneous events.
Remote execution vulnerability, affects Firefox and SeaMonkey.
MFSA 2006-47 (http://www.mozilla.org/security/announce/2006/mfsa2006-47.html): Native DOM methods can be hijacked across domains.
Information leaking vulnerability, can be combined with XSS, although limited. Affects Firefox and SeaMonkey.
MFSA 2006-48 (http://www.mozilla.org/security/announce/2006/mfsa2006-48.html): JavaScript new Function race condition.
Remote execution vulnerability, affects Firefox, Thunderbird and SeaMonkey.
MFSA 2006-49 (http://www.mozilla.org/security/announce/2006/mfsa2006-49.html): Heap buffer overwrite on malformed vCard, affects Thunderbird and SeaMonkey.
MFSA 2006-50 (http://www.mozilla.org/security/announce/2006/mfsa2006-50.html): JavaScript engine vulnerabilities
Multiple vulnerabilities which can lead to remote execution, affect Firefox, Thunderbird and SeaMonkey.
MFSA 2006-51 (http://www.mozilla.org/security/announce/2006/mfsa2006-51.html): Privilege escalation using named-functions and redefined "new Object()".
Remote execution vulnerability, affects Firefox, Thunderbird, SeaMonkey.
MFSA 2006-52 (http://www.mozilla.org/security/announce/2006/mfsa2006-52.html): PAC privilege escalation using Function.prototype.call
Remote script execution vulnerability through a "poisoned" PAC file. Affects Firefox and SeaMonkey.
MFSA 2006-53 (http://www.mozilla.org/security/announce/2006/mfsa2006-53.html): UniversalBrowserRead privilege escalation.
Remote script execution vulnerability, affects Firefox, Thunderbird and SeaMonkey.
MFSA 2006-54 (http://www.mozilla.org/security/announce/2006/mfsa2006-54.html): XSS with XPCNativeWrapper(window).Function(?).
XSS vulnerability using the XPCNativeWrapper construct. Affects Firefox, Thunderbird and SeaMonkey.
MFSA 2006-55 (http://www.mozilla.org/security/announce/2006/mfsa2006-55.html): Crashes with evidence of memory corruption (rv:1.8.0.5).
Probably just a DoS attack, but there is a possibility that it could be turned into a remote execution vulnerability. Affects Firefox, Thunderbird and SeaMonkey.
MFSA 2006-56 (http://www.mozilla.org/security/announce/2006/mfsa2006-56.html): chrome: scheme loading remote content
Remote script execution vulnerability that affects Firefox and SeaMonkey.
As some of these vulnerabilities are critical, it would be good if you can upgrade as soon as possible; otherwise, check for potential workarounds in the original advisories - in most cases the vulnerabilities are JavaScript related, so turning off JavaScript will help (and that goes in general).
New versions fix numerous security vulnerabilities, of which some are rated critical. Here's a short overview of the vulnerabilities that have been fixed:
MFSA 2006-44 (http://www.mozilla.org/security/announce/2006/mfsa2006-44.html): Code execution through deleted frame reference.
This vulnerability allows remote execution and affects only Firefox 1.5 and SeaMonkey 1.0. As Thunderbird uses the same browser engine as Firefox it is vulnerable to this as well, but the JavaScript parsing function in e-mails is not turned on by default (and we recommend that it stays turned off).
MFSA 2006-45 (http://www.mozilla.org/security/announce/2006/mfsa2006-45.html): Javascript navigator Object Vulnerability.
Another remote execution vulnerability, affects Firefox 1.5 and SeaMonkey.
MFSA 2006-46 (http://www.mozilla.org/security/announce/2006/mfsa2006-46.html): Memory corruption with simultaneous events.
Remote execution vulnerability, affects Firefox and SeaMonkey.
MFSA 2006-47 (http://www.mozilla.org/security/announce/2006/mfsa2006-47.html): Native DOM methods can be hijacked across domains.
Information leaking vulnerability, can be combined with XSS, although limited. Affects Firefox and SeaMonkey.
MFSA 2006-48 (http://www.mozilla.org/security/announce/2006/mfsa2006-48.html): JavaScript new Function race condition.
Remote execution vulnerability, affects Firefox, Thunderbird and SeaMonkey.
MFSA 2006-49 (http://www.mozilla.org/security/announce/2006/mfsa2006-49.html): Heap buffer overwrite on malformed vCard, affects Thunderbird and SeaMonkey.
MFSA 2006-50 (http://www.mozilla.org/security/announce/2006/mfsa2006-50.html): JavaScript engine vulnerabilities
Multiple vulnerabilities which can lead to remote execution, affect Firefox, Thunderbird and SeaMonkey.
MFSA 2006-51 (http://www.mozilla.org/security/announce/2006/mfsa2006-51.html): Privilege escalation using named-functions and redefined "new Object()".
Remote execution vulnerability, affects Firefox, Thunderbird, SeaMonkey.
MFSA 2006-52 (http://www.mozilla.org/security/announce/2006/mfsa2006-52.html): PAC privilege escalation using Function.prototype.call
Remote script execution vulnerability through a "poisoned" PAC file. Affects Firefox and SeaMonkey.
MFSA 2006-53 (http://www.mozilla.org/security/announce/2006/mfsa2006-53.html): UniversalBrowserRead privilege escalation.
Remote script execution vulnerability, affects Firefox, Thunderbird and SeaMonkey.
MFSA 2006-54 (http://www.mozilla.org/security/announce/2006/mfsa2006-54.html): XSS with XPCNativeWrapper(window).Function(?).
XSS vulnerability using the XPCNativeWrapper construct. Affects Firefox, Thunderbird and SeaMonkey.
MFSA 2006-55 (http://www.mozilla.org/security/announce/2006/mfsa2006-55.html): Crashes with evidence of memory corruption (rv:1.8.0.5).
Probably just a DoS attack, but there is a possibility that it could be turned into a remote execution vulnerability. Affects Firefox, Thunderbird and SeaMonkey.
MFSA 2006-56 (http://www.mozilla.org/security/announce/2006/mfsa2006-56.html): chrome: scheme loading remote content
Remote script execution vulnerability that affects Firefox and SeaMonkey.
As some of these vulnerabilities are critical, it would be good if you can upgrade as soon as possible; otherwise, check for potential workarounds in the original advisories - in most cases the vulnerabilities are JavaScript related, so turning off JavaScript will help (and that goes in general).
Keywords:
0 comment(s)
ISCAlert Update
Due to some changes to the way that we're doing our RSS feed (which ISCAlert reads and parses to do its stuff...) I had to make a minor change to ISCAlert. The latest version (1.1) will fix the problem with the indicator remaining blue and showing "Infocon: NO DATA."
For those of you who don't know, ISCAlert is a tiny Windows systray application that automatically monitors the ISC and displays the status of the Infocon as a small colored globe in the tray. If the Infocon changes, the globe changes color and blinks. Optionally, you can use Windows sound schemes to play sounds when the Infocon status changes. Finally, we also have the option of triggering a special "information only" alert that causes ISCAlert to notify you that something important is going on that may not rise to "Infocon-changing" level.
ISCAlert (v1.1) is available here.
(.EXE MD5: 74f1ee31e1b4f3297e767da5666c2489)
A version "internationalized" to Portuguese is here.
(.EXE MD5: 4fac5de0ebf508b9aa8f00a024bb10aa)
For those of you who don't know, ISCAlert is a tiny Windows systray application that automatically monitors the ISC and displays the status of the Infocon as a small colored globe in the tray. If the Infocon changes, the globe changes color and blinks. Optionally, you can use Windows sound schemes to play sounds when the Infocon status changes. Finally, we also have the option of triggering a special "information only" alert that causes ISCAlert to notify you that something important is going on that may not rise to "Infocon-changing" level.
ISCAlert (v1.1) is available here.
(.EXE MD5: 74f1ee31e1b4f3297e767da5666c2489)
A version "internationalized" to Portuguese is here.
(.EXE MD5: 4fac5de0ebf508b9aa8f00a024bb10aa)
Keywords:
0 comment(s)
Malware Analysis Project: Tools of the Trade
Every person out there has encountered situations when they needed a tool to do something and was not sure where to find one. If you did find one, good luck with understanding how to use it as most don't come with good documentation. I know I have spent many hours on Google looking for something that would do what I needed it to for that moment. Maybe it was an easy way to extract the files out of a .chm (yep there's a cool tool to do that with) or a simple tool that does unencoding. Here is what I'm looking for and would like for it to be a team effort. I would like to compile and maintain a list of tools useful for doing malware analysis. It may even be a website that has a useful feature. Here is what I would ask that you do if you wish to contribute. Please send the following via the contact page and label the subject as "Malware Analysis Tool Project":
- The name of the tool
- Where you can get it (if known)
- Shareware/Freeware
- What it does (short synopsis: you don't have to write a user's guide unless you really want to)
- Tips for using it or gotchas
- Is the source of the tool considered trustworthy? (i.e. would you run it on your primary system or only on a VM)
- Screen Shots of the tool in action (optional)
- Links to additional resource information about the tool (i.e. forums, mailing lists, websites, articles, etc.)
Keywords:
0 comment(s)
A Few Thoughts on the Recent MySpace Worm
As we mentioned in the July 17th handler's diary, a powerful worm hit MySpace about 1.5 weeks ago. There have been a few confusions regarding this and other recent MySpace incidents. The purpose of this note is to clarify these confusions.
MySpace is a social networking site that is popular among those who are young in spirit and have an affinity for music. According to a recent announcement by Hitwise, MySpace has become the #1 most popular destination on the Web. Netcraft ranks MySpace as the 77th most popular desgination, though.
An unusual aspect of this worm was that it resided purely on MySpace pages, rather than installing itself on personal computers of its victims. The essential component of the worm, which Symantec called ACTS.Spaceflash, was a Flash object that was embedded in the victims' profile pages on MySpace. The offending code resided in the redirect.swf file, and looked like this, according to the person who analyzed the worm's code:
The viewer of the Flash object was redirected to a page that, through clever scripting, modified the victim's profile. As a result, whenever someone viewed the victim's profile, the viewer's profile would also get infected.
The same MySpace weakness has been exploited since at least February 2006 to harvest logon credentials of MySpace users. This redirecting technique was referenced on Digg.com, which pointed to a password-harvesting toolkit whose description is still in Google cache.
Essentially, the weakness that these attacks exploited was the ability of users to embed active content in the form of Flash objects in MySpace pages.
Note that this weakness is not related to the recent issue that Macromedia fixed in Flash Player, despite what many stories reported. Macromedia's patch corrected a memory corruption condition that could allow an attacker to execute arbitrary code on a vulnerable system, according to US-CERT. (If you haven't already, you should upgrade your Flash Player to version 9 to fix this vulnerability.)
Coincidentally, MySpace addressed the weakness that the worm exploited by requiring that MySpace users who wish to view Flash objects hosted on MySpace upgrade to Flash Player 9. The reason is because Flash Player 9 supports a new tag that allows MySpace to disable the URL-redirecting feature. The new tag, briefly described in Marcomedia's documentation, looks like this:
MySpace started automatically adding this tag to all Flash objects that it hosts. The unfortunate side effect is that many third-party Flash wrappers, such as YouTube, rely on the URL-redirecting functionality to bring viewers to its site and sponsors. As pointed out by TechCrunch, this move "will likely do serious damage to the cottage industry of flash widgets in MySpace."
This is not the first worm that hit the MySpace site. The Sammy or JS.Spacehero worm took advantage of a cross-site scripting (XSS) flaw in MySpace to affect over a million users about 9 months ago. Also, note that these incidents are distinct from the MySpace ad-based attack that also affected about persons in the span of the last month. The ad attack took advantage of the seven-month-old WMF exploit that targeted website visitors through a banner ad; if you haven't applied the WMF patch yet, you really should. Finally, do not confuse these issues with the power outage that knocked MySpace off-line along with several other popular websites for a few days this weekend.
Well, I think that about sums it up for now.
-- Lenny
Lenny Zeltser
www.zeltser.com
MySpace is a social networking site that is popular among those who are young in spirit and have an affinity for music. According to a recent announcement by Hitwise, MySpace has become the #1 most popular destination on the Web. Netcraft ranks MySpace as the 77th most popular desgination, though.
An unusual aspect of this worm was that it resided purely on MySpace pages, rather than installing itself on personal computers of its victims. The essential component of the worm, which Symantec called ACTS.Spaceflash, was a Flash object that was embedded in the victims' profile pages on MySpace. The offending code resided in the redirect.swf file, and looked like this, according to the person who analyzed the worm's code:
getURL("http://editprofile.myspace.com/index.cfm?
fuseaction=blog.view&friendID=93634373&blogID=144877075", "_self");
fuseaction=blog.view&friendID=93634373&blogID=144877075", "_self");
The viewer of the Flash object was redirected to a page that, through clever scripting, modified the victim's profile. As a result, whenever someone viewed the victim's profile, the viewer's profile would also get infected.
The same MySpace weakness has been exploited since at least February 2006 to harvest logon credentials of MySpace users. This redirecting technique was referenced on Digg.com, which pointed to a password-harvesting toolkit whose description is still in Google cache.
Essentially, the weakness that these attacks exploited was the ability of users to embed active content in the form of Flash objects in MySpace pages.
Note that this weakness is not related to the recent issue that Macromedia fixed in Flash Player, despite what many stories reported. Macromedia's patch corrected a memory corruption condition that could allow an attacker to execute arbitrary code on a vulnerable system, according to US-CERT. (If you haven't already, you should upgrade your Flash Player to version 9 to fix this vulnerability.)
Coincidentally, MySpace addressed the weakness that the worm exploited by requiring that MySpace users who wish to view Flash objects hosted on MySpace upgrade to Flash Player 9. The reason is because Flash Player 9 supports a new tag that allows MySpace to disable the URL-redirecting feature. The new tag, briefly described in Marcomedia's documentation, looks like this:
allowNetworking="internal"
MySpace started automatically adding this tag to all Flash objects that it hosts. The unfortunate side effect is that many third-party Flash wrappers, such as YouTube, rely on the URL-redirecting functionality to bring viewers to its site and sponsors. As pointed out by TechCrunch, this move "will likely do serious damage to the cottage industry of flash widgets in MySpace."
This is not the first worm that hit the MySpace site. The Sammy or JS.Spacehero worm took advantage of a cross-site scripting (XSS) flaw in MySpace to affect over a million users about 9 months ago. Also, note that these incidents are distinct from the MySpace ad-based attack that also affected about persons in the span of the last month. The ad attack took advantage of the seven-month-old WMF exploit that targeted website visitors through a banner ad; if you haven't applied the WMF patch yet, you really should. Finally, do not confuse these issues with the power outage that knocked MySpace off-line along with several other popular websites for a few days this weekend.
Well, I think that about sums it up for now.
-- Lenny
Lenny Zeltser
www.zeltser.com
Keywords:
0 comment(s)
Packet Analysis Challenge
Yes its packet time. Here are some packets that I would like to throw out there to see what folks are able to come up with. You will need your favorite tool to read the file as it is a raw packet capture. This is exactly what we were initially given to work with including the source and destination IPs being obfuscated. I will give you a couple of clues from later captures we received that will help clarify but you don't really need them. The source IP does change but the destination IP does not. The destination IP is a primary DNS server. Everything that you need is contained in these packets. You should be able to come up with an general idea of what is going on. Is this an attack, scan or normal network traffic? Please explain briefly how you came to your conclusions. If you want to try this, but don't want to be mentioned in the future diary writeup with the solution, please let me know. I'll post the answer in a few days and explain how we came to our conclusions and how it was verified with a later capture. Have fun!!!
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments