Didier Stevens

Tuesday 20 July 2010

Mitigating .LNK Exploitation With SRP

Filed under: Vulnerabilities — Didier Stevens @ 7:13

As I’ve used Software Restriction Policies (SRP) on several occasions in my blogposts, and several people have suggested using SRP to protect against .LNK exploitation as an alternative to Ariad, I’ll describe how to configure SRP for the first time on a workstation that is not a member of a domain. For domain members, you have to configure SRP in the GPO on the domain controller.

Start the Local Security Policy manager from Control Panel / Administrative Tools:

Software Restriction Policies need to be defined the first time:

We exclude our system drive (C:) from being restricted (add other drives if you have more):

To protect against .LNK exploitation, we need to restrict DLLs too, not only EXEs:

And finally, switch from blacklisting to whitelisting:

After configuring SRP, execute a logoff/logon to apply them immediately.

From now on, only executables on your C: drive will be allowed to run.

.LNK exploitation from removable media is blocked:

Sunday 18 July 2010

Mitigating .LNK Exploitation With Ariad

Filed under: My Software,Vulnerabilities — Didier Stevens @ 13:42

Today I tested @Ivanlef0u ‘s .LNK PoC with my latest Ariad tool.

I adapted the PoC to work on a CD-ROM for drive D. When you load the CD-ROM with the PoC (I use an ISO file inside a VM) and take a look at DbgView’s output, you’ll notice that payload gets executed:

With Ariad installed on the machine in its default configuration (just block \autorun.inf), the PoC still works:

But configuring Ariad to block access to executables (this includes .LNK) prevents the PoC from executing:


Access to the .LNK file is denied, and Windows Explorer can’t start the payload.

And configuring Ariad to prevent files to be mapped in memory (this is something done by Windows with executables) also prevents the PoC from executing:


This time, access to the .LNK file is not denied, but dll.dll is prevented from loading into memory, thus again preventing the payload from executing.

You can use Ariad if you want to mitigate attacks with these shortcut links until Microsoft releases a patch. As it is expected that Microsoft will not release a patch for Windows XP SP2, Ariad can offer permanent mitigation.

Be sure to read Ariad‘s documentation before using it.

Thursday 15 July 2010

The Hex Factor RE Challenge

Filed under: My Software — Didier Stevens @ 18:11

Last year for Brucon, I produced some reverse engineering challenges (and I’m producing new ones for this year’s edition).

The Hex Factor blog posted the solution for level 300.

The source code for the challenge can be downloaded here. It’s completely written in assembler, even the I/O routines.

Here’s a trick I used to create your own EXE from assembler code, without any library:

A simple assembly program:

    BITS 32

    ret

Assemble with nasm: nasm -f win32 ret.asm -o ret.o

And link with mingw32‘s linker: ld -s ret.o -o ret.exe

Result:

Sunday 4 July 2010

Quickpost: Preventing the /Launch Action “cmd.exe” Bypass

Filed under: PDF,Quickpost — Didier Stevens @ 21:20

Adobe has released a new Adobe Reader version that contains functionality to block my /Launch action PoC, but Bkis found a bypass: just put double quotes around cmd.exe, like this:  “cmd.exe”.

I did some research and discovered that Adobe implemented a blacklist of extensions for the launch action, but that the blacklisting functionality identifies the file type of “cmd.exe” as .exe”, and not .exe

Adobe is aware of the issue, and will evaluate the need to fix the blacklisting functionality.

But meanwhile, you can apply my fix to block launching “cmd.exe”.

You can configure the blacklist of extensions via the registry. Go to HKLM\SOFTWARE\Policies\Adobe\product\version\FeatureLockDown\cDefaultLaunchAttachmentPerms and open registry value tBuiltInPermList.

This is a list of |-separated extensions, together with the action Adobe Reader should take (3 means block the extension). Add .exe”:3 to block “cmd.exe”:

With this addition, Bkis’ bypass will not work anymore:

Some further testing shows that adding 2 double quotes is also a way to bypass the blacklist: “”cmd.exe””:

So we need to block this too:

I tested 3 and 4 quotes too, but this is not accepted by Adobe Reader. But should there still be other valid characters to append to the extension, you can block them in the same way as I showed here, until Adobe fixes the blacklist functionality.

Quickpost info

Blog at WordPress.com.