AT&T Mailserver kann kein TLS

Hallo,

heute befassen wir uns mal wieder mit dem Thema Mailsicherheit. Heute:

AT&T Mailserver kann kein TLS, nicht mal SSLv3

Ich habe ja bereits einige Mailserver erlebt, die gar kein TLS können, oder nur bereits gebrochene Dialekte sprechen. Meistens sind das Server von Leuten, die nicht in der Telekommunikationsbranche sind. Aber TK Firmen waren da noch nie drunter. Daher hatte mich das hier doch stark verwundert:

2021-03-26 12:55:09 1lPLyv-0002Bo-89 == abuse@att.net R=dnslookup T=remote_smtp defer (-38) H=ff-ip4-mx-vip2.prodigy.net [144.160.159.22]: a TLS session is required, but the server did not offer TLS support

ATT.net aka. AT&T kennen Amis gut. In Comedysendungen wird AT&T immer als Gag eingebaut, weil die im Mobilfunksegment ungefähr so kompetent sind, wie die Deutsche-Pre-Corona-Bahn beim Einhalten Ihres eigenen Fahrplans 🙂 Jetzt könnte man der Liste an AT&T Verfehlungen auch noch Inkompetenz beim Betreiben von Mailserver hinzufügen.

Das mein Mailserver mit seiner Aussage oben richtig liegt, zeigt auch ein Test von CheckTLS.com:

secondstest stage and result
[000.000]Trying TLS on 144.160.159.22[144.160.159.22:25] (-1)
[000.070]Server answered
[000.299]<‑‑220 flpd588.prodigy.net ESMTP Sendmail Inbound 8.15.2/8.15.2; Fri, 26 Mar 2021 06:27:18 -0700
[000.299]We are allowed to connect
[000.299]‑‑>EHLO www12-do.checktls.com
[000.368]<‑‑250-flpd588.prodigy.net Hello www12-do.checktls.com [142.93.73.156], pleased to meet you
250 ENHANCEDSTATUSCODES
[000.369]We can use this server
[000.369]TLS is not an option on this server
[000.369]‑‑>MAIL FROM:<test@checktls.com>
[000.438]<‑‑553 5.3.0 flpd588 DNSBL:RBL 521< 142.93.73.156 >_is_blocked.For assistance forward this error to abuse_rbl@abuse-att.net
[000.439]Cannot proof email address (reason: MAIL FROM rejected)
[000.439]Note: This does not affect the CheckTLS Confidence Factor
[000.439]‑‑>QUIT
[000.508]<‑‑221 2.0.0 flpd588.prodigy.net closing connection

Jetzt ratet mal wieso ich AT&T eine Abusemail schicken mußte…. DOS Angriff aus deren Netzwerk. Zum Glück nur Amateure.

Nachtrag:

Wollt Ihr noch was zu Lachen haben?

2021-03-26 14:46:25 1lPLyv-0002Bo-89 ** abuse@att.net R=dnslookup T=remote_smtp H=ff-ip4-mx-vip1.prodigy.net [144.160.159.21]: SMTP error from remote mail server after MAIL FROM:<XXX@XXXX.XX>: 553 5.3.0 flph832 DNSBL:ATTRBL 521< XX.XX.XX.XX >_is_blocked.For assistance forward this error to abuse_rbl@abuse-att.net

Der Server ist seit mehr als 10 Jahren ohne eine einzige Spamemail am Netz, weil das ein interner Server ohne Kunden von uns ist. 11 Jahre Hackfrei. Der selbe Server konnte dann an die abuse-att.net was senden 😉

Die nutzen vermutlich die gleiche veraltete DNS-Blackliste wie Fefe. Der Vorbesitzer von dem IP Netz hatte da wohl irgendwann mal Spams vermailt. Ein Glück setzen wir so schlecht gewartete Blacklisten nicht ein.

BSI aktualisiert Mailserver auf TLS 1.2.. ABER

Scammer nutzen SMS zur Linkverbreitung

Hi,

seit heute kommen SMS von angeblich deutschen Telefonnummern, die Trojaner und Spamlinks enthalten.

Scammer nutzen SMS zur Linkverbreitung

Irgendjemand hat gerade in ein Fettnäpfchen getreten,denn alle die SMS gehen direkt an die Kripo in Hannover 🙂

Der Inhalt ist dabei immer gleich :

„Ihr Paket kommt an, verfolgen Sie es hier: https://gehacktedomain/t/?tokenid“

Die Welle scheint am 17.3. begonnen zu haben und auch Landeskriminalämter sollen bereits Warnungen vor diesen SMS ausgegeben haben, da hier Schadsoftware auf das Smartphone installiert werden soll. Nummern wie 0152 55 71 33 13 oder 0151 17 86 16 99  dürften frei erfunden sein, denn ich denke, jemand hat sich bei einem S7 Anbieter mit einem billigen Tarif die Möglichkeit eingekauft, massenhaft solche Spam-SMS zu verschicken.  Ergo, schön aufpassen, was da so an SMS bei Euch aufschlägt.

Wo ich mich schon richtig drauf freue, wenn diese SMS auf mein Linuxphone treffen 😀 Da ist nichts mit Hacken, das aktualisiert sich alle paar Stunden 😀

RCE Lücke in smartem Stromzähler

Das ein Gericht das BSI gerade daran gehindert hat, einfach die Anforderungen an die Zulassung von smarten Stromzählern zu senken, war eine mehr als positive Entscheidung. Wie sich zeigt ist die Sicherheit von smarten Stromzählern essentiell.

RCE Lücke in smartem Stromzähler

ThreadPost berichtet in einem Artikel vom 12.3. von einer ungepatchten Sicherheitslücke in einem „Schneider Electronic PowerLogic ION/PM Smart Meter“:

„Critical security vulnerabilities in Schneider Electric smart meters could allow an attacker a path to remote code execution (RCE), or to reboot the meter causing a denial-of-service (DoS) condition on the device.“

Dies Modell wird zwar nicht in Deutschland eingesetzt AFAIK, zeigt aber wie wichtig die Sicherheitsfrage bei diesen Geräten ist. Die fraglichen Geräte hängen wohl am Internet und sind so Angriffen ausgeliefert. Wieso man da bitte nicht mal eine Firewall vorsetzt, die Verbindungen nur vom zuständigen Datacenter zulässt, wird wohl niemand von der Firma beantworten wollen.

Dieses spezielle Smartmeter kann komplett übernommen werden, oder alternativ geDOSt werden, also an der Arbeit gehindert werden. Wenn ich so eine Lücke hätte, wüßte ich was das Smartmeter messen lassen würde: Das ich im Urlaub bin und nur der Kühlschrank läuft 😉  „Ist halt gehackt worden“, falls jemand die Frage stellt, wieso die Leitungen rot leuchten 😉

Das Schlimme an der Sache ist, daß solche Geräte mal wieder in Rechenzentren und Medizinischen Einrichtungen stehen. Damit sind diese Geräte, denen man den Hack nicht ansieht, dann Einfallstore für weitere Attacken. Wie man dem Bericht weiter entnehmen kann, ist wohl der ganze interne Softwarestapel schlampig zusammen gebaut worden:

“We found that the advance_buffer function always returns true, regardless of other inner functions failing and returning false. „

Das meint, daß egal ob eine Unterroutine die Rote Leuchte rausstellt und den Aufrufer darauf hinweist, daß es nicht geklappt hat, macht die aufrufende Routine einfach weiter. Das nennt man im Fachjargon „Fire & Forget Code“. Dieser geht immer davon aus, daß das was er tut funktioniert. Eine Fehlerbehandlung ist nicht vorgesehen. Und genau das fällt diesem Smartmeterhersteller jetzt auf die Füße. Aus Programmierersicht habe ich da jetzt kein Mitleid, weil das ist einfach nur schlampig zusammen gebastelt worden.