Ihre Paketzustellungsnachricht Nr#34632900-371

Nach langer Zeit haben wir heute mal wieder eine Spam aus der beliebten Serie: „Einmal mit Profiverbrechner arbeiten“.

„Ihre Paketzustellungsnachricht Nr#34632900-371“

Man kennt das ja: man kauft im Onlineshop eine Sache und bekommt vom Lieferdienst eine Trackingemail, oder, in letzter Zeit eher weniger, die Nachricht mal die Tür zu öffnen, weil das Paket gleich da ist. In der Email ist ein Link zur Trackingseite drin, zusammen mit der Paketnummer und noch son paar Daten.

Das machen sich Betrüger natürlich gern zu nutze um Emailadressen zu verifizieren, Daten abzufragen, die die nichts angehen, und Malware runterzuladen. So eine Email haben wir hier:

Darstellung der Spam in Thunderbird. Es sind 2 Texte zu "Verifikation der Email" vorhanden. Die Qualität der DPD Paketverfolgung ist aber so schlecht, daß nichts zu erkennen ist.Wie man da unschwer erkennen kann, sind HTML Emails echt blöd ohne Bilder 😉 Allerdings belingt die Täuschung als echte Mail schon nicht, weil die Deko in Form von externen Bildern nicht geladen wird von Thunderbird. Da fällt es dann leicht den Fake sofort zu erkennen.

Es fängt bereits mit dem Absender „contactdpdPaket….@[domain]“ an. Es sollte wohl ein DPD Simulation werden 🙂  Wenn man natürlich zu blöd ist sein Spamtemplate richtig auszufüllen: „contactdpdPaket….@[domain]“ wundert es nicht, daß so gar keine Zahl dieser Email übereinstimmt. Das ist einfach eine richtig schlechte Fälschung.

Schauen wir uns mal die Header an:

Return-path: <reply@bergbauernwagal.de>
Envelope-to: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Delivery-date: Thu, 07 Dec 2023 06:59:59 +0100
Received: from h3013040.stratoserver.net ([85.214.39.248] helo=artuner.online)
	by XXXXXXXXXXXXXXXXXXXXXXX with esmtp (Exim 4.96.2)
	(envelope-from <reply@bergbauernwagal.de>)
	id 1rB7QT-0041w7-0i
	for XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;
	Thu, 07 Dec 2023 06:59:59 +0100
Date: Thu, 07 Dec 2023 05:58:11 +0000
Message-Id: <538561069336279.0.CNE0599619157@artuner.online>
To: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
From: =?UTF-8?B?QmVzdGVsbHVuZy1WZXJzYW5k?= <contactdpdPaket202312067id1360227332@[domain]>
Content-Type: text/html; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject:  =?UTF-8?B?SWhyZSBQYWtldHp1c3RlbGx1bmdzbmFjaHJpY2h0IE5yIzM0NjMyOTAwLTM3MT8=?=

Jetzt macht die Analyse irgendwie keinen Spaß, weil unser Spamassassin das schon gemacht hat. Daher erteile ich dem jetzt das Wort:

FROM_LOCAL_HEX From: localpart has long hexadecimal sequence

Damit ist „contactdpdPaket202312067id1360227332@“ gemeint.

SPF_NONE SPF: sender does not publish an SPF Record

Ok, für „@[domain]“ kann man keinen SPF haben, da müßte also gleich eine andere Regel sein: illegal domainname.

PDS_OTHER_BAD_TLD Untrustworthy TLDs  [URI: artuner.online (online)]

Ganz offensichtlich ist .online als TLD bei Spammern sehr beliebt 😉

HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different

ja, „@[domain]“ und „@bergbauernwagal.de“ sind zwei unterschiedliche Domains 🙂

URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: artuner.online]

Also hat schon jemand die Domain der Links, die sich in der Email befinden, ihr aber oben nicht sehen könnt, in eine Blockliste eingetragen.

FROM_EXCESS_BASE64 From: base64 encoded unnecessarily

Damit ist u.a. das hier gemeint:

Subject: =?UTF-8?B?SWhyZSBQYWtldHp1c3RlbGx1bmdzbmFjaHJpY2h0IE5yIzM0NjMyOTAwLTM3MT8=?=
Subject: Ihre Paketzustellungsnachricht Nr#34632900-371

Aufgrund der Zeichen war das nicht nötig, weil keine Umlaute drin waren.

T_REMOTE_IMAGE Message contains an external image

In der Email stecken einige HTML Image Anweisungen wie diese:

<img border="0" src="http://artuner.online/img/<HASHWERT>" alt="logo" class="logo" />

Diese Bilder, wenn das überhaupt Bilder waren, lädt Thunderbird nicht selbst. Das muß immer der Benutzer erlauben. Das ist eine sehr wichtige Grundeinstellung von Thunderbird. Es könnte nämlich auch nur darum gehen, ein Bild zu laden, daß dann in einer Systembibliothek einen Exploit auslöst und so Euren PC hackt.

Diese Email gehört natürlich in unser Trottelarchiv und bei Euch in den Papierkorb.

1 Jahr Blog hinter dem Webcache

Wir haben hier natürlich für den November 2023 nur einen halben Monat, weil die Stats vom 13. des Monats sind. Eine kleine Rückschau zur Technik gibt es auch noch.

Sie verpassen nichts, sind nur Zahlen pro Monat mit einigen Balkendiagrammen.

1 Jahr Blog Zugriffszahlen

Einfach nur Zahlen veröffentlichen kann jeder, deswegen ein kleiner Bericht aus dem Jahr des Caches.

Aus dem Leben eines Webcaches

Die meiste Zeit lief das Cache problemlos, sonst hätte ich es auch nicht benutzt. Die Vorteile liegen klar auf der Hand, weil die Zugriffszeiten massiv verbessert wurden. Allerdings stieg auch der Komplexitätsgrad der Serverkonfiguration an:

– DNS Proxies
– Backend-Webserver
– Fake DNS Server
– Cacheserver

Ohne groß ins Detail zu gehen, weil mit irgendwas muß man ja sein täglich Brot verdienen ;), kommen wir zu einer Besonderheit der Konstruktion: Der Backendserver hat eine andere IP als der Cacheserver.

Weil das so ist, muß man dem Cache irgendwie mitteilen, daß eine aufgerufene Domain eine ganz andere IP hat. Dazu benutzt man einen FakeDNS Server. Der war in Perl geschrieben und besteht im Prinzip nur aus einer einzigen Schleife: „Wenn wer fragt, sagt diese IP auf“. Das dumme daran ist, es ist Perl. Perl fällt aus bzw. für den Fragenden kommt einfach ab und zu mal keine Antwort.

„Keine Antwort“ meint aber im Cache: „Hey, der DNS Server ist tod.“   Was macht ein Cache wenn der Server „tod“ ist? Genau, es entfernt den DNS aus der Liste der aktiven DNS Server. Ziemlich blöd, wenn das nur ein Server ist 🙁 Also haben wir zwei konfiguriert und das Cache sollte Roundrobin machen. Machts aber nicht, auch wenn es in der Anleitung steht 😉

d.h. ein dritter FakeDNS mußte her und da hörte der Spaß auf. Statt noch ein Perlscript zu starten, wurde named als Forwarder konfiguriert. Das antwortet jetzt immer stabil  auf Anfragen, weil es nur einmal am Tag nachfragt und geht so mit den arbeitsscheuen Perlscripten wohlwollend um.

Warum Perlscripte?

Weil um eine einzige IP auszugeben, ein vollwertiger PowerDNS nebst Datenbank vielleicht ein bisschen zu viel wäre. Dachte ich. Heute tendiere ich dazu mal entsprechend umzubauen, weil das den Komplexitätsgrad verringert und die Stabilität erhöht. Der Preis wird eine Datenbank basierte Pflege beinhalten, statt einfach ‚echo „domain.de 123.45.67.89“ >> fakedomainliste.txt‚ zu benutzen. Ein kleiner Preis, im Vergleich zum Stress durch die Ausfälle.

Wenn Ihr also plant WordPress mit einem Cache zu betreiben, dann macht es gleich richtig.

Praktischerweise konnte man aus diesem privaten Beispiel sehr viel für unsere Firma übernehmen und jetzt haben wir ein miniCloudflare, nur ohne Abhängigkeit von einer US-Firma \o/  Das reduziert die Last und macht Kunden glücklich.

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Vor einigen Tagen hatte ich ja was zum Kernel Bug geschrieben, nämlich, daß ich mir mehr Sorgen mache, daß eins der Desktopprogramme geknackt wird. Jetzt ist es bei Ghostscript soweit.

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Ghostscript < 10.1.02  hat eine Schwachstelle, die das Ausführen von Code erlaubt. Das an sich ist schon schlimm, wenn man dann erfährt, daß das bei den Maintainer untergegangen ist 🙁

Schlimmer ist aber, daß die Lücke in andere Anwendungen wie InkScape, LibreOffice und Gimp eskaliert, dort also auch funktioniert. Möglich macht dies das Äquivalent der größten Container-Sorge überhaupt: Diese Anwendungen halten sich eine selbst gepatchte Version von Ghostscript in der Codebasis und naja, in der ist der Bug auch drin.

Das ist vergleichbar mit einer Sammlung von Docker Containern,Snaps & Flatpaks, welche alle die gleiche ausnutzbare libPNG drin haben und jetzt alle geupdated werden müssen, wo ja eigentlich nur eine Komponente das Update wirklich bräuchte: Ghostscript. Was zeigt das: Dumme Entscheidungen brauchen kein Containermodell 😉

Anstatt einer Komponente, müssen jetzt ein Haufen unübersehbarer Anwendungen aktualisiert werden, wozu man erstmal rausfinden muß, wo das überall drin ist. Das muß man erst mal schaffen. Log4J lässt so derbe grüßen, daß heute wohl Murmeltiertag ist.

Da zu allem Überfluss ein POC-Exploit bekannt ist, werden echte Exploits nicht lange auf sich warten lassen.

Die Situation auf Debian ist besser als die von Fedora, weil Debian immerhin das erste GS Update ausgeschickt hat, bei Fedora aber nichts am Horizont ist. Dagegen habe ich mal was gemailt…

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36664

https://www.kroll.com/en/insights/publications/cyber/ghostscript-cve-2023-36664-remote-code-execution-vulnerability