SSL Certificate: Why Verify Domain Ownership?
Whenever you order an SSL Certificate, one of the steps of validation for any certificate is verifying that you or your organization owns the domain name. This is primarily done by checking the public WHOIS record of the domain name and also sometimes by calling the phone number or sending an email to the address listed.
But why? If a malicious attacker ever got an SSL Certificate for, say, www.microsoft.com, they couldn't use it on another domain name without a web browser warning that there is a name mismatch. The only way that the certificate could be installed on the correct domain name is if the attacker has access to the servers that the domain name is hosted on (very unlikely unless they are an authorized employee).
However, an issue came up recently which revealed a way that hackers could use an SSL Certificate for www.microsoft.com, without having access to the servers: DNS poisoning.
According to a recent report by PCWorld, research teams from Google and the Georgia Institute of Technology estimate that as many as 0.4 percent, or 68,000, open-recursive DNS servers are behaving maliciously, returning false answers to DNS queries. They also estimate that another two percent of them provide questionable results. Poisoning a DNS server allows the malware author to send your computer virtually anywhere he wants. Since your system is being driven to false web sites based on DNS information, there's no way for any malware software running locally to detect or report on the problem.
Here's how an attack would work. A victim would visit a Web site or open a malicious attachment that would exploit a bug in his computer's software. Attackers would then change just one file in the Windows registry settings, telling the PC to go to the criminal's server for all DNS information. If the initial exploit code was not stopped by antivirus software, the attack would give attackers virtually undetectable control over the computer.
Once they'd changed the Windows settings, the criminals could take victims to the correct Web sites most of the time, but then suddenly redirect them to phishing sites whenever they wanted -- during an online banking session, for example. Because the attack is happening at the DNS level, anti-phishing software would not flag the phoney sites.
Or an attacker could simply take complete control over the victim's Internet experience, Dagon said. "If you look up the address of a Christian Science Reading Room site, they'll point you to skin exotica," he said. "If you ask where Google.com is located, they'll point you to a machine in China selling luggage."
"It's really the ultimate back door," said Chris Rouland, chief technology officer with IBM's Internet Security Systems division. "All the stuff we've deployed in the enterprise, it's not going to look for this."
So, if a attacker got an SSL Certificate for www.microsoft.com and put it on their own server, and then was able to poison the DNS on a user's machine so that it thought the fake server was www.microsoft.com, the user would be under the impression that he is sending encrypted information to Microsoft when, in reality, he is sending information to an attacker.
This emphasizes the importance of verifying that the person who is ordering the SSL certificate is authorized to do so and owns the domain name.
Originally posted on Sun Dec 16, 2007
Comments