Last Updated: 2010-04-30 18:28:09 UTC
by Kevin Liston (Version: 2)
Malware Forensics at Large Firms
The malware forensics work-cycle is fairly tight at the day job. It focuses more on answering questions like:
· What are we dealing with? (e.g. an adware like Monkif, or an information stealer like Zeus?)
· Grab a sample to submit to the AV vendor
· Identify network behavior so we can identify infected machines on the wire
· How did it get in?
Depending on the workload, resources, etc. we don’t always get to answer all of the questions before the demands of keeping the business running or more severe incidents reallocates the response staff.
Smells Like Zeus
Last week, a sharp-eyed user noticed that their on-line bank was asking more questions than they usually do when they log in. During the initial triage I noted that it “smelled like Zeus.” Once we had got onto the box with EnCase we immediately looked for, and found, c:windowssystem32sdra64.exe on the system. Sure, case-closed. Submit the sample to AV to get them to update their signatures, examine the user’s proxy logs to identify the phone-home behavior and make signatures from that. There, the organization is protected.
But How Did It Get In?
The final-step in incident handling and the most-often ignored is the root-cause analysis or lessons-learned. With this particular case, I had a timestamp of when sdra64.exe was dropped on the box (if I trusted the MAC times) and could start digging through the web proxy logs for that machine at that time. That sounds like a lot of something-that-isn’t-much-fun.
You know what sounds like more fun? Timeline analysis.
(For more on doing your own Timeline Analysis in your environment, I recommend starting here: http://blogs.sans.org/computer-forensics/2010/03/19/digital-forensic-sifting-super-timeline-analysis-and-creation/)
In EnCase it’s not too hard to organize the view of the file system to track what files were modified or added around the time of sdra64.exe. I was at first interested in the files in the Temporary Internet Folders location of the user, since it will help me narrow down what website was hosted the exploit.
Java Applet Cache Files
In addition to the HTML and image files in the Temporary Internet Folders there were also files created in c:Documents and Settings[victim]Application DataSunJavaDeploymentcache[numbers]
There were files that had hash-like names, some with no extension, some with .idx, some with .hst.
The extentionless file is a zip archive of the .class files or bytecode of the java applets downloaded to the system. The .idx file looks suspiciously like the HTTP session used to pull it down, and .hst was the IP of the source.
That’s pretty handy information to have on hand. But what is the significance of java applet? On a whim, I submitted it to virustotal and it tells me that it’s an exploit for CVE-2009-3867. Neat, now I know how it got in and where it came in from.
With the tight deadlines, and the rushed process of identifying the process generating the bot-net traffic, or what dll is getting injected into iexplore.exe I know that I’m missing a lot of the other files that get dropped onto the system. If we’re lucky enough to get a memory snapshot of the system while it’s doing its evil I can use something like volatility to tell me what files a process has open. If it’s after-the-fact, I can glean some of that information from the prefetch files. In our zeus case while jumping into look directly for sdra64.exe I also saw SDRA64.EXE-[hash].pf.
The normal forensic value of prefetch files is it will tell you how many times an executable has been run and the last time that it was executed (I refer you to Harlan Carvey’s “Windows Forensic Analysis DVD Toolkit” pp 226 in the first edition, pp296 in 2nd ed) The real purpose of a prefetch file is to improve the efficiency of the OS so it tracks what files are opened by the executable. Using something like BinText you can see the list of files open by the application. This gives me an additional list of files to check against the whitelist for. In this particular example the .pf file also had a bit of HTML in there that looked like an iframe, I’m not sure if that’s a fluke or not, but it held additional clues about the exploit.
Last Updated: 2010-04-30 15:18:08 UTC
by Kevin Liston (Version: 1)
A reader reports that a new version of the Opera browser has been released today for Mac and Windows. The release notes are available here: http://www.opera.com/docs/changelogs/windows/1053/
The notes are simple, this is a security update to address a security vulnerability detailed here: http://www.opera.com/support/kb/view/953/
This is likely handled as an auto-update in most installations.
Last Updated: 2010-04-30 15:05:43 UTC
by Kevin Liston (Version: 1)
So you’ve just spent your morning digging through web proxy logs figuring out how one of your users managed to get infected with the latest rehash of FakeAV and you’ve got a handful of malicious URLs that you need to block on your perimeter. Let’s also suppose that you hold some goodwill towards your fellow sysadmin and wish to help stop further damage. Where do you start?
Depending on what vendor you use to manage your web proxy filters, you may be helping out by simply protecting yourself. That information should bubble up to their other customers and expand protection. Another way to help smaller organizations and individuals is to share this information with free security solutions.
Google Safe Browsing
Get the biggest bang for your buck by leveraging the Google Search engine which many folks rely on to save them from exposure to typo-squatters and other badness. URLs can be submitted here: http://www.google.com/safebrowsing/report_badware/
Although it’s advertised as web protection for your children, I find it works for parents and grandparents too. You can submit URLs and classify them here: http://www1.k9webprotection.com/support/check-site-rating.php
If you have an OpenDNS account you can submit a domain for tagging as malicious via their dashboard.
If you have a favorite list for submitting the results of your malware research, please leave a comment below.
Last Updated: 2010-04-30 14:10:07 UTC
by Kevin Liston (Version: 1)
Microsoft acknowledged the existence of a cross-site scripting (aka XSS) vulnerability in SharePoint Server 2007 and SharePoint Services 3.0.
CVSS(Base): 4.3 (unofficial)
Exploit Availability: public proof-of-concept
Impact: a specifically-crafted URL targeted to the users of an organization will allow arbitrary code to be executed in the context of the user in the security domain of the organization’s SharePoint server.
Patch Availability: patches are currently unavailable and projected to not be available until June 2010.
Workaround: Microsoft has provided workarounds for both the server and the endpoints. Details are available: http://blogs.technet.com/srd/archive/2010/04/29/sharepoint-xss-issue.aspx
Urgency: Although the vulnerability taken by it self is not that severe, it does open up opportunities to leverage other exploits that may not be otherwise exposed by your environment. This issue should not be considered an internal-only problem because your organization’s SharePoint servers are not on the Internet—all users of SharePoint are exposed. It is recommended that most organizations consider the workarounds proposed by Microsoft.
Last Updated: 2010-04-30 11:29:10 UTC
by Johannes Ullrich (Version: 1)
Microsoft published KB article #983438 late yesterday, with details about a XSS vulnerability within a SharePoint site. This vulnerability may be used to elevate privileges in Sharepoint. SharePoint Services 3.0 and SharePoint 2007 are affected.
Microsoft notes that the vulnerability is harder to exploit if Internet Explorer 8's built in XSS filter is used by administrators of the site. Another action that may help to mitigate the problem is to restrict access to the vulnerable Help.aspx file. With SharePoint using "httponly" cookies, the impact of the vulnerability is somewhat limited.