Page MenuHome GnuPG
Files F20064571

No OneTemporary
Actions

View Options

diff --git a/web/statement-spoofing.htm4 b/web/statement-spoofing.htm4
index a6df10c8..3f7966b9 100644
--- a/web/statement-spoofing.htm4
+++ b/web/statement-spoofing.htm4
@@ -1,202 +1,203 @@
m4_dnl -*-html-*-
m4_include(`template.m4')
m4_dnl $Id$
m4_define(`EN')
m4_define(`DE_FILE', `statement-spoofing.html')
m4_define(`TITLE', `Detecting spoofed email signatures')
-m4_define(`MAIN', `statement-sppofing.html')
+m4_define(`MAIN', `statement-spoofing')
PAGE_START
m4_undefine(`EN')
<div id="intro">
<h1>Detecting spoofed email signatures</h1>
(2018-04-30)
</div>
<div id="main">
<p>Who wrote an email? More precise: Who wrote the contents of the email?</p>
<p>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.</p>
<p>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.</p>
<p>Gpg4win and its crypto engine GnuPG had been affected.
Version 3.1.4 of Gpg4win released in October 2018 had the necessary fixes.</p>
<p>This happens on a regular basis with software products.
But what can we learn about it?</p>
<p>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:</p>
<h2>User perspective</h2>
<p>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.</p>
<p>However two points stand out:</p>
<ul><li>What about my communication partners?
</li><li>Why are so many clients affected?
</li></ul>
<h3>Be adequately cautious</h3>
<p>Signing emails cryptographically makes sense, because this way
the receiver will be given one more means to check that it was you.</p>
<p>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 change of a problem
`on the other end` will remain.)</p>
<p>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.</p>
<p>Depending on the importance:</p>
<ul><li>Check the available details for a signature.
</li><li>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?
</li><li>Seek conformation via additional communication channels. Like a phone call.
</li></ul>
<p>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.</p>
<h3>Research is hard to summarize</h3>
<p>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 signature usable, as the researcher conclude.</p>
<p>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 has to be made.</p>
<p>Needed are good recommendation 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.</p>
<p>The reported findings and suggestions have already made email
signatures safer in many aspects, and not easily reflected in
a research summary.
In the long run: Coming up with good interface recommendations
will lead to an even more robust ecosystem of applications.</p>
<h2>Developers perspective</h2>
<p>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:</p>
<p>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.</p>
<p>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.</p>
<p>Since 2016 there are notable approaches towards a better trust model
for OpenPGP based cryptography. GnuPG itself hold 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.</p>
<h2>Technical Details for Gpg4win</h2>
<p>GpgOL 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.</p>
<p>Also it was possible to use HTML in an email - if activated - to fake
a verification for inattentive users.</p>
<p>Both problems have been resolved with Gpg4win version 3.1.4,
released 2018-10-17.</p>
<h3>ID attack on GpgOL</h3>
<p>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.</p>
<p>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.</p>
<p>The issue is documented with example screenshots in the tracker [2].</p>
<h3>HTML display attacks on GpgOL</h3>
<p>The article describes that GpgOL should partially be affected
if an attacker added HTML elements in the mail,
that trick the user into believing the would they come from GpgOL
and thus faking the display of a signature status.</p>
<p>GpgOL has multiple countermeasures against this:</p>
<ul><li>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.
</li></ul>
<ul><li>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.
</li></ul>
<ul><li>GpgOL does not use HTML elements in the mail body to display any
signature status.
</li></ul>
<p>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.</p>
<p><img width=100% src="https://heinecke.or.at/div/gpgol-status-icon.png" alt="gpgol-status-icon.png" title="gpgol-status-icon.png"></p>
<h3>GPG Output spoofing and Gpg4win</h3>
<p>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.</p>
<h3>MIME attacks and GpgOL</h3>
<p>GpgOL uses a MIME parser that avoids displaying
complicated MIME structure and was not affected by this class of attacks.</p>
<h3>CMS attacks and GpgOL</h3>
<p>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.</p>
<h3>Timeline and references</h3>
<ul><li>2018-06-08 GnuPG-Team notified by an implementor about CVE-2018-12020.
</li><li>2018-06-08 Fix for CVE-2018-12020 released and announced.
</li><li>2018-06-13 Publication of blog entry for CVE-2018-12020.
</li><li>2018-09-25 Researchers notified Gpg4win-Team about
"Display Name shown as Signer (I2)" defect.
</li><li>2018-10-17 Fixed version of Gpg4win released.
</li><li>2019-03-13 Preliminary access to article via the German BSI.
</li><li>2019-04-30 Publication of research article.
</li></ul>
<p>[1] <a href="https://github.com/RUB-NDS/Johnny-You-Are-Fired/blob/master/paper/johnny-fired.pdf">'Johnny you are fired' – Spoofing OpenPGP and S/MIME Signatures in Emails, Müller et. al. 2019</a>
<p>[2] <a href="https://dev.gnupg.org/T4183">T4183</a>.</p>
<h2>Authors</h2>
-<p>2019-04-30
+<p>
Bernhard Reiter and Andre Heinecke for the teams of Gpg4win and GnuPG</p>
<!-- End Paste -->
<p>CC-BY-SA 4.0</p>
+</div>

File Metadata

Mime Type
text/x-diff
Expires
Sun, Feb 23, 7:17 PM (11 h, 11 m)
Storage Engine
local-disk
Storage Format
Raw Data
Storage Handle
14/cd/e0ca5d4b43a7aa22063094e445c3

Event Timeline