German researchers find a way to circumvent Domain Validation
The attack uses DNS poisoning to trick CAs into issuing fraudulent certificates
Researchers in Germany have found a way to trick Certificate Authorities into issuing fraudulent SSL certificates in what could represent a major threat to the SSL/TLS ecosystem.
Per a report by The Register, which spoke to one of the researchers, Dr. Haya Shulman of the Fraunhofer Institute for Secure Information Technology, the attack can essentially trick some CAs into incorrectly issuing SSL certificates. Obviously, the threat here is that spoofers could get an SSL certificate for someone else’s domain and use it to create a frighteningly convincing copy of that website. So convincing, in fact, that even a user’s web browser would be tricked by it.
The attacker could then phish people, infect them with malware or just steal their credentials. Shulman and her team have published their findings in a report that will be presented at the ACM Conference on Computer and Communications Security in Toronto next month. They have not divulged the names of the CAs that can be duped by the attack.
I asked around a little bit this morning and while I can now rule a few CAs out, I couldn’t find out who is affected.
The Register, which has seen the researcher paper, published the following excerpt:
The attack exploits DNS cache poisoning and tricks the CA into issuing fraudulent certificates for domains the attacker does not legitimately own – namely certificates binding the attacker’s public key to a victim domain.
The attack is initiated by a DNS request. The attacker must then craft a correct DNS response before the actual response from the real name-server gets there. The technique actually ensures that the DNS domain validation checks the CA is attempting are performed, but using the attacker’s DNS server instead of the one associated with the targeted domain.
The attack depends on getting said DNS responses broken into fragments, and then injecting malicious fragments to fool the CA into handing over the cert to the attacker. The first fragments of the response contain valid DNS challenge-response fields. The inserted fragments can be whatever the miscreant needs to complete the transaction so that he or she gets the cert.
It’s worth noting that this technique only works on Domain Validation SSL certificates (not OV or EV) and requires some fairly extensive legwork before it would be viable. It may only take a laptop, but an amateur would struggle to gather the correct information – namely responses from the target’s name-server that can then be “offset where the fragmentation occurs.”
The researchers suggest something called DV++ as a fix. This is an offshoot of a distributed trust concept that a lot of researchers and infosec experts have begun to examine lately.
In a distributed trust scenario, the functions typically performed by a central “monolithic” Certificate Authority are instead decentralized, which is a really popular term right now thanks to all the cryptocurrency and blockchain marketing bros that have co-opted it.
Basically it would work like this, rather than a single entity performing domain validation, the domain owner would have to assert ownership to multiple stakeholders.
“To pass a DV++ validation, domain owners must prove their ownership to a majority of the agents in a fully automated manner by responding to queries sent by the agents for the resource records in the domain.”
In some versions of the distributed trust model, like Milagro’s, the authentication check performed when a client arrives at a website would be met by three or more Trust Authorities, all of whom would have pieces of a public key. The user’s browser would then assemble the key pieces into a single key. This would potentially protect against Root Compromise.
What a distributed trust model would represent is a step away from the Public Key Infrastructure model that is currently used by SSL/TLS and similar cryptosystems. That’s an interesting discussion, and it kind of dovetails with Google’s recently announced plans to deprecate the URL.
We’ll update you when the research is presented next month.
As always, feel free to leave any comments or questions below!
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018in Hashing Out Cyber Security
How to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chromein Everything Encryption
Re-Hashed: How to Fix SSL Connection Errors on Android Phonesin Everything Encryption
Cloud Security: 5 Serious Emerging Cloud Computing Threats to Avoidin ssl certificates
This is what happens when your SSL certificate expiresin Everything Encryption
Re-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Messagein Hashing Out Cyber Security
Report it Right: AMCA got hacked – Not Quest and LabCorpin Hashing Out Cyber Security
Re-Hashed: How to clear HSTS settings in Chrome and Firefoxin Everything Encryption
Re-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithmsin Everything Encryption
The Difference Between Root Certificates and Intermediate Certificatesin Everything Encryption
The difference between Encryption, Hashing and Saltingin Everything Encryption
Re-Hashed: How To Disable Firefox Insecure Password Warningsin Hashing Out Cyber Security
Cipher Suites: Ciphers, Algorithms and Negotiating Security Settingsin Everything Encryption
The Ultimate Hacker Movies List for December 2020in Hashing Out Cyber Security Monthly Digest
Anatomy of a Scam: Work from home for Amazonin Hashing Out Cyber Security
The Top 9 Cyber Security Threats That Will Ruin Your Dayin Hashing Out Cyber Security
How strong is 256-bit Encryption?in Everything Encryption
Re-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3in Everything Encryption
How to View SSL Certificate Details in Chrome 56in Industry Lowdown
PayPal Phishing Certificates Far More Prevalent Than Previously Thoughtin Industry Lowdown