Google's email security flaw embarrassing, but no catastrophe

DomainKeys Identified Mail (DKIM) vulnerability highlights need to upgrade to stronger keys as they improve

It was almost a year ago that a curious mathematician with no real Internet security training was able to walk through a gaping security hole left by Google -- a weak email cryptographic key.

15 of the worst data breaches

But most security experts say that while the exposure of the vulnerability -- which was true not only Google but also multiple other major enterprises -- is embarrassing, it did not expose them to catastrophic risk.

"[It is] an important discovery [and] illustrates that cryptography is hard and that companies need to take it more seriously," said Ramon Krikken, research vice-president at Gartner. But, he said the risk in this case is "not even in the same league" as having a weak key for SSL certification.

"That would not just be embarrassing, it would be dangerous," he said.

The discovery, long since corrected by Google, became public Wednesday, in part thanks to a warning posted by the U.S. Computer Emergency Readiness Team (US-CERT), and in part thanks to a Wired.com report about mathematician Zachary Harris's find of the weakness.

A day later, Harris's story had been picked up by dozens of news outlets worldwide. It began with an email last December, claiming to be from a Google recruiter, asking Harris if he was interested in a job for which he was not really qualified.

Harris was intrigued enough to wonder if he was being spoofed, and shortly discovered that, as Wired Threat Level's Kim Zetter reported. "Google was using a weak cryptographic key to certify to recipients that its correspondence came from a legitimate Google corporate domain," the report said. "Anyone who cracked the key could use it to impersonate an e-mail sender from Google, including Google founders Sergey Brin and Larry Page."

[Bill Brenner in Salted Hash: This weak passwords story reminds me...]

The cryptographic key, called DKIM (DomainKeys Identified Mail), is used by domains to validate to a recipient that the domain in the header information on an email is authentic, and aid to fight phishing.

The current DKIM standard is for keys to be at least 1,024 bits in length. Harris found that Google was using just a 512-bit key, which he told Zetter he could crack "in about 72 hours using Amazon Web Services for $75."

At that point, he figured this might be a test by Google recruiters to see if applicants would see the vulnerability and exploit it. But when he cracked the key and then sent an email to Page, posing as Brin, he didn't get a response. Instead, he noticed a flurry of hits from Google IP addresses on his own web site, and also that two days later, Google had changed the DKIM key to 2,048 bits.

After that, Harris started looking at other sites, and found that a host of other major names -- PayPal, eBay, Yahoo, Twitter, Amazon, Apple, Dell, LinkedIn, SBCGlobal, US Bank, HP, Match.com and HSBC -- were using DKIM keys ranging from 384-bit to 768-bit.

"[The 768-bit keys] 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," Harris said.

Harris also said that while most of the companies he contacted quickly fixed their keys, some have not, even though it is relatively easy.

From adequate to outdated

Why would so many companies ignore such a seemingly obvious flaw? Perhaps in part because at the time they were generated, they were adequate. But over time, they have become obsolete, and companies neglected to update them.

Jerry Hoff, vice president of static code analysis at WhiteHat Security, said it was a common problem. "Organizations tend to 'set it and forget it' in regards to these certifications," he said. "As computing power grows and cloud-based models become widely available, attacks like this, which seemed impossible just a few years ago, are even more likely."

Jeff Hudson, CEO of Venafi, has seen the same. "Unfortunately, even the most security conscious organizations are so focused on system availability that they are in reactive as opposed to proactive mode when it comes to security," he said. "Why change the oil if the car is still running?"

Zachary Harris put it bluntly: "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."

Fred Tochette, a security manager at AppRiver, said one likely reason is that short DKIM keys did not seem that risky. "This is the first time that I'm aware of that anyone has tried to leverage domain keys to spoof themselves online in this fashion," he said.

"Another reason is because in order for domain keys to be effective, they have to be utilized. Many major companies are including their keys in their emails, but not a lot of smaller mail systems are even configured to use DKIM," he said.

This lack of universality could be one of the reasons not all companies have rushed to fix it. Harris said that the fix is easy, but does require placing the new, longer key in the firm's DNS record, and then remembering to revoke the old key.

Ramon Krikken said large firms are reluctant to tamper with their DNS "because it is such a critical piece of infrastructure."

It could also be a matter of functionality. "Certainly the larger the key the better," Tochette said. "But the big issue is for the people processing these keys -- the recipients. The larger the key, the more CPU cycles are required to process it and a system has to be able to handle that traffic, otherwise issues would arise."

Most analysts agree that updates are critical. "What is secure one day can quickly become a risk the next," he said. "If 2,048-bit suddenly becomes obsolete, organizations that have it deployed are sitting ducks if they cannot quickly identify, revoke and replace it across their networks."

This story, "Google's email security flaw embarrassing, but no catastrophe" was originally published by CSO.

Join the discussion
Be the first to comment on this article. Our Commenting Policies