An die IT der Stadt Braunschweig in Sachen MAILSERVER – 2024 Edition

Ihr erinnert Euch noch an diesen Artikel aus dem Jahr 2021?

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Da gibt es ein unrühmliches Update 😀

An die IT der Stadt Braunschweig in Sachen MAILSERVER – 2024 Edition

Im Jahr 2021 hatte ich einen offenen Brief an die IT-Verantwortlichen der Stadt Braunschweig geschickt, den könnte Ihr digital oben lesen. Weil wir gerade Mailserverprobleme einer anderen Stadtverwaltung bearbeiten, dachte ich mir, schau doch mal nach, was daraus geworden ist. Hier die 2024 – Edition 😀

Liebe IT-Verantwortliche der Stadt Braunschweig,

wie wir Euch im Jahre 2018, und dann nochmal im Jahr 2021, mitgeteilt haben, sind Eure SSL-Zertifikate im Mailserver nichts wert. Glauben Sie schon wieder nicht? Bitte schön:

# openssl s_client –connect mailin02.braunschweig.de:25 -starttls smtp -verify_hostname mailin02.braunschweig.de
CONNECTED(00000003)
depth=0 CN = braunschweig.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = braunschweig.de
verify error:num=62:hostname mismatch
verify return:1
depth=0 CN = braunschweig.de
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = braunschweig.de
verify return:1

Certificate chain
0 s:CN = braunschweig.de
i:C = US, O = Let’s Encrypt, CN = R10
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Aug 20 10:47:48 2024 GMT; NotAfter: Nov 18 10:47:47 2024 GMT

Server certificate
—–BEGIN CERTIFICATE—–
MIIE7jCCA9agAwIBAgISBJuzUCXTWYKiCMJPi/QRdpaNMA0GCSqGSIb3DQEBCwUA

Jetzt heißen Eure Mailserver für die Domain braunschweig.de aber nicht braunschweig.de sondern:

;; QUESTION SECTION:
;braunschweig.de. IN MX

;; ANSWER SECTION:
braunschweig.de. 300 IN MX 10 mailin02.braunschweig.de.
braunschweig.de. 300 IN MX 20 mailin01.braunschweig.de.

Also kann auch hier wieder nicht festgestellt werden, daß wir wirklich mit dem richtigen Mailserver reden.

Damit gilt leider, was auch schon 2018 galt: schlecht gesetuped.

Es gibt aber auch Positives zu melden: Die Stadt nutzt Let’s Encrypt für die Zertifikate und kann TLS 1.3, was, wie wir leider feststellen müssen, auch in 2024 keine Selbstverständlichkeit ist.

CPanel Scammails: Ihr Konto hat komische Aktivitäten

Man merkt, daß Apple mittlerweise 20% am Desktopmarkt hat, es kommen immer mehr Scammails mit Applebezug rein, so auch diese:

geschwärzte Scammail von CPanel

Der „Link“ geht zu über ein OneDrive in Taiwan zu einer gehackten Webseite:

h.t.t.p.s.://sdfn3ysu8egzq#########c2o5ze8yq.on.drv.tw/www.ezrahubsteel.com/#system@XXXXXXXXXXXXXXXXX.de
(leicht modifiziert, damit bots da nicht hingehen)

Natürlich ist das alles Schwachsinn, weil es das Konto gar nicht gibt und cPanel-Webmail  auch nicht. Also ab damit in die Digitale Mülltonne 🙂

aktuelle SSH Lücke verpflastern

Updaten ist immer gut wenn Sicherheitslücken geschlossen werden sollen, aber in der Realität kommt es vor, daß Dienste nicht immer (gleich) das Update bekommen, daß Sie benötigen.

aktuelle SSH Lücke verpflastern

Die aktuelle SSH Lücke wirft auf allen möglichen Geräten mit verwundbarer Version ein Problem auf, wenn dieses keine Updates erhält, denn ohne SSH kommt man nicht mehr auf dies Gerät drauf und davon hat keiner was. Solange das Gerät die SSH Schnittstelle ins LAN öffnet, mag ein Nicht-Patchen noch eine kalkulierbare Lösung sein.

Wenn das Gerät aber ins Netz zeigen muß, dann wäre es das Aus, wenn es kein Update gibt, oder gibts da doch was, was man machen könnte?

Das Qualsys Pflaster

Wenn Ihr Nachts um halb eins im Bett von der Lücke gehört hättet, hättet Ihr Euch auch den Qualsys Bericht dazu durchgelesen, der entscheidet dann darüber, ob man sich final hinlegen kann, oder ob eine Nachtschicht eingelegt werden muß.

In dem Bericht stand u.a. drin, daß man ca. 1 Woche hat, bis der Angreifer mit dem Angriff mal Erfolg haben wird. Darauf kann man sich leider nicht ausruhen, weil das nur ein Statistischer Wert ist, der zufällig auch schon beim ersten mal funktionieren kann.

Am Ende stand aber noch etwas anderes, nämlich daß man einfach „LoginGraceTime 0“ setzen kann, dann läuft der Angriff komplett ins Leere, dafür kauft man sich eine Pseudo-DOS Schwachstelle ein, spricht, Angreifer könnten beim rumprobieren die Leitung dicht machen, so daß es schwierig wird ins System einzuloggen. Natürlich ist das immer noch besser, als wenn jeder leidlich lästige Kleinkriminelle auf dem System Rootzugriff haben kann. PS: SSHD Neustart nicht vergessen 😉

Leider habe ich in keinem News- oder Blogbeitrag gelesen, daß es diese Möglichkeit gab.

Fedora hat’s mal wieder verpeilt

Ein bisschen enttäuscht war ich vom zeitlichen Verlauf der Fedora Updates von OpenSSH, denn die platzten mitten in Linux am Dienstag rein,was extrem verstörend war, weil die OpenSSH Patche selbst bereits seit 4 Wochen an die Distributionen übermittelt waren. Die Fedora Maintainer hatten mal wieder völlig verpeilt, ein CritPath Update einer schweren Sicherheitslücke zu verteilen. Nicht zum ersten mal, möchte ich betonen. Da muß man echt hinterher sein manchmal.

Link zur Lücke: CVE-2024-6387

Link zur Quelle: Qualsys Bericht