Tag Archives: TLS

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

OMG des Tages: Fulldisclosure ML bietet kein TLS an

Posted on by

Nicht das man es brauchen würde, aber in 2019 darf man doch von einer Securityliste erwarten, daß deren Mailserver TLS kann, oder? Nicht so bei NMAP.

seclists.org Mailserver bietet kein TLS an

Gerade wollte ich das Duplicator Pro Advisory an die  FullDisclosure Mailingliste schicken, da mault doch glatt mein Mailserver, daß er die Mail nicht schicken könnte, weil der Empfänger TLS verweigert. Ein OMG war die Folge:

CheckTLS Confidence Factor for „fulldisclosure@seclists.org“: 0

MX ServerPrefAnswerConnectHELOTLSCertSecureFrom
ack.nmap.org
[45.33.49.119:25]		0OK
(69ms)		OK
(151ms)		OK
(68ms)		FAILFAILFAILOK
(357ms)

2019-09-27 21:23:52 1iDvqI-0005NU-Mw == fulldisclosure@seclists.org R=dnslookup T=remote_smtp defer (-38) H=ack.nmap.org [45.33.49.119]: a TLS session is required, but the server did not offer TLS support

Jetzt braucht man natürlich keine Verschlüsslung, wenn eh an eine öffentliche Mailingliste Veröffentlichungen schickt, aber da laufen auch private Mailinglisten drüber z.b. über Bugs in NMAP und die sollten ja wohl verschlüsselt ankommen, oder?

Es kommt mir so bekannt vor…

Besonders prekär für die Admins des NMAP Mailservers ist der Umstand, daß deren Mailserver sehr wohl TLS beim Senden von Emails kann, sonst kämen die Emails nicht bei uns an:

2019-09-26 08:54:08 1iDNfD-00060F-Mj <= fulldisclosure-bounces@seclists.org H=ack.nmap.org [45.33.49.119] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=21878 id=6e00195f-664f-1d1c-0fb6-1333992ad574@sec-consult.com

Die große Ähnlichkeit zum BSI CERT-Bund Mailserver macht es natürlich nicht besser: BSI aktualisiert Mailserver auf TLS 1.2.. ABER .

Ich seh schon, mit dem TLS Gate habe ich noch auf Jahre jede Menge Spaß fürs Blog 😀

Hinweis: Duplicator Pro <= 1.3.14 hat eine fiese IFDC Schwachstelle. Bitte updaten!

Willkommen im Club der TLS Verweigerer: Apache Foundation!

Posted on by

Nachdem ich die Admins von Mozilla dies Jahr endlich dazu bewegen konnte, für den Mailserver Ihres Bugtrackers TLS zu aktivieren, muß ich leider feststellen, daß eine der größten Organisationen im FOSS Bereich derbe ins Klo gegriffen hat:

Willkommen im Club der TLS-Verweigerer: Apache Foundation!

Eigentlich sagen Bilder ja mehr als tausend Worte, aber in dem Fall erfüllt eine einzige Logzeile den gleichen Zweck:

2019-09-09 12:20:07 H=hermes.apache.org (mail.apache.org) [207.244.88.153] F=<bugzilla@apache.org> rejected RCPT <empfänger@empfängerdomain.de>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.

Damit reiht sich die Apache Foundation erfolgreich in den Club der TLS-Verweigerer ein. Ich vermute, daß, da auch der Mozilla Bugtracker das gleiche Problem hatte, eine gemeinsame Programmbasis vorliegt, mit den gleichen schlechten Default Einstellungen! Da ich schlecht fragen kann, weil Emailantworten ja nicht ankommen, werden wir nie rausfinden woran das liegt 😉

Fest steht, daß gerade für einen Bugtracker, der ja „Security related Content“ transportiert, die TLS-Verweigerung ein klarer Sicherheitsbruch ist. Wünschen wir dem Verantwortlichen daher ein böses Erwachen.

Natürlich werde ich versuchen, Apache zum Besseren zu bekehren, aber erfahrungsgemäß sind Admins, die das nicht selbst merken oder es für kein Problem halten, schwer in die Realität zu überführen. Bei Mozilla hat es 2 Jahre gedauert 😉

Update: 22:19

Entschuldigt die Ausdrucksweise, aber „boar ist das hart!“ . Ich habe ja die Geschichten von den störischen OO Entwicklern nicht sooo richtig geglaubt, aber was da heute an dämlichen Antworten auf Bugreports kam, das haut dem Fass den Boden raus!

„Was für eine unfassbare Scheiße.:!!“

Ich melde da einen Segmentation Fault, der seit einigen Tagen auftritt und bekomme als Antwort: „Das liegt an Deiner Maschine.“ . Die „latest“ Version von OpenOffice ist 4.1.6 , die ist von September 2018, also rund 1 Jahr alt. Das der Rest der Welt da mal ein paar Updates eingespielt haben könnte und OO deswegen crashed, ist zwar primär richtig, aber sowas von arrogante Scheiße, daß man dem Herrn gern mal eins zwischen die Ohren geben will. „Es ist natürlich nicht unser uralt Code der da failed, es ist das Security Update auf Deinem Rechner, daß nicht mitspielt.“ Was denkt sich so ein Depp eigentlich?

Ticket Nummer zwei war dann zu dem fehlenden TLS im Mailserver, kam als Antwort „ist kein OOO Problem“. Was zum Geier ist ein OOO Problem? OpenOfficeOrganisation oder was? Das ist doch dem Reporter egal, ob das vom Apache Admin, oder vom Projektleiter gelöst wird, Fakt ist, daß die mit dem mangelnden TLS Support technisch in der Steinzeit leben. Das wurde Anfang der 90er Jahre des letzten Jahrtausends eingeführt, immerhin ist das fast !!! 30 !!! Jahre her! Echt unglaublich.

Aber diese Mentalität paßt natürlich zur „unser Code ist steinalt, deswegen ist der gut“ Antwort. Konsequent sind die ja dann irgendwie 😀

Es gibt nur eine Lösung

Da kann man nur eins empfehlen: dnf erase openoffice;dnf install libreoffice

Auch wenn ich LibreOffice nicht mag, da dort bei Präsentationen die Medien Einbindung nicht richtig funktioniert. Aber immerhin schicken die häufiger Updates raus.

Wir erpressen Sie jetzt mal..oder so :D

Posted on by

Herzlich Willkommen zu einer neuen Ausgabe von „Erpresser – Man muß sie einfach gern haben“ .. wieso? na weil ich dann wieder was zu schreiben habe und Ihr was zu Lachen 😀

Kommen wir zu dieser Erpresser-Spam:

Ich markiere mal die Anekdoten farblich…

Return-path: <junko@kotorinouta.com>
Envelope-to: <#### eine unserer echten Adressen####>
Delivery-date: Mon, 08 Jul 2019 11:44:24 +0200
Received: from www1765.sakura.ne.jp ([112.78.112.75])
	by XXXXXXXXXXX.de with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(XXXXXXXXXXXXXXXXXXXXXXXXXX)
	(envelope-from <junko@kotorinouta.com>)
	id XXXXXXXXXXXXXXXXX
	for <#### eine unserer echten Adressen####>; Mon, 08 Jul 2019 10:44:23 +0200
Received: from [127.0.0.1] (dynamic-189-45-26-22.webnet.psi.br [189.45.26.22])
	(authenticated bits=0)
	by www1765.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id x585vAi13157658
	(version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <#### eine unserer echten Adressen####>; Mon, 8 Jul 2019 17:44:21 +0900 (JST)
	(envelope-from junko@kotorinouta.com)
To: <#### eine unserer echten Adressen####>
From: Mylah <junko@kotorinouta.com>
MIME-Version: 1.0
Message-ID: <2b514q3322k452d@kotorinouta.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 8 Jul 2019 12:56:54 +0300
List-Help: <http://friend.kotorinouta.com/help/forsubscribers>
X-EVENT_NAME: trxzzkst
X-Virus-Flag: YES
Subject:  Security Alert. Your accounts were hacked by a criminal group.

Hello!

I am a hacker who has access to your operating system.
I also have full access to your account.

I've been watching you for a few months now.
The fact is that you were infected with malware through an adult site =
that you visited.

If you are not familiar with this, I will explain.
Trojan Virus gives me full access and control over a computer or other=
 device.
This means that I can see everything on your screen, turn on the camer=
a and microphone, but you do not know about it.

I also have access to all your contacts and all your correspondence.

Why your antivirus did not detect malware?
Answer: My malware uses the driver, I update its signatures every 4 ho=
urs so that your antivirus is silent.

I made a video showing how you satisfy yourself in the left half of th=
e screen, and in the right half you see the video that you watched.
With one click of the mouse, I can send this video to all your emails =
and contacts on social networks.
I can also post access to all your e-mail correspondence and messenger=
s that you use.

If you want to prevent this,
transfer the amount of $500 to my bitcoin address (if you do not know =
how to do this, write to Google: "Buy Bitcoin").

My bitcoin address (BTC Wallet) is:  3HsB65YE6xgdt6x8Nnrxjck1YMNK1kMka=
L

After receiving the payment, I will delete the video and you will neve=
r hear me again.
I give you 50 hours (more than 2 days) to pay.
I have a notice reading this letter, and the timer will work when you =
see this letter.

Filing a complaint somewhere does not make sense because this email ca=
nnot be tracked like my bitcoin address.
I do not make any mistakes.

If I find that you have shared this message with someone else, the vid=
eo will be immediately distributed.

Best regards!

Solche Emails gibt es ja zu Hauf, der braucht man inhaltlich keine große Aufmerksamkeit schenken. Wir schauen uns mal an, was wir so über den Möchtegernerpresser herausbekommen:

1. Die Einlieferung der Email stammt aus Brasilien, DSL Anschluß, ergo gehackter PC oder seine echte IP 🙂

from [127.0.0.1] (dynamic-189-45-26-22.webnet.psi.br [189.45.26.22])

2. Was auch immer da per SMTP die Email in Japan eingeliefert hat, es hält nicht viel von moderner Software:

(version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)

3. Es handelt sich möglicherweise um eine Mailingliste bei einer Kinder-Sozialhilfe:

List-Help: <http://friend.kotorinouta.com/help/forsubscribers>

Google kennt zu der Domain folgende Info:

Poesie-Kindergarten für das Sozialhilfswerk Koori no Uta-Kindergarten Chigasaki-Stadt, privater Kindergarten der Präfektur Kanagawa

Also ein ziemlich fieser Charakter dieser Erpresser, wenn er einen Kindergarten als Tarnung für seine Aktivitäten benutzt.

4. Offensichtlich hat der Erpresser auch von der Technik keine Ahnung:

Filing a complaint somewhere does not make sense because this email cannot be tracked like my bitcoin address. I do not make any mistakes.

Der erste Fehler war, die Email an uns zuschicken. Fehler Nummer 2, natürlich kann man Emails bis zur Sender IP  verfolgen, wobei man das gar nicht muß, da uns der Erpresser freundlicherwiese seine Bitcoinadresse genannt hat

Bitcoin Adressen, und damit Bitcoins, lassen sich durch die Blockchain tracken, egal ob Bitcoin Mixer im Spiel sind oder nicht. Die Blockchain ist nicht anonym und der Benutzer auch nicht, im Gegensatz zu echtem Bargeld, das ist bis auf die Fingerabdrücke und DNS Spuren anonym! Es ist nämlich im wahrsten Sinne waschbar 🙂

Wenn man Bitcoins waschen will, muß man damit ins Spielcasino gehen. in China nehmen viele Casinos auch Digitales Geld an und man muß es ja nicht zwangsweise verlieren 😉

Es hat wohl noch niemand bezahlt

Stand 13:30 Uhr hat wohl niemand etwas auf dieses Konto überwiesen, was mich nicht wundert, die Scamwelle schappt ja schon seit jetztem Sommer durchs Netz:

https://www.blockchain.com/de/btc/address/3HsB65YE6xgdt6x8Nnrxjck1YMNK1kMkaL

oder auch

https://www.bitcoinabuse.com/reports/3HsB65YE6xgdt6x8Nnrxjck1YMNK1kMkaL

Wie immer …

Ab in die digitale Müllhalde damit!

BSI aktualisiert Mailserver auf TLS 1.2.. ABER

Posted on by

„Nein! Doch!! OOOHHHH!“ Es ist vollbracht. Das BSI hat den Newsletterserver für das Bürger-CERT nach 13 Monaten endlich auf TLS 1.2 gehievt, also auf den Stand der Technik vom Jahr 2008.  \o/

Delivery-date: Wed, 13 Mar 2019 15:27:52 +0100
Received: from newsletter.bund.de ([77.87.229.56])
	by XXXXXXXXXXXXX.de with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(Exim 4.90_1)
	(envelope-from <buerger-cert-newsletter@newsletter.bund.de>)
	id 1h44rG-0001dj-FW
	for XXXXXXXXXXXXXXXX.de; Wed, 13 Mar 2019 15:27:52 +0100

Bin mal gespannt, ob der 2030 endlich TLS 1.3 kann 😀

OHHHH NEEEEIIIINN!!!!

KEIN TLS IM SERVER

Das kann jetzt echt nicht wahr sein, aber der gleiche Server, der beim Senden TLS 1.2 nimmt, bietet nicht mal TLS an, wenn er was empfangen soll!

Trying TLS on newsletter.bund.de[77.87.229.56:25] (10):

secondstest stage and result
[000.106]Connected to server
[000.292]<–220 ESMTP
[000.293]We are allowed to connect
[000.293] –>EHLO www6.CheckTLS.com
[000.399]<–250-newsletter.bund.de
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[000.399]We can use this server
[000.399]TLS is not an option on this server
[000.400] –>MAIL FROM:<test@checktls.com></test@checktls.com>
[000.506]<–250 2.1.0 Ok
[000.506]Sender is OK
[000.506] –>QUIT
[000.612]<–221 2.0.0 Bye

Geht noch mehr FAIL ?

Mehr zu dem Thema : Mailserver – Gebrochenes TLS im Einsatz