Years ago I released a tool to create a Windows process with selected parent process: SelectMyParent.
You can not blindly trust parent-child process relations in Windows: the parent of a process can be different from the process that created that process.
Here I start selectmyparent from cmd.exe to launch notepad.exe with parent explorer.exe (PID 328):
Process Explorer reports explorer.exe as the parent (and not selectmyparent.exe):
Process Monitor also reports explorer.exe as the parent:
If we look in the call stack of the process creation of notepad.exe, we see 2 frames (6 and 7) with unknown modules:
We should see entries in the call stack for explorer.exe if notepad.exe was started by explorer.exe, but we don’t.
The <unknown> module is actually selectmyparent.exe.
0x11b1461 is the address of the instruction after the call to _main in ___tmainCRTStarup in selectmyparent.exe.
0x11b12a8 is the address of the instruction after the call to CreateProcessW in _main in selectmyparent.exe.
System Monitor also reports explorer.exe as the parent:
Finally, Volatility’s pstree command also reports explorer.exe as the parent:
For several years now I’ve been using my modified cmd.exe from Excel.
I’m not releasing this spreadsheet with my cmd code, but I release the VBA code. You can create your own spreadsheet (or Word document) with this VBA file. If you don’t know how, here’s a video:
Since I like to hack with Excel, I made a PoC for MS15-034 in VBA/Excel.
PS: If you want to see my videos as soon as they are published, subscribe to my video blog videos.DidierStevens.com or YouTube Channel.
Here’s the video:
It’s been some time that I posted a puzzle. So here is a new little puzzle.
What is special about this file?
In 2009 I added a command to my Disitool to inject data “into” an Authenticode signature without invalidating it.
This year I reported on some installer programs using this padding trick.
With MS13-098, Microsoft releases a patch to prevent this signature padding trick. This change in behavior will become active June 10th 2014.
But you can already activate it now by setting reg_sz key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Wintrust\Config\EnableCertPaddingCheck to “1”.
Here is the effect illustrated with my AnalyzePESig tool:
But beware of a potential issue with this regkey. Setting it to “0” will not revert to the old behavior (tested in VM with Windows XP SP3).
I had to deleted the key (actually, I renamed it) and reboot to revert to the old behavior. I informed Microsoft.
Soon I’ll release new versions of my Authenticode Tools.
Detecting extra data in the signature field is one of the new features. For example, it will analyze the size specified in the optional header data directory for security, the size specified in the WIN_CERTIFICATE structure and the size specified in the PKCS7 signature itself. These should be the same, taking into account some zero-byte padding.
In case you didn’t know: extra data can be added in the data directory that contains the signature, without invalidating the signature. My Disitool can do this.
With this new version of AnalyzePESig, I found some setup programs that contain extra data after the signature; data that seems to contain installation options for the installer. For example, the Google Chrome installer has this:
As you can see, the size specified in the optional header data directory for security and the size specified in the WIN_CERTIFICATE structure are both 6272 bytes, but the size of the PKCS7 signature is 6079. So that leaves 181 extra bytes. You can see them here:
And I found some other installers with extra data (config data or license information) in the signature directory: GotoMyPc, PowerGrep, RegexBuddy.
This update adds x64 shellcode support to my shellcode2vbs.py script.
A signed PDF file is just like all signed files with embedded signatures: the signature itself is excluded from the hash calculation.
Open a signed PDF document in a hex editor and search for string /ByteRange. You’ll find something like this:
36 0 obj
<</ByteRange[0 227012 248956 23362 ] /Contents<308226e106092a864886f7
This indicates which byte sequences are used for the hash calculation (position and length of each sequence). So in this example, byte sequence 227013-248955 is excluded, because it contains the signature in hex format padded with 0x00 bytes. This padding is not part of the DER signature, you can change it without changing or invalidating the signature.
I will give a talk on network forensics at my local ISSA chapter.
I’m preparing it with a couple of PoCs.
First PoC is how changing the canary value 0xFD0110DF to another value can provide defense against exploits like FX explained in this paper. I changed the appropriate instructions so that IOS uses canary value OxFC0220CF. You can see it at the bottom of this memory dump:
Second PoC is how I can change the behavior of an IOS command for offensive purposes. Topo mentioned this idea at Black Hat. The verify command checks the embedded MD5 signature in an IOS image. I patched the appropriate instructions so that the verify command always reports a valid signature, regardless of the actual embedded value:
I did not change CCO hash. This is the MD5 hash of the complete IOS image. I did not change this on purpose, but it would be as easy as changing the embedded hash. If you lookup this CCO hash with Cisco, you will not find it.
The ISSA Journal featured my article on Network Device Forensics, making it available to everyone.
And I’m giving a 2-day training on PDF at Hack In The Box Amsterdam 2013.