Category Archives: Allgemein

Datenschutz: Wie peinlich T-Online ist

Posted on by

Peinlicher, aber nicht ganz unerwarteter, Fauxpas von T-Online:

2020-02-25 04:55:03 1j69ZJ-0001iL-S3 H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 04:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-38) H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 05:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 06:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 07:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 08:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 09:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 10:55:03 1j69ZJ-0001iL-S3 H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 10:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-38) H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support

angemerkt sein, daß die Server für Kundenmails davon nicht betroffen sind. Das ändert aber nichts daran.

T-Online mit Datenschutzverstoß

Der Verzicht auf TLS stellt meiner Meinung nach, mal einen soliden Verstoß gegen Artikel 32 DSGVO dar, weil man als Mailserverbetreiber ja vorher nicht wissen kann, ob da drüber Personenbezogene Daten transportiert werden sollen oder nicht. Hellsehen, was einem einer jemals schicken wird, kann man ja nicht und daher muß man zwangsläufig vorher die Sicherheit der Datenübertragung aktiviert haben, weil nachträglich Sicherheit herstellen geht in dem Fall nun mal nicht.

Artikel 32
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;

Das kombiniert mit Artikel 4 2. schließt den Transport von Daten mit in den Begriff „Verarbeitung“ ein und erzwingt, weil der Aufwand praktisch nicht vorhanden ist und somit auch keine Kosten entstehen, die Verschlüsselung von Emails beim Transport durch den Einsatz von aktuellen Techniken ( STARTTLS mit TLS 1.2+).

In dem Fall wären es tatsächlich Personenbezogene Daten gewesen, weswegen unser Mailserver so eingestellt ist, daß er das in dem Fall auf keinen Fall über unsichere Leitungen schicken darf.

Die Adresse tosa@rx.t-online.de ist übrigens eine T-Online Adminadresse, falls man mal mit seinem Server gesperrt ist(, weil T-Onlinekunden Spams an ihre echten Adressen einfach ungefiltert an T-Onlineadressen weiterleiten) . Ich gehe mal davon aus, daß wie bei großen Organisationen üblich, Links nicht weiß was Rechts hätte tun sollen.

Die notwendigen Schritte den Verstoß abzustellen, werde ich jetzt anstoßen.

Update: 18:50 Uhr

Es gab Antwort von T-Online… und jetzt schön hinschauen… nicht lachen…

Received: from mailout02.t-online.de ([194.25.134.17])
	by userserver with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(Exim 4.93)
	(envelope-from <postmaster@rx.t-online.de>)
	id ---
	for unsere@adresse; Tue, 25 Feb 2020 13:26:31 +0100
Received: from fwd37.aul.t-online.de (fwd37.aul.t-online.de [172.20.27.137])
	by mailout02.t-online.de (Postfix) with SMTP id ---
	for <unsere@adresse>; Tue, 25 Feb 2020 13:26:31 +0100 (CET)
Received: from mail.t-online-team.de (SU1DYkZrrhdrbk+8MoWoNLfFvJAGt3hYNV-3h42o51p2-46yGQLhcUQTxiv6TV2wPu@[194.25.187.129]) by fwd37.t-online.de
	with (TLSv1:ECDHE-RSA-AES256-SHA encrypted)
	esmtp id ---; Tue, 25 Feb 2020 13:26:30 +0100
From: Deutsche Telekom E-Mail Engineering ************* <postmaster@rx.t-online.de>
Date: Tue, 25 Feb 2020 13:26:31 +0100
Organization: Deutsche Telekom AG
X-Mailer: Forte Agent 6.00/32.1186
Content-Type: text/plain; charset=ISO-8859-1

Diese Email ist der nächste Verstoß gegen den Datenschutz, weil in der DSGVO steht drin, daß man auch bei internem Datentransport an die Absicherung denken muß.

Wie man sieht nutzt der erste Mailserver (mail.t-online-team.de) auf dem Weg zu unserem Mailserver (oberster Eintrag) TLSv1.0 , ein seit spätestens 2015 final geknacktes Protokoll. Der nächste interne Server  (fwd37.aul.t-online.de) benutzt für den internen Transport zu mailout02.t-online.de gleich gar keine Verschlüsselung mehr. Der letzte Mailserver mailout02.t-online.de macht dann endlich mal was richtig auf dem weg zu uns und benutzt TLSv1.2.

D.b. das „mailout02.t-online.de“ und „fwd37.aul.t-online.de“ können entweder miteinanders kein gemeinsames Protokoll finden, oder haben TLS/SSL gar nicht im Programm. Da aber jeder von denen auf der jeweils anderen Seite der Verbindung irgendwie TLS kann, muß da bei T-Online das Chaos pur herrschen. Ob das absichtlich, unabsichtlich oder fahrlässig so ist, werden die Datenschutzbehörden klären.

„Hallo T-Online, das Jahr 2005 will seinen Uralt-Zeichensatz zurück haben!“

Von dem ISO-8859-1 Fail des Mailprogramms will ich gar nicht erst anfangen, aber wirklich, was für einen uralt Krempel nutzen die da??? de-latin1 und TLSv1 passen historisch natürlich gut zusammen 🙂

Ältere Fälle:

Willkommen im Club der TLS Verweigerer: Apache Foundation!

BSI aktualisiert Mailserver auf TLS 1.2.. ABER

Sächsische Polizei benutzte gebrochene Verschlüsselung

PHP: kleines Problem in 7.3 mit . + –

Posted on by

Da meldet sich doch mein Kalender heute mit der Meldung, er könnte den Termin nicht modifizieren, weil der Server einen 500er Fehler produziert hat. Der Aufruf des Webinterfaces verlief zunächst einmal ohne Befund.

PHP 8 ist bald da!

Der eigentliche Fehler im Script ist eigentlich ganz einfach, hat aber große Auswirkungen auf PHP Programme. Ich wage sogar die These, daß dieser Fehler in PHP 8 zu einem Y2K Problem wird: Fixbar, aber es wird trotzdem knallen.

Kleine Einführung, damit Sie dem auch folgen können:

PHP ist eine Programmiersprache die auf Webservern zum Einsatz kommt.

E= 3+1  ergibt E=4  ( Addition )
E= 3-1    ergibt E=2  ( Subtraktion )
„Hallo“ . “ “ . „Welt“  ergibt in PHP „Hallo Welt“
„Obj->F“ meint, Zugriff auf ein FELD (F) im Objekt (Obj) , wird in der Objektorientierten Programmierung von PHP benutzt. „$this->“ meint dabei das Objekt in dessen Kontext die Operation ausgeführt wird, sprich „meint sich selbst“.

„+-“ sind nummerische Operationen,  „.“ ist eine lexikalische Anweisung auf Textblöcke in PHP.

Schauen wir uns erstmal den Fehler an, den SabreDAV hier als Kalenderbackend produziert:

[Wed Jan 08 16:03:28.700531 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] PHP Fatal error: Uncaught ErrorException: The behavior of unparenthesized expressions containing both ‚.‘ and ‚+’/‘-‚ will change in PHP 8: ‚+’/‘-‚ will take a higher precedence in /home/<username>/cal/vendor/sabre/vobject/lib/Sabre/VObject/RecurrenceIterator.php:829: <cgiwrapper>
[Wed Jan 08 16:03:28.700685 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] Stack trace:: <cgiwrapper>
[Wed Jan 08 16:03:28.700946 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #0 /home/<username>/cal/vendor/composer/ClassLoader.php(386): exception_error_handler(): <cgiwrapper>
[Wed Jan 08 16:03:28.701145 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #1 /home/<username>/cal/vendor/composer/ClassLoader.php(386): include(): <cgiwrapper>
[Wed Jan 08 16:03:28.701369 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #2 /home/<username>/cal/vendor/composer/ClassLoader.php(278): Composer\\Autoload\\includeFile(): <cgiwrapper>
[Wed Jan 08 16:03:28.701539 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #3 [internal function]: Composer\\Autoload\\ClassLoader->loadClass(): <cgiwrapper>
[Wed Jan 08 16:03:28.701741 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #4 /home/<username>/cal/lib/Sabre/CalDAV/Backend/PDO.php(520): spl_autoload_call(): <cgiwrapper>
[Wed Jan 08 16:03:28.702034 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #5 /home/<username>/cal/lib/Sabre/CalDAV/Backend/PDO.php(461): Sabre\\CalDAV\\Backend\\PDO->getDenormalizedData(): <cgiwrapper>
[Wed Jan 08 16:03:28.702503 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #6 /home/<username>/cal/lib/Sabre/CalDAV/CalendarObject.php(96): Sabre\\CalDAV\\Backend\\PDO->updateCalendarObject(): <cgiwrapper>
[Wed Jan 08 16:03:28.702713 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #7 /home/<username>/cal/lib/Sabre/DAV/Server.php(888): Sabre\\CalDAV\\CalendarObject->put(): <cgiwrapper>
[Wed Jan 08 16:03:28.703037 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #8 [internal function]: Sabre\\DAV in /home/<username>/cal/vendor/sabre/vobject/lib/Sabre/VObject/RecurrenceIterator.php on line 829: <cgiwrapper>

Da wird also die fehlende Klammerung von Operationen mit „.“ „-“ oder „+“ angekreidet. Erstmal komisch, bis man den Sourcecode dazu sieht:

$this->currentDate->modify(‚+‘ . $this->interval-1 . ‚ weeks‘);

PHP 7.3 meckert hier also darüber, daß der Entwickler davon ausgeht, daß eine mathematische Operation Vorrang vor einer lexikalischen Operation hat. Vom Ablauf steht dort in etwa:

$TVAR = $this->interval
$TVAR = $TVAR – 1
$TSTRING1 = StringAusZahl( $TVAR )
$TSTRING2 = FügeStringsZusammen( „+“, $TSTRING1, “ weeks“ )
RufeFunktionAuf(  $this->currentDate->modify , $TSTRING2 )

Das geht nur, weil der Operator „-“ hier Vorrang hat im Parser. Wenn das nicht mehr der Fall ist, also „.“ gleichrangig mit „-“ wäre, dann knallts, weil dann käme das raus ( oder noch etwas völlig anderes ):

$TVAR = $this->interval
$TVAR = $TVAR – „1 weeks“

Und hier wäre es dann auch schon vorbei, weil das nicht geht. Man kann keinen String von einer Zahl abziehen. Deswegen muß man jetzt eine Klammerung vornehmen, die eindeutig macht, was da wie subtrahiert werden soll und was dann als Zahl behandelt werden soll.

IMHO wäre das schon ein ParserBug in PHP 0.1 gewesen, der es nie in die Stable von PHP hätte schaffen dürfen. Das Parserverhalten jetzt in PHP 7.3 zu ändern bricht ziemlich hart mit vorhandenem Code und wird totsicher für Probleme rund um den Globus führen.

So müßte es jetzt für PHP 7.3 + PHP 8 geändert werden, damit es später noch funktioniert:

$this->currentDate->modify(‚+‘ . ($this->interval-1) . ‚ weeks‘);

Jetzt ist klar, daß hier „-“ Vorrang vor „.“ hat. Problem gelöst.

„Security“ by Deutsche Bahn

Posted on by

Die Deutsche Bahn hat ja derzeit schon einen Gesprächstermin mit der Berliner Datenschutzbeauftragten, weil sie Greta’s Reisedaten preisgegeben haben, aber vor 16 Minuten brach auch die Sicherheitsfassade der DB IT zusammen. Auf Full-Disclosure wurde vom Vulnerability Laboratory eine DB Bahn Sicherheitslücke veröffentlicht.

„Security“ by Deutsche Bahn

Man kennt das als Bahnfahrer, man trifft an an einem Bahnhof ein und möchte woanders hin. Dazu braucht man einen Fahrschein, neudeutsch auch Ticket genannt. Um ein Ticket zu bekommen, stehen überall so kleine armlose Roboter rum, die Geld in Tickets wechseln. Dazu gibt man ein, wo man hin will und dann …. crasht gelegentlich die Anwendung intern, und da wird es spannend 🙂

Ein Prozess auf dem… und jetzt gut festhalten… Windows XP System, namens PasswordAgent.exe hat diverse Fehler, mal kann er was nicht abfragen, mal gibt es Laufzeitfehler, wie man das so noch von WinXP kennt ;). Jedesmal wenn das passiert, kommt eine Fehlermeldungsbox. Auf normalen PC wäre die im Vordergrund zusehen, hier allerdings versteckt sie sich hinter dem Anwendungsfenster des Verkaufsautomaten, damit der Kunde genau das nicht sehen kann.

Leider gibt es da noch einen Bug: Wenn man im Zahlenfeld auf Abbrechen klickt, während diese Meldung im Hintergrund angezeigt wird, kommt die nach vorne, vor die Verkaufsanwendung.

Jetzt haben wir ein Standardwindowsfehlerfenster und da ist ein Link drin zu den Details der Fehlermeldung. Darin wiederum ist ein Link zur M$-Hilfe. Drückt man drauf kommt, Ihr ahnt es, ein Browser ins Spiel, weil das ein Weblink ist. Ist der Browser erstmal gestartet, hat man über das Einstellungsmenü die Option ins Filesystem zu wechseln und der Rest dürfte auf der Hand liegen: Trojaner drauf, Ransomware oder einfach die DB Kunden verarschen, in dem der Automat keinen Fahrschein druckt oder oder oder…

Hier nochmal die Kurzfassung des Exploitweges:

PasswordAgent.exe := Unexpected Error (Background) – Runtime/Session/Timeout
=> Transaction Application => Cancel := Unexpected Error (Background) – Runtime/Session/Timeout (Front)
=> Click Error Report => Click Search Collection => Web Browser => Local File System => PWND!

Den Wert des Exploits schätzen die Finder auf 5.000€ – 10.000€ ein.

Angeblich kam die Bahn bereits selbst auf diese Lücke und hätte auch schon mit dem Patchen begonnen, insofern müßten potentielle Spaßvögel sehr schnell reagieren 😉

Quelle: https://www.vulnerability-lab.com/get_content.php?id=2191