DATEV - Sichere Mail?

Nicht SMIME und nicht PGP. Wie die DATEV das Thema "sichere Mail" umsetzt. Einer meiner Kunden hat eine Mail bekommen und bat mich etwas hinter die Kulissen zu schauen. Sein Steuerberate hat ihm so eine "komische Mail" gesendet und in Zeiten von Phishing und Malware wollte er erste mal wissen, was da passiert. Vor allem war erüber eine 166kByte große "secure-mail.html"-Anlage alarmiert. Aber auch andere Firmen machen es dem Anwender nicht wirklich einfach, wie ich auf Verschlüsselte Kommunikation beschreibe.

Mail im Posteingang

Auf den ersten Blick macht die Mail einen seriösen Eindruck. Sie kommt von einem Absender, mit dem mein Kunde auch tatsächlich Kontakt hat und der Betreff könnte auf einen aktuellen Vorgang hinweisen.

Die Mail macht erst mal einen vertrauenswürdigen Eindruck und auch die enthaltenen Links passen in dem Kontext. Allerdings ist diese Mail nicht per DKIM, SMIME oder PGP signiert. Könnte also von jedem Absender kommen.

Was hier aus Datenschutzgründen nicht zu sehen ist:
Der Absender die die Steuerkanzlei selbst, obwohl der angezeigte Inhalt nicht von ihr ist. Genau genommen ist das schon eine Fälschung des Absenders. Warum sendet die DATEV so eine Mail nicht mit einer Absenderadresse der DATEV? Vermutlich, damit der Empfänger in seiner Übersicht den Kanzleinamen sieht, was durchaus interessant sein kann. Dann wäre aber ein "Im Auftrag von" die bessere Umsetzung.

Header-Analyse

Also habe ich mir als nächstes den Header angeschaut. Er ist sehr überschaubar und schon die zweite Zeile zeigt, dass die Mail von der IP-Adresse [193.27.50.76] versendet wurde, die per Reverse-DNS auch auf den Host "idvmailout01.datevnet.de" auflöst. Die scheint also wirklich von der Datev zu kommen.

Received: from [212.227.15.41] ([212.227.15.41]) by mx.kundenserver.de
 (mxeue012 [212.227.15.41]) with ESMTPS (Nemesis) id 1MQuk3-1hKHxy28sp-00O3h1
 for <xxxx@msxfaq.de>; Thu, 21 Mar 2019 09:53:01 +0100
Received: from idvmailout01.datevnet.de ([193.27.50.76]) by mx.kundenserver.de
 (mxeue012 [212.227.15.41]) with ESMTPS (Nemesis) id 1MgfHA-1gWjDN26Iu-00h5iO
 for <xxxx@msxfaq.de>; Thu, 21 Mar 2019 09:53:01 +0100
Received: from demvencrypt14.services.datevnet.de (demvencrypt14.services.datevnet.de [10.252.104.153])
	by idvmailout01.datevnet.de (Postfix) with ESMTP id 44Q0tP2PRvzvDY
	for <xxxx@msxfaq.de>; Thu, 21 Mar 2019 09:53:01 +0100 (CET)
From: "xxxx" <xxxx@yyyyyy.de>
To: "xxxx@msxfaq.de" <xxxx@msxfaq.de>
Subject: AKS Kj. 2018
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0052_01C9D623.3D013AE0"
MIME-Version: 1.0
Return-Path: <xxxx@msxfaq.de>
X-ESWmail-Encrypted: Yes
Date: Thu, 21 Mar 2019 08:52:02 +0000
X-Virus-Scanned: amavisd-new-2.11.0 on idsmailproxy14.services.datevnet.de
Message-ID: <ab21980202ad41c28ebfd2a9e9be8ff0-GyFaWWVb@ehwa-partner.de>
X-MS-Has-Attach: yes
x-originating-ip: [10.200.46.106]
X-CompuMailGateway: Version: 6.00.4.17682.x86_64 COMPUMAIL Date: 20190321085204Z
Envelope-To: <xxxx@msxfaq.de>
X-Spam-Flag: NO

Ich habe den Absender mit "xxxx@yyyyyy.de" unkenntlich gemacht aber die DNS-Einträge zu der Domain abgefragt:

DNS Status Bemerkung

MX

Verweist mit Priorität 10 auf maildomain.datevnet.de und mit Prio 20 auf maildomain.datevnet.com. Soweit gar nicht mal ungewöhnlich. Der Steuerberater scheint das Komplettpaket von DATEV zu nutzen und auch das Mailhosting darüber abzuwickeln.

SPF

Umso weniger verstehe ich, das es zu der DNS-Zone keinen SPF-Eintrag gibt. Da eingehende Mail schon bei der DATEV eingeliefert werden dürfte der Absender auch die DATEV als Versender nutzen. Zumal die DATEV entsprechende Informationen ja publiziert. Ohne den Eintrag kann natürlich DATEV im Namen des Mandanten senden aber jeder andere kann es halt auch.

Wobei ich den Aussagen am Anfang mit den "Problemen" nicht so recht folgen kann. Dafür gibt es SRS, DKIM und DMARC

DKIM

Leider war die Mail, warum auch immer, nicht per DKIM signiert

WWW

Verweist auf einen gewöhnlichen Webhoster

Als Betreiber eines Mail-Service mit Verschlüsselung wäre es zu wünschen, dass der Hoster DATEV hier seine Kunden auch aktiv auf die fehlenden Einstellung hinweist. DATEV kennt ja die SMTP-Domains, da Sie für diese Empfänger auch Mails annehmen und könnte selbst regelmäßig, quasi als Services, die SPF/DKIM-Einträge seiner Kunden prüfen und ggfls. auf Fehler oder fehlende Einträge hinweisen. Sie könnten zumindest per DKIM signieren.

Interessanterweise gibt es einen eigenen technischen WebServer unter https://postmaster.datev.de/,, auf dem u.a. beschrieben wird, das Mails zu bestimmten Domains per TLS verschlüsselt werden oder per SMIME bzw. DKIM signiert sind.

Die Mail macht aber sonst keinen schlechten Eindruck aber sowohl Kunde als auch DATEV verschenken die Möglichkeit, die Mail per SMIME oder DKIM zu signieren. Theoretisch könnte dies ja "Versende von DATEV im Auftrag von <steuerberater>" per SMIME erfolgen.

HTML-Anlage

Also habe ich mir die Mail etwas genauer angeschaut. Die Mail selbst enthält ja keinen Inhalt und die verschlüsselte Mail soll ja in der Anlage sein. Da wird ja wohl kaum der Key mit enthalten sein. Ich habe nicht schlecht gestaunt, dass die HTML-Datei eigentlich ein Formular ist, in dem es ganz viele (hier 82) versteckte Formularfelder mit ca. 1972 Zeichen gibt.

Die eigentliche Mail ist also für den Empfänger so gar nicht weiter zu bearbeiten. Er muss die Anlage in einem Browser öffnen oder eine passende App installieren.

Zum aktuellen Zeitpunkt haben Sie also eine Mail erhalten, deren Inhalt sie aber nicht nutzen können. Ob damit schon eine Frist startet oder diese Mail als "zugestellt" bewertet wird, müssten wohl noch Gerichte klären. Stellen Sie sich mal vor, eine Firma möchte ihnen eine Rechnung senden aber der Postweg ist zu unsicher. Sie hinterlegt die Rechnung daher beim eigenen Pförtner und sendet ihnen eine Postkarte, mit der Sie aufgefordert werden, ihre Rechnung gefälligst selbst beim Lieferanten abzuholen.

Das Portal

Wenn ich URL ohne die Daten öffne, dann kommt direkt die Meldung, dass die Mail nicht entschlüsselt werden könne. Klar, da ich ja keine Daten angehängt habe.

Öffne ich die Basis-URL kommt direkt eine Anmeldeseite

Also komme ich wohl nicht umhin die HTML-Datei zu öffnen und sehe erst mal das versteckte Formular anzuschauen:

Im Chrome Debugging sehen Sie, dass die Bilder und einige andere Inhalte schon von DATEV nachgeladen werden.

Allerdings muss man dazu sagen, dass die DATEV bei dem Abruf noch nichts über den "Leser" selbst erfährt, sondern nur die IP-Adresse. Beim Druck auf den OK-Button sehen Sie gut die Übertragung der versteckten Felder zu DATEV.

Interessant finde ich hierbei, dass die Mail per FORM POST gesendet wird aber das Formular selbst, welche per Mail zugestellt wurde, keine Hinweise auf diese Verarbeitung enthalten. Ich wollte nur anmerken, dass die Mail ursprünglich von einer Steuerberatung an den Mandanten ging und auch wenn in der Mail auch das DATEV-Logo erscheint, so wäre ich als Betreiber schon etwas vorsichtiger einen "FORM Post" so ganz ohne Hinweis zu versehen. Es es sich hier bei dem Anwender schon um einen Nutzer gehandelt hat, gibt es nun einen Kennwortabfrage, ehe die Mail dann angezeigt wird. Bei der allerersten Nutzung wird der Empfänger darum gebeten, ein Kennwort einzurichten.

Nach der Anmeldung kann der Nutzer die Mail im Portal einsehen, quasi wie Web-Mail und sogar darauf antworten. Allerdings findet der Anwender diese Mails dann erst mal nicht bei sich lokal im Postfach vor. Er kann also nach Wochen oder Jahren nicht in "Gesendete Objekte" nachschauen und auch das Lesen der empfangenen Mail ist nur möglich, solange er Zugriff auf das Portal hat.

Schwächen

Die Nutzung on so genannten Verschlüsselungsgateways schein sich immer weiter zu verbreiten. Firmen möchten gerne mit ihren Empfängern "verschlüsselt" kommunizieren. Das ist löblich da weder PGP noch SMIME sich in der Breite durchgesetzt haben und auch DE-Mail wohl auch gescheitert sein dürfte. Allerdings hat diese Variante einige Designschwächen.

  • Erstanmeldung
    Wenn es einen Angreifer gelingt, die Mail noch vor der ersten Anmeldung des Anwender zu "sehen", kann er sich statt des Anwenders ein Konto anlegen. Steuerberater und DATEV arbeiten sicher zeitnah am PC aber der klassische Handwerke schaut nicht immer sofort jede Mail an. In der Zeit könnte ein Angreifer also im Namen des Handwerkers lesen und senden. Das Zeitfenster ist sicher nicht sehr groß aber eben auch nicht null. Andere Firmen senden dann alternativ eine SMS oder einen Postbrief mit einem Startkennwort
  • Phishing über veränderte Mail
    Auch wenn der Inhalt der Mail als Formularfelder unlesbar für einen Angreifer ist, so ist die Mail selbst nicht verschlüsselt und vor allem auch nicht signiert. Ein Angreifer könne also einfach eine andere Mail an den Empfänger senden, die genauso aussieht aber die URL nicht auf den Service der DATEV verweist sondern auf eine andere nachgebildete Seite. Der normale Anwender wird also einfach dort seine Anmeldedaten eingeben. Damit hat der Angreifer sogar die aktuellen Zugangsdaten. ich weiß leider nicht, wie die DATEV dann abgefischte Anmeldungen erkennen will. Der Angreifer wird das Kennwort natürlich auch bei anderen Diensten mit dem Benutzernamen durchprobieren.
    Erschwerend kommt hinzu, dass der Anwender anhand der URL (lokale Datei) gar nicht erkennen oder prüfen kann, ob der "FORM POST" verschlüsselt erfolgt.

    Da wäre mir ein "sichtbarer" Link auf die Webseite, auf der ich dann auch die richtige URL sehe, lieber. Nur wenn der Anwender die Maus über den "OK-Button" schweben lässt, kann er unten die URL erkennen.
  • Frage der "Zustellung" und Exportierbarkeit
    Gerade bei Steuersachen gilt eine höhere Aufmerksamkeit den Fristen und Antwortzeiten. Die zugestellte Information ist so nicht durch den Empfänger lesbar und ich bezweifle, dass die Mail so als "zugestellt" gewertet werden kann. Damit der Empfänger die Mail langfristig (z.B. 10 Jahre) aufbewahren kann, muss er sie aus dem Portal als entschlüsselte Datei herunter laden und in sein eigenes Mailsystem/Archivsystem importieren. Das sind alles einige Zusatzschritte mit Aufwand und damit Kosten beim Empfänger, nur damit die Absenderseite Kosten sparen kann. DATEV beschreibt aber zumindest den Export und Import für "Outlook".

Einschätzung

"Sicher" ist das Verfahren dahingehend, dass die Mail nicht unverschlüsselt zum Client gesendet wird. Dieses Ziel wird erreicht aber beim Client landet erst einmal ein Datenhaufen, mit dem der Anwender noch nichts anfangen kann und anscheinend auch ohne Hilfe von extern nie was anfangen können wird. Fraglich finde ich daher die technische Umsetzung, dem Anwender die komplette Mails schon einmal als "unlesbare" HTML-Datei zu senden, die dann der Anwender wieder per HTTPS an den Server von DATEV senden muss, der dann die Information serverseitig mit einem dort irgendwo hinterlegten Schlüssel decodiert und dem Anwender anzeigt. Natürlich erst, wenn der Anwender sich dort registriert hat und auch in Zukunft das Kennwort entsprechend eingeben kann. Andere Lösungen halten die Mail an dem Gateway auf und senden Sie erst an den Client, wenn dieser sich am Portal angemeldet hat.

Der Empfänger hat nach meiner Einschätzung die Mail als solches nie in seinem Besitz, sondern nur eine verschlüsselte Information. Er muss darauf vertrauen, dass der Service auf der Senderseite viele Jahre unter dem gleichen Namen mit der gleichen Funktion erhalten bleibt. Dabei handelt es sich sicher um einen vertrauenswürdigen Dienstleister, mit dem der Empfänger aber selbst gar keinen Vertrag hat, sondern nur der Steuerberater. Als Empfänger sollten Sie nicht darauf vertrauen, dass der Service auch 10 Jahre ihnen zur Verfügung steht.

Ich kann aber beim besten Willen nicht verstehen, warum diese "InfoMail" nicht durch das Gateway selbst per SMIME verschlüsselt wurde und keine DKIM-Signature zum Einsatz kommt. Ich kenne es eigentlich von anderen Lösungen so, dass der Benutzer eine Mail mit dem Gateway-Absender bekommt, dass eine Mail von XY hinterlegt wurde und abgerufen werden kann.

Weitere Links