It was a strange e-mail, coming from a job recruiter at Google, asking Zachary Harris if he was interested in a position as a site-reliability engineer.
"You obviously have a passion for Linux and programming," the e-mail from the Google recruiter read. "I wanted to see if you are open to confidentially exploring opportunities with Google?"
Harris was intrigued, but skeptical. The e-mail had come to him last December completely out of the blue, and as a mathematician, he didn't seem the likeliest candidate for the job Google was pitching.
So he wondered if the e-mail might have been spoofed - something sent from a scammer to appear to come from the search giant. But when Harris examined the e-mail's header information, it all seemed legitimate.
You may also like:Someone’s Been Siphoning Data Through a Huge Security Hole in the InternetMiddle-School Dropout Codes Clever Chat Program That Foils NSA SpyingTeen Reported to Police After Finding Security Hole in WebsiteThen he noticed something strange. Google was using a weak cryptographic key to certify to recipients that its correspondence came from a legitimate Google corporate domain. Anyone who cracked the key could use it to impersonate an e-mail sender from Google, including Google founders Sergey Brin and Larry Page.
The problem lay with the DKIM key (DomainKeys Identified Mail) Google used for its google.com e-mails. DKIM involves a cryptographic key that domains use to sign e-mail originating from them - or passing through them - to validate to a recipient that the domain in the header information on an e-mail is correct and that the correspondence indeed came from the stated domain. When e-mail arrives at its destination, the receiving server can look up the public key through the sender's DNS records and verify the validity of the signature.
For security reasons, the DKIM standard calls for using keys that are at least 1,024 bits in length. But Google was using a 512-bit key - which could be easily cracked with a little cloud-computing help.
Harris thought there was no way Google would be so careless, so he concluded it must be a sly recruiting test to see if job applicants would spot the vulnerability. Perhaps the recruiter was in on the game; or perhaps it was set up by Google's tech team behind the scenes, with recruiters as unwitting accomplices.
Harris wasn't interested in the job at Google, but he decided to crack the key and send an e-mail to Google founders Brin and Page, as each other, just to show them that he was onto their game.
"I love factoring numbers," Harris says. "So I thought this was fun. I really wanted to solve their puzzle and prove I could do it."
In the e-mail, he plugged his personal website:
Harris made sure the return path for the e-mails went to his own e-mail account, so that Brin and Page could ask him how he'd cracked their puzzle. But Harris never got a response from the Google founders. Instead, two days later, he noticed that Google's cryptographic key had suddenly changed to 2,048 bits. And he got a lot of sudden hits to his web site from Google IP addresses.
Oops, Harris thought, it was a real vulnerability he'd found.
"I assumed the e-mail got to some influential tech person who looked at it and said, 'Wait a second, how is this obviously spoofed e-mail getting through?' And they apparently figured it out on their own," he says.
Harris started exploring other sites and noticed the same problem with the DKIM keys used by PayPal, Yahoo, Amazon, eBay, Apple, Dell, LinkedIn, Twitter, SBCGlobal, US Bank, HP, Match.com and HSBC. Send an e-mail as [email protected]? No problem. Spoof [email protected]? Piece of cake.
Spoofing e-mail is one of the methods that attackers use in phishing attacks that trick users into opening malicious e-mails that appear to be legitimate messages from PayPal, eBay or a bank, in order to trick users into disclosing their account login credentials.
Moreover, some of the most high-profile attacks in recent years -- against Google, RSA and others -- have used spear-phishing attacks that involve targeting specific people at a company by sending them a malicious e-mail that appears to come from a trusted colleague or source, in order to trick the recipient into visiting a compromised website where malware is downloaded to their machine. A spoofed e-mail that is actually signed with a company's DKIM key can help attackers get their phishing attacks past filters set up to detect them.
Finding the vulnerability in Google's own domain was ironic, since Google makes concerted efforts to block e-mails sent to Gmail users from other spoofed domains.
A Google spokeswoman told Wired that the company took the problem very seriously and instituted a fix as soon as it became aware of the issue. She said the company has revoked the keys for all of its affected domains and re-issued new ones that are greater than 1,024 bits.
Harris found three classes of key lengths used by vulnerable domains - 384 bits, 512 bits, and 768 bits.
"A 384-bit key I can factor on my laptop in 24 hours," he says. "The 512-bit keys I can factor in about 72 hours using Amazon Web Services for $75. And I did do a number of those. Then there are the 768-bit keys. Those are not factorable by a normal person like me with my resources alone. But the government of Iran probably could, or a large group with sufficient computing resources could pull it off."
In addition to Google, he found that eBay, Yahoo, Twitter and Amazon were all using 512-bit keys. PayPal, LinkedIn, US Bank and HSBC were using 768-bit keys.
"It was good that PayPal and the banks were in the 768 category, but still, for domains that are as heavily phished as PayPal, 768 is really not okay," Harris says. "They really should have been at 1024, and they have heeded the message and said they really should have had stronger keys all along."
Most of the companies Harris contacted over the last few months have fixed their keys, though some are still dragging their feet, he notes. After contacting CERT Coordination Center at Carnegie Mellon University to report the vulnerability in August, Harris decided to go public to warn other domains about the need to check their DKIM keys.
Michael Orlando, vulnerability analyst with CERT, said his group planned to release an announcement about the issue this week to spread the word.
The fix is an easy one - companies simply need to generate a new key at the stronger length and place it in their DNS records. But they also need to remember to revoke their old key, Harris says.
"As long as the old one is still in the DNS record, even if you're not using it, an attacker can still use it," he says.
Harris thinks the problem is that many companies set their keys once and then forget about them, despite advances in cryptographic breakthroughs that make their keys obsolete.
"People who use cryptographic tools need to realize that local configurations need to be maintained just like software updates need to be maintained," he says. "In 1998 it was an academic breakthrough of great concerted effort to crack a 512 bit key. Today little old me can do it by myself in 72 hours on AWS. The field of cryptography keeps developing and breaking new ground just like everything else, and you can't just install a private key, or select a hash algorithm, and expect it to be good forever."
But Harris says the problem isn't just with the sender domains; he found that receiving domains also created vulnerabilities by accepting DKIM keys that were clearly marked as tests. In some cases, sender domains had generated test keys when they set up their systems, but never revoked them. Although Harris found keys that were clearly flagged as being test keys, recipient domains that saw these flags accepted the emails as being verified instead of considering them unsigned, as they should have done.
"So that's a problem on both sides; the senders are having these testing keys that they're leaving in DNS records long after the period of testing is completed, and then the verifiers are ignoring the testing flag." he says.
Harris isn't a security researcher, and he didn't even know what DKIM was before he started investigating the authenticity of the Google email he received.
"The fact that I went into this not knowing what a DKIM header was illustrates that somebody with enough technical background can figure this out as they go along," he says.
