Datenschutz – TLS Zwang beim Transport von Emails

Aus gegeben Anlass, daß Juristen, Manager und Admins die titelgebende Aussage verneinen, hier eine kleine, aber belastbare Zusammenfassung der Lage. All das hier gilt nur für Unternehmen oder Organisationen die zum Datenschutz verpflichtet sind, also bis auf Privatpersonen alle!

Datenschutz – TLS Zwang beim Transport von Emails

Es war 2018 als die Datenschutz Grundverordnung final in Kraft trat, als der Landesdatenschutz NRW folgendes Dokument verfasste:

LDI-NRW-E-Mail-Verschluesselung-BSI-TR-03108-1-2018-03-26

Darin war erstmal erwähnt, daß der Einsatz von Verschlüsselung für Datenschutzverantwortliche auch beim Transport von Email gilt. Geglaubt hat es leider kaum jemand 🙁

2018 hatte ich auch Kontakt zum Bundesdatenschutz und indirekt zur Deutschen Datenschutzkonferenz ( DDSK ), denen ich Auswertungen zum Einsatz von TLS geben konnte,  die die DDSK überzeugte, daß „Nicht-Verschlüsseln“ nicht mehr geht, weil das schon so viele können. (75% aller Verbindungen waren damals verschlüsselt.)

Seitdem habe ich immer wieder von Leuten gehört, daß mit der TLS Verschlüsselungspflicht wäre Blödsinn. Das muß anderen auch so gegangen sein, weil die DDSK 2021 eine Orientierungshilfe dazu verfasst hat, die eindeutiger nicht sein könnte:  Orientierungshilfe E-Mail-Verschluesselung.pdf

Wer das PDF nicht mag, der LDI NRW hat die aktuelle Fassung (2021) zusammengefasst:

https://www.ldi.nrw.de/technische-anforderungen-technische-und-organisatorische-massnahmen-beim-e-mail-versand

Stichwort: Obligatorische Verschlüsselung ( Seite 7 5.1. ) als Basisschutz ist Pflicht.

Wer wissen will woher das kommt

Die Pflicht zur Verschlüsselung leitet sich wie folgt her:

Artikel 32 DSGVO
Sicherheit der Verarbeitung
(1) Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der
Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des
Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter
geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu
gewährleisten; diese Maßnahmen schließen unter anderem Folgendes ein:
a) die Pseudonymisierung und Verschlüsselung personenbezogener Daten;

Bezogen auf Emails ist der Stand der Technik in 2024 : TLS 1.3

Die Implementierungkosten sind IMHO gerundet 0 €, weil das jede aktuelle Mailserversoftware direkt können sollte.
( Wenn nicht kann die Software auch gleich gelöscht werden, weil Schrott.)

Daraus ergibt sich dann, das a) fraglos anzuwenden ist, weil die anderen Gründe nicht als zusätzlich „Hürden“ greifen,
denn 0 € Kosten ist das Killerargument schlechthin.

Das BDSG hat das etwas besser formuliert:

Bundesdatenschutzgesetz §64 Abs. 3 Ziff. 1-14

Anforderungen an die Sicherheit der Datenverarbeitung
(3) 2. Verhinderung des unbefugten Lesens, Kopierens,
Veränderns oder Löschens von Datenträgern
(Datenträgerkontrolle),
(3) 8. Gewährleistung, dass bei der Übermittlung
personenbezogener Daten sowie beim Transport von Datenträgern
die Vertraulichkeit und Integrität der Daten geschützt werden
(Transportkontrolle)
,

Dies reicht eigentlich schon aus, aber wer Zweifel hatte, wie „Verarbeitung“ ist so definiert wurde:

Artikel 4 DSGVO

2. „Verarbeitung“ jeden mit oder ohne Hilfe automatisierter
Verfahren ausgeführten Vorgang oder jede solche
Vorgangsreihe im Zusammenhang mit personenbezogenen Daten
wie das Erheben, das Erfassen, die Organisation,
das Ordnen, die Speicherung, die Anpassung oder Veränderung,
das Auslesen, das Abfragen, die Verwendung, die
Offenlegung durch Übermittlung, Verbreitung oder eine andere
Form der Bereitstellung, den Abgleich oder die
Verknüpfung, die Einschränkung, das Löschen oder die
Vernichtung;

Jetzt der nötige LOGIK Teil:

Man muß nur Emails verschlüsseln, die Personenbezogenen Daten enthalten.

Da man nie vorher wissen kann, wann einem jemand Personenbezogene Daten schickt,
ergibt sich aus der Pflicht, diese zu verschlüsseln, der Umstand,
immer zu verschlüsseln, weil nachträgliche Verschlüsselung einer bereits durchgeführten
Übermittlung logisch und praktisch nicht  möglich ist. QED.

Das Jahr 2024

Ich habe erst letzte Woche die eine BUNDESBEHÖRDE angeschrieben, weil die auch Emails in Klartext annehmen. Dazu heißt es in der Orientierungshilfe von der DDSK:

Seite 7  5.1. obligatorische Transportverschlüsselung

Bei dem letztgenannten Verfahren (STARTTLS) kann die obligatorische Transportver-
schlüsselung durch entsprechende Konfiguration des sendenden MTA (Mail Transfer
Agent) erreicht werden die entsprechenden Konfigurationseinstellungen werden
(En)Forced TLS, Mandatory TLS o. ä. genannt. Unterstützt die Gegenstelle kein TLS,
dann wird der Verbindungsaufbau abgebrochen
. Einige MTA ermöglichen eine domä-

nenspezifische oder regelbasierte Spezifizierung dieses Verhaltens.

Bitte beachten Sie: „Unterstützt die Gegenstelle kein TLS, dann wird der Verbindungsaufbau abgebrochen.“ d.h. Klartextemaileinlieferungen sind zu unterbinden.

Das ist genau der Modus Operandi, den wir unseren Kunden seit 2015 anbieten und empfehlen.

Der TLS Zwang ist also nicht weg zu diskutieren, sondern im Gegenteil mehr als real!

Wie testet man sowas?

Linuxuser sind natürlich wie immer im Vorteil, weil Ihr das direkt am Heimischen PC testen könnt:

Die IP und Emailadresse werden hier mal unterdrückt, weil der Fall noch nicht abgeschlossen ist:

[root@s113 ~]# nc a.b.c.d 25
220 mx1.<DOMAIN>.de ESMTP Smtpd; Tue, 27 Feb 2024 20:21:48 +0100
HELO s113.resellerdesktop.de
250 mx1.<DOMAIN>.de Hello s113.resellerdesktop.de [83.246.80.131], pleased to meet you
MAIL FROM: <info@cloud-foo.de>
250 2.1.0 <info@cloud-foo.de>… Sender ok
RCPT TO: <email>
451 4.3.2 Please try again later
QUIT
221 2.0.0 mx1.<DOMAIN>.de closing connection

Diese Ablehnung  war „Greylisting“ vom <DOMAIN> Server, der wollte, das wir später nochmal kommen:

[root@s113 ~]# nc a.b.c.d 25
220 mx1.<DOMAIN>.de ESMTP Smtpd; Tue, 27 Feb 2024 20:31:30 +0100
HELO s113.resellerdesktop.de
250 mx1.<DOMAIN>.de Hello s113.resellerdesktop.de [83.246.80.131], pleased to meet you
MAIL FROM: <info@cloud-foo.de>
250 2.1.0 <info@cloud-foo.de>… Sender ok
RCPT TO: <email>
250 2.1.5 <email>… Recipient ok
DATA
354 Enter mail, end with „.“ on a line by itself
FROM: <info@cloud-foo.de>
TO: <email>
Subject: TEST EMAIL AUF SMTP SECURITY
Date: Tue, 27 Feb 2024 20:21:05 +0100

TEST EMAIL, KANN GELÖSCHT WERDEN

SECURITY TEAM Cloud-Foo.de
.
250 2.0.0 41RJVUwi012500-41RJVUwj012500 Message accepted for delivery

Ich empfehle einen Server in einem öffentlichen Netz zu nehmen, da der einen validen PTR Record haben wird. Was passiert, wenn Ihr keinen habt, erfahrt Ihr bei LINUX-AM-DIENSTAG.de am 5.März um 19 Uhr ! Popkorn mitbringen!!!

Also, obiger Mailserver nahm die Email unverschlüsselt an, was, wenn er sich hätte sicher sein können, daß keine Personenbezogenen Daten drin sind, auch ok gewesen wäre, aber das konnte er nicht. Dazu hätte es mehr als nur etwas KI gebraucht, nämlich Echte Intelligenz 😉

Hinweis: Wer obiges Beispiel nachspielen will, sollte seinen Hostnamen und seine Emailadresse eingeben, weil die Email sonst als SPAM erkannt wird 😀

Online-Banking-Check 2024

Weil wir gerade mal bei Sicherheitschecks waren, haben wir kurzerhand den Online-Banking-Check vom 2019 nochmal nachgeholt.

TLS-Gate – Online-Banking-Check

Online-Banking-Check 2024

Das Testziel war TLS 1.3, wenn das kommt: Test bestanden
Das zweite Ziel war, daß TLS < 1.2 nicht mehr geht. Den Test haben alle Kandidaten bestanden.

Hier das Testergebnis im Detail: Die Liste erhebt keinen Anspruch auf Vollständigkeit, falls Eure Bank nicht dabei ist, einfach mal selbst nachsehen 😉

Domainname[:443]TLS 1.3TLS 1.2CA
www.commerzbank.de++GlobalSign
www.nordlb.de+Atos
www.ksk-stade.de++QuoVadis
meine.postbank.de+Digicert
meine.deutsche-bank.de++Digicert
www.berliner-sparkasse.de++QuoVadis
www.bv-activebanking.de+Digicert
meine.norisbank.de++Digicert
www.dkb.de++Digicert
www.sparda-berlin.de+QuoVadis
www.vrbankmecklenburg.de+QuoVadis
www.volksbank-demmin.de+QuoVadis
calenberger.de (Calenberger Kreditverein)++Lets Encrypt!
www.ksk-walsrode.de++QuoVadis
www.diebank.de+QuoVadis
banking.seeligerbank.deDigicert
www.sparkasse-nordhorn.de++QuoVadis
hbciweb.olb.de+D-Trust GmbH
www.apobank.de++QuoVadis

Unsere Testmittel

Für TLS 1.2

echo „TEST“ | openssl s_client –connect www.commerzbank.de:443 -tls1_2 -nbio

Für TLS 1.3

echo „TEST“ | openssl s_client –connect www.commerzbank.de:443 -tls1_3 -nbio

Hier ein Negativbeispiel für TLS 1.3:

$ echo „TEST“ | openssl s_client –connect www.diebank.de:443 -tls1_3 -nbio | grep -E „(version|Cipher)“
004E9A2CE67F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1586:SSL alert number 40

Wenn diese Meldung + etwas Restausgabe kommt, dann ging es nicht. Manchmal sieht man auch „SSL alert number 70“.

Glückwunsch an alle Banken, die es geschafft haben!

ALARMSTUFE GELB – vermehrte Trojaner Emails durch Hack von Outlook / Exchange Mailservern

Da jetzt 2 Mails in 2 Tagen aufgetaucht sind, die Trojaner enthalten und dem gleichen Schema folgen, und wir von mehr wissen, muß ich folgende Warnung abgeben:

Achten Sie dringend darauf:
KEINE ATTACHMENTS ANKLICKEN/SPEICHERN/AUSFÜHREN .

 

Die Trojaner Emails sind an folgendem Muster erkennbar

ZIP Attachment mit 4-5 Buchstaben als Filename.

Der Inhalt der Email knüpft an eine Korrespondenz an, die Ihr mit einem Kontakt früher hattet.

I.d.R. so was: „Ich habe Ihnen gestern ein Dokument gesendet. Ist es dir angekommen?“

UND Umlaute gibts nicht mehr im Text, es gibt Buchstabendoppler und andere Bugs:

Sehr geehrte Projektbeteiligte,
im Anhang erhalten Sie das Protokoll Nr.: 208/AA 012 zur Baubesprechung vom 01.11.2024 zu Ihrer Kenntnisnahme und frIhre Unterlagen.
Termin der nchsten Baubesprecchng 019:
Bei Rckfrgen stehen wir Ihnen gerne zurr Verfgung.
Mit freundlichen Gren

MAßNAHMEN:

  1. Attachment mit der rechten Maus anklicken -> Anhang löschen
  2. Mail nicht löschen, zwecks Beweissicherung. Kann nach 6 Monaten weg.
  3. echten Kontakt über bekannte! Kontaktwege informieren, daß deren Outlook/Exchange gehackt wurde:

Diese Links mitschicken:

https://thehackernews.com/2024/02/critical-exchange-server-flaw-cve-2024.html

http://blog.fefe.de/?ts=9b3393bb

https://krebsonsecurity.com/2024/02/fat-patch-tuesday-february-2024-edition/

Weil:

Rapid7’s lead software engineer Adam Barnett highlighted CVE-2024-21413, a critical remote code execution bug in Microsoft Office that could be exploited just by viewing a specially-crafted message in the Outlook Preview pane.

Narang called special attention to CVE-2024-21410, an “elevation of privilege” bug in Microsoft Exchange Server that Microsoft says is likely to be exploited by attackers. Attacks on this flaw would lead to the disclosure of NTLM hashes, which could be leveraged as part of an NTLM relay or “pass the hash” attack, which lets an attacker masquerade as a legitimate user without ever having to log in.

Brian Krebs kommentiert dazu:

BrianKrebs @briankrebs

„IDK when Microsoft knew what, but this was definitely a vulnerability that was going to get reverse engineered and pounced on. It’s a scroll-your-Outlook-inbox-and-get-pwned bug. This could get bad quick.“

Und Ja, Brian Krebs hat recht, die Hütte brennt lichterloh!

LIEGT DER HACK BEI IHNEN?

Wenn Sie Outlook einsetzen, dann stellen Sie sicher, daß es alle Updates bekommen hat. Wenn Sie nicht auf dem neuesten Stand sind, könnten Sie betroffen sein. Wir empfehlen sofort auf Thunderbird umzusteigen, sollten keine Updates einspielbar sein.

Die Anzahl der Hacks in Emails im Zusammenhang mit den Outlook/Exchange Hacks nimmt rapide zu.

Daher kontaktieren Sie Ihre IT, informieren diese ggf. mit den obigen Links und lassen Sie alles Updaten.