Stealthy malware infects digitally-signed files without altering hashes

Re: why am I _NOT_ surprised

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.

Re: "Nipravsky reverse-engineered Microsoft's undocumented portable executable loading process"

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.

Re: Why not?

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 <......>").