Attacks on GnuPG's Web Key Directory (WKD)

Multiple vulnerabilities regarding GnuPG/WKD and how to attack them

/images/gnupg-wkd-vuln-256.png

tl;dr

Please refer to the advisory.

What is WKD?

Web Key Directory (WKD) is the new and fancy way to retrieve PGP keys without using a keyserver.

Basically this is how it works. In order to get a key for user@example.com:

$ gpg --auto-key-locate=clear,nodefault,wkd --locate-key user@example.com

  1. Encode the 'user' part:

    zbase32(SHA1('user')) = nmxk159crbcuk3imqiw13gkjmfwd8mqj

  2. Get SRV record via DNS:

    _openpgpkey._tcp.example.com has SRV record 0 0 443 wkd.example.com.

  3. Construct .well-known/ URL:

    https://wkd.example.com:443/.well-known/openpgpkey/hu/nmxk159c...d8mqj

  4. Retrieve keyring from URL

  5. Import matching keys

Note: This 'experimental' feature has been enabled by default since version 2.1.23.

Attack on the SRV record

  1. Let DNS respond with not just a Hostname, e.g.

    _openpgpkey._tcp.example.com has SRV record 0 0 443 10.0.0.1:8443/wkd-test?.

    There is a check that the URL must end in the correct domain, so retry.

  2. Let DNS respond with a custom URL ending in the correct domain:

    _openpgpkey._tcp.example.com has SRV record 0 0 443 10.0.0.1:8443/wkd-test?.example.com.

    There is a TLS certificate check, so retry with a valid certificate:

  3. Let DNS respond with a custom URL ending in the correct domain and with a valid certificate:

    _openpgpkey._tcp.example.com has SRV record 0 0 443 sektioneins.de:8443/wkd-test?.example.com.

Now, the attacker can control Host, Port and most of the path component of a URL to be retrieved by GnuPG. Considering that the request may originate from an internal network that can potentially access otherwise restricted resources, this attack can be classified as CSRF or SSRF.

GnuPG fixed this issue with version 2.2.10.

Attack the HTTP client

A variation of the previous attack would be to access arbitrary resources via 30x redirect.

Silly example:

  1. WKD GET https://foo.bar/.well-known/... redirects to https://cluster.example.com/rest/shutdown?when=now

  2. cluster.example.com checks originating IP.

  3. Request originates from company network, so shutdown is executed.

This leads to the same CSRF vulnerability.

GnuPG fixed this issue with commit 4a4bb874f63741026bd26264c43bb32b1099f060, to be released with version 2.2.12.

Denial-of-Service attack on bandwidth

Seeing that GnuPG downloads a keyring from the WKD server first and checks for contents later, it was possible to provide a huge file for download, which lead to DoS.

This issue was fixed with version 2.2.10 by limiting the download size.

Denial-of-Service attack on keyring

The keyring downloaded via WKD can contain any number of keys. If the key's email address matches the request, all keys are imported to the user's keyring. This keyring pollution can be rather annoying, in particular if the key's comment field contains commonly used email addresses, so that a local search for a user's key returns the downloaded key, too.

Trigger via Thunderbird/Enigmail

Thunderbird/Enigmail is a common setup for email encryption via GnuPG. The interesting thing about this setup is at what point in time a recipient's PGP key is retrieved via WKD:

  1. Enter email address in To:, CC: or Bcc: field of the composer window or let it be triggered by clicking a mailto: link in your web browser.

  2. Wait 2 seconds.

  3. A WKD request is triggered in the background without user interaction.

This is a serious privacy issue. Users do not expect their potential recipients to know that an email is being composed.

Enigmail tries to retain some privacy by allowing only one lookup request for each address in 24 hours.

Recommendations:

  • The user should be notified before sending any requests.

  • Key lookup should be done after pressing 'Send', not before.

  • It should be possible to disable WKD in Enigmail preferences.

Unfortunately the Enigmail developer has a different opinion, stated in their issue tracker after reporting this issue: Status: invalid. "you can use the option extensions.enigmail.autoWkdLookup from the config editor for this purpose." Technically this is true, yet the default is to do WKD lookups.

Information Disclosure: IPs

By triggering a WKD lookup, either manually or using an email client, the server can see the sender's IP address, whether it is IPv4 or IPv6, and the DNS responder's IP as well.

This is obvious, of course, but considering Enigmail's behaviour, a user just may not expect their potential recipients to know in advance, that an email is being composed.

Conclusion

Using GnuPG's WKD feature with versions before 2.2.12 can be a serious security risk, in particular in combination with Thunderbird/Enigmail. In a worst case scenario the attacker can

  • know when someone is composing an email (at least every 24 hours)

  • trigger CSRF with arbitrary URLs from behind a firewall, thereby circumventing any IP based restriction

  • get the sender's IP address and the IP address of their DNS provider

  • pollute sender's GnuPG keyring with useless keys

  • perform DoS on sender's bandwidth

It's best to just update GnuPG or disable WKD until updated.