Stealthy malware infects digitally-signed files without altering hashes Deep Instinct researcher Tom Nipravsky has undermined the ubiquitous security technique of digitally-signed files by baking malicious code into headers without tripping popular security tools. Nipravsky inserted malicious code into the small header attribute certification table field which contains information about digital …
Why am I _NOT_ surprised that a way of bypassing the alleged security of code signing' would eventually render it POINTLESS.
I don't have *ANY* love for "the tollbooth" involving 3rd party cert authorities, or (worse yet) the NEW requirement for ONLY MICROSOFT to sign a device driver for windows 10. It's just another tollbooth, after all, and just another way to *KILL* open source and limit what end-users can do with their own computers.
Well, looks like it was a complete waste of time, eh Microsoft? Or was your ORIGINAL motivation just another way of "protecting" DRM... which was another failure.
I guess we'll all just have to go back to NOT trusting binary executable downloads again, doing more frequent backups, and being VERY careful about clicking 'Yes' to the "Run Installer" prompt.
Digital signatures have never proved that code doesn't contain malware. We digitally sign all of our executables and installations - but the installation could still completely pwn a system if we wrote it that way, since installations usually run with effectively local Administrator privileges.
What they do is tell you who wrote the code (or at least who signed it), so you know who to blame if things go wrong. The problem now is not that digitally signed executables contain malware, but that the attribution of the malware can no longer be assumed from the certificate.
By the way, the Windows 10 requirement of requiring a Microsoft cross-signed digital signature is only for 64-bit kernel-mode drivers, and it can be disabled with one command, followed by a reboot.
And that is why you do not count on undocumented features for security when Internet connectivity is the order of the day.
The era of secret code is disappearing under the inexorable march of Internet connectivity and Open Source. It is now a security risk to not disclose your code and processes because that approach deprives you of all the eyes that can validate your code and ensure things will not become a major security failure.
Because the blackhats will deconstruct your code anyway, and they will find what you missed.
The format is documented. There is no reliance on obscurity, and there was no reverse engineering involved in "discovering" this. See http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx and the actual paper instead of the crappy Reg reporting of it.
The paper isn't even an attack on Authenticode per se - it's just a way to store stuff in PE executables without altering their signatures. This does not mean whatever you added actually gets executed. There still has to be code that actually loads and runs it - you could achieve the same thing by just having the PE executable load an external file from disk or over the network. This is what the "reflective PE loading" hype is about - a technique that's well used for ages for both malicious and non-malicious purposes.
At most it's an attack on stupid AVs that blindly assume a signed PE should never be checked for signatures etc. A well-known attack, even. And you still have traceability as to who signed a PE that does crazy stuff like loading code from its signature.
I don't know if storing the code to be loaded in this particular place has been done before, but similar and more advanced certainly has. One example would be bypassing kernel driver signing by loading a driver with a known vulnerability and exploiting it.
Stopping this completely is well recognized as impossible - even if you outright ban introducing new code at runtime (which certain smartphones do if I'm not mistaken), you can still introduce code into an interpreter or virtual machine.
"There still has to be code that actually loads and runs it"
Yes, but the program could actually read itself once loaded in memory so it sort of auto-execute an inner program.
Just wanted to point this out.
If you're signing a file, and putting the signature back into the same file, then you can't hash the signature because it doesn't exist yet! So *at least* the signature has to be excluded from the hash. If your file format supports multiple signatures (e.g. if you want to be able to sign with BOTH an old signature algorithm for compatibility with older OSs, and a new signature algorithm for compatibility with newer more secure OSs), then you have to exclude all the signatures from the hash.
Now, programmers have a nasty tendency at this point to start saying "ok, so some bits of the file are signed, some are excluded from the signature, lets allow some other things to be excluded from signature". And, in every case it's been tried, they then proceed to get it wrong and that horribly breaks security : PGP clearsigned messages were broken that way, PGP keys were broken that way, TLS certificates were broken that way, and now Authenticode is broken that way.
(PGP clearsigned messages allowed arbitrary headers at the start of the message that weren't verified, which was intended for "Hash: SHA256" but actually allowed e.g: "Dear: Norad, Please launch the missiles at the coordinates <......>").
Perfect example why products from companies like Symantec, McAfee and others are so shit. First they'll not detect the in-flight files, then their archiving products won't detect mucked with headers.
This looks like a beautiful way to finally put a bolt-hole in MSFT's pathetically crap DRM functionality!
All this "researcher" has done is write a program that would arbitrarily executes unsigned data. Big deal.
Embedding data within the certificate of a PE is both required for embedded certificates (multiple signers, etc.), but has been in live use for _years_... This is how things like webex go about embedding configuration inside of a signed executable that you download over the web. The point isn't that this is somehow a by-pass of PE signing, it is simply a way of attaching data to a signed PE. What that PE (or in this case of BS-"research" writting an entirely new 'loader') does with that data is the question. A well written application checks some additional signature on the data before use, a not so well written one might do just about any thing that you can do with data on a computer - including execute it.
The assertion that this gets 'past' AV is a bit silly however. I _wish_ that McAfee in particular even knew what a PE signature was, yet alone could exclude scanning based on one. It doesn't. Full file hashes every day all the time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
