Sunday, March 28, 2010

A Look at the Latest HBGary Responder 2.0 REcon Malware Analysis Tool

Let me first say that I have no relationship with HBGary.  I think HBGary, Memoryze, and Volatility each have their own strengths and weaknesses and each has a place in the Windows RAM dump analyst's toolbox.

After having some stability issues with earlier editions of HBGary REcon, I tried the latest REcon version available with HBGary Responder 2.0.0.0354 with a piece of malware that I needed to analyze and that worked like a champ for me.

This piece of malware was found spreading via USB media.  There was nothing unusual about this malware sample other than it was over 30MB in size and thus not uploadable to a number of free online malware analysis sites.  It also was packed with MPRESS and not easily unraveled in IDA.  What I already knew through other means was that the malware sample persisted and spread through an autorun.inf file in the root of the infected USB media and an EXE buried in a fake recycle bin entry.  On infected Windows endpoint machines this particular variant persists in a bogus iexplore.exe file in %WINDIR% and started itself through 3 rogue autoruns entries in the Windows registry.

The malware sample appeared to run OK under REcon's control in a VMware instance of Windows XP SP3.  I imported the resulting REcon .FBJ file into HBGary Responder.  The first screenshot below shows how HBGary Responder reported a possible issue with the imported REcon data -  correctly identifying the child iexplore.exe process created by the autorunme.exe sample as doing something worth of attention (see the red circled call the WSAStartup on the Report tab).  (Please click the image to make it larger and easier to view).




The next screenshot shows the Responder Timeline tab "process and thread" view of the REcon forensic journal data collected while running the malware.  The entries circled in red show that I ran the malware sample - autorunme.exe -  under REcon, and that spawned process iexplore.exe PID 296 with one thread TID 1716, and then another iexplore.exe instance with a PID of 264 with two threads TID 332 and TID 308.  (Please click the image to make it larger and easier to view).




The next screenshot shows the Responder Timeline tab's Sample Group track view of the same REcon data.  REcon uses a samplepoints.ini file to map API calls into each of these tracks.  I used the default samplepoints.ini file for this run of REcon.  (Please click the image to make it larger and easier to view).




And this final screenshot shows Responder's ability to graph the REcon data for analysis.  What I did to get here was click the eye icon on the tracks that I didn't want to see in the graph.  I deselected everything except for the Network track.  The I selected portion of the Network track's timeline that I wanted to view (the portion you see in yellow).  The you right click the yellow portion of the timeline and select "Send to new graph".  In that graph you can see where the malware tried to resolve DNS name sopa.mine.nu to begin the next phase of the infection process.  (Please click the image to make it larger and easier to view).



I already use HBGary Responder Professional alongside Memoryze and Volatility as part of my normal Windows RAM dump analysis process and am very satisfied with the results. My experience with HBGary REcon recently tells me that REcon is mature enough to incorporate into my normal malware analysis procedures.

If you need any assistance with malware RE/analysis or Windows RAM dump analysis for incident response for Windows Server 2003/2003/2008 or Windows 2000/XP/Vista/7 on the client side please contact me at sales @ sharpesecurity.com. A routine Windows RAM dump triage and full report normally costs around $500-1000 USD per dump analyzed. Malware RE and basic capabilities analysis is normally roughly in the same price range and takes around 1-2 days to turn around for a quick triage. Deeper dive analysis is available, but takes a bit longer and costs more.



email: david @ sharpesecurity.com
website: http://www.sharpesecurity.com/
Twitter: twitter.com/sharpesecurity

Interesting Article on Recent US Offensive Cyber Op

If there is any truth to this Washington Post article about the US military taking down a joint CIA-Saudi terrorist intelligence gathering website, it sounds like some serious policy and protocol work needs to be done to help guide our well-intentioned military and intelligence service decisions makers when similar situations arise in the future. If unintended collateral damage like what allegedly happened in this instance spread to another nation's SCADA systems or systems at sensitive facilities, the blowback could be much worse.

From the Washington Post article:

"By early 2008, top U.S. military officials had become convinced that extremists planning attacks on American forces in Iraq were making use of a Web site set up by the Saudi government and the CIA to uncover terrorist plots in the kingdom".

"We knew we were going to be forced to shut this thing down," recalled one former civilian official, describing tense internal discussions in which military commanders argued that the site was putting Americans at risk. "CIA resented that," the former official said".

"Elite U.S. military computer specialists, over the objections of the CIA, mounted a cyberattack that dismantled the online forum. Although some Saudi officials had been informed in advance about the Pentagon's plan, several key princes were "absolutely furious" at the loss of an intelligence-gathering tool, according to another former U.S. official".


email: david @ sharpesecurity.com
website: http://www.sharpesecurity.com/
Twitter: twitter.com/sharpesecurity

Monday, March 22, 2010

New Apache mod_isapi Vuln Affects IBM HTTP Server 6.1 and Earlier

Apparently the vulnerability in Apache mod_isapi described here affects certain versions of the IBM HTTP Server – which is included in IBM’s WebSphere Application Server in some cases.

I haven't verified yet if the existing Metasploit exploit (www.metasploit.com/modules/auxiliary/dos/http/apache_mod_isapi) works on vulnerable versions of IBM HTTP Server.

According to IBM, The mod_isapi module is provided only on Windows and only on IBM HTTP Server 6.1 and earlier. It is not enabled or configured by default and is not available in IBM HTTP Server 7.0 and later.

References:
http://secunia.com/advisories/38978/
http://secunia.com/advisories/38776/
http://www-01.ibm.com/support/docview.wss?uid=swg1PM09447


email: david @ sharpesecurity.com
website: http://www.sharpesecurity.com/
Twitter: twitter.com/sharpesecurity

Wednesday, March 17, 2010

Apache Server 2.2.15 Released

Apache released version 2.2.15 of their Apache web server. 2.2.15 has vulnerability fixes in it that you need to consider since at least one of the vulnerabilities patched has a known working exploit available publicly. Proof of concept code for CVE-2010-0425 (mod_isapi) has already been released on the explo.it site (http://www.exploit-db.com/exploits/11650).

The OpenSSL library has also been updated in this release to version 0.9.8m to address CVE-2009-3555.

The Apache download site is: http://httpd.apache.org/download.cgi

Metasploit module: www.metasploit.com/modules/auxiliary/dos/http/apache_mod_isapi

email: david @ sharpesecurity.com
website: http://www.sharpesecurity.com/
Twitter: twitter.com/sharpesecurity

Sunday, March 14, 2010

Good Practical Advice from Hacked Rage3D Site

Unfortunately, it appears that the popular Rage3D site was hacked recently.  I point this out not to embarrass them, but instead to applaud them for taking the time to give the following great advice as they work to address the problem.

From http://www.rage3d.com/ as of 14 March 2010:
"We recommend those of you registered in the Rage3D Forums change the password for the email address that you used to register in the Rage3D Forum.  If you use the same password anywhere else in your online life, you should change it there as well".

As the Internet becomes increasingly hostile, events like this underscore the importance of avoiding using the same credentials too broadly.  If your strong and otherwise secure password can be taken in cleartext from somewhere, that can be a serious problem if you use those same credentials for your brokerage or banking accounts.  The weak link breaks the chain.





email: david @ sharpesecurity.com
website: http://www.sharpesecurity.com/
Twitter: twitter.com/sharpesecurity

Monday, March 8, 2010

Is Microsoft MS10-015 Detection Tool Mpsyschk.exe Effective?

Has anyone seen Microsoft MS10-015 mpsyschk.exe tool (http://support.microsoft.com/kb/980966) find a copy of Alureon/Tidserv? If so, please ping me at david @ sharpesecurity.com. I ran mpsyschk across a large population of machines last week and found nothing. Based on what I had observed in AV reporting, I had at least expected a couple hits.

I took a look at the pass/fail logic in mpsyscheck.exe. The pseudocode for the function that makes the PASS or FAIL decision is below. It looks like the decision point is whether or not two 4 byte values at offsets 0x7FFE0308 and 0x7FFE030C in the in-memory copy of process mpsyscheck.exe can be read successfully or not. I do not know enough about this problem to say whether this is enough detection or not. If mpsyschk.exe thinks the machine is infected, it also appears to write a "Timestamp" value under HKLM\Software\Microsoft\MPSystemStateCheck.





email: david @ sharpesecurity.com
website: http://www.sharpesecurity.com/
Twitter: twitter.com/sharpesecurity

Friday, March 5, 2010

Serious Usability Bug in TCG's Opal Hard Drive Encryption Standard

There is, in my opinion, a serious usability problem with encrypted drives conforming to the Trusted Computing Group Opal standard (i.e. the Opal Security Subsystem Class (SSC)). If an Opal-compatible drive thinks power has gone away as part of moving the S3 standby power state, the drive deauthenticates or locks. If an Opal drive is locked, only the shadow MBR and data log areas are reachable on the drive. As a result, the machine cannot see the file system which means it cannot boot out of the S3 state or hibernate. Microsoft Windows will typically bugcheck in this case.

At least one vendor's workaround for this is to prevent machines from going into standby when something happens like a laptop lid gets closed. I believe people normally expect their laptops to go to sleep or hibernate when the lid is closed - not stay powered on. This to me is a showstopping defect for adopting the Opal standard in its current form. The TCG is aware of this problem, and my understanding is that they are working on it.

I look forward to adopting robust standards-based encrypted hard drive solutions later and I hope that standard will come out of the Trusted Computing Group. However, for now I would recommend avoiding Opal compliance. Instead I recommend either using a proprietary encrypted drive implementation like the Seagate Momentus FDE, or stick with mature software-based whole disk encryption solutions.

UPDATE 06 August 2010 - Hibernate mode is not a problem with Opal drives as pointed out by Kris in the comments section. Production Opal drives are due out en masse in Q4 2010. The TCG is working on revising the Opal standard to address the S3 standby problem, but that fix will not be in the Opal drives released in Q4 2010.

References:
Storage Work Group Storage Security Subsystem Class: Opal

email: david @ sharpesecurity.com
website: www.sharpesecurity.com
Twitter: twitter.com/sharpesecurity