Didier Stevens

Tuesday 9 December 2008

Updates: bpmtk and Hakin9; PDF and Metasploit

Filed under: Announcement, Hacking, Malware, My Software, PDF, Update — Didier Stevens @ 21:23

Hakin9 has published my bpmtk article. The article mentions bpmtk version 0.1.4.0; however, this new version has no new features. But it comes with extra PoC code, like a LUA-mode keylogger and “rootkit”. New blogposts will explain this new PoC code.

bpmtk12

And upcoming bpmtk version 0.1.5.0 contains a new feature to inject shellcode. Just have to update the documentation.

On the PDF front: I’ve produced my first Ruby code ;-). I worked together with MC from Metasploit to optimize the PDF generation code in this util.printf exploit module. It uses some obfuscation techniques I described 8 months ago.

Monday 3 November 2008

Quickpost: Remember FireOx?

Filed under: Hacking, Quickpost — Didier Stevens @ 17:05

Remember FireOx?

This time, I tested my Excel scripts on a CommNet machine, here at TechEd Barcelona. Worked without problem.

Thursday 23 October 2008

Excel Exercises in Style

Filed under: Hacking — Didier Stevens @ 10:34

I developed another variant of my “Excel macro injects embedded DLL” script.

In stead of creating and loading a temporary DLL from VBScript, I inject and execute shellcode directly from the VBA application.

Some HIPS would prevent my previous script from running, because it loaded an unapproved DLL. But my new version doesn’t load a DLL.

Of course, writing shellcode is more difficult than developing a PE executable.

Sunday 7 September 2008

Mister P and Q’s Excellent Solution

Filed under: Encryption, Hacking, Puzzle — Didier Stevens @ 15:49

Mr. P and Q has solved my Authenticode Challenge. You can download his solution here, I copied his howto here below. I’ll add my own details in an upcoming post, but in the meantime, be sure to do a web search for the modulus.

What you need:
An internet connection
A windows system
A CPP compiler
OpenSSL installed

Step 1:
Export the certificate used by Didier from ac.exe to didier.cer
Select AC.EXE, Right click properties, Digital Signatures tab, "Details button", "View Certificate" button,Details tab, "Copy to File" button, select
the "DER encoded binary X.509(.CER)" option and export to didier.exe

Step 2:
Use OpenSSL to extract the modulus of the certificate used
OpenSSL>x509 -modulus -inform DER -in didier.cer

Step 3:
Use OpenSSL to convert didier's certificate in PEM format (for later use)
OpenSSL>x509 -inform DER -in didier.cer -outform PEM -out didier.pem

Step 4:
Copy the modulus extracted in step2 into FindPQ.cpp, build the application, execute and (wait ... wait ... wait ...) ^1000
or download http://www.boo.net/~jasonp/msieve.exe.
Start msieve
msieve -v -n 0xD0EA1ABA978DF0065B2009F75C846F28B04ED5143B237B3FC24272245ADE837EFE0271E1A2854E0C81BA9F70A83AD86D47B0EACD062BC15BC61A99DC83124EC9
and (wait ... wait ... wait ...)^100 until it finally displays:
prp78 factor: 102639592829741105772054196573991675900716567808038066803341933521790711307779
prp78 factor: 106603488380168454820927220360012878679207958575989291522270608237193062808643

Step 5:
Create a 'real' RSA key so we can re-sign the modified ac.exe (remember the first part of this challenge)
Copy the two factors found(step 4) into CreatePEM.cpp, build the application and excute.
The application will produce newkey.pem

Step 6:
Use OpenSSL to combine newkey.pem and didier.pem (step3) into a PKCS12 keyfile (you will need to provide a password of your choice)
OpenSSL>pkcs12 -export -in didier.pem -inkey newkey.pem -out magic.p12

Step 7:
Import magic.p12 into your Windows system
Simply double click magic.p12 select all the default options specify the password you defined in Step 6 when asked.

Step 8:
Download signcode
https://www.thawte.com/dynamic/en/images/support/inetSDk5.zip
unzip

Step 9
Start signcode, select the modified ac.exe, select the "Didier" key and you're done ...

Good luck
Mister P and Q.

Thursday 3 July 2008

bpmtk: A New Version With bpmtk.dll Included

Filed under: Hacking, My Software — Didier Stevens @ 8:41

Here is a new version of the Basic Process Manipulation Tool Kit (bpmtk).

Some noteworthy changes:

  • bpmtk.dll has been added
  • for ASCII: and UNICODE:, now you can specify a string with spaces by enclosing it in double quotes (ASCII:”My Name”)
  • write and search-and-write use VirtualProtectEx to change the virtual page protection when a write fails

So now you can also load the bpmtk as a DLL in a process and it will execute its configuration. The configuration is embedded in the DLL as an ASCII string. To change the configuration, you’ve 2 options:

  1. edit the source code and recompile the DLL
  2. binary edit bpmtk.dll and insert your config between the strings #BPMTK_CONFIG_BEGIN\r\n and #BPMTK_CONFIG_END\r\n. Terminate all lines of your config with CRLF

Wednesday 25 June 2008

bpmtk: Bypassing SRP with DLL Restrictions

Filed under: Hacking, My Software — Didier Stevens @ 6:51

In my last bpmtk post, I argued that although whitelisting DLLs (supplementary to whitelisting EXEs) prevents my Excel macro from loading the embedded DLL, it would be far too difficult to build and maintain such a whitelist of DLLs. However, Cd-MaN commented with a technique to add DLL restrictions to the Software Restriction Policies without building an exhaustive DLL whitelist, the details are in his excellent blogpost (step 3).

In a nutshell, Cd-MaN configures SRP to restrict allowed DLLs to those found in the Windows and Programs Files directories (a restricted user is not allowed to write to these directories).

To bypass this SRP configuration with my Excel macro, I had to update it so that it would perform the process manipulation directly, in stead of doing this manipulation from within the embedded DLL. And here his how I did it:

The trick is to call WriteProcessMemory directly from within the script to disable SRP. Because I didn’t want to recode my search-and-write function from C to VBscript, I hardcoded the addresses to write to (this will only work for the specified version of advapi32.dll). The effect of these 2 WriteProcessMemory calls is to patch advapi32.dll inside the Excel process, thereby disabling SRP so that the embedded DLL is allowed to load (of course, now that SRP is disabled for Excel, I can also just start another program).

A new version of my bpmtk utility (with the DLL version of bpmtk.exe) will be posted soon.

Thursday 5 June 2008

bpmtk: How About SRP Whitelists?

Filed under: Hacking, My Software — Didier Stevens @ 13:44

After having showed you how my Basic Process Manipulation Tool Kit can be used to bypass Software Restriction Policies, I wanted to follow this with a post showing how SRP whitelisting can prevent this. However, while preparing this new post, I got an idea how I could bypass SRP whitelists (under certain conditions), but I’ve no idea how to prevent this. I finally decided to post this without a solution, maybe you’ll come up with one.

With a SRP whitelist, starting a program is denied by default:

As an administrator, you’ve to explicitly specify the programs that are allowed to be executed by your users (if there are many programs, maintaining this whitelist becomes time consuming). Because of this whitelist, tools like gpdisable or bpmtk can’t be executed to disable SRP. However, if I can execute these tools without starting a new process, SRP will not block them …
Applications with embedded scripting can also be used to manipulate processes. For example, the scripting features of Microsoft Office allow you to call the system APIs I’ve been using in my bpmtk. It’s often not easy (even impossible) to convert a C program to VBscript, but I’ve a workaround.

First, we adapt our C program from an EXE to a DLL (entrypoint DllMain in stead of main), because VBscript can load a DLL.

We’ll use Excel’s scripting features. I’ve created an Excel spreadsheet that embeds a DLL that can be executed with a mouse-click:

The MyDLL dialog is displayed by the embedded DLL.

The DoIt button starts this Sub:

DoIt will create a temporary file (in the user’s temporary file folder), write the embedded DLL to it (DumpFile), and then load the DLL (LoadLibrary).

Generating the temporary filename:

Writing the embedded DLL to the temporary file:

Each DumpFileX sub writes bytes to the temporary file (the DLL is embedded in these subs by including the hex dump in strings). It’s necessary to split this over several subs, because of the sub size limitation.

Once the DLL is stored in the temporary file, we call LoadLibrary to load our library in the Excel process. And this executes our code inside the Excel process. Because of this, SRP will not deny it, and our code can disable SRP.

Creating temporary files and loading libraries is normal behavior for programs, SRP will not block this. Even most HIPS will not block this, because loading a library is not the same as injecting a DLL (injecting a DLL is loading a library inside another process). The only thing that might be considered abnormal by the HIPS, is that a temporary file is mapped into memory, but there are also legitimate programs that do this.

SRP has an option to whitelist DLLs, but then you’re facing the huge task of identifying and specifying all DLLs your programs use!

If you implement a SRP whitelist because you absolutely want to control the programs executed by your users, take some time to reflect on your users and the scripting capabilities of your whitelisted applications. And if you really have to prevent the technique I show here, you’ll have to find another solution than SRP whitelists. Unfortunately, I’ve not found one yet… If you’ve an idea, post a comment (banning applications with embedded scripting or disabling scripting is not an option).

Tuesday 3 June 2008

Quickpost: bpmtk Config File Embedding

Filed under: Hacking, My Software, Quickpost — Didier Stevens @ 5:59

After a rather long detour in PDF file format land, let’s pick up where we left the bpmtk.

My Basic Process Manipulation Tool Kit requires a configuration file with instructions to manipulate processes, like this one to start cmd.exe in a restricted environment:

start cmd.exe
search-and-write module:. unicode:DisableCMD hex:41

Save this configuration in a text file, for example start-cmd.txt. And then start bpmtk with this file:

bpmtk start-cmd.txt

You can also embed this configuration file inside the bpmtk executable, like this:

bpmtk start-cmd.txt bpmtk-cmd.exe

This will create a copy of bpmtk.exe, called bpmtk-cmd.exe, with start-cmd.txt embedded as a resource (called BPMTK).
When you execute bpmtk-cmd.exe (without any arguments), the embedded script will be executed. Use this
trick if you often have to execute the same command, or if you have to execute bpmtk in an environment where you cannot provide an argument.

Quickpost info

Tuesday 8 April 2008

Quickpost: Back from Black Hat Europe 2008

Filed under: Hacking, Quickpost — Didier Stevens @ 7:44

Back from Black Hat Europe 2008, my laptop has undergone another lobotomy.

Mikko from F-Secure was in my training class.

Some briefings I really liked:

  • New Viral Threats of PDF Language
    Good overview of the format of PDF files, and the inherent security issues. Good demos (like rewriting the Acrobat reader alert dialog box to mislead the user) and interesting insights (a PDF has a logical and physical structure, changing the physical structure doesn’t change the content of the document: this is polymorphism). The speaker confirmed that his exploits don’t affect Foxit reader. But the slides don’t to this justice, let’s hope they publish more details. And it was fun to see some French military lingo popping up in a BH presentation.
  • Intercepting Mobile Phone/GSM Traffic
    THC explained how they cracked GSM A5/1 encryption, FPGA style and with 2 TB of rainbow tables. Interesting tidbits: mobile operators don’t provide the strongest available encryption A5/3 (my guess as to why: cost), and the GSM status channel will carry permanent subscriber IDs, although the protocol only foresees temporary IDs.
  • Mobile Phone Spying Tools
    Tools mainly used by untrusting spouses, but I see potential uses for industrial espionage: sales man leaves company for competition, installs mobile phone spying tool on his corporate mobile phone just before handing it back.
  • DTRACE: The Reverse Engineer’s Unexpected Swiss Army Knife
    Looks really powerful and flexible, let’s hope someone is brave enough to attempt a Windows port.

And the networking was great, shout-out to Malta Info Security.

Quickpost info

Wednesday 19 March 2008

bpmtk: Spying on IE

Filed under: Hacking, My Software — Didier Stevens @ 11:07

I was asked if it’s possible to intercept IE’s HTTPS requests. It is, it’s not difficult, and you don’t need admin rights to do it on your own processes. In other words, a malware doesn’t even need admin rights to spy on your IE process, if said malware is also running under your user account.

We need to hook the API calls to WinINet functions, like HTTPOpenRequest. We can do this by patching the Delayed Import Address Table of executables calling WinINet functions. In our case, to spy on IE, we need to patch the DIAT of urlmon.dll. One simple way to hook these API calls, is to develop a DLL that will patch the DIAT, diverting the calls to our own functions. Our functions will just call the original functions while intercepting the data.

Here is an example for HTTPOpenRequest:

wininet1.png

HookHTTPOpenRequestA is our hook function for HTTPOpenRequest. It will just output the flags, verb and objectname parameters to the debugger, and then call the original HTTPOpenRequest function with unmodified arguments (which we saved in variable OriginalHTTPOpenRequestA). BTW, if the declaration and use of OriginalHTTPOpenRequestA looks confusing to you, read the explanation of function pointers in C.

Patching the DIAT is easy, use the PatchDIAT function that I provide with my Basic Process Manipulation Tool Kit (it’s in iat.c).

wininet2.png

PatchDIAT needs the name of the executable we want to patch (urlmon.dll), the name of the API to patch (wininet.dll), the name of the function to patch (HttpOpenRequestA), the address of our hooking function (HookHttpOpenRequestA) and a variable to store the address of the original function (OriginalHttpOpenRequestA). PatchDIAT returns S_OK when patching was successful.

We package everything in a DLL, while hooking some other functions, like InternetReadFile (to intercept actual data), and then inject this DLL in IE with my toolkit:

wininet6.png

wininet7.png

I’ve stored a test file on my server: https://DidierStevens.com/files/temp/test.txt. When you browse to this test file with the patched IE, you’ll see this in Sysinternal’s DebugView:

wininet5.png

Lines 0 to 4 indicate the patching IE was successful.

Line 5 shows IE opening a connection to didierstevens.com on port 443 (that’s 1BB in hexadecimal).

Line 6 shows the preparation of an HTTPS GET request to file /files/temp/test.txt. Flags 00C00000 indicate HTTPS and keep-alive.

Line 7 shows that the call to InternetReadFile was successful and read 25 bytes (0×19).

Line 8 shows the actual data retrieved by IE: This is just a text file.

The next lines indicate we unloaded our DLL with success (thus undoing the patch).

As you can see, we can intercept data before it is encrypted by the HTTPS connection (/files/temp/test.txt) and after it is decrypted (This is just a text file.). This works because we patch the executable before it calls API functions that handle the encryption/decryption, so we get access to the unencrypted data.

I kept my demo DLL very simple to show you the basic principles. A complete spying program would have to hook more functions and tie all the data together to present it in a user friendly way.

It’s also simple to adapt my IE spying DLL to tamper with the data. For example, it could redirect IE to another web site by changing the lpszServerName argument before it calls the original InternetConnect function.

Older Posts »

Blog at WordPress.com.