24 replies to this topic

[joakim]

While doing some trickery, I ran into this weird thing, and thought it would be worth sharing. One would expect that an executable that is signed with a digital certificate, should be impossible to tamper with without invalidating the certificate. It is possible. Actually, when thinking about it, it may not be surprising given the design of Portable Executables. But it still bothers me that this should be possible. So the basic and minimum steps:

• Grab 1 arbitrary signed executable from your system. Preferrably a Microsoft one to make the test more catching.
  
  
• Append garbage data at EOF, but make sure it's size is a multiple of FileAlignment (found in the Optional Header). Use hex editor or just "copy /b source.exe+garbage.data new.exe"
  
  
• Increase the size of the certificate as given by its entry in the Data Directories. Increased the value by what you added in step 2. Most easily done with a PE editor.
  
  
• Also increase the size of the certificate as given inside the certificate itself. It's the first 4 bytes. Do this with a hex editor.
  
  
• Finally, also update the checksum as found in the Optional Header. This last step is likely only necessary if you're modifying a boot application.

Verify the certificate by right-clicking on the file and go to Properties, and then to Digital signatures.

So what does this mean? Have currently no idea, but I think one should use other means (like SHA1 of file) for validating such files on the system. But the added data/code will not be executed, so it will not affect the functioning of the target program, although data is hidden in the file. That means the real usage likely is limited to data hiding (steganography). For instance, it may be possible to spread data around with chunks inside several files too.

So what do you think? Is there something wrong with how Windows evaluates the digital certificates in executables? Or is it as expected but irrelevant?

A PoC, DigitalSignatureTweaker is now added; http://reboot.pro/fi...gnaturetweaker/ or by following my mediafire account. It supports both 32-bit and 64-bit compiled executables and runs on both x86 and x64 OS too. The new version also supports compression, encryption and timestamp manipulation. In addition, a separate program is included to extract the hidden data. There's more information in the included readme.

[Brito]

I would say this is a flaw on the concept of digital certificate.

One should not be allowed to add any more data onto a certified file. On this case you wrecked the binary code portion, however I suspect that one can add the code as an extra data section that does not disturb normal functioning. The advantage of this method is using certified files as mule carriers for a malicious payload.

[joakim]

Holy crap I just noticed that you can make the tampered executable run properly too, with signature valid!!!!! To do so you must also adjust the size of the certificate as given inside the certificate itself. It is the very first bytes, so very easy to find. I'll update the first post with a 4'th step. This is even more ugly than I initially thought, and I can already think of bad uses... Quite amazing that the implementation is flawed! Think about it. You can hide porn images inside microsoft signed system files, and the digital signature is still valid, as well as the executable working just fine. This is definetely bad!

For those unfamiliar with the stuff;

Here's a nice and easy (and free) PE editor to use; http://www.ntcore.co...FF_Explorer.zip
And here is Microsoft's PE and COFF specification; http://msdn.microsof...rdware/gg463119

[Wonko the Sane]

Think about it. You can hide porn images inside microsoft signed system files, and the digital signature is still valid, as well as the executable working just fine. This is definetely bad!

Actually if the Microsoft Signed System file is actually a .jpg viewer, it could be interesting. The "bad" or "good" will depend on the quality of the p0rn you stuff inside it

Very nice find.
Waiting for a more detailed POF.....


Wonko

[joakim]

Yes I'll see if I can come up with a nice example. In the meantime take AutoIt compiled scripts as an example. You can use the base exe (the interpreter) without any actual script attached. Then sign it and you've got a good base. Then attach the actual script/program inside the certificate itself. Reuse the same signed executable with any compiled au3 attached (ie turn it into a completely different program), while keeping a valid signature.

@Wonko
It does not matter what executable it is, as it is a design issue and works on all executables I think. I'll see if I can hide a movie inside the kernel..

[joakim]

Yep, hiding a movie (3,1 MB in this case) was very successful. VMplayer.exe, signed by VMware) with the video embedded almost doubled its size, kept a valid signature and still worked perfectly. The theoretical max size of "garbage" is 0xFFFFFFFF - size of original certificate. Could be an interesting steganography technique..

[MedEvil]

I don't know if it is a design flaw.
The code portion stays the same in all examples.
If one can actually make use of the added code, then i agree that it a design flaw.

So far all examples have shown, that a certified file stays trustworthy.

[Wonko the Sane]

It's use may be not only for "evil" intent.

Just as an example, one could have a "signed" app like this:
http://reboot.pro/414/
http://f0dder.dcmemb...ekrit.index.php
that would "remain verified" no matter what you store in it


Wonko

[homes32]

thats pretty crazy.

[joakim]

I just noticed that the issue was described back in 2009; http://blog.barthe.p...ned-executable/ (and I did not know about that one until now). In the blogpost there also is a cpp source for a PoC. Have not compiled and tested it yet, but will do so and if it does not work I'll go and create my own.

[joakim]

So I've finished a PoC; http://www.mediafire...x8rw98efb23t4od

The cpp source from the other thread did not compile, and since I'm not not good in cpp, I did it my own way.

The PoC, named DigitalSignatureTweaker, works on both 32-bit and 64-bit executables. I have tested on both architectures and modified the kernel (ntoskrnl.exe) to contain some garbage data. Both Windows 8 (x32) and Windows 7 (x64) booted fine without complaints.
I realize the method is probably most interesting as a steganographic solution, but in the download there also exist a signed executable (base.exe - AutoIt) to show what can be done with that. Details in the readme. But it is still somewhat disturbing that malware and stuff can be added to a signed executables.

Additionally, to the steps already mentioned, one must also update the checksum of the PE if target is a boot application. The program this for you too (ie all steps).

Have fun!

[joakim]

Actually it is possible to modify the code sections as well without invalidating the signature. But to do so the signature must have been MD5 based; http://blog.didierst...md5-collisions/
Note that SHA1 is the default when signing, and SHA1 is not yet broken like MD5..

A note regarding my PoC:
With a (hopefully) successful file modification, one should get a messagbox saying: "Finished!", "Now please check the executable and its signature". If you don't have the necessary file access rights, the CreateFile function will fail and program will just silently terminate. Until that has been solved, you must grant yourself the necessary rights before launching the program.

[Wonko the Sane]

It seems that - given enough time - also SHA1 collisions may be found
http://en.wikipedia....iki/SHA-1#SHA-1
http://code.google.com/p/hashclash/
Though - even if it works - it seems like not being an "every day" solution

Until that has been solved, you must grant yourself the necessary rights before launching the program.

Would using this:
http://www.grubletra...app=PowerPrompt
work?

I have it renamed to "All your base are belong to us.exe" on my system, and it is often useful....


Wonko

[Brito]

Hello,

I am mentioning this topic on the cover of our newsletter. Would you please be so kind to update the first topic with the PoC?

Extra nice points if you upload the program to our download center instead of temporary file hosts: http://reboot.pro/fi...ory/8-security/

[joakim]

New updated version added and included in the download center. It now better detects file permission issues and if needed uses takeown.exe and icacls.exe to solve it before modification. Also more error messages to show what goes wrong if anything. And x32 and x64 binaries included. However x64 binaries can still be modified from a x32 environment..

Updated version at: http://reboot.pro/fi...gnaturetweaker/ and linked to in first post.

[sambul61]

Would an average AV package find a bug if hidden inside an exec?

[joakim]

Would an average AV package find a bug if hidden inside an exec?

I've always had Symantec and nothing else, so I don't feel like making a statement about the average AV. But for Symantec, it will NOT complain if you hide an executable inside the signature of another executable, and likewise of course for obfuscated or otherwise encrypted data. However, Symantec will trigger an alert if you hide an autoit exe inside either a regular executable or an autoit exe. In those special cases it will be detected as "Bloodhound.Malautoit" (something I first realized when doing challenge 18).

[Brito]

Thank you Joakim, very good work!

[joakim]

New version added with more functionality. It is now configurable to:
- Preserve filesystem timestamps on executable.
- Optionally compress data.
- Optionally AES256 encrypt the data.

Additionally:
- Now with a GUI that shows more verbose information in a lower pane.
- Added a custom header in front of hidden data so identification of it is possible.
- Added a separate program to extract data from signatures.

So it is now much easier to test as there exist 2 separate programs: 1 to inject and 1 to extract.

Note that there currently exist a bug when injecting data from a 64-bit OS, so that part must be done from a 32-bit OS.

Although not exactly the same, it is somewhat related and worth mentioning:
Microsoft Office 2007/2010 signed documents also can hold injected data without invalidating the signature. Again it is about file format exploration, and in this case it is ooXML (zip). It is much information to it, but I made another program some months ago to do this, so I'll just give a link; http://www.forensicf...iewtopic&t=7918 That is also a Proof of Concept, but I just now realized that also signed documents can contain injected data. So the drawback with the method, that injected data don't survive a save operation within Office, is not at all a problem with signed documents since such documents are locked for editing anyway!! Try for yourself by creating a docx, xlsx or pptx and then go through the inbuilt wizard in MS Office to sign the document. Then use my program to inject data to it, and lastly verify the document and its signature by opening it in MS Office.

[joakim]

Just fixed a bug in the usage of NtQueryInformationFile and NtSetInformationFile that prevented the timestamp stuff to work inside a 64-bit OS.

[iycgtptyarvg]

I find this very shocking. Adding a variable length chunk of data without invalidating the signature is a terrible security flaw!

Thanks for alerting us to this.

[joakim]

By accident, when rebuilding bootmgr of Windows 8, I noticed further issues with the validation of digital signatures. More areas (not at eof) inside the actual signature can be modified too, without invalidating it. On the good side though, the Windows Resource Protection, if scanning the file, would detect issues as it is hash based.

[AceInfinity]

I tried this on MSE with it's FileAlignment of 200 bytes... This is fairly interesting.

[topten2008]

I tried the utility to hide autoit exe script. It hides it inside and whe I check with av - it shows zero detection ! Thats pretty good! Thank you for your utility! Something what I can't understand- How can my Exe be  executed then?  Thanx in advance !

[AceInfinity]

I tried the utility to hide autoit exe script. It hides it inside and whe I check with av - it shows zero detection ! Thats pretty good! Thank you for your utility! Something what I can't understand- How can my Exe be  executed then?  Thanx in advance !

 

Your exe cannot be executed from that file unless, assuming the file you've embedded your exe within, is an exe itself, and you were to inject some code to manually do something with your program I would assume. Otherwise, your embedded file is just another resource.