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 0×00 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.
I had a very good Samurai WTF training at Brucon by Raul Siles.
When Raul discussed the fact that clients are not worried about cross-site scripting when you demonstrate it with an alert box, I got the following idea:
Let’s redirect the customer to the competitor’s website. So instead of alert(“XSS”); let’s do window.location = “www.competitor.com”;. This will demonstrate that a cross-site script can cost your client money.
BTW, our training took place in a church:
I quickly developed a dll that kills calc.exe when started from anything else than explorer.exe.
This way, you can mess with all those PoCs that launch calc.exe ;-)
Last year I showed how to use a Teensy micro-controller to drop a PDF file with embedded executable. But I was limited to a file of a few kilobytes, because of the Arduino programming language I used for the Teensy.
In this post, I’m using WinAVR and I’m only limited by the amount of flash memory on my Teensy++.
First we use a new version of my PDF tools to create a PDF file with embedded file:
Filter i is exactly like filter h (ASCIIHexDecode), except that the lines of hex code are wrapped at 512 hex digits, making them digestible to our C compiler.
Another new feature of my make PDF tools is Python 3 support.
Here is a sample of our C code showing how to embed each line of the pure-ASCII PDF document as strings:
Macro PSTR makes that the string is stored in flash memory. The embedded executable is 57KB large, but still only takes half of the flash memory of my Teensy++.
After programming my Teensy++, I can fire up Notepad and let my Teensy++ type out the PDF document:
You can download my example for the WinAVR compiler here: