Dr.Oetker: E-Mail Bestätigung 7578

„Komisch, ich kenne gar keinen bei Dr.Oetker.“ Trotzdem habe ich angeblich Post von denen bekommen 😉

Dr.Oetker: E-Mail Bestätigung 7578

Was zuerst aussah wie eine Email mit einem Attachment, entpuppe sich als Newsletterartige Spam. So genau kann ich das nicht sagen, denn der Spaminhalt wird vom Emailprogramm nur als weiße Fläche angezeigt 😀 Thunderbird blockiert hier einfach mal brav alles. So wünsche ich mir das.

Nach einigem Suchen im Code vielen mir drei Dinge auf:

  1. „Die Russen waren es“ 😀

http://login.mediafort.ru/autologin/mail/?code=14844x0XXXXXXXXXXXXXXXXXXX&url=http://gmx.com@bazartimed.de?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Ich vermute es ist für die Rückantwort gedacht.

2. Die Schweine haben das MineCraft Netz infiltriert 🙂

<img src=“https://upload.fr-minecraft.net/images/frminecraft/ufja.png“>

Das ist eine Gutscheingrafik von Dr.Oetker.

3. Die Firma Expedia muß hier wohl als vermeindliches Geschenk herhalten.

Auffällig oft erscheinen „link.expediamail.com“, „mi.expedia.com“ und „travel-assets.com“ im HTML-Code.

Weg mit dem Dreck!

Wie immer lautet die Empfehlung: Nicht aufmachen, sondern direkt in die digitale Mülltonne damit!

IT Niedersachsen verwechselt Mailserver ;)

Aus der Reihe: „Was kann bei SMTP schon schief gehen“ heute die: IT Niedersachsen.

IT Niedersachsen verwechselt Mailserver 😉

Wenn man viel Infrastruktur hat, kann einem das schon mal passieren. Vor einigen Jahren hatte ich mal einen Beitrag über die Stadt Wolfenbüttel im IT Sec Vortrag, weil deren Mailserver komische Zertifikate für SMTP benutzt hatte, die keiner kennen konnte, weil selbst-signiert und für interne Testserver gedacht. Damals hatte deren IT das Problem, es überhaupt zu finden, weil die Microsoftlösung Ihnen einen vom Pferd erzählt hatte 🙂

Vielleicht ist das jetzt so etwas ähnliches:

Wenn man eine Email an eine Adresse schicken will, die von diesem Server bedient wird:

80.228.54.249 „inetmail23.niedersachsen.de“

Dann bekommt man im Exim das hier:

SSL verify error: certificate name mismatch: DN=“/C=DE/ST=Niedersachsen/L=Hannover/O=Land Niedersachsen/OU=IT.Niedersachsen, FG 24a/CN=inetmail14.niedersachsen.de

Weil das ausgelieferte Zertifikat nicht mit dem Hostnamen übereinstimmt. Vermutlich wurde einfach nur das falsche Zertifikat verteilt. Witzig ist nur, daß es auf beiden Servern passiert ist, denn ein „host inetmail23.niedersachsen.de“ zeigt zwei verschiedene IPs an. Da darf man von einem Deployserverproblem ausgehen, also hat es keiner mit Handarbeit verteilt 🙂

 

Alle mal Firefox updaten!

Remote-Code-Execution in Firefox < 85.0.1 … Alle mal auf Update drücken!

Alle mal Firefox updaten!

Das Cert schreibt dazu:

Zusammenfassung:
Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Mozilla Firefox und Mozilla Firefox 
ESR ausnutzen, um beliebigen Programmcode auszuführen.

Übersetzung: Jede Webseite kann Euch beim Besuch hacken!

Wer es sofort braucht:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/85.0.1/1.fc32/x86_64/firefox-85.0.1-1.fc32.x86_64.rpm

bzw. sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/85.0.1/1.fc33/x86_64/firefox-85.0.1-1.fc33.x86_64.rpm

Alle anderen müßten dann mal auf Ihre Distro warten.

Fedora: Chromium Patch wird ausgeliefert, aber nicht für alle

Hallo,

überraschenderweise hat mein Pinephone als erstes die gepatchte Chromium 4324-150 bekommen.

Fedora: Chromium Patch wird ausgeliefert, aber nicht für alle

Wenn Ihr für Fedora 32 und 33 in den Genuss des Updates kommen möchtet, müsst ich jetzt leider selbst Hand anlegen:

32:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/chromium/88.0.4324.150/1.fc32/x86_64/chromium-88.0.4324.150-1.fc32.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/chromium/88.0.4324.150/1.fc32/x86_64/chromium-common-88.0.4324.150-1.fc32.x86_64.rpm

33:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/chromium/88.0.4324.150/1.fc33/x86_64/chromium-88.0.4324.150-1.fc33.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/chromium/88.0.4324.150/1.fc33/x86_64/chromium-common-88.0.4324.150-1.fc33.x86_64.rpm

Die Pakete sind zwar schon fertig, aber noch nicht im Repo drin. Daher hat es mich gewundert, daß mein Pinephone das bereits so drauf bekommen hat. Da Rawhide das Testrepo des Testrepos ist, kann es sich nur um wenige Stunden handeln, bis Ihr das auch automatisch bekommt.

Da die Bugs in der Wildness bereits ausgenutzt werden und die totale Kontrolle des befallenen PCs bedeuten, ist Zeit ein Luxus, also updated lieber gleich.

 

Schwachstelle in Chrome und damit wohl in Chromium

Google hat verkündet, daß jeder mal sein Chrome auf den neusten Stand bringen muß, weil für die erst vor 4 Tagen gebaute 88.0.4324.96 schon Exploits im Umlauf sind.

Schwachstelle in Chrome und damit wohl in Chromium

Eine Schwachstelle in Chrome muß jetzt nicht gleichzeitig eine in Chromium sein, aber bis das geklärt ist, gehen wir mal davon aus, daß es das ist.

Jetzt haben wir nur ein Problem, zumindest für Fedora gibt es noch keinen Build zu dem man wechseln könnte. Die 88.0.4324.96-4 ist gestern erst gebaut worden. Hätte es da die 150 schon gegeben, wäre die vermutlich benutzt worden.

Für Eure Distros müßte jetzt mal in Eure Updatecenter schauen, ob die vielleicht schon eine neue 150er Version für Euch haben.

Die Schwachstelle

Über die Schwachstelle wissen wir, daß Sie in der Javascript-Engine von Chrome enthalten ist, da das keine angepaßte Komponente ist, wird das so auch für den Chromium gelten. Google gab dazu auch bekannt, das es bereits über eingesetzte Exploits informiert wurde. Für die unter Euch, die sich informieren wollen: CVE-2021-21148 ist eure Nummer.

D.b. wenn Ihr kein Update habt: Internetverbot für Chrome/ium bis das Update da ist.

 

RCE Exploits bei Cisco VPN Routern

Bei CISCO ist mal wieder Tag des offnen Ports: 6 schwere Sicherheitslücken.

RCE Exploits bei Cisco VPN Routern

Remote-Code-Execution auf Ciscoroutern erlauben die komplette Kaperung der Geräte durch Angreifer.

Die Schwachstellen haben die Nummern CVE-2021-1289 bis CVE-2021-1295 (CVSS score 9.8).

Folgende Geräte sind betrofffen: RV160, RV160W, RV260, RV260P, and RV260W VPN Router mit einer Firmware < 1.0.01.02.

Außerdem gibt es dann nochmal zwei Schwachstellen, bei denen Angreifer Dateien überschrieben konnten, was auch keinen Deut sicherer wäre als die CVE-2021-1295. Ob CISCO das noch irgendwann mal lernt?

Realtek RTL8195A Firmware updaten

Wer von Euch einen Realtek RTL8195A Chip z.B. in einem Arduino einsetzt, der solltet Ihr jetzt dringend ein Firmwareupdate für den Chip durchführen.

Realtek RTL8195A Firmware updaten

Wie die Hacker News berichten, gibt es im Wifi Handshakeprotokoll einen ausnutzbaren Fehler, der es ohne Anmeldung ans Wifi-Netzwerk erlaubt, das System auf dem der Chip verbaut ist, komplett zu übernehmen.

Critical Bugs Found in Popular Realtek Wi-Fi Module for Embedded Devices

Das ist zwar kein Chip den man in Notebooks oder Laptops findet, aber in BastelMicrorechnern schon. Seit April 2020 gibt es dafür schon eine neue Firmware, aber Einspielen müßt Ihr die wohl auf den meisten Minicomputern selbst. Für den Arduino gibt es tatsächlich ein Update, daß die Firmware mit einspielt.

Die hi-teck Erpressung

Wollt Ihr mal was zu Lachen haben?

Die hi-teck Erpressung

Man achte auf die Details wie den Domainnamen, die lustige Sprache wie „alle einige Stunden“ des Übersetzungsbots und die faktische Unmöglichkeit der Behauptungen, die soooooo übertrieben werden, daß der Spinner als gottgleich erscheint 🙂

Absender: Aileen <abraham .at. hi-teck.com>

Grüß Gott!

Ich habe beobachtet Ihr Gerät im Netz seit langer Zeit und habe es geknackt.

Es war einfach für mich, weil ich mich damit schon lange beschäftige.

Wann Sie besuchten die pornografische Webseite ich habe angesteckt Ihr Computer mit dem Virus, der sicherte mir vollständigen Zugang zu Ihr Gerät, inklusive die Kamera, das Mikrofon, die Anrufe, die Messenger, zu all dem was geschieht am Bildschirm, zum Telefonbuch, zu Passworten aller sozialer Netzwerken und weiteres.

Um das Handeln meines Virus zu verstecken, ich habe gebastelt ein sonder-Driver, updated alle einige Stunden und daher vollständig unnachweisbar.

Ich habe herunterladen das Video aus Ihrem Bildschirm und Ihrer Kamera und habe geschnitten ein Video auf dem in einem Teil des Bildschirms Sie masturbieren und der andere Teil zeigt ein Porno-Video die Sie gleichzeitig schauten.

Ich kann schicken jederzeit allerlei Daten aus Ihrem Gerät ins Internet oder an alle jene, die stehen an Ihrer Kontaktliste, an den Messengern oder in sozialen Netzwerken.

Außerdem, ich kann bereitstellen den Zugang zu Ihren Messengern, sozialen Netzwerken oder zum E-Mail jedem beliebigen Menschen.

Wenn Sie dies vermeiden wollen tun Sie folgendes-

Überweisen Sie auf meine Bitcoin-Geldbörse 1300 amerikanische Dollars.

Adresse meiner Bitcoin-Geldbörse : bc1q3dwsh4ryljth0yemny3wp6pe87dkheaxyg9q32

Sie haben 48 Stunden zur Überweisung. Andernfalls ich werde alles Obenstehende dürchfuhren.
Der Zeitgeber hat gestartet automatisch sofort nachdem Sie den Brief eröffnet hatten.
Die Meldung über Eröffnung dieses Briefs bekomme ich auch automatisch.

Wenn Sie wissen nicht wie man das Geld überweist und was ist Bitcoin, schreiben Sie die Anfrage in Google „Bitcoin kaufen“.

Sofort nach Erhalt der notwendigen Summe das System wird mich automatisch benachrichtigen und wird anbieten aus meinen Servern alle von Ihnen erhaltene Daten zu löschen.

Und ich werde das Löschen bestätigen.

Beschwerden Sie sich nirgendwo – meine Geldbörse kann nicht nachgefolgt werden und der E-Mail aus dem der Brief wurde geschickt wird erstellt automatisch und es ist sinnlos mich etwas zu schreiben.

Sollten Sie diesen Brief irgendjemandem teilen wollen, das System wird die Anfrage auf die Server automatisch schicken und diese werden Ihre Daten in sozialen Netzwerken veröffentlichen. Außerdem, der Wechsel von Passworten in sozialen Netzwerken, von E-Mail und am Gerät wird Sie nicht helfen, weil alle Daten sind bereits herunterladen am Cluster meiner Server.

Ich wünsche Sie viel Glück und tun Sie keinen Blödsinn.

 

Das kam gestern Abend bei einem Kunden auf einer fiktiven Adresse an. Die Adresse benutzt der Server des Kunden um einem Postfachnutzer mitzuteilen, daß er doch SSL einschalten soll, wenn er Mails abholt. D.b. der PC eines Kunden wurde tatsächlich gehackt und der Angreifer hat einfach an alle Adressen, die er im Posteingang gefunden hat, diese Mail versendet. Vor so einem Hansel muß man keine große Angst haben, wenn man aktuelle Software und möglichst kein Windows einsetzt.

Ich werde jetzt mal versuchen den Kunden zu identifizieren, alleine an dem Merkmal kein SSL benutzt zu haben 😀 Wir schicken diese Nervmails nicht umsonst rum 😉

Nachtrag:

Hier könnt Ihr mal sehen, daß es nicht nur „uns“ und „Euch“ so erging 🙂

https://www.bitcoinabuse.com/reports/bc1q3dwsh4ryljth0yemny3wp6pe87dkheaxyg9q32

Ich habe übrigens tatsächlich einen verdächtigen Kunden-PC gefunden. Die Betonung liegt auf „verdächtig“, das muß der Kunde natürlich erst einmal selbst prüfen. Morgen wissen wir mehr.

Vodafone: falsche SSL-Cipher behindern Mailserver

Aus der Rubrik SSL-Fail haben wir heute die Domain „kabelmail.de“. Jetzt fragt Ihr Euch natürlich, was Vodafone damit zu tun hat, oder?

Vodafone: falsche SSL-Cipher behindern Mailserver

Der Teil ist weniger spannend als man vermuten könnte:

# dig +short mx kabelmail.de
100 mx01.xworks.net.

Die Domain xworks.net gehört zu Vodafone. Das Problem selbst ist der Windowswelt weiter verbreitet, da es nicht der erste Fall eines Großunternehmens ist, daß seine Mailserver nicht unter Kontrolle hat 😉 Jetzt schauen wir uns aber erst einmal an, was überhaupt los ist.

Der nachfolgende Auszug ist stark auf das Wesentliche verkürzt, gebt den Befehl einfach selbst ein, wenn Ihr alles sehen möchtet:

# openssl s_client -connect mx01.xworks.net:25 -starttls smtp
CONNECTED(00000003)

Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits

SSL handshake has read 5195 bytes and written 513 bytes
Verification: OK

New, SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-SHA

Jetzt muß man wissen, das Cipher immer Kinder ihrer Zeit sind, meint, die kann man einer Protokollgeneration zuordnen. „DHE-RSA-AES256-SHA“ ist ein SSLv3/TLS1 Cipher, weswegen OpenSSL hier auch SSLv3 anzeigt, obwohl TLS1.2 gesprochen werden soll.

Hat man jetzt einen Server, der kein SSLv3, TLS1.0 TLS1.1 mehr erlaubt, weil das komplett gebrochen ist und de facto kein „Stand der Technik“ mehr ist, kann man sich leicht ausmalen, was mit einer SSLv3 Verbindung passiert, die eigentlich TLS 1.2 sein müßte 🙂 Genau, sie kommt nicht zu Stande:

2021-01-09 11:22:10 1kxoMm-0002bp-LI == XXXXXXXXXXXXXXXXXXXXx@kabelmail.de <XXXXXXXXXXXXX@kabelmail.de> R=dnslookup T=remote_smtp defer (-37) H=mx01.xworks.net [31.25.48.11]: TLS session: (SSL_connect): error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

Den TLS Handshake einer Verbindung kann man sich so vorstellen:

Client: Hallo Server, ich würde gern TLS mit Dir sprechen, hier sind meine möglichen Cipher…..
Server: Hallo Client, nett, ich könnte das hier anbieten: Cipherliste des Servers
Client: Klasse, dann nehmen wir den ersten aus Deiner Liste, den ich auch kann.. Wie wärs mit .. „ECDHE-RSA-AES256-GCM-SHA384:256“

„ECDHE-RSA-AES256-GCM-SHA384:256“ gehört zur TLS 1.2 Ära ist also was halbwegs aktuelles.

Die Cipherliste ist so definiert, daß der „beste“ aka. „highest“ Cipher vorn als erstes steht. Das machen Client und Server beide so, der erste gemeinsame Cipher der Reihenfolge von „bester“ -> „schlechtester“ Cipher  wird dann benutzt.

Die Ursache

Ursache des SSLv3 Problems bei Windows Mailservern ist jetzt genau die selten gepflegte Cipherliste, die bei der Installation anno 1995 auf die Platte gemeisselt und seitdem kaum aktualisiert wurde. Ich seh hier natürlich Microsoft in der Pflicht, aber hey, ein Mailserveradmin sollte das wissen und checken. Die Ursache ist also bekannt, die Lösung trivial: einfach diese Liste aktualisieren und gut.

Die Ursache ist also bekannt, wieso jetzt den Artikel? 🙂

Ja, wieso eigentlich, beim Großunternehmen ENBW hat es damals doch auch sofort geklappt, eine Email und ein erstaunter „Was zum Geier ist das?“ Rückruf später, konnte man dem ENBW Mailserver wieder Emails senden 🙂

Am 9.1. wurde der Vodafone Support :

TECHNIK: Falsche Cipher Reihenfolge beim Mailserver von kabelmail.de

Moin,

Wenn man DSGVO konform Emails an Kunden von Ihnen schicken möchte, funktioniert dies nicht,
da der SMTP-Server von kabelmail.de => mx01.xworks.net die falsche Reihenfolge der SSL-Cipher konfiguriert hat.

Das kann man selbst ganz einfach mit openssl feststellen:
… die Openssl Anweisung von oben…
Wie man leicht erkennen kann, wird ein SSLv3 Cipher ausgehandelt, weil Ihr Server den als „besten“ Cipher im Cipheroffer anbietet.

Keine Panik, das passiert vielen M$ Kunden und läßt sich ganz einfach lösen:

Drehen Sie die Reihenfolge der Cipher in der Mailserverconfig einfach um und packen Sie die TLS 1.3 und 1.2 Cipher nach vorn in der Liste.

Eine automatische Antwort vom Ticketsystem war auch umgehend da. Am 12.1. kam dann diese Email von Support von Vodafone:

Lieber Vodafone-Kunde,
wir haben Ihre Nachricht an unsere Experten für Ihr Anliegen weitergeleitet.
Die Kollegen antworten Ihnen in Kürze oder rufen Sie zurück. Haben Sie bitte noch ein klein wenig Geduld – vielen Dank.
Hatten Sie mehr als ein Anliegen, antworten wir Ihnen separat.
Freundliche Grüße
Ihr Vodafone-Team

 

Am 14.1. kam dann diese Email von einer anderen Abteilung des Supports:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:

– Ihre Kundennummer
– Was funktioniert nicht?
– Seit wann funktioniert es nicht?

Rufen Sie uns am besten an. Oder antworten Sie auf diese E-Mail.

Freundliche Grüße
Ihr Vodafone-Team

meine Antwort:

Am 14.01.21 um 16:31 schrieb Technischer Kundenservice:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:
– Ihre Kundennummer
Keine Kundenbeziehung.

– Was funktioniert nicht?

Siehe Ticket: Man kann Euch DSGVO Konform keine Emails senden, weil der SSLv3 Cipher benutzt wird, statt dem TLS1.2+ .

– Seit wann funktioniert es nicht?

Seit Jahren, mir gehts nur langsam so auf den Senkel, daß ich Sie informiert habe.

Die alte Leier, man hälts ne Zeitlang aus, merkt dann, daß der andere nie was ändern wird und tritt ihm dann in den Hintern 😉 Irgendwie hatte ich mich aber undeutlich ausgedrückt, denn es kam eine weitere Email:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:

– Ihre Kundennummer

Rufen Sie uns am besten an. Oder antworten Sie auf diese E-Mail.

Freundliche Grüße
Ihr Vodafone-Team

meine Antwort:

Sehr geehrte Damen und Herren,

wir haben keine Kundenbeziehung und nicht Sie helfen mir, sondern ich helfe gerade Ihnen.

Alles was Sie wissen müssen, steht bereits im Original Ticket drin, Sie müssen es nur an die zuständigen Admins weiterleiten.

Seitdem herrscht Schweigen im Walde und auch das Problem wurde noch nicht behoben. 14 Tage sind eigentlich genug Zeit um eine Liste von Ciphern zu aktualisieren, also kommt Ihr jetzt schon in den Genuss der Story 🙂 Die ich Euch natürlich nur deswegen ins Blog stelle, weil die Ursache klein, die Wirkung groß und die Lösung trivial ist 😀 und natürlich weil es Vodafone ist 😉

Unter Linux braucht man sich da im Normalfall eigentlich keine Gedanken machen, da OpenSSL so eine Cipherliste bereitstellt, die mit jedem Update automatisch aktualisiert wird. Man kann es natürlich auch selbst im Mailserver eintragen, wenn man da noch härter sein will, ist aber eigentlich nicht nötig. Man könnte ja auch mal auf ältere Mailserver stoßen, die nicht den aller neusten Cipher bereit haben.

Falls jemand von Vodafone zufällig diesen Artikel findet, Sie suchen das hier: „6618829#5df0179#“ 😉