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.

50 comments

  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:Should have used apps! by Anonymous Coward · · Score: 0

    Modern app appers know that modern apperating apps only app APP-signed apps, NOT LUDDITE code-signed software!

    Apps!

    Please run the KillMySelf app, you appsucker

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

  7. Nope by Anonymous Coward · · Score: 0

    It's "hackers" that did done it. You don't think our esteemed editors are "hackers", do you?

  8. 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 Anonymous Coward · · Score: 0

      You sound new to the industry. CRL's designed purpose, like everything else in technology, is irrelevant to what it can be used for. Further, any CA can simply use cert stapling to force revocation upon every verification or download attempt.

      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.

      Not with pinning. In addition, that would require the CA root cert private key to be compromised, which is always kept offline in professional CA's. That's like worrying about a specially crafted novel virus that bypasses all current vendor security explicitly crafted to only gain access to your smartphone selfies. Sure it's possible, but unless your last name is preceded with a political title there is nothing to worry about.

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

      No. Please stop spreading disinformation about the networking security field. Clear your browser cache, open the inspector, and watch the network timings. For a better view download Wireshark and learn how to use it. Learn what OCSP is. These things are taught in highschools now. People start in helpdesk for $10 an hour with this knowledge. Why don't you have it? Why are you writing as if you are an authority when cracking open a freshman textbook will show that you are twenty years behind and lacking theoretical understanding?

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

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

  9. Re:More evidence that CAs are useless window dress by Anonymous Coward · · Score: 0

    If you don't trust any, you can always make your own instead of whining an incomplete solution is the same as no solution at all.

  10. Re:More evidence that CAs are useless window dress by Anonymous Coward · · Score: 0

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

    Not if we use letsencrypt. You said it yourself that we cannot trust someone simply because they have a certificate. He could be the guy selling you fake Rolex from the back of his van, but at least you know that he owns and controls the domain (i.e. the van). That's really all that you can guarantee with certificates from an identity perspective anyway, that a public facing identity matches a domain controlled by the one presenting it to you. Whether that means that you should trust any further dealings with that domain is up to you at that point.

  11. 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 Anonymous Coward · · Score: 0

      Of course there is. You can even self-sign your code signing certificate.

      As my good buddy Bugs Bunny used to say, "What a Maroon" you are ...

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

  12. 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 Anonymous Coward · · Score: 0

      No, no, you've got it all wrong. Hackers are selling them, crackers are buying them.

    2. Re:bad title by Anonymous Coward · · Score: 0

      Buying AND selling. Because any "news" refering to "hackers" really means "THOSE BAD PEOPLES IN TEH INTARWEBBERTUBEZ!" Which "BAD PEOPLES" you ask? "WELL, THOSE!" and so forth.

      There are no hackers. They're all s'kiddies at best.

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

  13. Re:More evidence that CAs are useless window dress by Anonymous Coward · · Score: 0

    Uh no, most people can't.

  14. not a fan by Anonymous Coward · · Score: 0

    I wish I could have some form of code signing pseudonym. The software I write would benifit from a code signing certificate to authenticate it's from me but I certainly don't want my private details plastered all over it.

    1. Re:not a fan by Anonymous Coward · · Score: 0

      "private details" is actually only your name and possibly country/city of residence.
      Most people would have to provide more information than that just to get a domain...
      But I agree that there would be advantages to a reputation based system, which wouldn't really care what you are called and whether you are a dog or not, just that you have released good stuff before.
      You can just sign your releases with GPG though. Sure Windows won't handle it automatically and it only is useful for advanced users thus, but certainly better than nothing.

  15. Re:More evidence that CAs are useless window dress by Anonymous Coward · · Score: 0

    And what does that have to do with anything? You are obviously a misinformed moron.

    Anyone can BUY a code signing certificate.
    If someone bus one, they can use it to sign code.

    It is a an utter falsity that code signing certificates are stolen, forged, or what have you, and that is the point.

    The last time that a code signing certificate was "stolen" to sign malware was when the signing key was "stolen" by the United States in order to release their malware.

  16. Re: More evidence that CAs are useless window dres by Anonymous Coward · · Score: 0

    ...
    slow clap via facepalming

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

    3. Re:The certs do not define safety by Anonymous Coward · · Score: 0

      Certum does (approx. $25), startssl did (maybe still does?, approx $50)
      Well, depending on what you consider "negligible".
      Note that these certificates are a bit "lesser", they are not automatically FULLY trusted by Windows, you have to use them for a while to become so.
      But the EV ones are only available to organizations anyway.

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

  19. Re:More evidence that CAs are useless window dress by Anonymous Coward · · Score: 0

    Literally any modern OS can be a CA. Your Android phone can be a CA.

  20. We need a lets encrypt equivalent by Anonymous Coward · · Score: 0

    It's sad when those people can get certs more easily than independent developers. We need something that's like Letsencrypt that verifies applications based on on a site or something similar.

    1. Re:We need a lets encrypt equivalent by Anonymous Coward · · Score: 0

      The even more ridiculous part is, as OpenSource developer you can at least get relatively cheap certificates easy enough, but those aren't good enough to get crash reports! Completely ridiculous as of course the software can just include its own crash reported for the same effect, just with more duplicated code and higher risk for security issues. As a result, OpenSource projects don't do it. When it's a big enough project that then results in Microsoft themselves analyzing the bugs and the reporting it to the developers! WTF?!?
      Things like this just remind me how Microsoft still is completely incapable of understanding or even accommodating OpenSource.
      Another example is their store and the method to include "converted" desktop apps. Not only do you need a code signing certificate, you also need to answer loads of ridiculous questions.

  21. 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.
  22. 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.
  23. 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.
  24. Have no Fear APK will help you by Anonymous Coward · · Score: 0

    Have no fear APK will be along shortly to tell everyone about how hosts can stop you from being a victim of this by using his magic hosts file engine.

  25. The "trust" companies aren't trustworthy. by Anonymous Coward · · Score: 0

    The "trust" industry sells certificates in a way that makes it seem like you can trust any signed code, even though all they're doing is identity verification. Visit half a dozen software download sites and you'll easily run into malware wrapping installers that are signed with EV certificates. It's infuriating when an individual code signing certificate requires a visit to a notary, hard to meet requirements, and, after all that, gets blocked by the WIndows SmartScreen. As if my personal identity is less valuable than some throw away corporation registered by an industrial scale malware distributor.

    Last time I tried to get a code signing certificate from COMODO, they wanted ME to give THEM a link to an official list of notaries in my jurisdiction. Well, there isn't one, and the process for proper notary validation costs several times what they charge for the code signing certificates, so I'm positive none of the notary verification for personal code signing certificates in my jurisdiction gets done.

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

  27. Hosts work doing more for less natively by Anonymous Coward · · Score: 0

    See subject: It's fact like it's a fact I utterly destroyed "postbigbang"'s "points" https://it.slashdot.org/comments.pl?sid=11788759&cid=56189059/ easily along w/ UNIDENTIFIABLE anonymous "ne'er-do-well" troll who stalks me OR attempts to smear me etc. https://it.slashdot.org/comments.pl?sid=11788759&cid=56189141/ - especially the latter FOOL who tried LIES, lol!

    UNIDENTIFIABLE anonymous "ne'er-do-well" motives?

    Right here (along w/ their 'modus operandi's reasons' https://yro.slashdot.org/comments.pl?sid=11782351&cid=56188765/ as to WHY they stalk me anonymously - I've taken them down SO BADLY so many times, they have to do that, lol... I'd just toss their embarassing FAILS vs. me right back @ 'em & laugh!)

    APK

    P.S.=> Unbelievable - I block sources of threats online (most use host-domain names) you CAN'T be infected - period... apk