Category Archives: Reversing

Review of McAfee Application Control (ex-SolidCore): the ultimate solution to patching?

What is McAfee Application Control

I had the opportunity to review this security software, and I want to share here the results of my tests.

McAfee bought the SolidCore solution and renamed it into McAfee Application Control (along with other features). For convenience, we will keep referring the solution as SolidCore.

In a few words, this tool falls into the category of white-listing defense systems. It hardens a Windows system by fingerprinting all executables files of the disk drive and enforcing access control based on this hash. Somehow a sort of Tripwire but with access control and attack detection.

The problem is that McAfee claims that the solution will protect unpatched systems. Such a claim is appealing, because in real life it is not always easy to patch systems in production. Beyond technical considerations, there is always business and management constraints. The solution of McAfee is supposed to prevent vulnerabilities to be triggered thanks to the memory protection features. Look on their website, they say it loudly: “you can delay patching and it protects from buffer overflows”.

MacAfee Application Control commercial sheet

Really? When you check more thoroughly, you find that the solution operates only in user-mode, leaving all kernel-mode issues on the side. Already, any security specialist should become suspicious and think about the numerous limitations it implies…

Anyway, such a statement deserves serious testing. Here we go.

Testing Lab

The testing environment is composed of:

  • a Windows XP SP1 virtual machine (no patch),
  • a Windows XP SP1 virtual machine (no patch) with SolidCore installed and enabled,
  • a Windows virtual machine running WinDBG for kernel debugging,
  • a Linux virtual machine running Metasploit (Backtrack),
  • a few vulnerable programs: aurora.html for heap overflows and two executables vulnerable against buffer overflow,
  • OllyDbg on both machines to observe the exploitation process.

The point is simple: test some vulnerabilities against unpatched systems, with and without SolidCore, and compare the results.

The purpose here is only to focus on what SolidCore is doing (though we are not going to attempt to reverse the application). I will not get here into explanations on assembly and memory exploitation, so please refer to the many great tutorials that can be found on the Internet.

As mentioned, I am myself a noob in reversing and shellcoding so please drop a comment if you see something wrong.

Installing SolidCore

Like Tripwire, SolidCore needs to take an image of the system when it is sane.

So, basically, after setting it, there are a few commands to type into a command window to scan the whole disk:

sadmin so
sadmin enable

It will look for executables (.exe, .dll, etc.) and build a database using SHA-1 hashes.

SolidCore Activation

SolidCore commands and status after activation

Now, only applications installed before the scan will be allowed. If you drop a new file or move an existing one to a new patch and try to execute it, it will fail like this:

SolidCore blocking execution of a program

SolidCore blocks the execution of a new executable file

After that, whenever you need to install a new application, you have to go through the “update mode”. Just enter:

sadmin bu

At this moment, the protection is deactivated and you can execute anything. Then, you need to do a new scan and re-enable the protection as done previously.

Also, not all memory protections are activated by default. This is supposed to enable memory randomization (aka ALSR but McAfee made):

sadmin features enable mp-vasr

Now, see the enabled features:

SolidCore features list

SolidCore features list and memory protection (mp-vasr, mp-casp)

So far so good, now we can play!

Let’s see what is behind the scene…

The first thing to notice is that SolidCore installs a service launched with the LocalSystem account.

SolidCore service

SolidCore service

SolidCore background service process

SolidCore background service process

Let’s have a look within a kernel debugging session with WinDbg.

While booting, the target displays a lot of interesting info concerning the McAfee solution:

Solidcore log buf: F8418B60, F84415C0
K.0004.0008: Nov 30 2012:04:49:09.812: SYSTEM: rtinit.c : 1474: McAfee Solidifier driver version 6.0.1-9049
K.0004.0008: Nov 30 2012:04:49:09.828: SYSTEM: rtinit.c : 1476: DriverEntry @F846E500
K.0004.0028: Nov 30 2012:04:49:10.093: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\ntdll.dll to \Device\HarddiskVolume1\Solidcore\vasr\ntdll.dll at 0x5cda0000.
K.0004.0028: Nov 30 2012:04:49:10.500: SYSTEM: rtinit.c : 129: Booting up with RTEMode = 1
[...]
K.0432.0436: Nov 30 2012:04:49:15.671: ERROR: cap_kern.c : 1106: Failed to compute checksum for '\Device\HarddiskVolume1\WINDOWS\system32\autochk.exe'. err = 1099
K.0432.0436: Nov 30 2012:04:49:15.796: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\kernel32.dll to \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll at 0x65d60000.
K.0432.0436: Nov 30 2012:04:49:15.828: SYSTEM: imgp.c : 3114: Starting decoying of \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll (\Device\HarddiskVolume1\Solidcore\k32_c__v.dll)
K.0432.0436: Nov 30 2012:04:49:15.890: SYSTEM: imgp.c : 3118: Finished decoying of \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll (\Device\HarddiskVolume1\Solidcore\k32_c__v.dll) with err = 0
K.0432.0436: Nov 30 2012:04:49:15.953: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\user32.dll to \Device\HarddiskVolume1\Solidcore\vasr\user32.dll at 0x48c60000.
K.0732.0828: Nov 30 2012:04:49:20.859: SYSTEM: utl.c : 500: Failed to find username, err 0xc000020c, perhaps the service is not running.
K.1312.1316: Nov 30 2012:04:49:21.281: SYSTEM: pkgc_misc.c : 679: Rebased \Device\HarddiskVolume1\Solidcore\pkgc\10980000\Device\HarddiskVolume1\WINDOWS\system32\_si.dll to 10980000
K.1312.1316: Nov 30 2012:04:49:21.390: ERROR: imgp.c : 3190: 0001 Failed to set branch target 0x10c46740 from 0x00000000 at VA 0x10a56760.
K.0732.0828: Nov 30 2012:04:49:23.875: SYSTEM: utl.c : 520: Retrying usermode lookup of username [1].
K.0732.0828: Nov 30 2012:04:49:23.890: SYSTEM: utl.c : 476: Found username as WINXP-MCAFEE\phocean
K.1904.1932: Nov 30 2012:04:49:27.078: SYSTEM: pkgc_misc.c : 679: Rebased \Device\HarddiskVolume1\Solidcore\pkgc\20170000\Device\HarddiskVolume1\WINDOWS\system32\_si.dll to 20170000
K.1904.1932: Nov 30 2012:04:49:27.453: ERROR: imgp.c : 3190: 0002 Failed to set branch targ et 0x20436740 from 0x00000000 at VA 0x20246760.
[...]

We learn the driver entry point and that it is relocating a few strategic DLL: ntdll, kernel32, user32 and _si.dll. Ntdll, kernel32 and user32 are obviously the main user-mode API of Windows and we can expect that SolidCore is also putting a few hooks inside them. _si.dll is part of SolidCore and appear to be unlinked while the system is running.

Let’s look around modules to confirm the position fo the driver:

SolidCore driver

SolidCore driver (WinDbg kernel debugging)

So, the McAfee driver is named swin. Quickly looking around, we also find that a DLL is injected in all processes: scinject.dll. Also, see on the screenshot, how kernel32 was effectively relocated. So every time the machine will start, the library will be located at a different address (it could be interesting to check the entropy of this randomization, by the way, but this is another topic).

McAfee SolidCore, injection of scinject.dll in processes

McAfee SolidCore injects the DLL “scinject.dll” in running processes.

Just to make sure, I checked that the dll does not get injected by the registry setting:

McAfee SolidCore AppInit_DLLs

McAfee SolidCore does not use AppInit_DLLs

Nothing there, so it must be done through a hook.

First tests: Metasploit

I was told that SolidCore was doing good against Metasploit, so one of the first thing I did was to fire up Backtrack and play with it against the SP1 “solidified” target.

And I have to say that I was quickly disapointed.

Sure, I could not get a Meterpreter session or get a standard payload to work out of the box, whereas it was a piece of cake on the standard SP1.

SolidCore and payload failure

SolidCore prevents standard Metasploit payloads (including Meterpreter) to run successfully.

But if SolidCore was at least disturbing the exploitation, it did not protect at all against the vulnerability itself. So I got things like this:

SolidCore and Metasploit DoS

Denial of Service during exploitation attempt with Metasploit: SolidCore will not magically “patch” vulnerabilities!

A good old denial of service. Note that on the event log, SolidCore itself doesn’t log the exploitation attempt.

I did several tests and depending on the vulnerability I got:

  • service crash
  • system instability
  • complete DoS (system shutdown)
So if a script skiddie will not be able to control the target, he will still obviously be able to cause a lot of damage!

It was not really a surprise: McAfee will not patch the system! But think twice when you are said the contrary…

More tests, about memory protection: buffer overflows

As I was also told that McAfee was protecting user-mode apps against buffer overflows, I was even more excited.

I prepared various representative tests:

  • heap overflow, based on Aurora
  • stack overflows (one base on strcpy, the other one on Windows CreateFile)

But first, one thing I wanted to quickly eliminate was the memory randomization feature, named mp-vasr:

SolidCore mp-vasr

SolidCore mp-vasr IS NOT ALSR

mp-vasr is not ALSR! The function gets always loaded at the same memory address, so there is not process memory randomization at all… Another disappointment…

Next step was to try to exploit the stack overflow. The first payload I used displays a message box. It calls LoadLibrary and GetProcAddress to dynamically resolve function addresses.

When we try to exploit the buffer overflow, we get this:

SolidCore blocking a shellcode

SolidCore causes memory access violation during shellcode injection

We have a memory access violation, because the code is trying the access to the address NULL. Weird, let’s see it with OllyDbg.

First, there is something that looks like a hook in ntdll:

SolidCore checking against PE signature

SolidCore checking against PE signature

So this thing is checking the code for a PE signature (5A4D). Then, it will go through scinject.dll (by calling casp_inject_save_addr, wich is the only exported function).

I could not reverse it (which would require much more time and skills than I have now), but at least we know where it is sitting and how it is triggered.

If we continue the execution, we can then see that the buffer overflow is happening very well:

SolidCore and buffer overflow

SolidCore does not prevent stack overflow!

Yes, we have the stack is fully overflowed and we can control EIP! So nothing should prevent us from exploiting it, shouldn’t it? ;-)

Here we go:

This first payload is low-tech, with hardcoded addresses of MessageBoxA and ExitProcess:

global _start

_start:

 ;MessageBoxA(windowhandle,msg,title,type)
 mov ebx, 0xEEEEEEEF
 add ebx, 0x11111111 ;\0
 push ebx
 push 0x293a2064 ;d :)
 push 0x656e7770 ;pwne
 mov ecx, esp
 xor edx,edx
 push edx ;OK button
 push ecx ;title
 push ecx ;message
 push edx ;NULL window handle
 mov eax, 0x6a216476 ;MessageBoxA
 call eax
 ;exit
 xor edx,edx ;empty edx out
 push edx ;move address of MessageBoxA onto stack
 mov eax, 0x5cdb98fd ;ExitProcess(exitcode);
 call eax ;exit cleanly so we don't crash parent

Let’s how it looks in OllyDbg:

Buffer overflow exploitation despite McAfee Application Control

Buffer overflow exploitation despite McAfee Application Control

I then tested with another more sophisticated shellcode (sorry, I cannot publish this one as I am not the author), which resolves dynamically the addresses of kernel32 and GetProcAddress. It works as well. The only caveat that I observed is that LoadLibraryA is systemically blocked (after going through some scinject.dll routines, it always returns 0 in EAX, wich means failure).

In other words, a simple shellcode will work as long as the necessary library are loaded. Though most real life programs will already come with at least kernel32 and user32, it still gives a lot of opportunities.

And then, with more shellcoding kung-fu, I am sure it is possible to get something even more target independant. The following two articles from Phrack probably give most hints to achieve this:

But I need much more knowledge and practice in shellcoding before I can get something to work. I will see it later, and let me know if you could go ahead yourself.

Conclusion

Clearly, McAfee Application Control aka SolidCore is not an efficient protection against buffer overflows. If you want something much better, update your systems to something like Windows 7 64 bits and use Microsoft EMET to force DEP and ALSR on programs that don’t support it by default.

Also, no way to delay patching because you have SolidCore. Full exploitation (shellcode) is just made a little bit more difficult, and that’s it. The systems will still be exposed to many risks like denial of service unless they are patched. Like always, defense in depth and a proper security policy are the foundations to decide on the patching policy, not a tool or a feature.

This is a pity that the marketing teams give the wrong message, because McAfee still surely addresses many use cases. It is surely efficient enough to improve the control on workstations, that, for some reason, are difficult to control. For example, SolidCore will probably be enough to prevent the average Joe to mess the system. Why not being honest and keeping focus on this feature?

On the other hand, if the McAfee guys want to be as ambitious as they claim,  they will have to move SolidCore to the kernel-mode and enhance the memory protections from there.

Rootkit in my lab? (Part III)

First, thanks for all the comments in the previous articles (Part I and Part II).

I decided to analyze one the crash I experienced during registry analysis.
I could reproduce all the time a BSOD with Regshot. I thought it would be nice to see what I could get with WinDBG.

I had my environment set up with the suspicious VM configured to debug activated on the serial port, which is a simple pipe on Mac OS X.
Another VM is configured with a serial port as the other end of this pipe, and WinDBG attached to it.
Another method would be to just configure Windows to create a crashdump file with kernel symbols, that you can later load into WinDBG. Of course, the first method offers more opportunities to check and play with the live system.

Then, I just boot the target and trigger the crash, simply by starting a scan with Regshot:

Windows then crashes, WinDBG catches the exception and stops.

So what do we have ?

First, the error type, PAGE_FAULT_IN_NONPAGED_AREA (50), means that an instruction pointed to an invalid memory address. Let’s check this.

With !analyse -v, you get the full error dump.

Crashing Instruction

It shows the function (nt!CmpGetValueKeyFromCache, offset 0x89) and the memory address where the crash was triggered.

The instruction at this address is:

80637807 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

This instruction is trying to copy 8 bytes at the address pointed by EDI.
EDI has the value of 0xe1285050 at execution time.

And what do we have at this memory location ?

EDI pointing to invalid memory section

Nothing indeed. Note that this corruption persists at every boot.

So what can we conclude?
We can certainly exclude hardware failure, because it is a virtual machine and because the corruption always occur at the same memory region, even after a reboot.
At least, I can now be sure that something in the kernel is definitely corrupted.

Could it be a rootkit trick? Still the question remains, but to me it now looks very, very suspicious. Some rootkit code, poorly written, could have sat in this non-paged memory area and been paged out, causing the BSOD. I have not much knowledge about it at this time but I am going to search on this. At least, I now have good starting point to look at.

That’s all for today, folks. I wrote it while I am still working on it, so sorry if it looks rough and incomplete. It is sort of live, thoughts are still in process.

Again, I am looking forward to reading your comments and suggestions. (Hopefully) there will be a part IV!

Rootkit in my lab? (part II)

I finished checking the RAM with Volatility and… I found nothing. Nada.

It’s a lot of fustration. There must be something just there, but my findings are certainly limited by my skills.

I attach here some of the main outputs of Volatility. As far as I can tell:

  • no evidence of injection or kernel hooking
  • no suspicious process
  • no suspicious driver
  • no suspicious registry entry
  • etc.

Based on my observations, I first tried to narrow my investigations (drivers and hooks) but as I could not find anything, I ended dumping most of Volatility outputs in hope to see something unusual. I also compared them with a fresh Windows XP SP3 install. I extracted keyboard related drivers (keyboard.sys, kbdclass.sys, i8042prt.sys), hashed them, scanned them: there were native. I am less sure on how to deal with the software certificate system, but I did checked all Microsoft and root certificates in the bank along with their signature with a clean system: nothing wrong.

Dear reader, any help or tip is welcomed! Am I missing something obvious? Could it be possibly not a rootkit but some kind of corruption? If so, how to detect it?

Just drop me an e-mail if you want to have a look on the dump itself.

Volatility outputs:

Rootkit in my lab?

Context

For now, I can’t tell much about the context, mainly because it may – or may not – involve other people. The only thing I am interested in is to spot the issue and understand precisely what is going on.

What makes the case really interesting though, is that it occurred on a fresh install of a Windows XP virtual machine. I aimed it to be a clean malware reversing snapshot. I noticed the weired behavior minutes after finishing the system install and setting up a bunch of reversing and live analysis tools.

So I bet that if I got some malware, it probably comes from one of those. At this time, unfortunately, there are too many and I could not spot the exact time, so I can not start the analysis from this angle.

This article is almost written in live, so pardon my mistakes. I will update it as soon as I find something new. Of course, I am really expecting your feedback, suggestions and corrections. I see it as a great opportunity to learn, even though this one may not be the easiest…

Symptoms

Two things alerted me quickly.

The first one was, at a point, the permanent failure of going through the full windows update process. Believe me, I have tried all ways.

The second one was the weird dialog when trying to access to the keyboard layout settings. It says “Incompatible driver detected“. To me, this looks like there is a keylogger somewhere…

Suspicious activities: the keyboard driver and windows update seem to be messed

Then, as I started to check around, more odd stuff came out.

I fired up Process Explorer, and soon realize that it was “unable to verify” the signatures of all the running Windows processes. I could not find anything else suspicious, though (no odd process, memory content looks normal, etc.).

On the left, Process Explorer fails to validate any Windows process.
On the right, expected behavior on a clean system.

Ok, while I am with the Sysinternal suite, why not scanning with Rootkit Revealer:

Rootkit Revealer cannot access to the SYSTEM hive of the registry

Interesting… and what about GMER:

GMER crashes when accessing the registry…

Oops! Now it crashes when it is accessing the registry…

For the fun, let’s see what happens if we try to set up an antivirus (Security Essentials):

Windows certificate warning when installing… Microsoft Security Essentials!!!

Nice one! Very suspicious! Note that after a full scan, Security Essentials reports me that the system is clean and everything is fine. I am so relieved. :)

Curious to see how my certificates are, I run certmgr.msc. I compared all Microsoft root certificates with a clean machine and could not see anything different. But again something happened:

certmgr.msc crashes

Oh, just one of my last attempts to do live analysis (this the WinPcap setup included with Wireshark):

WinPCAP installation also fails

Ok, so enough played. The thing seems to be nicely done, and live analysis is going to be way too hard and unreliable.

Memory Analysis

This is where I am now. I reverted to a snapshot prior to my live analysis attemps, confirmed the strange behaviors are still observable, and suspended the VM to get the vmem file.

So I have spent the last hours scanning the memory with, of course, Volatility.

So far, I have to confess that I found NOTHING. But analyzing the memory can be a harsh process when it comes to sophisticated threats, and I may have reached the limits of my skills.

But, anyway, I could not dream of a greater and more exciting opportunity to learn!

My discoveries, if there are, will be published in another article.

UPDATE: I forgot to tell that it is a Windows XP SP3 machine, but not fully updated due to the issues.

Debugging the MBR with IDA Pro and Bochs

Analyzing the MBR is sometimes required during a forensic process, if you suspect a malicious activity that is not detected on-line. With static analysis, you may see if an obvious corruption happened, but you will need to debug to learn more.

Prerequisite :

  • IDA Pro (6.0) with the IDA Python plug-in (1.4.3)

Steps :

  1. Prepare your forensic disk image.
    In general, it is that simple :

    $ dd if=<source> of=disk.img bs=65536 conv=noerror

    Or :

    $ ddrescue -n <source> <dest> file.log

    Check the disk geometry using :

    $ fdisk -luc disk.img

    These values will be useful for step 5.
    However, if you have an exotic disk, it may be much trickier. For example, I got some geometry errors with a flash disk when using Bochs at step 11. Special thanks to Gene Cumm from the bochs-developpers mailing list who gave me the tip to specify the geometry to dd :

    $ dd if=input of=output bs=2064384 count=507

    2. Refer to CHS if you wonder how to get these values.

  2. Extract the MBR from the disk or from the image you just took. 
    $ dd if=<source> of=mbr.dump bs=512 count=5
  3. Download and install the Bochs x86-64 emulator, which comes with a debugger that will work nicely with IDA.
  4. Download this archive from Hexblog (IDA Pro’s blog). We will use two files from there : bochrc, wich is the configuration file for Bochs, and mbr.py which a python file helpful from preparing the debugging environment.
  5. Copy bochrc in your working directory and edit the following line to match your disk image geometry : 
    ata0-master: type=disk, path="sdb.img", mode=flat, cylinders=507, heads=64, spt=63

    Before going on, you may test that Bochs can use the image with these settings :

    C:\>"c:\Program Files\Bochs-2.4.5\bochsdbg.exe" -f bochsrc -q
  6. In the same directory, copy mbr.py and edit the following settings : 
    # Some constants
SECTOR_SIZE = 512
BOOT_START  = 0x7C00
BOOT_SIZE   = 0x7C00 + SECTOR_SIZE * 4
BOOT_END    = BOOT_START + BOOT_SIZE
SECTOR2     = BOOT_START + SECTOR_SIZE
MBRNAME    = "mbr.img"
IMGNAME     = "sdb.img"
  7. Now open a console and type : 
    C:\> mbr update
  8. With IDA Pro, open the boshrc file. IDA should recognize the format and set the proper settings.
  9. From the menu, open File/Script File and select mbr.py. It will close IDA after execution.
  10. Open again your *.idb file, set a breakpoint at 0x7C00.
  11. Start the debugger.

You should now be able to go ahead and debug the MBR step by step.

References :