Targeted Attacks Exploit VBA Vulnerability in July MS Tuesday

It’s déjà vu. Last year around this time, I blogged about an exploit in the wild for a vulnerability included in the June 2011 MS Tuesday. This year, there is an active exploit in the wild for a vulnerability in July’s MS Tuesday.

Since mid-March, attackers have been sending their targets customized emails with malformed attachments that exploit the Microsoft Visual Basic for Applications DLL Loading Arbitrary Code Execution Vulnerability (CVE-2012-1854). The attachments are archive files that contain a clean Microsoft Word file along with a malicious Dynamic Link Library (DLL) file. So far, the attacks have been limited and have mostly affected Japanese organizations.

The vulnerability involves how Visual Basic for Applications handles the loading of DLL files and how an attacker can remotely execute code to compromise a computer. The vulnerability can be exploited by creating any Microsoft Word Document, such as a .doc file, and pairing it with specially crafted malware that has the filename Imeshare.dll located in the same folder. The Word file can be clean and any arbitrary file. It does not require any special code. The Word files can be legitimate files that are actually used by the targeted organization or files that are commonly received from external contacts. The DLL files, on the other hand, are specifically developed to exploit the particular vulnerability. The image below is what the malicious email attachment would contain. Note that the file name of the Word document can be anything; however, the name of the DLL is constant.
 


 

The example above uses the zip file format as the archive, but any type of archive can be used. We have confirmed the use of the zip file format and LZH archives in the wild so far. While the DLL file can be easily seen in the archive, it could go unnoticed after the files are extracted as the file could be set to hidden. So for those computers that have Do not show hidden files and folders selected under Hidden files and folders in Folder Options, only the Word file would be visible when the files are extracted. This might trick the user into believing there is nothing suspicious here and lead to the file being opened by the user, which compromises the computer, allowing a remote attacker to take complete control.

We have seen various types of malware with the file name Imeshare.dll. The malware includes Trojan Horse, Trojan.Dropper, Backdoor.Trojan, and Backdoor.Darkmoon, among others.

For protection, users should immediately apply the patch for this vulnerability. It is also important to be cautious when receiving emails, especially when they have attachments or links, and to be extra vigilant when there are DLL files included, as this type of file is not normally sent by email.

Backdoor.Korplug: Loading Malicious Components Through Trusted Applications

Symantec is observing limited targeted attacks using a new backdoor Trojan, Backdoor.Korplug. This backdoor surfaced earlier this year in March 2012. In these attacks, the targets are sent a crafted email containing a malicious attachment, typically in the form of a password protected zip file containing a malicious executable or in the form of an Office document exploiting Microsoft Windows Common Controls ActiveX Control Remote Code Execution Vulnerability (CVE-2012-0158). Here we will detail an interesting technique used to launch the payload.

We have already seen attackers make use of stolen certificates from legitimate companies in an attempt to add additional levels of trust to a binary. Korplug does not rely on stolen certificates; instead it piggybacks on legitimate signed executables in order to run its code within the privileged process. Let’s see how they do it!
 

Targeted email

Figure 1. Targeted email with malicious attachment
 

In a typical attack vector the malicious document is attached to a targeted email and then sent to the victim. When the document is opened, it will exploit the MSCOMCTL.OCX RCE vulnerability and, if successful, will drop and run the main payload.

Here is part of the shellcode used to drop and run the payload:
 

Figure 2. Shellcode drop and payload run
 

The payload will also drop and run a harmless document displaying a warning—an attempt to trick the user into thinking that the document cannot be displayed (Figure 3). However, if the user has a recent version of Microsoft Word installed, and has applied the patches provided by Microsoft, the user would be protected and the attackers would not be able to leverage this exploit in the first place.
 

Figure 3. Decoy document

 

Staged payload

Symantec detects the payload as Backdoor.Korplug, but its code is more complex than typical back doors seen in targeted attacks. Also, its structure indicates that this threat comes from a framework organized into several different components. Each one of these components performs a specific task, including a keylogger plugin and a screen capture plugin.

The payload contains three encrypted modules:

  • rc.exe
  • rc.dll
  • rc.hlp

 

Figure 4. Malicious attack structure
 

The interesting part is that the rc.exe file is a legitimate Windows file that will load the malicious rc.dll file. That malicious rc.dll file then loads a copy of the payload (the blob within the rc.hlp file).
 

Figure 5. Certificate of legitimate rc.exe file

 

Piggybacking legitimate rc.exe file

If the rc.exe file is a legitimate executable, why does it load a malicious DLL file? Well, let’s have a look at its import table:
 

Figure 6. Imported functions from rc.dll file
 

This executable imports two functions from the rc.dll module . Normally, when loading, the rc.exe file imports a legitimate rc.dll file (a Windows component needed for the rc.exe file to run properly). However, if a malicious rc.dll file is present in the same directory as the malicious rc.exe file, then the executable will load this malicious DLL file first, instead of loading the legitimate one from the Windows system directory. This is normal behavior for Windows.

The rc.dll file is a bridge to load any other component the attacker chooses:
 

Figure 7. Code from the rc.dll file which loads the rc.hlp payload
 

The DLL file reads a binary blob from the rc.hlp file and then executes it.
 

Putting it all together

The full order of the attack is:

  1. Exploit document opened with malicious payload
  2. Payload drops rc.exe, rc.dll, and rc.hlp files
  3. Payload runs legitimate rc.exe file signed by Microsoft so it will run unrestricted
  4. Malicious DLL file loaded to trusted rc.exe process
  5. Binary blob (copy of payload) in rc.hlp file loaded to trusted rc.exe process
  6. Main payload (Backdoor.Korplug) runs in trusted rc.exe process

The threat can now load any other component it wants—and if it needs to run another privileged process it can just reuse the same trick.
 

Conclusion

So, the rc.exe file is a legitimate Windows component: it does not contain vulnerabilities, hidden backdoors, or  bugs—and it is not badly written. This trick may, in theory, work on any signed executable that imports code from external modules, although certain conditions are necessary for it to work.

This trick is cheap, but effective, and we are seeing this piggybacking technique used in attacks more frequently. Symantec, however, detects all the malicious components of this threat: the targeted email, the malicious document, the payload executable, and the malicious DLL file.

Symantec detects this malware as Backdoor.Korplug and Bloodhound.Exploit.457. To stay safe, never open suspicious emails or emails from unknown senders, and keep your antivirus definitions up to date.

Check out the latest Symantec Intelligence Report highlighting the latest trends on targeted attacks.

Memories of the Nimda virus

This weekend is the tenth anniversary of the infamous and pervasive Nimda virus.

In this article, we take a look back in time at the outbreak. After all, as the US philosopher George Santayana warned a century ago, “Those who cannot remember the past are condemned to repeat it.”

Nimda first showed itself on 18 September 2001.

Those were heady days. The Code Red worm had appeared in July, taking everyone by surprise with its collateral damage – massive amounts of network traffic, dedicated only to redistributing the worm.

Microsoft’s “Whistler” project had been released to manufacturing as Windows XP in August.

Terrorists attacked and destroyed the World Trade Center towers on 9/11 as a shocked world watched on.

And whilst US flights were grounded as a post-9/11 precaution, Australia suffered its own aeronautic outage as the country’s second-biggest airline, Ansett, abruptly stopped operating, stranding passengers around the region – including a whole raft of Sophos Sydney colleagues who found themselves camping out at Melbourne airport with tickets to nowhere.

Nimda storms the internet

Boy, did Nimda show itself. It could spread every-which-way, and it did: by sending itself out to your email contacts; by breaking into web servers and infecting files all over your website; by spreading automatically across your network; and by parasitically infecting existing programs on your hard disk.

The result was that if an infected file made its way into your organisation and ran, you could end up with hundreds or thousands of infected computers on your network. And each infected computer – whether PC or server – might have hundreds or thousands of infected, damaged or modified files.

Coming just a week after 9/11, Nimda attracted plenty of speculation that it might be a form of cyberterrorism.

The virus code includes the text:

Concept Virus(CV) V.5, Copyright(C)2001 R.P.China

Since adjectives go before the noun in English, the country of China is known as PRC, not RPC. Does this tell us something? Is the error the sign of a mistake by a Chinese who knows only a bit of English? Are we looking at a Frenchman pretending to be a Chinese who knows a bit of English? Are we looking at a Russian pretending to be a Frenchman pretending to be a Chinese who knows a bit of English?

The answer is, as so often with malware and cybercriminals, that we just can’t say. We couldn’t know ten years ago when Nimda came out; and we often can’t tell today.

Nimda as cyberterrorism

Perhaps, ten years on from Nimda, we can learn to tone down the finger-pointing a bit. It’s certain that State actors around the world (that means “hackers paid by a country’s intelligence services”, not students at the Royal Academy of Dramatic Art) are involved in what might tabloidally be called cyberspying.

But if we trot out the talk of cyberwar and cyberterrorism too much, we distract attention from the clear and present danger of plain-and-simple cybercrime – which almost certainly costs us billions of dollars a year – by making it sound comparatively unimportant. (Things can be simple and important. In fact, simplicity is often the key to significance.)

Nimda as a proof of No Good Viruses

One intriguing aspect of Nimda – to techies, at any rate – is its parasitism: the mechanism it uses to infect other files.

Basic parasitic malware of the day usually carried the original host file around tacked onto the end of the virus. More sophisticated viruses inserted their content as a new code section, or even – as in the CIH, or Chernobyl, virus – into unused parts of the executable.

Nimda took the simplistic approach – carry the original host around with you – but in a complicated way. It embedded the infected host inside itself as a Windows resource. And needless complexity is often the enemy of correct behaviour (if any behaviour by a virus can be called “correct”).

Nimda, indeed, would happily reinfect files it had already hit. So you could end up with NOTEPAD embedded inside Nimda, embedded inside Nimda, embedded inside Nimda, and so on.

Not ad infinitum, of course, since only in Turing Machines do you get an infinite amount of memory. But the embedding could get very deep: a colleague and I ended up preparing samples which had been reinfected up to 250 times each to use in testing Sophos’s virus cleanup code.

This sort of unintended side-effect is yet another reminder of why there is no such thing as a harmless virus, since even a virus which was supposedly “just for fun” might have unexpected bugs. And once a virus is in the wild, spreading of its own accord, there’s no chance of issuing a recall notice.

It also reminds us that virus writers aren’t always the programming geniuses which they’re sometimes made out to be, and why decent security companies don’t queue up to hire virus writers – even if they’re willing to overlook the business and moral issues of hiring a crook.

Nimda says we still make old mistakes

Of further interest in Nimda was its network-spreading technique. One problem facing a network-spreading virus is how to persuade users elsewhere on the network to run the newly-added files.

Nimda did this by dropping infected DLLs called RICHED20.DLL around your network. A DLL by this name is loaded as-needed by a variety of Windows programs when you start dealing with documents more complex than just plain text.

By putting an infected RICHED20.DLL into directories containing .DOC files, for example, the Nimda DLL would be loaded instead of the official DLL if the user were to browse to that directory and examine a document. This is because Windows loads DLLs from the current directory by default unless the programmer explicitly instructs otherwise.

And this is interesting because I wrote about sloppy DLL loading just two days ago! Two of the very latest Patch Tuesday updates from Microsoft fix bugs of exactly this sort.

Ouch. Ten years on, and we’re still writing software which is incautious about how it chooses its add-on code libraries.

Nimda reminds us about patching

Another important lesson to be learned from Nimda is just how vital it is that we patch known holes inside our network quickly, so that if malware breaches our first levels of defence, it doesn’t get open slather to roam internally.

Nimda greatly accelerated its spread by breaking into and infecting websites, using what is known as a directory traversal vulnerability in the IIS web server. Web servers aren’t supposed to let you access files outside their own data directory, so they are supposed to watch out for character sequences such as “../../..”, even if cunningly disguised.

The “dot-dot” element in a path name means “go up one level”, and if allowed in a URI, could allow an outsider to access files which aren’t supposed to be visible at all.

One month after Nimda, Microsoft issued security bulletin MS01-078, entitled "Patch Available for 'Web Server Folder Traversal' Vulnerability".

But this bulletin didn't actually announce the arrival of a patch. It was issued simply to remind everyone that a patch had been issued in MS01-057, more than a month before Nimda appeared.

Ouch, again. Ten years on, and at least some of us still have change control bureaucracy which dithers for weeks about individual patches. As I’ve written before, if you have a change control committee of that sort, you probably need to appoint a change control committee change committee.

Nimda shows us that prevention is better than cure

There. I’ve said it. I’ll say it again, truism though it might be. Prevention is better than cure.