back to article 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 …

  1. bombastic bob Silver badge

    why am I _NOT_ surprised

    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.

    1. Electron Shepherd

      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.

  2. Pascal Monett Silver badge

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

    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.

    1. patrickstar

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

      1. Tchou

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

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

  3. frank ly

    Why not?

    "... and is not subject to hash calculation."

    Was there a 'good' reason for that, at the time the process was standardised?

    1. Jon 37

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

  4. s. pam Silver badge

    Yet another example of failed A/V and DRM

    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!

  5. Oh Homer
    Paris Hilton

    "not released"

    Except in the sense that they just revealed the "what" to malware developers, a group that is easily capable of working out the "how".

  6. Anonymous Coward
    Anonymous Coward


    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.

  7. energystar

    Something started to smell...

    When Red Hat began to supply dual hashes for their downloads, several years ago.

    1. Mainway
      Thumb Up

      Re: Something started to smell...

      Yes an don't you just love how these Black-Hat miscreants give there tool to all and sundry to download off the web so that any thirteen year old twerp with zits can sit in there bedroom doing the same!

  8. Ammer

    Nothing New...

    Changing a Signed Executable Without Altering Windows Digital Signature

    Posted by Aymeric Barthe Feb 22nd, 2009

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like