DS GVO: Email Transportverschlüsselung wird Pflicht sein

Willkommen im Chaos des Datenschutzes. Ich hatte ja schon lange den Verdacht, daß EMails auch nur noch mit TLS übertragen werden dürfen, wenn man zum Datenschutz verpflichtet ist. Dabei habe ich mich aber immer gewundert, wieso das nie in der Presse steht. Jetzt wird sich das hoffentlich hektisch ändern.

Die Meinungen zur TLS Verschlüsselung von Emails

Wie uns Rechtsanwalt Schwartmann auf seiner Webseite wissen läßt, ist ab Freitag aufgrund der Datenschutz Grundverordnung wahrscheinlich eine TLS Verschlüsselung für eingehende und ausgehende Emails Pflicht, sofern man ein Unternehmen betreibt oder aus anderen Gründen zum Datenschutz verpflichtet ist.

Nach Ansicht des Landesbeauftragten für Datenschutz und Informationsfreiheit Nordrhein-Westfalen ist eine Transportverschlüsselung auf jeden Fall erforderlich:
Bezüglich der sicheren Implementierung der Transportebene hat das Bundesamt für Sicherheit in der Informationstechnologie die Technische Richtlinie „BSI TR-03108-1: Secure E-Mail Transport“ herausgegeben.
Unter datenschutzrechtlichen Gesichtspunkten ist diese Richtlinie als Stand der Technik zu betrachten, so dass ihre Umsetzung eine notwendige Voraussetzung für die datenschutzkonforme E-Mail-Kommunikation ist.

Quelle: https://www.rechtsanwalt-schwartmann.de/verschluesselungspflicht/
„(Ende Zitat)

Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit hat uns heute morgen endlich wissen lassen, daß nur der Einsatz von TLS 1.2 in Frage kommt:

„Inwieweit ein Provider, der die Infrastruktur zur Verfügung stellt, eine Option anbieten muss, die ausschließlich den Empfang von TLS 1.2 transportverschlüsselten E-Mails zulässt, beurteilt sich nach dem gegenwärtigen Stand der Technik.

Der gegenwärtige Stand der Technik ist, daß TLS 1.2 seit 2008 das Maß der Dinge ist. Der Nachfolger TLS 1.3 wird aber bald kommen, da die Planung des Standards kürzlich beendet wurde. Das hält aber gerade den BUND, wo die Information her ist, nicht davon ab, auch heute noch mit TLS 1.0 zu senden 😀 (Böser Dienstleister vom Bundmailserver 😉 )

IMHO

Ich schließe mich dieser Meinung an, da auch ich die DS GVO so interpretiere, daß alle Kommunikationskanäle verschlüsselt sein müssen. Wie einfach das gehen kann, zeigt folgende Anleitung :

Zunächst mal wählen wir im Account unter „Mailserver“ die „EMail-Options“ aus:

Nun aktivieren wir die beiden obersten Punkte:

„Verbindung zum Server benötigt Verschlüsselung“ und „Empfangener Mailserver muß TLS benutzen“

Das war es dann auch schon, jetzt kommen nur noch TLS gesicherte EMails an den Mailserver ran. Damit entspricht das Mailserververhalten dem geltenden Datenschutzrecht.

Wer es ganz genau nehmen will, der müßte auch noch DANE implementieren, da dies in einer BSI Richtlinie zum Thema gefordert wird. Da DANE aber AFAIK noch nicht 100% ausgereift ist, könnte der Teil schwierig werden, was nicht heißt, das einige Provider dies nicht schon implementiert hätten.

Bei Exim ist grade eine passende Diskussion gestartet worden.

Quellenlinks:

https://www.ldi.nrw.de/mainmenu_Aktuelles/Inhalt/Technische-Anforderungen-an-technische-und-organisatorische-Massnahmen-beim-E-Mail-Versand/Technische-Anforderungen-an-technische-und-organisatorische-Massnahmen-beim-E-Mail-Versand.html

https://www.rechtsanwalt-schwartmann.de/verschluesselungspflicht/

https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03108/index_htm.html

STYLE_GIBBERISH – der neue SPAM Trend

Da ich ja nicht mehr allzuviel Spams in meinem Postfach zu sehen bekomme, um nicht zu sagen, gar keine mehr, wird es mal wieder Zeit auf den Stand der Spammails einzugehen. Der ist noch immer so gruselig wie vor Jahren, in meinen alten Beiträgen zur Spamanalyse:

Heute ist es die Postbank, morgen schon …
Virus per Online-Einschreiben
oder Mailserver mit der eigenen Addresse täuschen
…und noch ein paar andere…

Diesmal soll es um die „ING-DiBa Kontosicherheit“ gehen, die mir etwas mitteilen wollte, aber dazu nicht in der Lage war 🙂

Schauen wir uns zunächst mal die Header an, es sofort auf, daß die Email  VON und AN die gleiche Adresse geht :

Received: from localhost.localdomain ([91.45.174.108]) by
 mrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA (Nemesis)
 id 0MalH0-1dUPAp17kI-00KN3S for <SPAMTRAP>; Sat, 27 May 2017 01:32:58
 +0200
Date: Sun, 28 May 2017 07:05:41 +0300
To: SPAMTRAP
From: ING-DiBa Kontosicherheit <SPAMTRAP>
Message-ID: <27f454376ba4bd7add8932a946d4e5d1d3e58@localhost.localdomain>
X-Mailer: PHPMailer 5.2.16 (https://github.com/PHPMailer/PHPMailer)

Besonders deutlich als Spam, outet natürlich der 1und1 Server diese Spam 😉  PHPMailer ist derzeit sehr beliebt was die Spammer betrifft, da er brav auf jedem gehackten PHPfähigen Server läuft.

Unser Spamassassin hat die Email dann aus einander genommen und mir einen bis dahin völlig unbekannten Spam-Tag gezeigt :

Inhaltsanalyse im Detail:   (4.7 Punkte, 5.0 benötigt)

Pkte Regelname              Beschreibung
---- ---------------------- --------------------------------------------------
-0.0 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
1.2 DATE_IN_FUTURE_24_48    Absendezeit 24 bis 48 Stunden nach Datum in "Received"-Kopfzeilen
-0.0 SPF_PASS               SPF: Senderechner entspricht SPF-Datensatz 
0.0 FREEMAIL_FROM           Sender email is commonly abused enduser mail provider (<SPAMTRAP>)
-0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.12 listed in list.dnswl.org]
0.0 HTML_MESSAGE           BODY: Nachricht enthält HTML
1.1 MIME_HTML_ONLY         BODY: MIME-Nachricht besteht nur aus HTML
-0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3) [212.227.17.12 listed in wl.mailspike.net]
-0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
0.0 TVD_SPACE_RATIO        No description available.
3.1 STYLE_GIBBERISH        Nonsense in HTML <STYLE> tag
0.0 T_REMOTE_IMAGE         Message contains an external image
Subject:  =?ISO-8859-15?B?WnUgSWhyZXIgU2ljaGVyaGVpdCAoUmVmZXJlbnpudW1tZXI6IA==?=i3qwx34018)

Dieser Style-Gibbrish sieht so aus :

<style>

1mvv1ze1aa0-phchyg0i2au-msrxtcsjntv-i7p2jrrrb1-0jm77ygif69
9ucup9rjk91-jbw5456n89t-2jxyjwxfrpc-zguxavahkm-8ffe0zh5det
k2m2e4qk3nh-g1kgfuhzkg1-8yxrh55b2dn-gzse9g9wpzh-9vmxwgz6t
wjicrmr2ss7-gokyjkdjrk7-cmnjgh3p847-qhogebh5cvm-3roisw1p4o
72xpjo0uoxj-4ncqa1qavne-9ticuweosja-cv6s8vq5n53-bex9y2a7iu7
...

Und dient dazu, die Email zu individualisieren, damit Checksummen vom immer „gleichen“ Inhalt, halt nicht immer gleich sind 😉  Das scheint ein neues Phänomen zu sein, da ich das erst bei zwei Spams in den letzten Wochen hatte.

Die übliche Schrott-URL „http://d9n0b3c8n7m2c0.hopto_org/TN7e5/wE2Yb_html?“ zur gehackten Webpräsenz mit Trojaner, Fake Webseite der Bank usw. darf natürlich auch nicht fehlen. (damit keiner drauf drückt, wurde der Link verändert ).

Der Schrott im Styleheader der HTML Mail, funktioniert deswegen, weil er am Ende des Dokuments steht und keinen SchlußTag hat, damit wird er von der Renderengine ignoriert, und selbst wenn er interpretiert würde, würde die CSS Engine, daß einfach als Error überspringen. Ergo, der Umleitung steht nichts mehr im Weg.

Wenn man sich die Mail so ansehen würde, erschiene im Mailprogramm übrigens nur ein Bild mit einem Link drüber, ob man da das Logo sieht, oder ob das schon ein Angriff auf die (PNG|JPEG|GIF|SVG)  Renderengine des OS sein wird, wer weiß, am besten nicht nachsehen 😉

Wie immer : Weg mit dem Dreck – > Ab in die Tonne!

Jetzt diggen wir mal etwas tiefer und das auch der Grund, wieso das über das OSBN geht, denn LINUX ist im Spiel 🙂

Wenn man die URL’s aufruft, kommt der Grund für den Hack recht schnell ans Licht :

HTTP/1.1 200 OK
Date: Sat, 27 May 2017 07:19:37 GMT
Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.14

  1. Ubuntu ist kein Server-OS .. Merken!
  2. komplett veraltete Version von Serverdiensten bedürfen nicht mal eines ZeroDays ala #SambaCry

Das ist ein aktueller Apache : httpd-2.4.25 und das ein aktuelles PHP : php71-php-cli-7.1.5-1

Merke: Hosting den Profis überlassen!

Folgt man der Spur durchs Netz kommt man über den javascript-Refresh in der aufgerufenen Webseite:

window.location = 'http://e0m7b93c5l7s9.o2l9j5d8a0f4c1.dynu.net/5lrHbq9Z
/c.php?click=yes&acc=yes&data=r5KHCKorFo&e=' + email;

Zu dieser Seite :  lwcp23.mooo.com

$ host e0m7b93c5l7s9.o2l9j5d8a0f4c1.dynu.net
 e0m7b93c5l7s9.o2l9j5d8a0f4c1.dynu.net is an alias for lwcp23.mooo.com.
 lwcp23.mooo.com has address 54.208.245.114

einer gehackten Amazon Instanz. EC2 rulz halt 😀 und das ist jetzt schon wieder witzig, weil genau der gleiche uralte Webserver dort läuft:

Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.14

gibt es da vielleicht einen Grund für ???  JA :

$ host d9n0b3c8n7m2c0.hopto.org
d9n0b3c8n7m2c0.hopto.org is an alias for lwcp23.mooo.com.
lwcp23.mooo.com has address 54.208.245.114

Es ist der gleiche Server, nur mit anderer Web-Adresse, da fragt man sich dann, ob die Spammer einfach nur zu blöde sind, es gleich ohne Umleitung richtig zu machen, oder unterwegs noch mehr passiert als man zunächst sieht.

Ein kurzer Portscan zeigt uns über den Server zunächst nichts interessantes außer Port 8443 in Betrieb.

Completed SYN Stealth Scan at 09:35, 7.96s elapsed (1000 total ports)
Nmap scan report for ec2-54-208-245-114.compute-1.amazonaws.com (54.208.245.114)
Host is up (0.12s latency).
Not shown: 996 filtered ports
PORT     STATE  SERVICE
22/tcp   open   ssh
80/tcp   open   http
443/tcp  closed https
8443/tcp open   https-alt

Jetzt habe ich gedacht, es gäbe keinen Witz mehr bei der Analyse, aber so kann man sich irren :

$ curl -i --insecure https://54.208.245.114:8443
HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Set-Cookie: JSESSIONID=F368A79640EEBD34D3CF5F19E5A95A3B; Path=/; Secure; HttpOnly
Location: https://infield-demo.cellebrite.com:8444/cas/login?service=https%3A%2F%2Finfield-demo.cellebrite.com%3A8443%2Fj_spring_cas_security_check
Content-Length: 0
Date: Sat, 27 May 2017 07:37:16 GMT

Wenn man jetzt nach dieser URL googelt, kommt u.a. das hier :

Cellebrite - Mobile Forensics Webinars

www.cellebrite.com/Mobile…/News…/WebinarsIm CacheÄhnliche Seiten
Cellebrite's Mobile Forensics solutions enable forensic professionals worldwide to ... UFED Physical Analyzer LIVE-Produktdemo: Beschleunigen Sie Ihre ...

Wer es nicht weiß, „Forensics“ ist die Analyse von Computern, wenn in die eingebrochen wurde oder die zum Einbruch benutzt wurden(oder für Kinderpo…. usw. ).

Da stellt sich mir jetzt ernsthaft die Frage, was das für ein komischer Server ist, daß der sowas .. ach nein, DAS IST DER SERVER infield-demo.cellebrite.com 😀 . Dieser Server hat nichts .. keine Security, kein aktuelles OS, keine aktuelle Software,. nicht mal eine 404 Webseite 😀  Oh man..

Deswegen, immer brav das OS upgraden , gell 😉

Neue TLS Probleme beim BSI

Vor zwei Wochen habe ich auf Probleme beim EMailversand des BSI aufmerksam gemacht. Damals bekam ich nach 24h die Rückmeldung, daß die Probleme behoben seien.

Leider mußten wir heute feststellen, daß das BSI Mailserver benutzt, die nicht-deterministisch sind, sprich, mal gehts, mal nicht 😉  Einer unser Server, der die gleiche Konfig hat wie alle anderen mit StartTLS anbietet, bekam nun unverschlüsselt Post vom buerger-cert.de Mailserver, obwohl dieser keine Stunde vorher einem anderen Server eine TLS verschlüsselte Verbindung angeboten hat… HMMMM!

Da haben wir dann mal genauer hingesehen und fanden noch weitere Probleme beim TLS des bei der OpenIT GmbH gehosteten Servers:

A) Es fällt auf, daß buerger-cert.de als MX gar keinen eigenen Mailserver einsetzt, sondern den zentral Mailserver von Openit.de benutzt :

2016-08-23 13:18:08 1bc9iZ-0005l4-Nl => mailversand@buerger-cert.de R=dnslookup T=remote_smtp H=mx.openit.de [217.69.65.200] X=TLSv1:AES128-SHA:128 C=“250 Ok: queued as E9B4011A055″

Das wird den gleichen Sicherheitslevel haben wie mx.kundenserver.de aka 1und1 Mailserver, oder vielleicht doch nicht ? 🙂

B) Nein, haben sie nicht, denn der dort eingesetzte Postfix Mailserver (220 mx.openit.de ESMTP Postfix)  scheint „etwas“ veraltet zu sein, oder auf veralteter Software zu laufen, denn er bietet nur TLS 1.0 an. Experten kennen das auch als SSLv3 und das ist ja bekanntlich geknackt worden und sollte nicht mehr eingesetzt werden.

Jetzt muß man 1und1 bescheinigen, wenigstens konsequent zu sein und überall TLS 1.2 einzusetzen, aber dafür immer noch SSLv3 anzunehmen 😀 Was die Macher von ssl-tools.net dazu meinen, kann man hier sehen :

https://ssl-tools.net/mailservers/1und1.de    (Ja, den Gag versteht man nur, wenn man den Link aufruft 😉 )

Was ssl-tools.net vom bueger-cet.de Mailserver hält, sieht man hier :

BSI-Neue-Probleme-mit-TLS(Stand: 25.8.2016 )

C) Die Mailserver im Cluster sind unterschiedlich konfiguriert … hää ?????? Einer kann TLS 1.2 der nächste nicht ??  Da kann man nur den Kopf schütteln.

Fazit

Auch wenn das BSI ein Problem gelöst hat, es sind noch viel mehr vorhanden. Bin mal gespannt, wann das behoben wird, denn die Meldung an das BSI ging natürlich vor diesem Artikel raus 🙂