Sunday, November 16, 2014

Today I'll be taking a look at Stuxnet, and at a kernel level mostly (as usual) more than its impact on user-mode. I'll still however be going over a few user-mode things as it ties in with our kernel level discussion. I also won't go in-depth regarding all of the ways Stuxnet uses its four-slot toolbelt of zero-day flaws, and a lot of other Stuxnet's methods of attack (network, etc). ESET, Symantec, and others have done a fantastic job in that regard.

What is Stuxnet?

First of all, it's important (and a bit hilarious) to know the story behind Stuxnet. If you're researching Stuxnet for the first time, it's really easy to get confused. There's finger pointing, claims, supposed "confirmed sources", etc, left and right. I'll briefly go over it. For example:

The article is adapted from journalist David Sanger's forthcoming book, Confront and Conceal: Obama’s Secret Wars and Surprising Use of American Power, and it confirms that both the US and Israeli governments developed and deployed Stuxnet.

The US and Israel made the Stuxnet virus as a new kind of weapon targeted against Iran, a media investigation revealed. The operation reportedly started in the Bush era, but was intensified by Obama administration.

My initial reaction was "What the hell am I reading?", and it still sort of is. It goes on and on. All in all, after reading the above, you're likely inclined to believe that the US (and maybe even Israel) were behind Stuxnet. Whether or not this is true is a story for another day, although it's easier to lean towards 'yes' than it is to 'no'. The reason for this is due to the fact that Stuxnet as I discussed above used four zero-day flaws within Windows. It's a pretty big deal when malware exploits one zero-day flaw within the OS, but four is extremely high.

It's also pretty laughable to think that Stuxnet was created by amateurs not invested in any sort of organization regarding cyber warfare, etc of some sort, or amateurs in general. A lot of amateurs make malware for a lot of reasons, but causing nuclear centrifuges to commit suicide is pretty advanced. Aside from the many reasons to believe the answer is yes, some may lean towards no, and it's largely due to the fact that most cannot imagine the US and Israel working closely together to create something like Stuxnet.

I digress, and in any case, I'm not here to discuss politics or debate the true creator(s), so let's just get to the part where we talk about what Stuxnet was primarily created for. Stuxnet is a worm that was developed primarily to target industrial PLCs, which led to the nuclear centrifuges ultimately destroying themselves. The malware obviously couldn't be outright sent to the nuclear facilities themselves, so this is where its USB attack vector comes into play. More notably known as a supply chain attack:

So the creators of Stuxnet, they were thinking that these companies would do some communications with power plant workers; maybe exchange with USB devices. That’s probably how Stuxnet infected the system.

In the end, Stuxnet ended up destroying nearly one-fifth of Iran's centrifuges. In November 2010, it was reported that uranium enrichment within the Natanz nuclear facility had halted several times due to severe technical issues.

User-Mode

Stuxnet has two ways of injecting itself into the address space of a process and then executing exported functions. Stuxnet's user-mode modules are implemented as DLLs, and the first method is done by injecting itself into a preexisting process.

Preexisting Process Inject

1. Allocates a memory buffer in the calling process for the modules to be loaded.

The Import Address Table (IAT) is essentially just a table of jumps. It's used primarily as a lookup table when an application is calling a function in a different module. Compiled programs cannot know the memory locations of the libraries they depend on, therefore an indirect jump (jmp) is required whenever an API call is made.

In the above code we can see jumps to functions such as USER32.GetKeyboardLayout, which is a wrapper for the NtUserLoadKeyboardLayoutEx win32k syscall. This is in regards to Stuxnet's keyboard layout vulnerability (CVE-2010-2743), which is one of four exploitative ways used to escalate privileges in order to reach ring 0.

I would have loved to set a breakpoint on win32k!NtUserLoadKeyboardLayoutEx and trace the malware as it's extremely interesting, but setting breakpoints is not possible on an LKD session. I would have needed to break in to another physical machine (which I don't have), or set up a host > virtual COM port, which is a bit of a pain. I'll chalk it up to something to do on a rainy day. Call me lazy... I know.

3. Calls LoadLibraryW which is exported from kernel32.dll and passes it as a parameter for specially crafted file names such as: KERNEL32.DLL.ASLR.[HEX] or SHELL32.DLL.ASLR.[HEX]. Below we can see an example of a KERNEL32 variant:

First of all, to even successfully execute the malware you need to set your system time to before June 24th, 2012. This is due to the fact that Stuxnet hard-coded a poison pill to fully delete itself on June 24th, 2012. This was most likely done with the original idea in mind that Stuxnet wouldn't escape the nuclear facilities, which would allow time for Stuxnet to be reversed and ultimately defeated.

This piece of malware wanted to stay inside nuclear facilities, target Siemens systems, cause large actual damage, spread to cause more damage, and then go ghost. Fortunately, it did happen to escape its intended environment (some even speculate deliberately) and was inevitably reversed and defeated long before its hard-coded deletion date.

First of all, let's take a pre-infected look at the system with Autoruns + Process Explorer:

Everything looks to be pretty normal, and nothing really out of the ordinary. We can see we have one instance of lsass.exe.

Now let's turn things up a bit by executing the malware, and then comparing our results from pre-infection:

We can see now within Autoruns we have two new services - MRxCls and MRxNet. These are Stuxnet's kernel-mode drivers which enable its rookit functionality.

One big thing about malware that surfaces to the face of the public media (for whatever reason, we'll assume popularity/intention) is that journalists love to spin it and give awkward buzzwords - Undefeatable, The Most Sophisticated Malware, etc. Was Stuxnet an elborate piece of code? Yes, absolutely. Not only was knowledge needed regarding your typical rootkit/Win development, but heavy reverse engineering knowledge regarding Semens software was necessary as well.

However, one of Stuxnet's biggest weak points was its immense lack of anti-debugging/reversing techniques. Among a slew of reasons such as zero VM obfuscation, you can literally use the default regedit to find the locations of both MRxCLS and MRxNet. For example:

This had led Stuxnet to be something of a joke among some reverse engneers and analysts, even moreso if you believe that it was created by [insert government]. It's hard to imagine [insert government] wouldn't go to any lengths at all to hide its malware, but then again you never really know, right? : ) I'll continue the discussion regarding its kernel-mode functionality a little later as I'd like to swing back to user-mode real quick.

I couldn't get Process Explorer to run after infection, as the VM would bugcheck. I have no idea why, and AFAIK Stuxnet doesn't employ anti-debugging against Sysinternals tools by any means, so it was likely a buggy sample. I digress, and used VMmap instead:

We can see there's now three instances of lsass.exe, two of which are fake (newly created host processes). So first off, which is our legitmate lsass.exe? Well, 2/3 are the only ones above 1xxx regarding PID, so let's assume the only one not above 1xxx is legitimate:

If sort by Protection regarding the tabs, we can see it's mostly Execute/Read which doesn't raise any red flags. Let's assume for the moment this is legitimate and take a look at another one:

Uh oh, we can see two instances of memory that was chosen to share from this lsass.exe that has Write permissions in addition to Execute and Read. When a process has all three, it's a huge red flag for a fake/compromised process. In addition, note how the Size>Commited>Total Working Set, etc are equal. We can now at this point determine PID 648 is legitimate, and PID 1812 is fake. We can also at this point then assume that PID 1840 is fake as well:

Yep! In this case, we have five instances of memory that was chosen to be shared with R/W/E permissions, in addition to ntdll with R/W/E permissions as well. Note the Size>Commited>Total Working Set, etc equals again as well. At this point we can fully determine 1812 and 1840 are our fake lsass.exe instances, and 1840 is in relation to the patching of ntdll.

Let's further compare the three images based on their strings:

(PID 648 - legit)

(PID 1812 - fake #1)

Note we have quite the changes here, with the important being "!This program cannot run in DOS mode.". This is the classic MZ exe format used for .exe files within DOS. We can note the ASCII string - 4D. Let's take a look at the bottom of the string list:

(PID 1812 - fake #1)

We can see a number of functions, such as InternetOpen. We can at this point determine the DLL was successfully injected into this image of lsass.exe.

We can of course expect similar results with PID 1840:

(PID 1840 - fake #2)

We can also see abnormal termination of the NT Kernel, as well as a jmp:

Another big red flag of a malformed image.

Let's head back to discussing our kernel-mode drivers, MRxCls and MRxNet. As noted above, these two drivers aren't packed whatsoever with a protector nor packer, so inspecting them in-depth is painless:

First off, both of these drivers were digitally signed (albeit fake... what a surprise) to fool the user into believing it was a legitmate driver signed off as such by VeriSign. For example:

We can see MRxCls was fake-signed by VeriSign which claimed to be from Realtek. Realtek is obviously a legitimate company and releases lots of software/drivers for their products, such as audio, so this would fool a user if they ever questioned the legitimacy of the apparent MRxCls/Net drivers.

Stuxnet creates new device objects and attaches to the device chain for each device object. As we can see, Stuxnet attached to cdfs.sys, which is part of the filesystem, specifically the CD-ROM filesystem driver. Other filesystem drivers it attaches to are: ntfs.sys, and fastfat.sys. After attaching, Stuxnet manages the driver object, which in turn provides Stuxnet with the ability to succesfully intercept IRP requests.

Other than checking regedit, we can also confirm the existence of the MRxCls service within the registry using the !dreg command, which displays formatted registry key information. Before we do this however, we need to load ntsdexts.dll, or we'll get the following:

lkd> !dreg System\CurrentControlSet\Services
No export dreg found

This is due to the fact that ntsdexts.dll isn't of course loaded in the extension DLL chain list:

Overall, there's a lot to this rootkit. I didn't go into the MRxCls configuration file decryption, network changes/attack methods, other methods of zero-day flaws, etc but even so you can see that this is a pretty sophisticated piece of malware. However, as we now see, its biggest downfall was its complete lack of protection.

The only personal explanation I have for this is that the creator(s) were either rushed to get it done by 'x' timeframe, so they focused on main code more than obfuscation, or they just imagined it wouldn't ever escape its original intended environment, so they'd never have to worry about reverse engineering being an issue.