[English]Ich ziehe mal ein Thema zu einem Sammelbeitrag zusammen, welches schon ein paar Tage bei mir auf der Agenda steht. Vor einigen Tagen wurde bekannt, dass es in OpenSSH die Schwachstelle CVE-2023-38408 gibt. Während die IT nun auf Patches wartet, (in Linux gibt es wohl Update) stellt sich ein zweites Thema: nämlich die Aktualisierung von OpenSSL und Windows und bei der Microsoft-Lösung PowerBI.
Anzeige
Zuerst einige Begriffserklärungen. OpenSSL ist eine freie Software zur Absicherung von Verbindungen für die Transport Layer Security und umfasst Implementierungen der Netzwerkprotokolle und verschiedener Verschlüsselungen. Zudem gibt es das Programm openssl für die Kommandozeile zum Beantragen, Erzeugen und Verwalten von Zertifikaten. Die in C geschriebene Basisbibliothek stellt allgemeine kryptographische Funktionen zum Ver- und Entschlüsseln sowie diverse weitere Werkzeuge bereit. In OpenSSL werden aber immer wieder Schwachstellen öffentlich – einige Artikel werden hier im Blog bei einer Suche nach dem Begriff ausgeworfen.
OpenSSH ist dagegen ein Programmpaket zur Dateiübertragung. Dazu nutzt es Secure Shell inklusive SSH File Transfer Protocol und beinhaltet dafür Clients, Dienstprogramme und einen Server.
Erst im Februar 2023 wurden in OpenSSH 9.2 wurde zwei Sicherheitsprobleme behoben (siehe mein Blog-Beitrag Nachlese zu Sicherheitslücken und Patches (6. Feb. 2023)).
OpenSSH Schwachstelle CVE-2023-38408
Laut NIST-Beitrag vom 22. Juli 2023 gibt es in der PKCS#11-Funktion im ssh-agent in OpenSSH vor 9.3p2 die Schwachstelle CVE-2023-38408. Ein nicht ausreichend vertrauenswürdigen Suchpfad kann zu einer Remote Code-Ausführung führen. Dieses Problem besteht aufgrund einer unvollständigen Korrektur für CVE-2016-10009. Yair Divinsky von vulcan.io hat zum 20. Juli 2023 im Beitrag How to fix CVE-2023-38408 in OpenSSH auf das Thema hingewiesen. Wäre womöglich an mir vorbei gegangen, wenn nicht dieser Kommentar hier im Blog hinterlassen worden wäre.
Anzeige
Jetzt müssen unsere Linux-Freunde mal wieder stark sein, nachdem es letzte Woche eines der Vorzeigeprojekte "Ghostscript" getroffen hat, ist jetzt das sehr sicherheitsrelevante OpenSSH, an dem die Besten der Besten programmieren, und JEDER in den Quellcode reinschauen kann, und das z.B. auch bei SFTP für öffentlich zugängliche Server eine außerordentlich wichtige Rolle spielt, vom BSI mit einem Score von 8.1 für die grandiose Leistung CVE-2023-38408 auf Sicherheitskala bedacht worden. Gratuliere! Patches gibts derzeit wahrscheinlich nur für OpenSSH 9 (9.3p2), aber da die Lücke in einer offensichtlich fehlerhaften Sicherheitskorrektur von OpenSSH 7 CVE-2016-10009 steckt, werden wohl auch zu 7 und 8 Backports nötig sein.
Und wie man leicht anhand der CVE-Nummern ausrechnen kann, war die Lücke auch nur unkritische 7 Jahre offen.
Gibt noch Folgekommentare mit dem Hinweis, dass die Schwachstelle nur relevant ist, wenn der sh-pkcs11-Helper (z.B. bei Smartcards und Tokens) verwendet wird. Ergänzung: Gerade gesehen, dass The Hacker News die obige Schwachstelle und die Aufforderung zum Patchen von Linux-Systemen aktuell in diesem Artikel angesprochen hat.
OpenSLL in der Microsoft Welt
In diesem Kontext fällt mir noch das Thema OpenSSL unter Windows und in Microsoft-Produkten ein. Aber wie steht es um die Aktualisierung in der Windows-Welt? Alles, was Open Source-Software, gepflegt durch Microsoft, betrifft, verursacht bei mir irgendwie Unwohlsein. Ich ziehe daher mal die zwei Fundsplitter hier zusammen, die zu OpenSSL im Hinterkopf schlummern.
OpenSSL-Schwachstellen in Microsoft PowerBI Desktop wird nicht gefixt
Zum 21. Juli 2023 hat mich ein Blog Leser-Klaus per E-Mail kontaktiert, um auf ein spezielles Thema im Kontext OpenSLL hinzuweisen. Das geht um die Software Microsoft PowerBI Desktop, eine Software, mit der sich Unternehmensdaten in visuellen Berichten darstellen lassen. Tools sollten Nutzern auch ohne Programmierkenntnisse ermöglichen, individuelle Auswertungen zu erstellen. Der Leser schrieb dazu:
Hallo,
ich habe mal wieder etwas Interessantes.
Das Produkt nennt sich „Microsoft PowerBI Desktop" und wird über den Microsoft Store verteilt/heruntergeladen.
Für „Open SSL" gibt es eine Reihe CVE's. Unter „Microsoft 365 Defender" wird Open SSL wegen der CVE's als Sicherheitsempfehlung gemeldet.
Der Leser hatte nachfolgenden Screenshot mit den Sicherheitsempfehlungen des Defender mitgeschickt (auf den Screenshot klicken, um das Bild zu vergrößern).
Es werden also eine ganze Reihe bekannter Schwachstellen in OpenSSL ausgewiesen, die dort nicht geschlossen wurden. Der Leser schrieb mir dazu:
Als ich mir das genau angesehen habe, durfte ich feststellen, dass die Geräte gar kein Openssl installiert haben, sondern sich die Meldung auf "Microsoft PowerBI Desktop" beziehen, das offensichtlich Bibliotheken von Openssl verwendet.
Hier wäre Microsoft in der Pflicht was zu tun. Macht Microsoft aber nicht, wenn man mal auf das Datum der CVE's achtet.
Vielleicht einen Beitrag wert?
Das Thema habe ich nun hiermit im Blog öffentlich gemacht. Für mich war das aber nichts wirklich neues, auch wenn mir der obige Sachverhalt konkret unbekannt war. Aber ich hatte im Beitrag IT-Sicherheit: Alles kaputt? mal erwähnt, dass man PowerBI nicht mal mit der Kneifzange anfassen solle.
OpenSLL und Updates durch Microsoft
Zudem liegt mir das Thema OpenSSL und die Aktualisierung durch Microsoft noch an einer anderen Stelle "im Magen". Es gibt den Beitrag Windows 10 und die OneDrive-Sicherheitslücken – Teil 3 aus dem Jahr 2018, wo ich Erkenntnisse von Stefan Kanthak in Bezug auf "langsames patchen von OpenSSL-Schwachstellen durch Microsoft" in ihrer Software thematisiert hatte.
Von der cURL-Bibliothek ist bekannt, dass Microsoft sich da unendlich Zeit mit dem Patchen von Schwachstellen lässt – siehe meine Blog-Beiträge Windows: Microsoft liefert cURL-Bibliothek weiterhin mit Schwachstellen aus (Feb. 2023) und Windows und die cURL-Falle; gelöschte Curl-Instanz macht Windows-Update kaputt).
Im Kontext dieser Beiträge hatte Stefan Kanthak mich im März 2023 angeschrieben und erneut darauf hingewiesen, dass Microsoft mit dem Schließen von OpenSSL-Schwachstellen auf dem Kriegsfuß steht. Nebenbei merkte er an, dass "auch ICU (IBMs "International Components for Unicode") IMMER total veraltet ist", was hat leider außer ihm noch niemand bemeckert habe. Im Kontext des obigen Themas geht es aber um OpenSSL und Stefan Kanthak wies auf diesen Kommentar hier im Blog hin:
Hallo zusammen,
anscheinend patcht Microsoft auch bei seinem OpenSSH-Feature in der Windows Servervariante nicht sauber über Windows Update.
Die OpenSSH-Version und die LibreSSL-Bibliothek haben auch schon einige Tage hinter sich.
Windows Server 2022 (Microsoft Windows [Version 10.0.20348.1547])
PS C:\> ssh -v localhost
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2Windows Server 2019 (Microsoft Windows [Version 10.0.17763.4010])
PS C:\ > ssh -v localhost
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
Blog-Leser M.D. bestätigt in diesem Kommentar vom 21. Juli 2023, dass bei ihm ebenfalls OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2 angezeigt wird. Ich habe mal auf die Schnelle in der Windows Eingabeaufforderung auf einem gepatchten Windows 10 2019 IoT LTSC mit den oben angegebenen ssh-Befehlen geprüft, welches OpenSSH-Version installiert ist. Es hat sich an den Versionsnummern nichts geändert, es wird die Version OpenSSH_for_Windows_7.7p1 angezeigt. Bereits im Juli 2020 fragt jemand auf Github, warum Windows 10 20H1 immer noch mit OpenSSH 7.7p1 ausgeliefert werde. Vielleicht mal das Thema im Auge behalten – oder sehe ich das mit dem Aktualisieren von OpenSSH etwas zu kritisch?
Anzeige
OpenSSH ist nicht gleichzusetzen mit OpenSSL! Das eine hat mit dem anderen was diese Lücke angeht nur wenig bis garnichts zu tun. OpenSSL darf aber gerne auch mal in Windows aktualisiert werden, da hat SK aber schon recht.
Für OpenSSH 7 und 8 hat übrigens bisher immer noch keine Linux-Distribution ein Update veröffentlicht. Und die meisten Distributionen, auch Debian und Ubuntu, verwenden noch die 8er Version, also Scheunentor immer noch offen. Für SLES ist aber was angekündigt, die anderen sind aber wohl noch am untersuchen oder coden.
Einschätzung anhand jüngster Details:
1. https://www.openssh.com/releasenotes.html
"Exploitation can also be prevented by starting ssh-agent(1) with an
empty PKCS#11/FIDO allowlist (ssh-agent -P ") or by configuring
an allowlist that contains only specific provider libraries."
Es gibt also etwas, was man ohne Updates schonmal dagegen tun kann. Das ist aber keine Mitigation, die jeder User hin bekommt (also auf Linux-Seite "Mausschubser" wie mich), fällt also grob unter die Kategorie "Frickeln".
2. https://packetstormsecurity.com/files/173661/OpenSSH-Forwarded-SSH-Agent-Remote-Code-Execution.html
"Originally, the path of a shared library to be loaded in
ssh-pkcs11-helper was not filtered at all by ssh-agent, but in 2016 an
allow-list was added ("/usr/lib*/*,/usr/local/lib*/*" by default) in
response to CVE-2016-10009, which was published by Jann Horn (at
:
– if an attacker had access to the server where Alice's ssh-agent is
forwarded to, and had an unprivileged access to Alice's workstation,
then this attacker could store a malicious shared library in /tmp on
Alice's workstation and execute it with Alice's privileges (via her
forwarded ssh-agent) — a mild form of Local Privilege Escalation;
– if the attacker had only access to the server where Alice's ssh-agent
is forwarded to, but could somehow store a malicious shared library
somewhere on Alice's workstation (without access to her workstation),
then this attacker could remotely execute this shared library (via
Alice's forwarded ssh-agent) — a mild form of Remote Code Execution.
"
Für mich sieht das so aus: Der Angreifer lauert auf einem manipulierten SSH-Server, das kann einer mit Remoteshell-Zugang oder evtl. auch ein SFTP-Server sein, bei letzterem bin ich mir aber nicht sicher. Alice verbindet sich per OpenSSH (oder SFTP) mit dem Server. Der Angreifer kann nun auf Alices Workstation im Temp-Verzeichnis Code ablegen und mit den Rechten von Alice ausführen. Er kann also alles machen, was Alice auch kann, auch einfache Benutzer haben schon Schreibrechte im User-Profil, in Temp und ggf. in gemounteten Netzlaufwerken oder lokal gemeinsam benutzten Datenverzeichnissen. Das kann man dann alles schonmal klauen, verschlüsseln und löschen, was schonmal schlimm genug sein kann. Man denke auch an User-Startup-Scripte, in die er weitere Dienste für sich starten kann, eine Reverseshell, was weiß ich. Außerdem kann er schonmal z.B. per (vorinstalliertem) nmap das lokale Netzwerk ausspionieren und so weitere Angriffspunkte finden "Living Off the Land Attacks (LOTL)". Er kann natürlich auch einen Bloodhound ablegen und im Userkontext starten, oder was so Seiten wie kitploit sonst so an interessanten Werkzeugen anpreisen. Kann der Angreifer über irgendeine noch nicht bekannte/gepatchte andere Lücke sich Root-Rechte verschaffen, so kann er darüber hinaus auch weiteren Schaden anrichten.
Da der Quellcode von OpenSSL offen ist, hätte jeder Mitleser hier in den letzten 7 Jahren den Fehler bereits finden können und einen Patch dafür einreichen können. Ich denke mal, diesem Nadelstich kann kein Linux-Fanboy hier wiederprechen, oder?
Stimmt – ich habe das noch etwas mehr herausgearbeitet – aber das Thema OpenSSL ist unter Windows /PowerBI imho unschön.
Zumal es da zwischen Linux und Windows — wahrscheinlich — noch einen gehörigen Unterschied gibt: Die OpenSSH-Versionen unter Linux mögen häufig veraltet sein, jedenfalls laut Versionsnummern, aber die Linux-Distributoren pflegen oft neue Patches in alte Versionen ein! Zumindest für SUSE Leap (15.4) wird als Standard-Version die 8.4p1 ausgegeben, die hat aber den Patch für den Agent-Bug bekommen. Die aktuellen Binaries sind vom 21. Juli dieses Jahres. Die anderen Distributionen machen das in der Regel genau so. Aus Kompatibilitätsgründen scheint es sinnvoller zu sein, die alten ABIs/APIs zu behalten und wenigstens aktuelle Sicherheits-Bugfixes zurück zu portieren.
Microsoft scheint das, wenn überhaupt, eher seltener zu machen. Die Binaries der OpenSSH dort sind, wie beim anderen Beitrag erwähnt, deutlich älter, allerdings immer noch nicht so alt wie der originale Quellcode der zu Grunde liegenden Version. Vielleicht haben sie den einen oder anderen Fix zurück portiert. Das lässt sich aber ohne den zugehörigen Quellcode oder Debug-Sessions schwer beurteilen.
Man kann natürlich auch unter SUSE Leap manuell auf die neueste Version upgraden, das dürfte aber wegen Abhängigkeiten eine größere Upgrade-Runde bedeuten. Und für Bleeding Edge gibt es ohnehin SUSE Tumbleweed.
Also bei meinem Debian stable ist die Version 9.2p1-2 in den Paketquellen gelistet?! Also nicht die Version 8, wie oben erwähnt.
9.2p1-2 ist halt auch noch nicht abgesichert, musst also auch noch auf 9.3p2 warten.
Mein XUbuntu 22.04 hat gerade 8.9 bekommen:
Holen:1 http://de.archive.ubuntu.com/ubuntu jammy-updates/main amd64 openssh-client amd64 1:8.9p1-3ubuntu0.3 [910 kB]
Wenn die "Besten der Besten" an sowas gearbeitet haben, braucht es vielleicht *noch* Bessere, die Fehler finden oder missbrauchen können? Es ist daher doch eher so, dass sich 7 Jahre kein Besserer gefunden zu haben scheint – was die CVE auch nicht besser, aber nun doch endlich öffentlich macht.
Ich gehöre hier nicht zu den Besten, könnte da sicherlich nichts anderes finden, als Kommafehler in den Kommentaren.
Also das SSH-Szenario greift doch nur, wenn man ssh-agent zum Forwarden nutzt, oder? …noch dazu auf ein attacker-controlled-system – dann hat man sowieso ein Problem.
Finde daher CVE-2023-38408 jetzt nicht ganz so problematisch.
das sehe ich auch so. das problem ist der ssh-agent und der ist ja eigentlich client seitig und nicht serverseitig aktiv.
Replace OpenSLL with OpenSSL. :)
Wir wurden in den letzten Tagen über den SSL Port angegriffen! Lies sich auf folgende Länder zurückverfolgen USA, China und Indien (heisst nicht das die Angreifer daher kamen aber die IPs wurden benutzt).
Die Angriffe gingen ins leere da unsere Firewall das schon geblockt hat und wir eh kein SSL VPN benutzen (Wireguard for the win).
Zeigt aber sobald eine Schwachstelle bekannt wird, wird diese auch massiv angegriffen.
Hier nochmal ein Aufruf an alle Ihre System abzuhärten und sich gebenfalls proffesionelle Hilfe dabei holen.
Der Kommentar ervibt für mich kaum Sinn. Tagtäglich prasseln auf Webserver die zahlreichen Angriffsversuche ein. Port 443 usw. oder OpenSSL steht damit aber nicht direkt im Zusammenhang. Ist doch besser als Port 80 für Datenverkehr zwischen Systemen.
OpenSSH (Secure Shell) hat icht viel mit Transporz Layer Security (TLS) oder Secure Socket Layer (SSL) zu tun. SSH ist ein anderes Protokoll und wird in der Regel über Port 22 genutzt.
warum wird hier in einem blogpost von openSSL und openSSH projekt gesprochen? das sind zwei grundverschiedene projekte.
Es ist als Sammelbeitrag angegeben – das mache ich gerne, wenn vorab unklar ist, wie umfangreich ein Thema wird. Weiterhin sollte inzwischen hinreichend klar sein, dass es wirklich zwei verschiedene Projekte sind – die Gemeinsamkeit: wie schnell wird Open Source bei Schwachstellen gepatcht, wenn sie in Linux oder unter Windows bzw. in MS Software vorkommen.
Ubuntu hat heute Nacht ein paar Patches heraus gebracht, aber noch nicht für alle Versionen, die noch unterstützt werden. Die anderen Distributionen werden sicher bald nachziehen.
Die bei Heise.de erwähnte Einstufung von 8.1 (von 10) des BSI für diese Lücke war wohl auch etwas zu heiß gekocht. Ubuntu gibt dem gerade mal 5.5.
SuSe hat am 24.Juli openssh 7 und 8 gepatcht (TID war vom 20.Juli)
https://www.suse.com/security/cve/CVE-2023-38408.html
Geht doch flott.
Aber es ist ein komplexes Angriffsszenario bei dem der Angreifer schon eingedrungen sein muß. Also nicht kritisch, wenn nicht ohnehin schon was passiert ist.
Warum MS da mit Patches vor sich hin schläft, ist allerdings ein kritikwürdiger Punkt
Nicht nur bei OpenSSH wird bei den Abhänigkeiten "etwas"geschludert. Generell sind verschiedene Produkte betroffen die nicht im Cloud-Fokus sind. Zum Beispiel auch der WSUS, da sind auch für bestimmte Funktionen einige Abhänigkeiten EOL und nicht mehr supportet. Ich hatte das mal in einem Blog-Beitrag aufgearbeitet: https://www.infrastrukturhelden.de/microsoft-infrastruktur/microsoft-windows/server/windows-server-2022/windows-server-update-service-wsus-reporting/
Gruß
Fabian