16 years of CVE-2008-0166

Debian OpenSSL Bug

Party Confetti

Breaking DKIM and BIMI in 2024

https://16years.secvuln.info/

- ------------------------------------------------------------------------
Debian Security Advisory DSA-1571-1                  security@debian.org
http://www.debian.org/security/                           Florian Weimer
May 13, 2008                          http://www.debian.org/security/faq
- ------------------------------------------------------------------------

Package        : openssl
Vulnerability  : predictable random number generator
Problem type   : remote
Debian-specific: yes
CVE Id(s)      : CVE-2008-0166

Luciano Bello discovered that the random number generator in Debian's
openssl package is predictable.  This is caused by an incorrect
Debian-specific change to the openssl package (CVE-2008-0166).  As a
result, cryptographic key material may be guessable.

Keys depended on a limited number of factors like the PID and the architecture, limiting the number of possible keys to a few ten thousand

Old bugs never die

ssl.com incident 2000

Matt Palmer on mozilla-dev-security-policy, 2020

There was another one in 2021 (with a key generated by OpenSSH)

crt.sh id 4876710821

In 2021, I started badkeys

Tool and website to easily check cryptographic public keys for known vulnerabilities

Detecting the Debian OpenSSL bug

Existing tools and lists of affected keys were not exactly great

  • Some of the old tools no longer worked on modern systems
  • All collections of affected keys were incomplete
  • Information about the exact details of the bug was confusing, incomplete, and sometimes wrong

Debian OpenSSL Bug variations

  • PID (0 to 32767)
  • OpenSSL and OpenSSH
  • Different output if .rnd file exists
  • Older and newer OpenSSL versions differ if the .rnd file does not exist
  • Architectures: 32/64 bit, x86 vs. ppc/others vs. mips
  • Key size
  • RSA, DSA, Elliptic Curves (!)

https://github.com/badkeys/debianopenssl/

Due to the amount of possibilities, it is close to impossible to cover everything, but badkeys detects all reasonably plausible variations

A few weeks ago

"I should test DKIM keys with badkeys"

DKIM

TXT record at key1._domainkey.hboeck.de:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE[...]

E-Mail header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hboeck.de; s=key1; t=1715197611; bh=Z9fPSuWvmaUL/fgn9g0k2ORYPJe3Y3Vc5NiKvQJXc2w=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=TNyZHQd[...]

How to scan DKIM

Get lots of e-mails and extract selector/domain combinations

How to scan DKIM (better)

Try common selectors like dkim, mail, etc., with top domains

Scanning Tranco 1 Top Million list

Around 350,000 TXT records with a valid RSA key.

855 vulnerable to Debian OpenSSL bug (0.24%).

Domains with vulnerable keys

@cisco.com, @oracle.com, @skype.net, @github.partners, @partner.crowdstrike.com, @partners.dropbox.com, @1password.com, @seznam.cz

Why?

  • 2006: Debian OpenSSL bug was introduced
  • 2007: DKIM was published (RFC 4870)
  • 2008: Debian OpenSSL bug was found

Most affected keys were configured as a CNAME to a host belonging to the company Cakemail

Trying to disclose a security issue to security@cakemail.com

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.

You would think that "I have your private key" is the kind of vulnerability report that could not be any clearer

Plenty of bad experiences with bug bounty programs

The worst: GitHub

There were these logos...

Gmail with email logos

BIMI

Brand Indicators for Message Identification

Brand Indicators for Message Identification or BIMI (pronounced: Bih-mee) is an emerging email specification that enables the use of brand-controlled logos within supporting email clients.

How does BIMI work?

If you want a BIMI logo you have to pay a lot of money to Entrust or Digicert

💰💰💰💰💰

How does BIMI work on a technical level?

BIMI requires DKIM and DMARC (with p=reject/quarantine)

BIMI TXT record for default._bimi.entrust.com

v=BIMI1;l=https://bimi.entrust.net/entrust.com/logo.svg;
a=https://bimi.entrust.net/entrust.com/certchain.pem

A logo (SVG) and a certificate (X.509)

The certificate contains a cryptographic key that is not used at all

If you can break DKIM, you can also break BIMI

entrust.com was among the hosts with a DKIM key vulnerable to the Debian OpenSSL bug

BIMI is based on an extremely problematic specification

draft-brand-indicators-for-message-identification-05

"other documents" and "elsewhere"

  • Further restrictions apply to the SVG; these are documented elsewhere.
  • Other documents may cover these topics.
  • Out of Scope: The explicit mechanisms used by Verifying Protocol Clients - this will be deferred to a later document.

BIMI protocol

  • Server checks record/logo/certificate and sets certain headers (BIMI-Indicator, BIMI-Location)
  • Mail client trusts these headers

How does the mail client know these headers came from its mail server and not from the sender?

Regardless of success of the BIMI lookup, if a BIMI-Location or a BIMI-Indicator header is already present in a message it MUST be either removed or renamed. [...] Allowing one or more existing headers through to a MUA is a security risk.

They understood the security problem and provided a fix that does not really work

Combination of BIMI-supporting client and non-BIMI-supporting server create an inherent security flaw

Some justifications I heard

  • BIMI was not meant to be implemented by "normal" mail clients (only by tightly integrated ones like Gmail)
  • No mail client actually implements the spec
  • The existing implementations do not use the spec

8.7. CGI scripts in Indicator payload

MTAs and MVAs should aggressively police Indicators to ensure they are the Indicators they claim to be, are within appropriate size limits, and pass other sanity checks.

Does anyone understand what that means?

BIMI SVG files

BIMI has defined a profile with a subset of SVG

SVG Tiny PS (Portable/Secure)

That is not entirely unreasonable, but...

How do you create such an SVG file?

The recommendation is to first create a file with a different, but similar profile in Adobe Illustrator, and then use a text editor to manually change it to match the SVG Tiny PS profile

Based on what I learned about BIMI, I have a recommendation for e-mail services, mail server developers, and mail client developers

Do not implement BIMI

I am not done with BIMI yet

Entrust issued over 200 certificates not following the SVG Tiny Portable/Secure profile

Entrust is currently already under fire for poor handling of various policy violations by their WebPKI CA

https://wiki.mozilla.org/CA/Entrust_Issues

Final words

  • Old bugs never die, remember that
  • badkeys is free software, but not yet packaged in Debian
  • BIMI is total garbage



Thanks for listening!

Hanno Böck, https://hboeck.de/