Slashdot Mirror

← Back to Stories (view on slashdot.org)

Hackers Are Selling Legitimate Code-signing Certificates To Evade Malware Detection (zdnet.com)

Posted by msmash on from the security-woes dept.

Zack Whittaker, writing for ZDNet Security researchers have found that hackers are using code-signing certificates more to make it easier to bypass security appliances and infect their victims. New research by Recorded Future's Insikt Group found that hackers and malicious actors are obtaining legitimate certificates from issuing authorities in order to sign malicious code. That's contrary to the view that in most cases certificates are stolen from companies and developers and repurposed by hackers to make malware look more legitimate. Code-signing certificates are designed to give your desktop or mobile app a level of assurance by making apps look authentic. Whenever you open a code-signed app, it tells you who the developer is and provides a high level of integrity to the app that it hasn't been tampered with in some way. Most modern operating systems, including Macs , only run code-signed apps by default.

29 of 50 comments (clear)

  1. Does this site work anymore? by Anonymous Coward · · Score: 1

    Can I purchase a cert that helps?

  2. What does that even mean? by KBentley57 · · Score: 1

    "Most modern operating systems, including Macs , only run code-signed apps by default." 1. Acquire source 2. $COMPILER 3. ./a.out I must not understand, anything really. Can someone clear this up, or is this just some slow Sunday news?

    1. Re:What does that even mean? by Anonymous Coward · · Score: 1

      Your point is well taken. There are tons of ways to run unsigned code. Ignore that factual mistake. The point is that CAs are a very weak point in the system (as we all knew). Turns out delegating the keys to your kingdom, so to speak, isn't the best idea. The stewards of public trust, in this area like most others, are corrupt and greedy.

    2. Re:What does that even mean? by Gravis+Zero · · Score: 1

      google are so hard! https://www.manpagez.com/man/1...

      --
      Anons need not reply. Questions end with a question mark.
    3. Re:What does that even mean? by KBentley57 · · Score: 1

      Why would I ask google, when I could ask slashdot? That's as insane as asking someone to rtfm.

    4. Re:What does that even mean? by Dutch+Gun · · Score: 1

      Are you asking "why can I compile and run locally-built apps?"

      Macs (and I think Windows) set a special attribute on files that have been downloaded from potentially untrustworthy sources, like downloading from the internet. It's not completely correct to say that Macs will only run signed apps by default. Rather, by default, they only run apps which are downloaded from an untrusted source if they are signed with a valid code certificate. Needless to say, a locally compiled application doesn't have this attribute set.

      To demonstrate this in practice, try creating a local web server. Something like (if I recall correctly):

      python -m SimpleHTTPServer

      Open a browser to "localhost:8000"

      Then, "download" your executable and save it. Try to execute it, and you'll see your macOS protest, because that "unsafe" attribute has been set via the process of downloading and saving the executable via the browser. Once run, that attribute is cleared, and the program is considered safe for execution without further checks.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    5. Re:What does that even mean? by Jaime2 · · Score: 1

      It means that ZDNet copied and pasted text from a barely readable article at RecordedFuture, and made no effort to figure out what the original author was trying to say. The RecordedFuture article was mostly of the "the sky is falling" type, with very little actual analysis, so figuring out what they were trying to say wouldn't have helped all that much anyways.

      At the end of the day, what they were saying was that anti-malware software often uses a scoring system and code that's signed with a legitimate certificate starts off with a higher score than unsigned or improperly signed code, and therefore gets through some defenses. Pretty much everyone already knew this. They also said that issuers of signing certificates have profit pressure to lower the bar on validation. This is also not new and the primary reason that some security people see centralized certificate authorities as a "bad idea".

      The quote you reference is an incomplete analysis. MacOS and Windows both have a simple protection mechanism built in for software downloaded from the Internet: they ask an "Are you sure" question if the executable is not signed by a trusted source. This was never designed to stop all malware and does a good job of filtering much of it. If a computer has more sophisticated anti-malware installed, it will do more analysis and might block malware even if it's signed. They both described the feature incompletely and failed to mention that the behavior is actually a pretty good deterrent that either causes malware writer to choose a different deployment avenue, or significantly raises their cost.

  3. More evidence that CAs are useless window dressing by FrankSchwab · · Score: 5, Insightful

    So, we've found out in the past that some Certificate Authorities are about as trustworthy as the guy offering you Rolex's from the back of his van. At least he's open with the fact that he'll sell one to anyone.

    From that, we realized that a modern browser has innumerable CAs that they trust - and any one of them can issue rogue certificates.

    And now we realize that, not only do we have to worry about those, we have to recognize that, because the certificate issuance process isn't handled inside the client company, that anyone who can acquire the credentials of someone who can login to Digicert or whoever, can issue rogue certificates. And keeping credentials secret has been shown in the current world to be almost impossible.

    And yet we continue to write checks to CAs for certificates that we can't trust.

    --
    And the worms ate into his brain.
  4. Re:More evidence that CAs are useless window dress by Z00L00K · · Score: 1

    It doesn't have to be the CA in this case, it's enough if the developer has been compromised in some way, even more so if a major company has been compromised.

    Imagine if someone could sign their program with the Microsoft certificate - it would be a major effort to quench that mess.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  5. Re:More evidence that CAs are useless window dress by Anonymous Coward · · Score: 1

    There's already a company that can sign with the Microsoft certificate.

  6. Revoke comes to mind by oldgraybeard · · Score: 2

    Isn't that the whole basis of the trust systems response? Is that certs can be revoked?

    Just wondering? I guess if you got bit in the mean time you would be irked. But future things could be stopped? Maybe? Wondering?

    Just my 2 cents ;)

    1. Re:Revoke comes to mind by mysidia · · Score: 2

      Isn't that the whole basis of the trust systems response? Is that certs can be revoked?

      The Revokation mechanism is desgined to help with the rare case that the code signer's public key is compromised. It's NOT designed to facilitate the CA doing safety reviews on code they've signed to identify it as malware and cancel the signature.

      For performance reasons.... the Valid/Revoked status is generally cached at a minimum, for example, and some clients won't necessarily even check for revokation without a patch/upgrade being sent out to manually blacklist the cert --- the HARD end date on a cert is the expiration date on the cert;
        and revokation is not a very dependable facility; at least not without additional measures.

    2. Re:Revoke comes to mind by oldgraybeard · · Score: 1

      If that is true, what is the purpose? Why do we use it? Just my 2 cents ;)

    3. Re:Revoke comes to mind by Opportunist · · Score: 1

      It's mostly not entirely dependable because it happens so rarely (or happened, at least) that we still keep finding loopholes and faulty implementations.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    4. Re:Revoke comes to mind by Jaime2 · · Score: 1

      The purpose is to allow for a mechanism to recover from CA compromise, discovered protocol weakness, or private key compromise. If implemented properly, it would serve these purposes well. Unfortunately, the implementation of Certificate Revocation List checking has historically favored ease of access over security. It wasn't until a few years ago that some major web browsers checked for revocation at all.

      There are many reasons for this failure. Some security professional don't like the whole idea of the CA hierarchy and therefore don't put a lot of value in checking revocation status. These professionals would rather check for fingerprint changes and implement some sort of consensus-based mechanism to decide whether to trust a new cert. Some non-security minded folk think that checking for revocation only helps in very rare instances and hurts in the much more common cases of temporary unavailability of the CRL while also hurting performance - mostly in added connection latency.

      Think about this: a browser goes to an https site, gets a cert during the handshake and decides to check if the cert is revoked. The browser reads the CRL URL from the cert, and goes to download it. The CRL URL is almost certainly https, so it gets a cert when making that connection (unless the CRL is at the same domain as the content). This process repeats until there is a loop or until one of the CRLs is already in memory. Worst case, the CRL is on one of the sites that we are checking for revocation. In the event of a private key compromise, the bad actor can simply man-in-the-middle both the content and the CRL check. Presto, revocation check defeated. Absent this worst-case scenario, all of these checks are serialized, at least doubling the time it takes to connect.

    5. Re:Revoke comes to mind by mysidia · · Score: 1

      Absent this worst-case scenario, all of these checks are serialized, at least doubling the time it takes to connect.

      This is why operating systems cache CRLs for weeks; to avoid serialization of CRL check with requests.
      The issue is similar for running programs VS visiting a website, except users expect programs to launch even faster, AND
      even While offline or disconnected to the internet, So the system has even LESS time to check for revocation on a code certificate.

      The PKI standards were simply Not designed in a way to handle revocation in an acceptable manner for end-user computing, thus Revocation checks
      are widely delayed or permitted to fail ------ If you want to revoke a cert AND have high effectiveness, then this needs to be a high-profile revocation with
      an announcement, And a software update for certificate blacklisting that users and administrators are alerted to apply to their systems quickly.

      The CRL URL is almost certainly https

      No. From what I see; most of the time the CRL URL is most certainly non-HTTPS.
      It makes sense..... ultimately there would be a circular dependency if CRL servers were HTTPS.
      Also, when the CRL is a HTTP file -- the file being downloaded generally has to be signed by the CA itself;
      one of the cool things about OCSP (for CA's that support) is the CA can delegate a separate certificate to handle revocations through the OCSP server,
      so the CA certificate does not have to be kept online to sign every new CRL.

    6. Re:Revoke comes to mind by Jaime2 · · Score: 1
      Pinning is an alternative to certificate revocation. The fact that pinning does not suffer the same weaknesses makes none of the above statements about certificate revocation invalid. Actually, I even said this:

      These professionals would rather check for fingerprint changes

      ... which is just a simplified explanation of pinning.

  7. No DV code signing certificates by tepples · · Score: 1

    One key difference between the TLS certificates that Let's Encrypt offers and code signing certificates is that the latter are always at least organization-validated. There's currently no counterpart in the code signing PKI to domain validation.

    1. Re:No DV code signing certificates by tepples · · Score: 1

      There's currently no counterpart in the code signing PKI to domain validation.

      Of course there is.

      What CA issues a code signing certificate that operating systems trust automatically based solely on evidence of domain ownership?

      You can even self-sign your code signing certificate.

      That has the same drawback as self-signed TLS certificates. Because operating systems do not trust them, the operating system assumes that the publisher is trying to impersonate the would-be rightful holder of such a certificate and blocks execution.

  8. bad title by superwiz · · Score: 2

    Shouldn't it be "hackers are buying..." instead of "hackers are selling..."?

    --
    Any guest worker system is indistinguishable from indentured servitude.
    1. Re:bad title by MobyDisk · · Score: 1

      Yes, but no. The article says that hackers hack into Apple, Comodo, or Symantec and use their credentials to generate and sell certificates. So hackers are selling the certificates, and buying the certificates too.

  9. The certs do not define safety by aberglas · · Score: 1

    There is absolutely nothing wrong with thieves.com getting a code signing cert that validates that their malware is genuine thieves.com malware.

    The user then gets a message

    Do you trust gobbldy gook ... press OK if you want to get on with your work.

    They press OK.

    That said, I recently got a cert and the checks were essentially meaningless.

    1. Re:The certs do not define safety by tepples · · Score: 1

      There is absolutely nothing wrong with thieves.com getting a code signing cert that validates that their malware is genuine thieves.com malware.

      Except the CAs that I'm aware of don't trust domain ownership; they insist on (at least pretending) to verify the organization's identity and charging for that (purported) service. Either that or there's some automated CA that I'm not aware of that offers a code signing certificate accepted by Windows at negligible or no cost to, say, free software developers or hobbyist developers of proprietary freeware. Which CA might that be?

    2. Re:The certs do not define safety by aberglas · · Score: 1

      Theives.com can be a perfectly valid organization. Their line of business just happens to be malware. The CA is not saying anything about the products they provide.

      Further, in practice, all you need is a DUNs number, which you get just by applying to them. The CA then checks that number matches your name. So no check at all really. (I recently bought a code signing cert.)

  10. Must first incorporate or form an LLC by tepples · · Score: 1

    https://slashdot.org/comments....

    The CA is not saying anything about the products they provide.

    Agreed.

    Further, in practice, all you need is a DUNs number, which you get just by applying to them. The CA then checks that number matches your name.

    Apparently getting a D-U-N-S number requires your business to be organized as a corporation or LLC, not a doing-business-as or other passthrough. Thus there's also the cost to incorporate or form an LLC with your jurisdiction's business regulator, keep that corporation or LLC renewed, and file its income tax return. Or should every developer of free software and every hobbyist developer of proprietary freeware be expected to have already done this?

    So no check at all really.

    And that your credit card is valid.

  11. It's not the CA's fault people don't understand by Opportunist · · Score: 1

    When people attribute a trait to something that doesn't have it, is it said something's fault to not have it?

    A certificate does not say that something is safe. Only that whoever claims to be the originator really is the originator. If you enter your online banking credentials for your SuperOnlineBank into the (certificated) site hxxps://superonlinbank.com, whose fault is it? If you took a look at the certificate (or the URL, for that matter) you could easily have seen that you're not dealing with who you want to deal with.

    In other words, a certificate only verifies that whoever signed the site, the executable, the document, is actually who he claims to be. Not that he is in any way trustworthy or that you can turn your brain off and let the certificate do the work. It cannot do that. How should it?

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  12. Re:More evidence that CAs are useless window dress by Opportunist · · Score: 1

    And it's not trustworthy.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  13. Re:More evidence that CAs are useless window dress by gweihir · · Score: 1

    Indeed. And when I took a course on "authentication systems" about 3 decades ago, this potential problem was already well-known.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  14. Is it really that hard to get this correct? by michael_wojcik · · Score: 1

    They're not selling certificates. The CAs are selling the certificates, which are public documents once they're created.

    The "hackers" are selling the private keys that correspond to the certificates.

    This is a perfectly sensible, if unethical, business model. The incentive to keep the key private is to avoid diluting (usually to nothing) the value of certificate as a proof of provenance. Someone who obtains a code-signing certificate with the intent of selling the key doesn't have that incentive.

    And the headline's emphasis is wrong. As summary and TFA mention, the key finding is that these resold keys are displacing stolen keys for signing malware. And "legitimate" is imprecise, since (according to the research) while the certificates were obtained directly from CAs, that was under false pretense, with stolen credentials. So if the researchers are correct, this is more a shift from stealing signing keys to stealing credentials used to obtain certificates for keys generated by the attacker. That's not new; it's just more common than was popularly thought.