Credit: Flickr/ejbSF
Following a story we published last week about a widespread e-mail vulnerability involving weak cryptographic keys, system administrators at many companies around the world began to check their DNS records to make sure that the DKIM keys they were using to authenticate their e-mail were at least 1,024 bits in length — the recommended standard for secure authentication of e-mail.
No doubt, if they found they were using substandard keys — at lengths of 384 bits, 512 bits, and 768 bits — they replaced those keys with stronger ones to secure their corporate business e-mail.
But according to one researcher who contacted us after the story ran, these companies may be overlooking one problem — third-party e-mailers who are responsible for sending out marketing newsletters and other communication to customers on their behalf. In fact, one e-mail marketing company, which thought it had fixed the problem a year ago, had left US Bank, Capital One, Walmart, TD Ameritrade, TiVo and others open to easy spoofing.
A company may fix the problem with DKIM keys they generated themselves, but forget that third-party e-mailers also have to fix the keys they use to send e-mail on the company’s behalf. Oftentimes, the e-mailer will generate its own DKIM key to send such correspondence, and system administrators may or may not be aware of these or be able to delete them from their DNS records without causing problems for the e-mailer.
The researcher, who asked us to use his hacker handle “Quincy Robertson,” uncovered the DKIM problem with third-party e-mailers last year after another researcher named John Graham-Cumming found that Facebook was using a weak DKIM key in 2010.
Facebook fixed its DKIM key after Graham-Cumming notified the company, but Robertson began wondering if other companies might have the same problem. After doing a little research, he found that a number of large companies — banks, retailers and investment firms among them — were all using the exact same weak key — a 384-bit key — to authenticate their e-mail. He thought this was odd until he traced the key back to a third-party e-mailer called Epsilon Interactive.
In Sept. 2011, Robertson contacted CERT, at Carnegie Mellon University, to report the problem, and CERT reached out to Epsilon on his behalf.
“I didn’t want to anger Epsilon’s lawyers directly,” Robertson says, referring to the longstanding issue that many security researchers have when they try to disclose vulnerabilities and the affected company either reports the researcher to law enforcement or sends the researcher a threatening legal letter.
In this case, Epsilon did the right thing after being contacted by US CERT and promptly re-issued 1,024-bit keys for the e-mail it was sending out on behalf of its clients.
But after our story ran last week, Robertson checked the DNS records for domains belonging to a number of Epsilon’s customers, and found that many of them still had the old 384-bit key in their DNS records, along with the stronger 1,024-bit key.
As mathematician Zachary Harris explained in our first DKIM story, as long as a weak DKIM key remains in a DNS record — even if a company is no longer using it to authenticate its e-mail — a hacker can still use the weaker key to spoof e-mail and send it out as if it came from that company. In Epsilon’s case, the problem was exacerbated by the fact that the e-mailer had used the same DKIM “master” key for all of its customers, reducing the amount of work a hacker would have to do to spoof their e-mail.
“It took somewhere around five hours to break it on my quad-core system at home using publicly available software (Msieve, factmsieve, and GGNFS),” Robertson says.
“There are some tedious format conversions needed to get the factorization results turned into a private key,” he says, but notes that he created a fully automated script to do this, which will generate the private key for a company, using the company’s domain name and DKIM selector.
Among the Epsilon customers that still had the 384-bit key in the DNS records of some of their subdomains were: US Bank, Barclays, Capitol One, Scottrade, TD Ameritrade, Walmart, Disney, Marriott, Ritz-Carlton, the American Automobile Association, Walmart, the Home Shopping Network, TiVo and Pizza Hut.
Quinn Jalli, senior vice president of marketing technology for Epsilon, acknowledged the issue and said his team was in the process of cleaning out the old keys from DNS records.
“We did not know that was the issue,” he told Wired. “It wasn’t an act of negligence. Removing them would have been fairly simple. But we did not know that leaving the keys would create that vulnerability.”