Category Archives: Secure the Web

SMTP: pphosted.com trifft auf moderne SSL-Technik

Posted on by

pphosted … pphosted … woran erinnert mich das nur? Nach ja, wenn man eigene Mailserver betreibt und deren Logs liest, dann stolpert mal ab und zu mal über irgendwas.irgendwasanderes.pphosted.com . Normalerweise bemerkt man das nicht, aber letzte Woche mußte ich so tief in die Kryptoabgründe blicken, daß ich Euch das nicht ersparen kann 😀

SMTP: pphosted.com trifft auf moderne SSL-Technik

DISCLAIMER: Diese Geschichte ist wahr und kann jederzeit bewiesen werden. Sie erhebt aber keinen Anspruch auf Vollständigkeit. Teile der betroffenen Infrastruktur könnten auch anders ausgestattet sein. 

Ok, nach dem das gesagt wurde… Hammertime! 😀

Frage: Was passiert, wenn ein Mailserver von *****************.pphosted.com auf einen OpenSSL 3 Mailserver im Jahre 2024 trifft?
Antwort: Eine Weile lang kommen verschlüsselte Emails, dann nur noch Klartextmails 😀

Ihr wisst ja, daß ich bei einem Hoster arbeite und deswegen viel mit Emails und Mailservern zu tun habe. Letzte Woche bekommen wir von einem Kunden ein Ticket rein, er bekäme keine Emails mehr von einem wichtigen Partner. Dieser Partner würde jetzt immer eine Meldung bekommen, daß er nicht verschlüsseln würde.

Die Fehlermeldung gibt unser Mailserver aus, wenn der Empfänger die DSGVO Pflicht aktiviert hat, aber eine Klartextemail von 1980 reinkommt. Sprich: die TLS Verschlüsselung war aus. Das verhindert auf SMTP Ebene die Übertragung der Email selbst, so daß der verschlüsselte Transport nach DSGVO Artikel 32 (1) a  garantiert wird. So weit, so klar.

Keine Updates am Mailserver

Jetzt hatte aber im Dezember noch alles geklappt. Seit Anfang Dezember hatte weder OpenSSL, noch unser Mailserver Exim, ein Update bekommen. Da lag es nahe, daß die Ursache auf der anderen Seite zu suchen ist. Was wir noch nicht wußten war das hier:

TLS error on connection from mx07-00181c02.pphosted.com [185.132.180.43] (SSL_accept): error:0A0000C1:SSL routines::no shared cipher

d.b. der andere Server hat erst probiert eine TLS Verbindung aufzubauen, konnte aber nicht (mehr). Deswegen ist er auf Klartext zurückgefallen, was natürlich ein Konfigurationsfehler ist, weil wenn man in 2024 eine Emails nicht verschlüsselt schicken kann, dann schickt man die gar nicht, sondern meldet den Fehler dem Absender. DSGVO Konform halt. Da unser Server für den Kunden keine Klartextmails annimmt, kam es zu der korrekten Fehlermeldung.

Das was hätten wir geklärt, aber das wieso fehlt noch

Und jetzt wird es richtig gruselig. Über unseren Kunden hatten wir Kontakt zum Support des Partners, der uns nach einigem Hin-und-Her dann in einer Email geschrieben hat, daß wir doch einen der folgenden Cipher ( das sind die eigentlichen Verschlüsselungsalgorithmen ) benutzen sollten ( und das ja nicht würden):

Natürlich findet Ihr hier keine IPs/Namen des betroffenen Kunden oder dessen Partners.

Erstmal die Werbung für Ihren Anbieter 🙂

„We always use TLS and millions of email pass through our email gateways and no one reported the similar issue, it appears that issue at the other end only.

Hence we have opened a case with Proofpoint support to share more details on this incident .

Regards,
********* ***
„

Dann diese Email:

„As checked with Proofpoint (************’s email hygiene solution), it appears that there is no common cipher from recipient end during TLS negotiation.

Below are Proofpoint supported cipher list which recipient needs to ensure that they have one of them listed in their cipher list:

O CipherList=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:RC4-SHA:DES-CBC3-SHA

Hence, kindly share the same to recipient IT team and ensure that they support one of the ciphers from the list.

Note: We always use TLS and millions of email pass through our email gateways and no one reported the similar issue.

As no action is pending at Takeda’s end, hence we are proceeding to archive this incident.„

Daher kannte ich „PPhosted“ => Proofe Point Hosted 🙂 Die verkaufen den Leuten Appliances, die die in Ihre Serverschränke stecken können, oder wie hier, hosten die Software individuell für den Kunden. So etwas wie Microsoft mit Office 365 auch macht. Software als Service, Ihr kennt das bestimmt.

Die Cipherliste

Werfen wir mal einen Blick in die Liste der „validen“ Cipher die uns in der Email gegeben wurde:

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:RC4-SHA:DES-CBC3-SHA

Wer von Euch passendes Kryptovorwissen hat, der hat schon längst angefangen zu lächeln, zurecht ;). z.B. ist der „DES-CBC3-SHA“ Cipher schon bei TLS 1.0 aka SSLv3 dabei gewesen, also sagen wir mal, dieser Retner ist sehr rüstig 😉

Mehr Infos zu Ciphersecurity gibt hier: ciphersuite.info

Aber „ECDHE-RSA-AES256-GCM-SHA384“ ist ein ganz gängiger TLS 1.2 Cipher, gegen den nichts zu sagen ist. Was fällt uns noch auf? Dazu müßt Ihr erstmal wissen, wie so ein Ciphername aufgebaut ist: (mehr Info)

{KEX}-{AUTH}-{SESSIONCIPHER}-{TYPE}-{HASHALGO}-{HASHSIZE}

In unserem Fall:

KEX = KeyExchange => ECDHE => EllipticCurve Diffie-Hellmann
AUTH = Authentication Algorithm in Handshake => RSA
SESSIONCIPHER = der eigentliche Algo => AES256

Der Rest ist für das Problem egal. Wenn Ihr mal die Liste oben durchseht, dann sind das alles RSA basierte Cipher. Jetzt wißt Ihr vielleicht noch nicht, daß RSA auf dem absteigenden Ast ist, was Krypto betrifft, weil  der Algo ist 1970 entworfen worden und braucht heute Keylängen von 16k um „sicher“ zu sein ( abhängig von Anwendungfeld ). Die Länge ist blöd, der Energieeinsatz ist groß, und die Berechnungen dauern länger, als wenn man EllipticCurves benutzen würde.  u.a. hat Fedora RSA aus der OpenSSH Defauleinstellung verbannt, vermutlich weil OpenSSH das gemacht hat. OpenSSL wirds ähnlich handhaben und sogar Lets Encrypt hat RSA als Default Type für die ausgestellten Zertifikate umgestellt.

Kurzfassung: RSA ist tod.

Jetzt gibt es genug Leute die noch auf RSA setzen, aber wie das so mit Untoten ist, die nerven ne Weile 😉

Um es zu verstehen, ist wichtig, wie Exim (mit Fedora) funktioniert. Die Verschlüsselung der Verbindung wird von OpenSSL durchgeführt, Exim fungiert hier nur als Vermittler. Deswegen kommen OpenSSL Fehlermeldungen direkt durch. Der logische erste Schritt ist dann, sich mal anzusehen ob OpenSSL die Cipher aus der Liste noch anbietet:

$ openssl ciphers liefert:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-CCM:AES128-GCM-SHA256:AES128-CCM:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-CCM:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM:PSK-AES128-GCM-SHA256:PSK-AES128-CCM:PSK-AES256-CBC-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA:DHE-PSK-AES256-GCM-SHA384:DHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM:DHE-PSK-AES256-CBC-SHA:DHE-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA:ECDHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:RSA-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:RSA-PSK-AES128-GCM-SHA256:RSA-PSK-AES256-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA

ok, also unser OpenSSL arbeitet noch mit dem Cipher, auch wenn RSA nicht mehr die erste Wahl ist. Ist auch ok, man muß ja nehmen, was andere anbieten.Das war es also nicht die Ursache. Ich nehme Euch mal durch 4 Stunden Debuggen mit.

Erstmal testen, ob der Cipher überhaupt noch geht:

$ openssl s_client -connect HOSTNAME:25 -starttls smtp -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384
CONNECTED(00000003)
000E2F7FCA7F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1586:SSL alert number 40

Oh Scheisse, der Cipher geht tatsächlich nicht mehr. (Wieso steht da übrigens nicht.)

$ openssl s_client -connect HOSTNAME:25 -starttls smtp -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
CONNECTED(00000003)
…
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384

„HMM… EllipticCurve geht also, aber RSA geht nicht mehr, was aber vorher ging.???“

Also habe ich unseren Cluster gescannt und alle, außer diesem Host klappten mit RSA, nur der nicht.  Daraufhin habe ich mir einen Testserver gesucht und alles verglichen, was an konfigs und software so da war.

Vielleicht haben wir ja Einstellungen in Exim die RSA ausschließen? Nein, weil ging ja im Dezember noch und OpenSSL und Exim hatte keine Updates.

Gab es Änderungen in der Systemkonfiguration über andere Pakete, z.b. GNUTLS? Nein, keine Updates.

Hat sich die systemweite Crypto-Policy vielleicht umgestellt, weil ein Timer abgelaufen ist und RSA deaktiviert wurde (siehe OpenSSH Änderung).  Auch nichts, und das zu durchsuchen und zu verstehen, wie das wie zusammenhängt, hat den Großteil der Zeit gekostet. Langsam wurde es eng.

Ok, Testserver mal neustarten, vielleicht gibt es da einen Hinweis? Nein…….oh Scheisse, jetzt geht der Testserver auch nicht mehr. Also mit STRACE nachgesehen was der an Files, Libs usw. lädt bzw. nicht mehr lädt. Sehr viele spannende Infos könnte ich auch da geben, aber dann schreibe ich übermorgen noch dran 😉

Der Funken vor dem Licht am Endes des Tunnels

Am Ende habe ich einen Hilferuf an die Eximmailingliste geschickt, und da kam dann der berühmte Funken der ersten Erkenntnis als Frage: „Hast Du eigentlich RSA oder EC Zertifikate im Einsatz?“

Ich hatte die ganze Zeit so einen Verdacht… der Server war am 29.12. einmal neugestartet worden. Dabei zieht sich der Exim die Zertifikate rein und solange der läuft, lädt er die nicht nach. Das Zert war aber schon einige Tage vorher verlängert worden, und danach hat es nachweislich noch funktioniert… weil der Server sich das Zert nicht neu eingelesen hat… weswegen man irrtümlich davon ausgehen mußte, daß keine Kausalität bestand. Die wurde erst mit dem Neustart hergestellt 🙁

Das erklärt aber noch nicht, wieso andere uns weiter Emails schicken können und nur pphostet nicht mehr!

Um das zu klären, muß man grob wissen wie der Schlüsselaustausch bei TLS funktioniert:

Jeder Server gibt die Liste Ciphern bekannt, die er unterstützt, vom Stärksten zum Schwächsten akzeptierten Cipher. Dann wird abgeglichen, welcher Cipher bei beiden der stärkste ist und der wird genommen, außer, und das war mir nicht bewußt, das Schlüsselmaterial hat was dagegen.

EC vs RSA

Wenn man ein EC Zertifikat hat, kann man damit keinen RSA Cipher verwenden. Nun bietet unser Server EC und RSA Cipher an, weil er das kann, die andere Seite kann aber keine EC Cipher und deswegen kommt keine Verbindung zu Stande, wenn man ein EC Zert hat….. oh yes.. Let’s Encrypt hat uns ein EC Zert gebaut, weil wir, wieso auch, nicht auf RSA bestanden hatten.

Das ist aber in 2024 nicht wild, da kann jede Kryptosuite und jeder Mailserver EC.. oh nein!!!

PPHOSTED ist im Jahr 2015 gefangen

Hier eine Liste (Zufällig ausgewählt) mit Ciphern die mit pphosted Servern ausgetauscht wurden:

remote_smtp H=mx07-0019ad02.pphosted.com [91.207.212.232] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx07-003d6e01.pphosted.com [185.132.181.218] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx08-003d6e01.pphosted.com [185.183.29.223] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx0a-0021cb01.pphosted.com [148.163.148.203] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx0a-0023b801.pphosted.com [148.163.149.109] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx0b-001dcc01.pphosted.com [148.163.159.10] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx0b-0021cb01.pphosted.com [148.163.152.203] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250

Alles RSA Cipher und jetzt testen wir die Server mal, ob die vor oder nach 2018 leben mit:

openssl s_client -connect $serverip:25 -starttls smtp -tls1_3

Ergebnis: (irrelevante Daten entfernt)

servername 91.207.212.232
CONNECTED(00000003)
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
servername 185.132.181.218
CONNECTED(00000003)
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
servername 185.183.29.223
CONNECTED(00000003)
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
servername 148.163.148.203
CONNECTED(00000003)
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE

Fazit: Die leben alle vor 2018!!

Was habe ich gemacht?

Ich habe geprüft, ob die Server mit TLS 1.3 eine Verbindung aufbauen können. Können Sie das nicht, sind die auf einem technischen Stand von vor 2018, als TLS 1.3 eingeführt wurde. Das kann durch eine veraltete Konfiguration so sein, oder weil jemand vergessen hat, die Verschlüsselungssoftware auf den neuesten Stand zu bringen.

Jetzt rechnet mal, wie lange ist 2018 her? 🙂

Machen wir den Test doch mal bei uns mit OPENSSL V3 2024 im Rücken :

$ openssl s_client -connect s113:25 -starttls smtp -tls1_3
CONNECTED(00000003)
…
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit

So muß das aussehen 🙂

Fazit

Wir stellen fest:

– pphosted Server können kein TLS 1.3
– pphostet Server können keine TLS 1.2 ECDSA Cipher (siehe Liste aus der Email oben)
+ Sie können aber schon ECDHE Keyexchanges

Das zusammen nordet den technischen Stand ungefär 2015, 2016 ein, eher 2015. 2008 als TLS 1.2 auf den Markt kam, gabs EC noch nicht, deswegen müssen da seitdem ein paar Updates gemacht worden sein. EC wurde erst im Februar 2011 in RFC 6090 definiert.

Ich hab hier übrigens eine Liste mit 366 pphosted Servern, alle das gleiche Ergebnis. Das sind sicherlich nicht alle, aber die Stichprobenmenge erlaubt einen wahrscheinlichen Schluß: Mit aktueller Verschlüsselung haben die es nicht so 😀

„Was macht Proofe Point eigentlich so beruflich?“ werdet Ihr fragen:

„Protect your people from advanced email attacks and identity-based threats. Defend sensitive data from theft, loss and insider threats.

Proofpoint Named a Leader in The Forrester Wave™: Enterprise Email Security, Q2 2023
“ Quelle: https://www.proofpoint.com/us  | 2024-01-09-13:00:00

Ich überlasse es Euch zu urteilen 😉

WIe haben wir eigentlich deren Out-Dated-Mailserver wieder bediehnt? Da kommen die Untoten wieder ins Spiel. Noch ist RSA  mit großen Schlüssellängen nicht gebrochen worden, auch nicht vom GoogleQuantencomputer, also vagabundiert RSA jetzt ein Jahr lang als Legacy auf unserem Mailserverzertifikat rum, nur auf dem. Man kann Lets Encrypt glücklicherweise sagen, daß es RSA ausstellen soll. Aber länger als ein weiteres Jahr, wird es die hoffentlich nicht geben. Vielleicht beendet ja LE den Support und dann gehts auch notgedrungen schneller.

Wenn die bei Proofe Point nichts ändern, werden die danach 50% Ihrer Kunden nichts mehr mailen können 😀 Der Tag kann gar nicht früh genug kommen, wenn Ihr mich fragt. Die ziehen da den Leuten Geld aus der Tasche und dann so etwas.

Die Polizei schickt keine „Haftbefehle“ per Email.

Posted on by

Ich mußte heute herzlich lachen, weil eine Scammertruppe, die vermutlich aus dem Ostblock stammt, eine „Vorladung“ bzw. „Haftbefehl“ über Server der deutschen Telekom verteilt hat. Dabei haben Sie eine Schwachstelle in einem Webdienst ausgenutzt oder hatten gültige Zugangsdaten.

Die Polizei schickt keine „Haftbefehle“ per Email.

So eine Email kann echt Leben retten, weil wir ja Sommerloch haben und es echt schwer ist, gerade Themen für Linux am Dienstag zu bekommen. Ergo war ich ganz erpicht darauf, diesen „Haftbefehl“ zu sehen, den ein Freund bekommen hatte 😀

Jetzt liegt der Text schlauerweise nur als Bild vor, sodaß man es mit Virenscannern nur per Signatur erkennen kann, aber einmal OCR drüber laufen lassen und…

Zu Ihrer Kenntnisnahme,

Ich, der unterzeichnende Michael RUPP Polizeidirektor, stellvertretender Generaldirektor der öffentlichen Sicherheit,
Zentraldirektor der Kriminalpolizei und des Dienstes für internationale polizeiliche Zusammenarbeit (SCIP), in
Zusammenarbeit mit Herrn Jean Philippe Lecouffe, Direktor der Operationen von EUROPOL, gestützt auf die Artikel 20 21. 1
und 74 bis 78 der Strafprozessordnung,

Wir übermitteln Ihnen diesen Haftbefehl kurz nach einer verdeckten Beschlagnahme von Computern, um Ihnen
mitzuteilen, dass Sie Gegenstand mehrerer laufender Gerichtsverfahren sind.

Wir leiten rechtliche Schritte gegen Sie ein wegen:

o Kinderpornographie.
o Padophilie
o Exhibitionismus
o Cyberpornographie
o Verstoß gegen die guten Sitten

Zu Ihrer Information: Das Gesetz 3903 der Strafprozessordnung vom März 2007 versehärft die Strafen, wenn Prostitution,
sexuelle Nötigung oder Vergewaltigung begangen wurden.

Sie haben die Straftat begangen, nachdem Sie im Internet (auf einer Werbeseite) angesprochen wurden, eine
kinderpornografische Seite besucht haben, Nacktfotos/-videos gemacht haben und Ihr Austausch von unserem Computer-
Agenten aufgezeichnet wurde und den Beweis für Ihre In Übereinstimmung mit dem Artikel Nr. 98-451 vor 19.|uni 2007,
808 Abs. 15 cp – Amtsblatt 11. Juni 200 Wer solche Taten begeht, wird strafrechtlich verfolgt und mit einer
Freiheitsstrafe von 8 bis 35 Jahren und einer Geldstrafe von 50.000 bis 250.000 Euro bestraft.

Aus Gründen der Vertraulichkeit senden wir Ihnen diese E-Mail, Bitte senden Sie uns Thre Begründungen per E-Mail, damit
sie innerhalb einer strengen Frist von 72 Stunden geprüft und auf Sanktionen untersucht werden können,
Nach Ablauf dieser Frist sind wir gezwungen, unsere Beschwerde an die Staatsanwaltschaft weiterzuleiten, um einen
Haftbefehl gegen Sie zu erwirken, und wir werden Ihre sofortige Verhaftung veranlassen.
In diesem Fall wird Ihre Akte auch an pädophile Vereinigungen und die Medien zur Veröffentlichung
weitergeleitet, damit Ihre Familie und Verwandten wissen, was Sie tun, und Sie werden in allen europäischen
‘Verwaltungen und im Nationalen Register für Sexualstraftäter (RNDS) als Sexualstraftäter registriert.
Wir warten auf Ihre Antwort-E-Mail, um Ihnen mitzuteilen, wie Sie weiter vorgehen sollen.
+ Bitte senden Sie Ihre Antwort an die unten angegebene E-Mail-Adresse der Abteilung:
* info.regulierang01@gmail.com

Mr Michael Rupp.
Polizeidirektor
– BUNDESPOLIZENINSPEKTION MÜNCHEN
BRIGADE FÜR DEN JUGENDSCHUTZ
Denisstraße 1 – 80335 München

 

Alle Rechtschreibfehler und grammatikalischen Verstümmelungen liegen entweder beim Täter oder der OCR 😉

Bei „BRIGADE FÜR DEN JUGENDSCHUTZ“ mußte ich so lachen, weil das Sowjetsprache ist und so gar nicht zu Europol oder der PI München paßt 🙂

Schauen wir uns mal die Header an:

Return-Path: <bv8000963@magenta.de>
Received: from fwd73.dcpf.telekom.de ([10.223.144.99]) by ehead24a09.aul.t-online.de with LMTP id VnlyJvSBhmSfDgAATKPkTA:T6 (envelope-from <**********@magenta.de>); Mon, 12 Jun 2023 04:26:10 +0200
Received: from spica15.mgt.mul.t-online.de ([172.20.102.121]) by fwd73.aul.t-online.de with esmtp id 1q8XED-0W8nQm0; Mon, 12 Jun 2023 04:24:21 +0200
Received: from 80.255.13.4:64582 by cmpweb02.aul.t-online.de with HTTP/1.1 (Lisa V7-3-3-1.0 on API V5-51-0-0); Mon, 12 Jun 23 04:24:20 +0200
Received: from 172.20.102.132:49924 by spica15.mgt.mul.t-online.de:8080; Mon, 12 Jun 2023 04:24:20 +0200 (CEST)
Date: Mon, 12 Jun 2023 04:24:20 +0200 (CEST)
From: Abteilung Kriminalpolizei <**********@magenta.de>
Sender: Abteilung Kriminalpolizei <**********@magenta.de>
Reply-To: „bvb175000@magenta.de“ <bvb175000@magenta.de>
To: „winnipooo@t-online.de“ <winnipooo@t-online.de>
Message-ID: <1686536660935.2098793.ebf4c26453c3211c5e5373917ea4959ad249fe29@spica.telekom.de>
Subject: =?UTF-8?Q?CYBERKRIMINALIT=C3=84T_-_VORLADUNG?=

Wie oben markiert, sieht man schön, daß das angeblich über eine Webanwendung eingeliefert wurde. Das kennt man schon bei der DTAG, hatte da auch mal eine schöne Scamemail über die DTAG, da wars auch ne Webanwendung. Es ist also durchaus möglich, daß das wirklich per Web eingeliefert wurde. „172.20.102.132:49924 “ ist eine private Adresse innerhalb des eigenen Netzwerkes. Das meint, daß auch die Einlieferung schon aus dem Netz der DTAG kam, was auf eine andere Sicherheitslücke hindeutet. Fairerweise muß man sagen, daß Angreifer Received-Header in Emails einfügen können, aber auf den ersten Blick sieht die Kette valide aus.

Über den Schwachsinn, den die Kriminellen in das Bild mit der Überschrift „Bundespolizei  EUROPOL / Mandat für Gerichtsverfahren“ geschrieben haben, brauchen wir uns nicht groß auslassen. Da ist einfach irgendwas zusammenkopiert worden und bedrohlich verpackt worden. Mehr Relevanz hat das nicht. Es sollte ja jedem klar sein, daß so etwas nicht per Email kommt. Das und die GMAIL Adresse sollte eigentlich auch bei den einfältigerne Mitmenschen sofort für „BETRUG“-Schriftzüge vor dem geistigen Auge sorgen 😉

Damit diese Zielgruppe von Menschen, die auch glauben, daß man Verwandte freikaufen müßte, gewarnt werden, habe ich das ganze an die zuständigen Behörden geleitet, u.a. auch die Behörde von besagtem Herrn Rupp in München. Es zahlt sich aus, ein Adressbuch mit Polizeikontakten zu haben 😉

Also, laßt Euch nicht verarschen 🙂

post

LDA Bayern, Staatsanwaltschaft und Hetzner stoppten Datenleak nicht (gleich)

Posted on by

Keine Ahnung was ich mir dabei gedacht habe, aber irgendwie war ich der irrigen Meinung, deutsche Behörden in Form von Datenschutzbehörde und Staatsanwaltschaft würden die Datenschutzinteressen der EU-Bürger umsetzen. Das es nicht so einfach werden würde, hätte ich mir nach meiner Behördensafari zur SSLv3 Panne bei der Kripo Leipzig 2017 eigentlich denken können, nein, denken müssen! Alles fing mit einer Linux am Dienstag Nachbesprechung an …

Die Behörden und der Passierschein A38

Wir schreiben den 13. September 2022. Es ist ein Dienstag und damit fand abends, wie jede Woche, die Videokonferenz zu Linux am Dienstag statt. Da wir zufällig auf Webserverthemen gekommen waren und wie man da mal nachforscht, was die Angreifer tun, haben sich Matthias und ich nach dem Ende der Zusammenkunft noch ein bisschen in unseren Webserverlogs umgesehen. Dabei viel mir ein Zugriff auf eine Datei namens „datenbank.sql.tgz“ auf, welches auf dem Server todsicher nicht gab. Das bewies auch das Webserverlogfile mit einer 404 Antwort auf die Anfrage. Hacker machen das auf blauen Dunst gern mal, wenn Sie auf anderen Server solche Dateien finden. Es könnte ja noch mehr Unvorsichtige geben da draußen. Damit man als Admin auf dem Laufenden ist, was solche Versuche betrifft, schaut man gelegentlich mal in die Logs.

Während ich noch die Anzahl und Varianten der Anfrage in den Logs ermittelte, suchte Matthias schon bei Google, wer denn so blöd war und solche Dateien öffentlich indizierbar rumliegen lies … und wurde prompt fündig 🙂 Ein Server, der mal irgendwann eine Webseite werden wollte, lieferte uns unter seiner IP direkt alles, was das Herz eines Datendiebs höher schlagen lässt: frei zugängliche Backupfiles der Datenbank seit ~2020. Aber das war nicht alles, da gab es doch noch das „Parent“ Verzeichnis.. ohhh… Tokens.. zu Webdiensten… Rootzugänge zur Datenbank .. Passwörter für das CRM System bei ZOHO und eine Datei namens „export.csv“ und die hatte es in sich: Die Goldader!

Bares Gold funkelte uns da entgegen, wenn man Datendieb war und im Darkweb fremde Daten verkaufen wollte. Ein Dump der Kundendatenbank mit u.a. Vorname, Nachname, Geschlecht, Geburtstagsdatum, Emailadresse, Mobilfunknummer und alles, was man so an Schönheitsbehandlungen bei der entsprechend verantwortlichen Firma so gebucht hatte, nebst Beträgen und anderen Daten, die wir aufgrund mangelnder Italienisch Kenntnisse nicht direkt zuordnen konnten. Ein kurzer Check bei „‚;– “ später war klar, daß einige der Kunden auch schon bei Facebook und anderen Leaks Daten verloren hatten, aber einige waren „ohne Befund“. Jetzt waren das nur knapp 3.500 Datensätze und damit kein echtes Spektakel wert…. aber es sollte anders kommen!

Der Skandal sind nicht die paar Datensätze

Die teils eklatanten Sicherheitsmängel bei eingesetzter Software und Konfiguration des Server lassen wir jetzt mal beiseite, dies sind Sachen, welche die LDA Bayern zu interessieren haben. Nur soviel, deren Hauptwebseite läuft noch PHP 5.6 und einem WordPress 4.x, was beides schon vor 2018 veraltet war. (Aktuell: PHP 8.2 und WP 6.0.2)

Am Mittwoch habe ich dann morgens die Kripo im Braunschweig informiert, die auch im Rahmen der Möglichkeiten geholfen hat. Es liegt nämlich keine durch die Polizei verfolgbare Straftat vor, auch wenn „Verleitung zu einer Straftat“ meiner laienhaften Meinung nach durchaus gegeben ist, weil ja jeder der bei Google sucht, diese Daten ohne weiteres runterladen und missbrauchen kann.

Daher rief die Kripo bei Hetzner in Nürnberg an und erfuhr dort in der Rechtsabteilung eine knallharte Abfuhr: man sollte doch das ABUSE Formular von Hetzner nutzen, die Rechtsabteilung könnte da nichts an die Admin weiterleiten. Merkt Euch mal, daß die Kripo die Rechtsabteilung von Hetzner auf dem kurzen Dienstweg am 14.9. informiert hat.

Der Abuse bei Hetzner

Da ich bereits alle Daten für die Landesdatenschutzbehörde in Bayern (LDA Bayern) aufbereitet hatte, habe ich auch das Formular bei Hetzner ausgefüllt. Ein sehr tristes Formular, wie ich erwähnen darf. Dort habe ich erwähnt, daß die Kripo die Rechtsabteilung bereits informiert hat und das es eine Verfahrens-ID bei der LDA gibt. Man darf also mit einer Anfrage der LDA rechnen. Das ganze war natürlich mit Beweisen und der Bitte um Abschaffung des Missstandes garniert. Jetzt könnte man meinen, alles getan zu haben und das die Daten zügig aus dem Netz entschwinden werden. Weit gefehlt!

Es vergingen also die Tage und nichts passierte

Natürlich habe ich jeden Tag die Webseite per Tor besucht um zu prüfen, ob die Daten noch da sind. Tor ist eine nützliche Hilfe, wenn man bei solchen Verfahren nicht ins Visier von mit Maschinenpistolen bewaffneten Abseilfans kommen möchte, da einige Staatsanwaltschaften auch schon mal Täter- und Zeugen-IPs verwechseln 🙂

Die Reaktion der Staatsanwaltschaft Nürnberg-Fürth

Am Samstag den 17.09. habe ich der Staatsanwaltschaft in Nürnberg-Fürth eine Handlungsaufforderung per Email geschickt, in der alles erklärt wurde und unter Berufung auf §13 StGB ( Begehen durch Unterlassen ) erklärt wurde, daß Hetzner ja informiert wurde, aber nicht handelte, obwohl es Ihnen möglich war, was jetzt klar ein §13 Fall wäre. Da kommen hilfweise noch die Beziehung zwischen Hetzner und dem Webseitenbetreiber durch §28 DSGVO und die Allgemeine Schadensersatzpflicht nach §823 BGB ins Spiel.

Kurz erklärt:

§28 DSGVO regelt das Verhältnis zwischen Datenverarbeiter, hier Hetzner als Hoster, und dem Datenschutzverantwortlichen aka. dem Kunden. Da ist eine Pflicht enthalten, daß der Auftragsdatenverarbeiter den Kunden über Missstände informiert und an der Beseitigung mitwirkt.

§823 BGB regelt, daß wenn jemand den Schaden von einem Dritten ( hier die betroffenen Kunden des Serverkunden ) abwenden kann, er dies zu tun hat, ansonsten wäre er schadensersatzpflichtig. Juristen mögen mir die starke Vereinfachung verzeihen 😉

Daraus ergibt sich meiner Meinung nach, daß §13 StGB auf Hetzner zutrifft, denn sie sind informiert und in der Lage den Schaden leicht abzuwenden. Die brauchen nur den Server kurz vom Netz nehmen. Dauert vielleicht eine Minute 😉

Auch das Schreiben an die Staatsanwaltschaft verpuffte ohne Wirkung.

Die Landesdatenschutzbehörde Bayern

Am Donnerstag, den 22.09. habe ich mit der LDA Bayern telefoniert, die mir mitteilte, daß die verantwortliche Kollegin bis nächste Woche unerreichbar sei. Mein Tipp: Urlaub. Daher sollte ich doch eine Email zur Nachfrage auf die Verfahrens-ID schreiben, weil der Kollege, der das auch machen könnte, heute nicht mehr mit mir telefonieren könne. Also, habe ich eine Email geschickt. Natürlich führte auch dies zu … nichts.

„Michael Ende hat das Nichts in weiser Voraussicht in der Unendlichen Geschichte verarbeitet, er kannte wohl die deutschen Behörden näher.“ ( ein Berliner Kängeroo )

Passierschein A38

Am 27.09, dem Dienstag nach dem Anruf, habe ich dort nochmal angerufen, denn die Kollegin sollte ja wieder da sein. Ratet mal, habe ich mit der gesprochen oder nicht 😉 Ihr ahnt es, „sie ist in einem Meeting, das bis heute Nachmittag dauert.„. „Und was ist mit dem Kollegen von letztem Donnerstag, ist der zu sprechen?“ „Nein, schreiben Sie eine Email….“  .. kommt mir irgendwie bekannt vor 🙁

Ok, da ich schon einmal am Telefon war, rief ich bei der Staatsanwaltschaft an und wollte mal nachfragen, ob denn die Email überhaupt angekommen ist, weil man von denen ja auch nichts gehört hat. Oh mann!

Das nachfolgende Gespräch ist dem Gedächtnis entnommen und könnte abweichend formuliert worden sein, ist aber sicher inhaltlich so abgelaufen:

Telefonzentrale Staatsanwaltschaft Nürnberg-Fürth: „Staatsanwaltschaft … „
Ich: „[Name], ich wollte nachfragen, ob meine Email vom 17.9. 12 Uhr angekommen ist und wenn ja, was da Sachstand ist.“
Telefonzentrale Staatsanwaltschaft Nürnberg-Fürth: „Um welches Aktenzeichen handelt es sich denn?“
Ich: „Keine Ahnung, ich habe ja von Ihnen noch nichts gehört.“
Telefonzentrale Staatsanwaltschaft Nürnberg-Fürth: „ohne Aktenzeichen kann ich Sie nicht Durchstellen.“
( und wie machen Kripobeamte das, wenn die mit dem Staatsanwalt über was neues reden wollen? 🙂 )
Telefonzentrale Staatsanwaltschaft Nürnberg-Fürth: „ich kann Sie nur zum Amtsgericht, dem Landgericht und dem OLG durchstellen. Wohin wollen Sie?“
Ich: „Und was solle ich bei denen? Ich will ja wissen, ob meine Email bei Ihnen ankam“
Telefonzentrale Staatsanwaltschaft Nürnberg-Fürth: „Ohne Aktenzeichen kann ich Sie nur zum Amtsgericht, dem Landgericht und dem OLG durchstellen. Also wohin?“
Ich: „Und was machen wir da jetzt?“ ( Ganz im Stil von Paul Panzer )
Telefonzentrale Staatsanwaltschaft Nürnberg-Fürth: „ich kann Sie zum Amtsgericht, dem Landgericht und dem OLG durchstellen. Wohin wollen Sie?“
Ich: „Dann nehme ich das Amtsgericht“
… es klingelt … nun rauscht es, als wenn das Büro ohne Wände auf dem Mittelstreifen der A2 erbaut wäre..
Telefonzentrale Amtsgericht Nürnberg-Fürth: „Registratur, Hallo?“
Ich: „Es rauscht fürchterlich“
Telefonzentrale Amtsgericht Nürnberg-Fürth: „Ja, das ist das Telefon. Wer war da?“
Ich: „[name] ich wurde von der Telefonzentrale der Staatsanwaltschaft vermittelt. Ich habe vor 10 Tagen eine Email an die Staatsanwaltschaft geschickt und würde gern wissen, ob die ankam, weil nichts passiert ist. „
Telefonzentrale Amtsgericht Nürnberg-Fürth: „Sie sind hier beim Amtsgericht. Sie sind hier falsch.“
Ich: „Das weiß ich, daß haben Sie der Telefonzentrale bei der Staatsanwaltschaft zu verdanken. Wissen Sie denn vielleicht, wo man da richtig wäre?“
.. und ja, der Kollege wußte das. Er versucht zweimal mich zu verbinden, aber keiner ging ran. Dafür habe ich aber die Durchwahl der Wachtmeisterrei von der Staatsanwaltschaft bekommen :)…
… etwas später …
Wachtmeisterrei Staatsanwaltschaft Nürnberg-Fürth: „Staatsanwaltschaft Nürnberg-Fürth [Name] Bitte?“
Ich: „[Name] ich wollte nachfragen, ob meine Email vom 17.9. 12 Uhr angekommen ist und wenn ja, was da jetzt mit ist.“
Wachtmeisterrei Staatsanwaltschaft Nürnberg-Fürth: „Ich verbinde Sie mal“
... mit der Poststelle, wie sich rausstellte …
Ich: „[Name] ich wollte nachfragen, ob meine Email vom 17.9. 12 Uhr angekommen ist und wenn ja, was da jetzt mit ist.“
Poststelle Staatsanwaltschaft Nürnberg-Fürth: „Haben Sie denn ein Aktenzeichen für mich?“
….normalerweise wäre das jetzt eine Endlosschleife geworden aber…
Ich: „Nein, woher denn, es hat ja niemand geantwortet.“
Poststelle Staatsanwaltschaft Nürnberg-Fürth: „Wenn Ihnen noch niemand geantwortet hat, dann liegt die Anzeige noch beim Staatsanwalt.“
Ich: „Das war keine Anzeige, jedenfalls nicht im klassischen Sinne, mehr so eine Aufforderung etwas zu tun.“

Die Dame erklärte dann, wie das da so normalerweise mit der (E)Post abläuft und das 10 Tage doch ein „bisschen knapp wären“ um da schon nachzufragen, aber ich solle doch bitte eine EMail mit der Nachfrage und bitte um Rückmeldung schicken, sie leitet das dann garantiert an den Richtigen weiter. Das habe ich dann gemacht und Euch anschließend diesen Text niedergeschrieben 😀

Das Gespräch mit der Telefonzentrale ist übrigens länger gelaufen als oben beschrieben, denn dort kam es wirklich zu einer Endlosschleife wegen dem nicht-existenten Aktenzeichen 😉

Der Tag danach

Der Tag nach dem Tag danach, und die Tage nach diesem Tag, waren wie die Tage vor dem Tag davor: Nichts neues im Westen. Hätte ich den kleinen Witz mit Michel Ende nicht schon gebracht, jetzt wäre ein Zitat über das sich ausbreitende Nichts angebracht.

Am 21.9. habe ich mich mit der c’t Redaktion besprochen. Die fanden zwar alle Vorwürfe bestätigt, aber der Fisch war leider zu klein um darüber zu berichten, womit die ~3500 Datensätze gemeint waren. Mir ging es aber um die Untätigkeit, da ich denke, daß darin der eigentliche Skandal besteht. Ich, und andere mit denen ich die Infos zum Ablauf besprochen habe, sehen das auch so. D.b. die Erwartungshaltung an unsere Behörden ist offensichtlich in der Bevölkerung deutlich überhöht.

Hinweis: Wir sind jetzt zur Orientierung bereits in Woche 4 der Nichtsausbreitung angekommen.

Am Mittwoch den 5.10. habe ich die von YouTube bekannte Rechtsanwaltskanzlei WBS über Ihr Kontaktformular um deren Meinung zum weiteren Vorgehen per Rückruf gebeten. Da ich eine gute Zusammenfassung schon für die LDA gemacht hatte, habe ich mal meine Datenschutzmeldung hinzugefügt. Herr Solmecke hatte am 3.10 und am 5.10 passende Videos zum Thema eingestellt, was lag also näher? 🙂

Die Zeit verging und Ihr ahnt es schon … bis heute kein Rückruf 🙁 ( <= Stand 7.10. .. wichtig 🙂 )

Am Samstag den 8.10. habe ich bei unserem Rechenzentrum angerufen, ob die vielleicht einen „Kontakt“ bei Hetzner haben, aber leider ist Hetzner die „geschätzte Konkurrenz“ und Kontakte damit, gefühlt, nicht erwünscht 🙂

Das Lebenszeichen

Mein Status wechselte am 10.10.2022 in „bedingt hoffnungsvoll“ als ich folgende Email laß:

Dear Sir or Madam,

We have received your information regarding spam and/or abuse and we shall follow up on this matter.

The person responsible has been sent the following instructions:

– Solve the issue
– Send us a response
– Send you a response
…
Kind regards
XXXXXXX XXXXXX
Hetzner Online GmbH

Wie ich im Anhang nachlesen durfte, ist das (un)stylische WebFormular auch nur ein Frontend für einen Emailversand an die abuse@hetzner.com Adresse, was zwei Dinge nahelegt:

1. die Kategorisierung als „sonstiges“ ( weil nichts andere paßte ) hatte keinen Einfluß auf die Verarbeitungszeit und
2. die sind da echt sehr weit in Rückstand geraten, denn laut Anhang kam die „Email“-Version des Formulars da beim Absenden des Formulars an.

Dienstag, der 11.10.2022

Das Telefon klingelt. Eine Nummer aus Köln. Dummerweise, in einem Augenblick in dem ich nicht in der Nähe war. Ein Check im Web und ich wußte, es war WBS, also Rückruf. Leider kam kein Gespräch mit dem Anrufer zustande, Noch wissen wir nicht, was der- oder diejenige mitteilen wollte.

Ein quälend langsam vergehender Dienstag wäre die Folge gewesen, wenn ich nicht einen Vortrag für Abends hätte schreiben müssen: „SSH: All Inclusive„.

Servern down

Abends stellten wir bei Linux am Dienstag fest, daß der Server nicht mehr erreichbar war. Wer den letztendlich abgeschaltet hat, konnten wir noch nicht in Erfahrung bringen. Am Vortag, als Hetzner mailte, war der Server noch da, es muß also im Laufe des Dienstags passiert sein.

ZIEL ERREICHT

Die Daten sind aus dem Netz verschwunden, was das erklärte Ziel der Aktion war. Danke an alle, die mit geholfen haben. Von den involvierten Behörden habe ich bis heute (12.10.) noch nichts dazu gehört.

Das Letzte(?) Update vom 17.10.2022

WBS.LAW rief mich gerade an, nur um mir mitzuteilen, daß sie noch gar nichts gemacht hatten und erstmal hören wollten, was los ist. D.b. das weiterhin unklar ist, wer Hetzner nach 4 Wochen dazu gebracht hat, dem, Abuse endlich mal nachzugehen, denn bis heute gibt es von den Behörden dazu keine Rückmeldung.

An dieser Stelle breche ich jetzt das Eis und stelle den Bericht ins Netz. Wenn es ab jetzt noch Meldungen dazu gibt, reich ich Euch die ggf. nach.

Nein, war es nicht.. 19.10.2022

Da kam doch jetzt gerade doch noch ein Lebenszeichen von der LDA Bayern rein. Bildet Euch selbst eine Meinung dazu:

Sehr geehrter Herr ……,

wir kommen zurück auf Ihre Eingabe vom 14.09.2022. Nachdem Sie nicht die Verletzung eigener Rechte behauptet und plausibel dargestellt haben, bewerten wir Ihre Eingabe als Kontrollanregung.

Wir möchten Sie zunächst darauf hinweisen, dass wir, das Bayerische Landesamt für Datenschutzaufsicht (BayLDA), die Einhaltung des Datenschutzrechts im nicht-öffentlichen Bereich in Bayern überwachen, d. h. primär in den privaten bayerischen Wirtschaftsunternehmen, Vereinen und Verbänden und bei freiberuflich Tätigen.

In Ihrer Eingabe verweisen Sie jedoch auf eine Sicherheitslücke bei einem italienischen Verantwortlichen. Wir haben Ihre Angaben geprüft und dabei festgestellt, dass wir in dem Fall nicht tätig werden können, da das verantwortliche Unternehmen nicht in unserer Zuständigkeit ist. Zu Recht geben Sie an, dass sich die ungesicherten Backup-Dateien auf einem Server befinden, der gemäß der IP-Adresse bei der Hetzner Online GmbH lokalisiert werden kann. Hierbei, also bei der Hetzner Online GmbH, handelt es sich jedoch datenschutzrechtlich gesehen nicht um den Verantwortlichen, sondern wahrscheinlich lediglich um einen Auftragsverarbeiter, der von dem italienischen Unternehmen eingesetzt wird. Für die Sicherheit der Daten ist zunächst jedoch das verantwortliche Unternehmen zuständig. Dieses Unternehmen muss dafür Sorge tragen, dass personenbezogene Daten ausreichend geschützt sind. Tätig werden muss in dem Fall deshalb auch der Verantwortliche, der die Dateien nicht gesichert hat, und eben nicht der Auftragsverarbeiter.

Wir bitten Sie deshalb sich an den Verantwortlichen, also das italienische Unternehmen, oder aber an die für Sie in Ihrem Bundesland zuständige Datenschutzaufsichtsbehörde zu wenden. Ein Tätigwerden unsererseits ist aufgrund der fehlenden Zuständigkeit nicht möglich. Den Vorgang schließen wir deshalb mit diesem Schreiben ab.

Mit freundlichen Grüßen
…
Bereich 4 – Cybersicherheit und Technischer Datenschutz

Bayerisches Landesamt für Datenschutzaufsicht
Promenade 18, 91522 Ansbach

Fangfrage: Hmm…wer wird aus Deutschland in Italien bei einer Behörde wohl mehr Erfolg haben: Ich mit deepl.com als Helfer oder eine deutsche Datenschutzbehörde???

Der 24.Oktober 2022

„Bella-Italia“ lässt schön grüßen, die Datenschutzeingabe mit Deepl’s Hilfe ist per Email angekommen und einem Vorgang zugewiesen worden.

Gespannt warten wir auch die nächste Nachricht, denn wenn die ähnlich schnell sind, kann ich jetzt 4 Wochen in Ruhe verreisen 😀