1. Injecting custom payload into signed Windows executables! Title
Igor Glücksmann
REcon 2012

2. Credits
Robert Žáček, AVAST Software

3. Overview Signed executable files & Windows
Format of signed PE files (Authenticode)
Modification method 1: limited targets
Modification method 2: more targets
Modification method 3: any executables
Fixing the vulnerability
Suggestions to developers

4. Signatures

5. Signed executables & Windows
Subject: executable (PE) files – EXE, DLL, SYS
Both 32- and 64-bit
Executables with an embedded digital signature
Microsoft Authenticode specification
Sig: signer name, optional product name, URL, timestamp
The signature asserts that:
The file originates from a specific software publisher
The file has not been altered since it was signed
Signing via Windows catalogs

6. PE files

7. Format of a PE file DOS header DOS stub NT headers Section headers
e_lfanew
NT headers
Section headers
Sections
Overlay

8. Format of a signed PE file
DOS header
Signature
DOS stub
File header
NT headers
Optional header
Checksum
Section headers
Data directories
Sections
Security directory
Overlay
The signature contains the hash of the “blue” area
Signature

9. PE file signature Signature is in PKCS#7 format
Uses X.509 v3 certificates
SignedData structure contains the hash of the file
Hash: SHA-1, SHA-256, MD5
Hash covers the whole file excluding the 3 regions
The chain of certificates should end in a trusted root
The user-mode API to validate signatures resides in wintrust.dll & imagehlp.dll

10. Modifying a signed executable

11. Story of a modification
Forum at
Modify a signed executable without invalidating its digital signature!
Appending arbitrary data to a signed file
Aymeric on software – February 22nd, 2009
Including tools to perform the modification easily

12. Appending arbitrary data
Append the payload
Go to the security directory table and adjust the size accordingly
Update the first DWORD of the signature accordingly
Update the checksum
Hash unchanged  sig valid
Payload not in the address space
Steganography?
We can do better!
DOS header
DOS stub
NT headers
Section headers
Sections
Overlay
Signature
Payload
Signature
Payload

13. Installers / SFX archives
DOS header
Unpacker stub + archive
Stub usually fixed, pre-built
Archive often in overlay
Finding the archive
Hardcoded offset
Parsing PE structures
Scanning for archive signature
What if the stub scans for the signature backwards?
DOS stub
NT headers
Section headers
Sections
Archive
Signature
Payload archive

14. ZIP archive The main header is at the end of the file
The exact behavior depends on the particular stub, but backward scan is common
Any interesting signed targets out there?
Local file header 1
File data 1
Local file header 2
File data 2 …
Local file header N
File data N
Central file header 1
Central file header 2 …
Central file header N
End header

15. Adobe Flash installer Demo…
High-profile target, almost everybody has it
Great for social engineering
A bit harder than just replacing a file in the archive (the installer is actually a downloader, encrypted files)
Handy: the installer runs elevated
Calls WinVerifyTrust to check its integrity…

16. Common SFX stubs Not just plain SFX, they can also run extracted files
Archive
Archiver
Behavior
ZIP
WinRAR
Scans backwards
WinZIP
Hardcoded offset, data in last section
Xceed
IZArc HP
RAR
Scans forwards
CAB
MS SFX
Data in resources
7ZIP
7-Zip
7zsfx
Scans forwards in the first 2MB
Not just plain SFX, they can also run extracted files

17. 7zsfx
Extended 7-Zip SFX stub with added installer features
Used by NVIDIA, Symantec, Comodo, TI, …
Stub + script + archive (+ signature)
Stub scans forwards, 2MB limit for archive, 1MB for script
Internationalization features (undocumented)
Searches for a localized script marker first (user locale based)
If not found, searches for the generic script marker
 Having a small signed archive, we can append a fake localized script (or more…)
Demo…

18. Real-world use Any malicious use?
No evidence about malware so far
But there is a non-malicious use! (to avoid repetitive signing?)
Microgaming (CAB), Support.com (ZIP), …
With a huge file set, you can find interesting carriers
ZIP (WinRAR) by Microsoft
ZIP (Custom) by HP, ZIP (Xceed) by Dell
Adobe installers
Acronis driver (x86/x64) with a ZIP in overlay

19. Method 1 overview We can append any data to the file overlay
The content is not mapped into the address space
We can exploit vulnerable application that process their files backwards, or don’t check the order of sigs
Limited scope
Design problem, hard to fix

20. Content beyond the signature
DOS header
Can there by any content after, but outside the signature?
Authenticode spec: yes
Windows XP SP2: no
Windows Vista/7/8… yes
Restrictions (no sig inside image)
The sig can be anywhere in the overlay, however
DOS stub
NT headers
Section headers
Sections
Overlay
Signature
Overlay 2

21. Moving the signature
DOS header
We can append an archive and merge it into the signature
Now, we can swap positions of those two blocks
And of course correct the offset
The hashed part has been split, but the whole “stream” remains the same
 Signature is still valid
DOS stub
NT headers
Section headers
Sections
Archive
Signature
Payload archive
Signature
Payload archive

22. Common installers Installer Behavior NSIS
Scans forwards for signature (by aligned blocks), CRC DWORD
Inno Setup
Offsets in PE header or resources – but point far into the overlay
Wise (old)
Hardcoded offset in data section, pointing to the beginning of overlay
Setup Factory
Scans forwards for a signature, only in a small block (img + overlay)
InstallShield
Parses DOS/NE header – skips sections to get to the overlay

23. Real-world use
We can now replace the extracted archive for many common SFX files (WinRAR, 7-Zip, …)
Additional installers affected (Nullsoft, Inno)
Doesn’t work on Windows XP SP2/SP3
Doesn’t work for drivers
Seems not to be used in the wild, just a few files:
With trailing zeros
Double signed (Borland)
NB10 record with link to PDB (Microsoft)

24. Method 2 overview
We can insert any data into the file overlay, provided the signature is moved before the insert point
The content is not mapped into the address space
We can exploit application that search for their signatures in the overlay, or use offsets into the middle of the overlay
Broader scope – many SFX archives and installers
Restricted to Vista+ OS, no drivers
Unless there’s a reason to allow data after the signature, easy to fix

25. Getting out of the overlay
Can we change the real image, not just the overlay?
The verification code checks that:
The signature doesn’t start before the end of any non-empty section (non-empty == PointerToRawData != 0)
There is at least one section
Overflows of section sizes etc.
MajorLinkerVersion >= 3 || MinorLinkerVersion >= 5 ?!
It seems we can’t get into the image because the file’s headers prevent that (by containing non-empty sections)

26. Inserting a new PE header
DOS header
Move the whole content, starting with DOS header’s e_lfanew field
Move the signature, so that its first DWORD (size) actually is the new e_lfanew field
Insert custom NT headers
Extend the signature to cover the whole new block, incl. the e_lfanew field
Remove checksum and sec. dir. record from the old image
DOS stub
New NT headers
New NT headers
NT headers
Sections
Overlay
Section headers
Signature

27. Final layout of the twisted file
DOS header
The signature now hides:
e_lfanew field (offset of NT header)
the signature itself
the new NT headers
anything else that may be in that block
The rest is not used, it’s there as an overlay to match the hash
What about our payload?
Signature
New NT headers
DOS stub
NT headers
Section headers
Sections
Overlay

28. Including a payload Checks we need to pass:
There has to be at least one section
There can’t be any non-empty sections before the signature
 We can have only empty sections
So, the payload has to be inside the header
Inconvenient, but there are options
The header can contain code, unless
the header has the NX bit enabled
the system has DEP enforced for all processes
We can point imports to a UNC path (WebDAV)
Demo…

29. Method 3 overview
We can twist any signed executable to insert our own NT headers
No sections – all code has to be in headers
Possible issues with DEP enforcement
Restricted to Vista+ OS, no drivers
Easy to fix, the files are just “wrong”

30. Affected Faking the data shown in
file’s properties page
UAC prompt
IE-downloaded file warning
Bypassing program’s self-checking if done on EXEs
Interesting for auto-updates if the product communication with its servers is not secured properly and can be tampered with
Evilgrade framework ( – DNS attacks
AppLocker / Software Restriction Policies

31. AppLocker Rules for executable modules, MSIs, scripts
Allow/deny for a user or group, based on:
Path
Publisher (extracted from the digital signature)
Any
Specific one
Specific publisher plus specific VersionInfo (product, file, version)
File hash
SHA256
Same excluded areas as the Authenticode hash!

32. Mitigation
If Authenticode specs could be updated (i.e. all the existing signed executables invalidated)…
Include the final size (file / signature) into the hashed part
chicken-egg problem, probably solvable (harder to sign though)
Restrict allowed items in PKCS#7/X.509 part to the bare minimum, check that the sig doesn’t contain anything else
Might be hard – additional “certs” in PKCS#7, optional attributes, BER encoding, Authenticode extensions (page-hashes)
Store the signature in a separate file, as a full-file hash
Slightly inconvenient to transfer
Signing via catalogs… doesn’t really help
File hash (SHA-1) stored in a separate file (signed itself)
Windows doesn’t check catalogs for all operations
Same excluded areas as the Authenticode hash!

33. Offical hotfix MS12-024 – April 10, 2012 Updated imagehlp.dll
Reintroduced check – signature ends at the end of file
If not, the Properties page doesn’t even show the sig tab
Fixes methods 2 & 3
Added scanner for banned markers within signature
Prevents method 1 for common SFX archives / installers
Again, the signature tab doesn’t show if a marker is present

34. Forbidden markers 50 markers
Cover known vulnerable SFX archives and installers
ZIP, CAB, 7zsfx, …
The list is extensible via registry
Some of the markers are just 4 bytes long…
Signatures of abused stubs don’t validate anymore
There probably are other vulnerable installers out there, and new ones may appear

35. For developers If you really need to write your own installer…
Remember a signature may be appended to your archive, and there may be something fishy inside
If looking for signatures, scan forwards, if multiples, use the 1st
Parse PE header and avoid the signature block
Read DOS header (IMAGE_DOS_HEADER), extract offset of PE header, seek
Read PE header (IMAGE_NT_HEADERS32/64), extract DataDirectory[ 4 ]
Use a hardcoded offset
You can put the content inside of the image, but…
Integrity checking by verifying your own signature via OS API may not be reliable

36. For developers 2 If you need to verify other files’ signatures
If using API, make sure the OS is up-to-date
If using own code
Validate the PE structure properly
No need to be too clever (sorting the excluded regions, …)
The file can’t be too twisted because the existing sign tools wouldn’t sign it
Make sure the signature is at the end of the file
Employ additional checks
Markers?
Size is not a good heuristics
Most signatures are below 10KB, but you can find some over 100KB

37. Conclusion
We cannot really trust that a signed file hasn’t been tampered with
For some files it matters, for some files it doesn’t
The major part has been fixed
Be careful not to add another vulnerable application to the list

38. References
Microsoft Portable Executable and Common Object File Format Specification
Windows Authenticode Portable Executable Signature Format
Microsoft Security Bulletin MS12-024

39. Q&A
Questions?