'No questions asked' Windows code cert slingers 'fuel trade' in digitally signed malware Trusted code-signing certificates are being sold to miscreants by allegedly unscrupulous vendors, fueling a growth in digitally signed Windows malware, a study has claimed. Security researchers at Masaryk University in the Czech Republic, and Maryland Cybersecurity Center (MCC) in the US, identified and monitored four …
a) Code Signing is not a security feature as it tells you nothing about the nature of the code, wether it's malevolent or benevolent or it has security critical bugs.
b) Outsourcing cryptography is a bad idea, particularly when it's outsourcing trust. Just because some entity unknown to you believes that X is trustworthy doesn't mean that you should trust X.
a) Code signing is as much secure as certificates are.
Just like everything in encryption, everything is secure as much as the keys are. If they keys aren't the whole encryption (signing does still use a form of encryption) is not secure.
The issue here is as long as keys are sold on a commercial basis only, without real checks and audits, they cannot be secure.
b) A lot of things work on a chain of trust. Even PGP....
Certificates are a broken idea anyway. Not only is it a horrid requirement for small companies or FOSS projects but it is completely unnecessary.
Look at HTTPS compared to SSH. With SSH, no signed certificate is required. The first time you log onto a server you get a signature in your "authorized" store and if it subsequently changes, you know something odd (not necessarily nefarious) is going on and you can inquire.
With HTTPS, you are at the absolute whims of "authorities" which can quite possibly be full of absolute idiots. I do not put my digital security trust in a bunch of idiots.
I predict that the main push for these things is to weaken open-source communities and smaller companies. It certainly does not provide security.
For stores where you cannot build from source... Peer review and checksums is probably the best you will get. It works very well for the pirate bay.
Which is no more than a self-signed certificate. You can still play MitM. In a sound SSH implementation you don't rely on the key the server presents you on first access.
You're right with CAs - they cannot be simple commercial entities just selling certificates for profit. They should be bound to much higher standards and liable for their mistakes. Just, it will make certificates more expensive, and people instead want stuff for free.
Certificates can either be self-signed or signed by someone else. The whole point of the story is that you can't trust the someone elses. So why do you have a problem with self-signed? At least ssh is encrypted which is a lot better than telnet was.
Code signing is not for encryption - code signing is for authentication and anti-tampering. Evidently, self-signed applications don't certify anything, and people may be deceived into using malware thinking it's from a trusted source.
Both HTTPS and SSH are encrypted regardless of the trust of the certificate/key, but as long as you can't trust the other end, encryption will just cut out of the loop some eavesdropper along the channel, but, still, your data may end in the wrong hands.
Unluckily, everything depends on how to trust the keys - and it's not just a technical problem. If someone along the chain will sell valid keys to crooks for money, and there's no process to stop him or her, we're f****d.
"Look at HTTPS compared to SSH. With SSH, no signed certificate is required. The first time you log onto a server you get a signature in your "authorized" store and if it subsequently changes, you know something odd (not necessarily nefarious) is going on and you can inquire."
When people visit hundreds of websites every day that method is completely unworkable, especially since much content comes from third-party sites and you never see their URLs in the browser. If the usual method to communicate a validity string, such as a SHA file hash, is to put it on the web page where a hacker could modify the binary and the hash value to match, it's of no value security-wise. It just assures you downloaded the backdoored malware intact. If you even bother to check the hash or SSH fingerprint.
And with the push to reduce the certificate validity period from two ears to one year or worse it's completely untenable. It only works for SSH because the certs never change, a risk in itself.
With HTTPS, you are at the absolute whims of "authorities" which can quite possibly be full of absolute idiots. I do not put my digital security trust in a bunch of idiots.
This problem is more general than just HTTPS, and it's not a total problem. HTTPS, after all, is "HTTP over SSL" in origin, although these days it's over TLS, and the certificate stuff is part of SSL/TLS.
And there is a little-known and monstrously impractical alternative to those authorities, called certificate pinning. You obtain the "public" certificate of the server you want to contact, and you get your software to use that certificate to verify that the server is the server you think it is.
I can't imagine trying to use certificate pinning for general HTTPS web browsing(1), but for contexts where *knowing* *absolutely* that the certificate presented by the server is the right one is important, it's the only way. (Example: automatic upgrades downloaded by upgrader modules.)
(1) Try to imagine the conversations you'd have with receptionists when you show up unannounced to obtain each company's public server certificates for your pinned browsing. If you think this is remotely practical, well, frankly, you're weird.
@KarlKarl you don't seem to understand certificates. SSH and HTTPS (SSL) are the same from this perspective. Both can use self-signed certificates. Your browser may not like a self signed cert, but that's not a good thing and neither is it a good thing in PuTTY etc.
You have no way of knowing that the server you connect to is the real one the first time unless that cert is trusted by a trusted authority already. If you don't install your own specific cert on your SSH service then you've missed an important security step in configuration.
The general principal is that MS (for example) pre-trust some known good authorities. Organisations buy certs from them which are therefore "trustworthy" in so much as you know who issues them. Alternatively you set up your own cert service and set your systems to trust that (in Windows land this is a domain policy). You then issue certificates for all your systems which your systems will then trust because they trust the root.
In your version, each system gets a random and self signed cert with no heirarchy so all I have to do to defeat you is set up a system with the same name and get your machine to connect to it instead of the machine you wanted. This is trivial DNS/hosts stuff. You will then trust that machine forever and not the real one?
So obviously, you just delete all the certificates in your OS/browser upon installation and when it then presents as an unknown certificate, you verify it as you would an SSH Key and only then do you add it to your certificate store, right?
You can turn such "trust" into your "ideal" SSH concept in seconds, just clear out the trusted certs. All of them. And the first time you go on The Reg you add its cert to the store. It's no different.
But, hey, it sounds really convenient and just what everyone will immediately do, I'm sure.
I see it the other way - it's not that because Verisign said its secure that I can trust it. It's that PayPal (or whoever) have chosen to use Verisign (or whoever) and therefore assume the risk when it all goes wrong. I still check that Paypal are who they say they are via HSTS, key pinning, secured DNS, etc. Who they choose to certify with is up to them.
Please note: No certificate authority is capable of sniffing encrypted traffic of the certificates that it signs. That's not how it works. They might be able to generate a FAKE certificate, but they can't sniff info you've sent to PayPal using the proper cert. And any fake certificate should flag immediately with any modern browser.
Code signing certificates a good idea in theory but not in practice as, since they were opened up to commercial exploitation there's no way to trust the vendors:
114kti Co
3rd Eye Solutions Ltd
Abingerdale
Ad Shows
Ahranta
Arcdo Co.
Beijing Gigabit Times Technology Co.
Biz Secure Labs Pvt. Ltd.
Buster Ind Com Imp e Exp de Acessorios P Autos Ltda
CDNetworks Co.
Changsha Hongfu Environmental Protection Technology Co.
CharacTell Ltd
Cigam Software Corporativo LTDA
CWI SOFTWARE LTDA
Cybercreat
Delta Controls
DIAGRAM SOFTWARE
DigitalDM Pty Ltd
Dmitry Shesterin
Eagle Point Software Corporation
Esaya.com Inc.
FSPro Labs
Gamsoft Sistemas de Informa̤̣o Ltda
Guangzhou ShuLian Software Technology Ltd
Guiyang Netho Technology service Co.
Haivision Network Video
Helpful Technologies
HS SOLUTION
INBEE.COM
IObit Information Technology
iS3
isonet ag
Jinan WanMing technology Co.
joaweb
John W.Richard
Korea Virtual Payment Co.
Kunshan Youxun Network Tech Co.
Myfolder net
NIA
OM NETWORKS Co.
pointmani
Positive Networks
Realtek Semiconductor Corp
Reg Revenue
Remedica Medical Education and Publishing Ltd
Respondus
S2BVISIO BELGIQUE SA
SHANGHAI ZHONGYUAN NETWORKS LIMITED
Shenzhen Hua?nan Xingfa Electronic Equipment Firm
Shenzhen Paojiaosizhi Information Technology Co.
Shenzhen Paojiaosizhi Information Technology Co.
Shenzhen QVOD Technology Co.
Shenzhen QVOD Technology Co.
Silver Arrow Color Labs.
Skyline Software Systems
SMART ADV LTD
Smart Plugin Ltda
smnetworks
SoftWindow
Syncode Sistemas e Tecnologia Ltda
TAB Software Corp.
Tavultesoft Pty Ltd
Technical and Commercial Consulting Pvt. Ltd.
Tencent Technology(Shenzhen) Company Limited
Tera information Technology co.Ltd
The Department of Education and Training
TT4YOU
WEBPIC DESENVOLVIMENTO DE SOFTWARE LTDA
Windowlink Ltd
WLSE Desenvolvimento de Software E Assessoria LTDA EPP
Code certifications provide very little security to end users, and they're becoming a real liability to the security of independent developers. There are very few companies offering affordable and accessible code certificates. Last time I bought one I had to send scans of my passport and other sensitive documents to a company I'd never heard of in Israel. When it came time to renew, I discovered the company had sold out to an even more questionable company in China, so who knows who has access to those docs now...
I don't think so. You seem to be saying that, if we just got over it and cheerfully spent the money, things would be better. These certs aren't free, and the problem's still there. Perhaps one reason we'd prefer the certification process to be free is that all the power for whether the code we wrote is trusted goes to someone else.
The same is true of https. Sure, you can see having a certificate that isn't self-signed as an indication that the server is likely to be who it says it is, but if you're really in a situation where you can't be sure of that, you have bigger problems. If you're getting DNS poisoned to bounce you or someone's taken over a domain name, the problem is big and needs to be dealt with more strongly. Meanwhile, an HTTPS cert of any type provides the user an encrypted connection to the site and protects them. You have to choose where you go, but https://www.iamevil.scammerparadise.net is still going to be risky no matter whether they paid someone to verify that they owned it.
One of the four apparently dodgy e-credential vendors tracked by the MCC team, for example, was “selling more than 10 certificates per month" netting a "total of $16,150 in revenue” over a period of roughly three months
It's unclear whether that means $16,150 every month for three months or $5,383 a month but, even in the best case scenario of $16,150 every month that's a grand total of $193.800 per annum.
After you factor in mooring costs, marina club membership fees, fuel, etc. that's barely even going to get you a reasonably sized boat in Marbella, never mind a yacht with a crew in Monaco.
Factor in more than one member of the crime syndicate, each of whom will take a cut, and before you know it, if you're lucky you'll have enough change from a day out in a pedalo on the Serpentine to get the kids a '99' with chocolate sauce each.
One of the pillars of our digital security is bought and sold so cheaply that, were I a criminal myself, I'd be looking at how much I might make versus the time I might do if caught and thinking "I could make more than that working for a living. Stop wasting my time and wake me up when you've found a way of making some real money, guys!"
Now that's scary.
True but, otoh, if I'm in a position to sell (albeit perhaps ill-gotten, nevertheless legit) certs on the 'net then I'm in a position to charge even more for legit services without the risk of doing five-to-ten and making nothing at all in the meantime, only to be released from my 'minimum security' prison with a ban on going anywhere near computer/networking technology for another ten-to-twenty.
Sub $200K p.a. is chickenfeed in today's cyber/techno-crime world and certainly not worth doing the time for - you can make more money as a vapourware consultant (and they don't work any longer hours than the criminal fraternity) or by getting VC/ICO/crowdfunding investment in some 'product' or 'platform' that'll never see the light of day let alone turn a profit by the time you sell it to some gullible schmuck(s) with more money than sense.
You're behind a "secured" door with thousands of keys that can unlock it, held by entities you don't remotely know other than their "close" relationship to Microsoft through a third party.
Let's just call it the "Security of Inconvenience" with the idea of trust replaced with blissful hope.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
