16 years of CVE-2008-0166
Debian OpenSSL Bug
On May 12th 13th, 2008,
Debian Linux
announced the discovery of a severe security vulnerability in its OpenSSL package.
A patch in Debian's and Ubuntu's OpenSSL packages broke the random number generator,
effectively limiting the number of possible keys to
a few ten thousand plausible variations.
To celebrate the sixteenth anniversary of this discovery, I am hereby disclosing that many DKIM setups still used keys vulnerable to this bug in 2024. This also affects BIMI due to a poorly designed specification.
I presented these findings at the miniDebConf Berlin. A video recording is available (high quality, low quality).
DKIM is a mechanism that allows sending mail servers to sign emails with a cryptographic key published via a DNS TXT record.
By scanning DKIM keys with my tool badkeys, I discovered a surprisingly large number of hosts vulnerable to the 2008 Debian OpenSSL bug. This trivially allowed sending emails with forged DKIM signatures for those hosts and thereby also passing DMARC checks.
The hosts included notable names like @cisco.com, @oracle.com, @skype.net, @github.partners, @partner.crowdstrike.com, @partners.dropbox.com, @1password.com, and @seznam.cz (unfixed at disclosure, fixed now).
By scanning the Tranco Top 1 Million list, I collected 355,055 TXT records with a valid RSA key. Ed25519 keys were only found in negligible numbers (to be precise, two). DKIM does not support other key types.
Of the records with RSA keys, 855 were vulnerable to CVE-2008-0166 - around 0.24 %. 777 records contained identical keys. Overall, there were 22 unique vulnerable keys.
I found 21 additional records with vulnerable keys through other methods. (Details about the scanning methodology can be found here.)
Most records in the large set of 777 identical keys were configured as a CNAME to a host belonging to the company Cakemail.
I tried disclosing this issue to Cakemail. The affected host has a security.txt file with a security contact address (security@cakemail.com) and a link to a PGP key that does not work (404 error).
After trying to contact security@cakemail.com, I got this error message: "We're writing to let you know that the group you tried to contact (security) may not exist, or you may not have permission to post messages to the group."
Therefore, I did not directly communicate with Cakemail, but they appear to have replaced their DKIM key. I have disclosed this issue to many affected organizations. Some have probably contacted Cakemail.
I can only speculate, but it may have to do with timing. The Debian OpenSSL bug was introduced in 2006. It was discovered and fixed in 2008. The DKIM specification was published as RFC 4871 in 2007.
DKIM has no requirement to rotate keys. It appears that a sizeable number of companies configured DKIM TXT records in 2007 and never changed them.
The security team at Seznam - a Czech search engine and email provider - did not believe me when I reported this issue. They assume that as they are not actively using that key (beta._domainkey.seznam.cz), that means that it cannot be used to forge emails. This is, of course, not true.
While disclosing this issue, I had plenty of bad experiences with bug bounty programs. In multiple instances, triagers showed incompetent or highly problematic behavior. I am still in the process of trying to clarify some issues, I may share some stories at a later point in time.
I found some RSA keys with very short key sizes, some with 512 bits, some even smaller. Those can be broken on consumer hardware these days. I have not looked closer into this.
I also found some unparseable or defective keys. I have not found any other interesting vulnerabilities.
Generally, large parts of the DKIM ecosystem use substandard cryptographic security. The majority of DKIM keys use RSA with 1024 bits. The standard recommendation for RSA keys is to use a minimum key size of 2048 bit. While it has been assumed that powerful attackers may be able to break 1024-bit RSA for more than 20 years, such attacks have not been publicly documented.
The latest version of badkeys allows you to scan DKIM keys directly. (Use version 0.0.11 or above, as previous versions had a bug that would prevent some DKIM keys from being scanned.)
badkeys is a Python tool that can be installed via pip.
With the parameter --dkim, it checks DKIM records in text files. It supports common formats like DNS zone files or the output from tools like dig or host:
$ badkeys -aw --dkim example.org.zone rsa[2048] key ok, example.org.zone[12]
The -a parameter shows all keys found, not just vulnerable ones. The -w parameter enables warnings about insecure or discouraged key sizes and exponent values.
badkeys can also directly scan DKIM TXT records with the parameter --dkim-dns:
$ badkeys -aw --dkim-dns 20230601._domainkey.gmail.com dkim._domainkey.entrust.com rsa[2048] key ok, 20230601._domainkey.gmail.com blocklist/debianssl vulnerability, rsa[1024], dkim._domainkey.entrust.com rsawarnings/too_small vulnerability, rsa[1024], dkim._domainkey.entrust.com
Obvious caveat: a tool like badkeys can never find all possible vulnerabilities or compromised keys.
It is a moneymaking scheme invented by certificate authorities.
BIMI allows publishing a logo in SVG format that some email services will display alongside your emails. While not strictly required by the specification, usually, that will only happen if you also buy an expensive certificate (so-called Verified Mark Certificate) that asserts that this is your logo.
Those certificates are very expensive (above $1,000 per year).
Here's a Gmail screenshot showing some logos:
While testing to send DKIM-signed emails, I noticed that some would show a company logo in Gmail.
BIMI is designed in a way that when you publish a default BIMI record, all DKIM-signed emails will automatically get BIMI treatment and show a logo. In some cases, I only controlled the DKIM key of a subdomain, but even then, the BIMI logo configured for the main domain is shown automatically.
No, and I was very surprised by this.
The BIMI spec is written in a way that there is no cryptographic connection between the certificate and the DKIM key. As soon as one is able to sign a mail with DKIM, it passes BIMI.
While BIMI certificates are standard X.509 certificates that contain a cryptographic key, that key is not used at all.
Certificate authorities in other areas, e.g., in the WebPKI, are required to guarantee some basic security checking of cryptographic keys, disallow short RSA keys, and revoke known-compromised keys. No such mechanisms exist for BIMI and DKIM.
Sure. Let's take the domain entrust.com. It
has had a DKIM TXT record configured
at dkim._domainkey.entrust.com:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyGF0xzO7Eig1H8QdIErjEKOGnIVvoLU5VjcMRBRWZK65NinL+gVnjuMD2mYdjC3f+7sQCWxGDSKIFn/bB+iXxO2x1/ktkwXHQfQ/9FcFuy+LE0Snsm0SwXN/2l1m5f9e1xdswC+dzHt6DIpDSDENsRal019YKQTqwVyB++7QORwIDAQAB
This is a 1024-bit RSA key generated with a version of Debian vulnerable to CVE-2008-0166. We can use badkeys to figure out that the private key is this one:
-----BEGIN RSA PRIVATE KEY----- MIICWwIBAAKBgQCyGF0xzO7Eig1H8QdIErjEKOGnIVvoLU5VjcMRBRWZK65NinL+ gVnjuMD2mYdjC3f+7sQCWxGDSKIFn/bB+iXxO2x1/ktkwXHQfQ/9FcFuy+LE0Sns m0SwXN/2l1m5f9e1xdswC+dzHt6DIpDSDENsRal019YKQTqwVyB++7QORwIDAQAB AoGAH7zFxt0tY6ryaPKkCI0Fjjd21xDTzxFb11U3AO52BeDJ5BmbGo20lidTg96i SN0/Whf0qDLQcSPdc8Eo+TJ51jIbLPdy16Rn7cPPJzUDIzJPas4ewkI7lsU37hlC cr7T521l8g6w/mS2TtTZykpsHvb0tztjQuElS7TxWUuVuskCQQDmrvjJU3u9CMkb 3avhUAXlsK4nboo8GTPt4Ss9O2/ipTx3K+qtAfHM7HiZie3iYwxCKQQ3MdMlmh/N fPR/rTS9AkEAxaPt3EN8wB4w95FAQd9J338n1hXF0lE7UH1aBemuIbWXgY1UTlL4 X1Kx7rLeuQv8mzFkuQyXSFbq7eBXSBOZUwJACKxLbkZVQKYz6XhMHgyELD6YTaM6 T0gjS65LkeHKMxtDSre7+wU3shyx7BPjfb97loE0R174MVG6IF+yUZqRgQJALhtt LTqNSuCAOfEn1XY67KnkaDxSFxueQ8vKiaCXYAPWIYIQDemrScmn+vC9ptvWBXqD bewzCsxEKFRy6DyyQwJAGVyC2vMIL7aeMhB+V9YVDZJlV3MEGCYmbF84ZtLhSWTX QfUe81qGdL3IBMRqz2GnSS0y7qPN/8CP5W9cKy8aDg== -----END RSA PRIVATE KEY-----
We can use a tool like dkimsign (part of dkimpy) to sign a mail with a sender using an @entrust.com mail address:
$ dkimsign dkim entrust.com 25731-rnd.key < unsigned.txt > signed.txt
You can find a signed test mail here.
entrust.com has a BIMI default record configured at default._bimi.entrust.com. Therefore, all DKIM-signed emails automatically get BIMI treatment. The record looks like this:
v=BIMI1;l=https://bimi.entrust.net/entrust.com/logo.svg;a=https://bimi.entrust.net/entrust.com/certchain.pem
The URLs point to a logo in SVG format (l=) and a corresponding certificate (a=).
A BIMI-supporting email service receiving an email with a valid DKIM signature for entrust.com - which we can generate, as we have the private key - will show a BIMI logo.
By the way, have I mentioned that Entrust is one of only two companies that sell BIMI certificates?
Yes, after learning about this, I started reading the specification. It is extremely weird and has obvious security design flaws. It does "trustworthy" things like explaining that certain things (that are crucial for a secure implementation) are explained "elsewhere" or "in other documents" - without revealing where "elsewhere" is or where to find these "other documents".
No.
It is impossible to implement BIMI in mail user agents in a secure way based on its specification. You need additional security measures that are explained "elsewhere" and "in other documents".
You could implement BIMI troll mode by inserting a logo "say no to BIMI" into emails with BIMI records configured.
It would work in any MUA that implements the current version of the BIMI specification. However, I am not aware of any that do.
According to the specification, the mail server checks the certificate and sets those headers. The MUA should trust the MTA based on "locally defined checks". It is not explained what that means. (Possibly, that explanation is "elsewhere" or "in other documents".)
I haven't. It is a free icon (CC0) from SVG Repo.
I know. I published this page on May 12th. The Debian OpenSSL bug was announced on May 13th, 2008.
It was a simple mistake. At some point during the preparation of this web page, I had looked up the date, but I must have misremembered it. Therefore, I announced the 16th anniversary of the Debian OpenSSL bug one day too soon.
If you need help with email security, DKIM, or cryptography, you can find more information and reach me here.
These days, I spend a lot less time working on IT security. Most of my time, I try to understand the technologies we need to fix the climate crisis and create hopefully insightful and well-researched content. If that sounds interesting to you, you can you can read some articles here and subscribe to my newsletter.
Hanno Böck
First published:
Last update: