Hackers Are Selling Legitimate Code-signing Certificates To Evade Malware Detection (zdnet.com) 50
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.
Does this site work anymore? (Score:1)
What does that even mean? (Score:1)
Re: (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.
Re: (Score:2)
google are so hard! https://www.manpagez.com/man/1... [manpagez.com]
Re: (Score:1)
Re: (Score:2)
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 a
Re: (Score:2)
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 cer
More evidence that CAs are useless window dressing (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.
Re: (Score:2)
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.
Re: (Score:1)
There's already a company that can sign with the Microsoft certificate.
Re: (Score:2)
And it's not trustworthy.
No DV code signing certificates (Score:2)
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.
Re: (Score:2)
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.
The certs do not define safety (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
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.)
Must first incorporate or form an LLC (Score:2)
https://slashdot.org/comments.... [slashdot.org]
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 [dnb.com] requires your business to be organized as a corporation or LLC, not a doing-business-as or other passthrough [apple.com]. 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 credi
It's not the CA's fault people don't understand (Score:2)
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 wa
Re: (Score:2)
Indeed. And when I took a course on "authentication systems" about 3 decades ago, this potential problem was already well-known.
Revoke comes to mind (Score:3)
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
Re: (Score:3)
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 withou
Re: (Score:2)
Re: (Score:2)
It's mostly not entirely dependable because it happens so rarely (or happened, at least) that we still keep finding loopholes and faulty implementations.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
These professionals would rather check for fingerprint changes
... which is just a simplified explanation of pinning.
bad title (Score:3)
Re: (Score:2)
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.
Is it really that hard to get this correct? (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 head