English | Deutsch
Home »

Detecting spoofed email signatures

(2019-04-30)

Who wrote an email? More precise: Who wrote the contents of the email?

This is what cryptographic signatures should help you with. It is called preserving the integrity and authenticity of an email contents. The software must therefor help to spot if somebody sends an email trying to trick the receiver into believing it was from somebody else.

Researchers from Münster and Bochum have published an applied research article [1] today. In it they discuss a number of ways of how to 'spoof' an email signature, trying to bypath the email client's checks. Considered were a number of clients that implement the widely distributed cryptographic standards OpenPGP and S/MIME. The researchers found many smaller and larger problems. As it is good custom they have reported the findings and suggested improvements to the implementors in a process they call coordinated disclosure. This is why you may only hear about it now, though most software has already been updated.

Gpg4win and its crypto engine GnuPG had been affected. Version 3.1.4 of Gpg4win released in October 2018 had the necessary fixes.

This happens on a regular basis with software products. But what can we learn from it?

Obviously it is good to have independent applied research about email cryptography that comes from a usability perspective. Progress is made possible by competing implementations and thus open standards. We can look at the less obvious lessons from two main perspectives:

User perspective

Following general practices of safely operating your computing equipment has made you secure against the problems, because you use well maintained software products, which you update. For example Gpg4win by default will have notified you about the availability of a new version in October.

However two points stand out:

  • What about my communication partners?
  • Why are so many clients affected?

Be adequately cautious

Signing emails cryptographically makes sense, because this way the receiver will be given one more means to check that it was you.

In general it impossible to fully control what the software and people at the other end will do. (Here the discussion could branch off into pros and cons of an open standard with many implementation versus a single proprietary vendor solution. Though being interesting to ponder, a small chance of a problem 'on the other end' will remain.)

So when receiving a message from someone: The more important it is and the more sensitive, the more cautious you should be. This is what humans do in other settings as well.

Depending on the importance:

  • Check the available details for a signature.
  • Judge the context of the information (like writing style or situation the communication partners are in). Is it plausible to be from this person in this situation?
  • Seek confirmation via additional communication channels. Like a phone call.

To support users to be adequately cautious, the display of just two states like 'unverified' and 'verified' is not enough. Email clients should offer ways to display different status levels of a signature and allow to look at details. Gpg4win is being developed into this direction and already displays several states for a signature.

Research is hard to summarize

The summary of the research article shows that the majority of tested clients had one or more issues. And the root case is that it is hard to make digital signatures usable, as the researchers conclude.

In order to reason this, they took a variety of technical approaches - called 'attacks' - to see if they find technical problems. The combination of 14 attacks with about 40 email client- and plugin-configurations means a lot of work. Findings and countermeasures also had to be documented and reported properly to the development teams. Thus the work is done within a longer time period and if a component is fixed quickly (like for example one important GnuPG fix), this will not be reflected in the summary. This is fine from the perspective of research because it helps to support the conclusion that in addition to good cryptographic foundations, also sound suggestions for implementing the user facing side have to be made.

Needed are good recommendations on how applications should behave regarding email signatures. This is a lot of work and will take time. For once it has to work with the user interfaces of different applications. And secondly it is harder than specifying algorithms or protocols, because it depends on how users perceive the interfaces.

The reported findings and suggestions have already made email signatures safer in many aspects, and this is not easily reflected in a summary of the research. In the long run: Coming up with good interface recommendations will lead to an even more robust ecosystem of applications.

Developer perspective

Take a look at the proposed development improvements mentioned in the article, it is a reminder about a number of pitfalls to avoid. In addition:

When connecting your application safely to the crypto engine GnuPG use GPGME, the official application programming interface (API). GPGME has the code for parsing and state holding that is necessary to deal with the response codes of the GnuPG command line executable. Since more than a decade GPGME is preferred over calling a GnuPG executable yourself. The article is a hint towards why: Applications using GPGME were safe from the CVE-2018-12020 defect and the class of problems from matching regular expressions and state confusion.

Again it is shown that allowing HTML/CSS styling in emails add to the technical problems of keeping our clients secure. So even if users demand it strongly, it is not a good choice when security is an issue at all. At least the default should be off. Maybe it would help to come up with a simpler markup language which offers a very limited set of styling methods for email contents that can be kept under control from a security point of view.

Since 2016 there are notable approaches towards a better trust model for OpenPGP based cryptography. GnuPG itself holds information where a public key came from and how often it was used in communication. And the Web Key Directory (WKD) allows for a standard way to get a public key associated with an email address. Please consider this for your applications.

Technical Details for Gpg4win

GpgOL is the Outlook add-in coming with Gpg4win. When displaying a signed email, it was possible to trick GpgOL to show a wrong sending email-address of a valid signature.

Also it was possible to use HTML in an email - if activated - to fake a verification for inattentive users.

Both problems have been resolved with Gpg4win version 3.1.4, released 2018-10-17.

ID attack on GpgOL

In GpgOL before Gpg4win-3.1.4 it was possible to abuse a display issue of Outlook to show a valid signature which did not match the visible sender address. This was possible for both S/MIME and OpenPGP and bypasses the check that matches a sender address against the data in the certificate (aka 'public key' in OpenPGP lingo) in the UI. To work the attacker has to control a key that is already trusted.

Clicking on the GpgOL status icon brings up details of a signature. A user doing this could still detect the attack. The improved GpgOL additionally shows the user ID used to validate a signature in the trusted sender category, close to the mail body.

The issue is documented with example screenshots in the tracker [2].

HTML display attacks on GpgOL

The article describes that GpgOL should partially be affected if an attacker added HTML elements in the mail, that trick the user into believing they would come from GpgOL and thus faking the display of a signature status.

GpgOL has multiple countermeasures against this:

  • The signature state is displayed as a large icon in the Outlook menu. This icon provides an overall indication and details of the signature as a tooltip (see screenshot below). Full information about the used certificate can be obtained by clicking the status icon.
  • GpgOL additionally uses categories located visually closer to the email contents. Categories are displayed as part of the header and not of the body so they cannot be completely faked. Faked categories in the body would scroll and be part of a different display area.
  • GpgOL does not use HTML elements in the mail body to display any signature status.

While a quick glance on the category may not be enough to recognize a fake signature, a closer look on the category and the status icon will be.

GPG Output spoofing and Gpg4win

All parts of Gpg4win use the official GnuPG Programming API (GPGME) and as such are not affected by GnuPG output parsing problems. GPGME handles all parsing of GnuPG output itself and provides a C API to access it.

MIME attacks and GpgOL

GpgOL uses a MIME parser that avoids displaying complicated MIME structures and was not affected by this class of attacks.

CMS attacks and GpgOL

GpgOL is not affected by the CMS attack classes as it replaces the content of a mail with the data that was actually used for verification. Certificate validation is correctly handled by GpgSM.

Timeline and references

  • 2018-06-08 GnuPG-Team notified by an implementor about CVE-2018-12020.
  • 2018-06-08 Fix for CVE-2018-12020 released and announced.
  • 2018-06-13 Publication of blog entry for CVE-2018-12020.
  • 2018-09-25 Researchers notified Gpg4win-Team about "Display Name shown as Signer (I2)" defect.
  • 2018-10-17 Fixed version of Gpg4win released.
  • 2019-03-13 Preliminary access to article via the German BSI.
  • 2019-04-30 Publication of research article.

[1] 'Johnny you are fired' – Spoofing OpenPGP and S/MIME Signatures in Emails, Müller et. al. 2019

[2] T4183.

Authors

Bernhard Reiter and Andre Heinecke for the teams of Gpg4win and GnuPG

CC-BY-SA 4.0