Microsoft (and others’) DLL Load Hijacking Bug – Remote Exploit Possible

Microsoft’s  security advisory that came out Monday is a bit vague on this bug, but the issue is a bit more serious matter and deserves security pro’s attention, especially if your company uses in-house applications.  MS KB is here.  The issue itself is not new, but recently published research that details remote attack vectors is.  

More in depth analysis and a good read about this issue, and confirmation of public exploit code can be found here.

Metasploit has a detection module and audit kit for this bug that can be used to discover applications that are vulnerable to unsecured DLL loading (and also exploit them). 

This bug, at the moment, requires users to open a file which has a bogus DLL in the same directory.  There are many applications that are vulnerable (both MS and 3rd party), but Microsoft is leaving it to these vendors and their own internal teams to release application specific updates.  Also, for the application to be vulnerable it must accept files as input.  I’m working on getting the list of known vulnerable applications.

The remote vector uses SMB which is hopefully blocked at your perimter, WebDAV is usally not, though.

Office documents with embedded content are another vector, as well as USB drives.

The KB above and this MS RD blog entry have an MS developed tool that will mitigate most of this threat.  It’s an optional download and will not be released by MS update. 

The SRD blog states that if users disable outbound SMB and kill the WebDAV client service on workstations they’re good to go (although the attack vector of locally hosted share or USB thumb drives will still persist), so it may be worthwhile looking at the MS fix tool.


Analyze Malware In The Time It Takes To Grab a Cup Of Coffee

Malware analysis is not a skill that every IT security professional has. It comes with a heavy amount of programming experience, an understanding of assembly, computer memory, debuggers and decompilers. Malware analysis can take a lot of time and skill, and is usually not done by organizations’ security staff. The staff leaves it to AV vendors and security research companies to do the analysis and make reports.

What happens when your company sees a lot of spam with zip attachments? Wouldn’t it be nice to see what these attachments do if opened; if they’re a Trojan or are making your client machines into botnet zombies? If you could analyze these files and see where they’re calling you could block these URL’s and IP’s at your perimeter, and not just rely on your spam filters or users’ judgment.

I found a pretty neat site called I’ll let you read more about the site’s origin and purpose, but to summarize: allows you to submit script and executable files to it and will send you a detailed analysis within a few minutes. takes your script or executable and runs it on a vm, then sends you the processsystem calls, dll hooks, networkdns traffic generated. You can choose what OS to run your files on, and the best part is it’s FREE!

So, now when your company starts getting those spam emails with attachments you can be the hero and provide custom remediation to the threat, right after you finish your cup o’ joe!

The Perfect Storm – A Story of Snort False Positive Verification

I recently had an opportunity to do some research into a large volume of Snort IDS rules that had begun to fire (to the tune of millions of alerts a day) for an organization.  At first glance these alerts appeared to be false positives, but they smelled like a lazy application DDoS attempt from some external source after a little review.  When the alerts didn’t stop, and considering the application in question wasn’t even being used I needed to provide clarity as to why these alerts were firing.  A simple “ignore them, they’re false positives” wasn’t going to fly here.   

The snort rule summary is as follows (full code displayed later): 

 Its an Oracle 10g application exploit alert, SID 15554 

Alert if 

Source: Outside 

Destination: Inside 

Traffic flow: to server 

Port: 6000-6199 

Protocol: HTTP 

Packet contents match following Perl regular expression (more explanation to follow): /^(GET|POST|HEAD)s+[^x25]*x25[x23x24x27x2ax2bx2dx2ehlqjzt1234567890]*[diouxefgacspn]/i 

Don’t let the regex above spook you.  Even tho it has hex characters in it, breaking it down isn’t too hard.  I’ll get into it’s meaning in more detail below:  

First, a little background on big companies and their web sites.  Oftentimes the volume of traffic to the sites is so large companies will use clustered web servers with load balancing appliances in front of them.  For security reasons the server cluster won’t be hosting the website on normal port 80 or 443, but the virtual IP (VIP) of the load balancer will accept 80 and 443 traffic.  Then, the traffic is NAT’d internally and distributed to one of the web servers on a non standard port.  What I discover is that the company had randomly decided to use a port in the 6000-6199 range for post nat’d web traffic.    That in conjunction with the IDS placement and meant the first five cases of the Snort rule were met.  However, five out of six cases is not enough for an alert. 

 The final case to match was the regular expression.  Here is an attempt to breakdown what this expression means in a more user friendly format: 

 Match the words “GET, POST or HEAD” if they appear at the start of a message.  Then match any number of spaces but not a line that  ends with a “%” sign.  Continue to match any series of characters (both numbers and letters) followed by a “%” sign.  Continue to match if the next set of characters matches one of these “#$’*+-. hlqjzt1234567890” and lastly match if the next characters contain one any of these “diouxefgacspn”.  This is all case sensitive. 

 After some HTTP packet analysis it was determined that the search functionality on the website matched this regular expression, and was causing the alert to fire erroneously.  Here is a sample of an HTTP GET request for a user initiated search: 

 GET HTTP/1.0 

Other legitimate requests may also have been matching the Snort rule. 

 Verification of the regular expression matching was performed on the following website: 


The end result was something of a perfect storm, wherein the Snort rules’ cases where being matched by legitimate web traffic. This explanation satisfied the organization and the rule was flagged as false positive. 

 Here is the complete text of the Snort rule:

oracle.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET [6000:6199] (msg:”ORACLE Oracle Application Server 10g OPMN serviceformat string vulnerability exploit attempt”; flow:to_server,established; content:”HTTP”; nocase; 
pcre:”/^(GET|POST|HEAD)s+[^x25]*x25[x23x24x27x2ax2bx2dx2ehlqjzt1234567890]*[diouxefgacspn]/i”; metadata:policy 
balanced-ips drop, policy security-ips drop; reference:bugtraq,34461; reference:cve,2009-0993; 
reference:url,; classtype:attempted-admin; 
sid:15554; rev:1;)