[English]Im Kommandozeilenprogramm wget gibt es eine kritische Schwachstelle, die mit dem CVSS Base Score 10.0 bewertet wird. CERT-Bund warnt vor der Schwachstelle, die in wget Versionen <=1.24.5 enthalten ist. Ein Angreifer kann einen nicht im Detail spezifizierten Angriff durchführen. Wer wget unter Linux oder Windows nutzt, sollte dringend handeln und die Verwendung des Programms aussetzen. Denn noch gibt es keine aktualisierte Version.
Was ist wget?
Bei wget handelt es sich um ein freies Kommandozeilenprogramm des GNU-Projekts zum Herunterladen von Dateien aus dem Internet. Zu den unterstützten Protokollen gehören ftp, http und https. Das Programm gibt es unter anderem für Unix, GNU/Linux, OS/2, Windows und SkyOS. Es steht unter der GNU General Public License und kann von der Wget-Seite heruntergeladen werden.
Kritische Schwachstelle CVE-2024-38428 in wget
Blog-Leser Bernie hat im Diskussionsbereich auf die Warnung von CERT-Bund vom 17. Juni 2024 zu wget hingewiesen (danke dafür). Es wurde eine Schwachstelle entdeckt, die als kritisch und mit dem CVSS Base Score 10.0 bewertet wird.
Die Schwachstelle betrifft die Open-Source-Versionen von wget Versionen bis einschließlich der Version 1.24.5 (das ist die derzeit aktuelle Version). Beim CERT-Bund heißt es zur Schwachstelle nur, dass ein anonymer Remote-Angreifer die Schwachstelle in wget ausnutzen kann, um einen nicht näher spezifizierten Angriff durchzuführen. Auf GitHub gibt es diese Warnung zur Schwachstelle.
Anzeige
Details zur Schwachstelle CVE-2024-38428
Unter CVE-2024-38428 erfährt man, dass das Modul url.c in GNU Wget bis 1.24.5 Semikolons in der userinfo-Unterkomponente eines URIs falsch behandelt. Dadurch kann es zu einem unsicheren Verhalten kommen, bei dem Daten, die eigentlich in der userinfo-Unterkomponente sein sollten, fälschlicherweise als Teil der host-Unterkomponente interpretiert werden. Tim Rübsen diskutiert die Details zu diesem Bug entdeckt seit dem 2. Juni 2024 auf der gnu.org-Liste im Beitrag Re: Semicolon not allowed in userinfo.
Manipulierte URLs könnten Authentifizierungs-Details und sensitive Informationen offen legen. Es besteht zudem die Gefahr einer Manipulation. Norddeutsch hat es in einem Kommentar so zusammen gefasst: Die verlinkten Diskussionen git hier, insb. gnu.org sprechen konkreten möglichen Missbrauch an:
- Auth Details: exposure of sensitive information
- Host Header Manipulation: phishing, MitM redirect
- Data leakage. unintended exposure of credentials
So wie ich es auf die Schnelle gesehen habe, gibt es noch kein wget-Update, welches diese Schwachstelle schließt. Aktuell sollte man daher auf die Verwendung des Kommandozeilenbefehls verzichten. Leser Nordeutsch schätzt, dass die Linux-Distributionen in einigen Tagen mit einer korrigierten Version bereitstehen.
Anzeige
Betrifft das auch den wget2 Zweig?
Ich verstehe die CVSS Einstufung von maximalen 10 Punkten nicht. Wo steckt da der automatisch wurmable-Faktor drin? Wie kann jemand von außen ohne Interaktion via wget Zugriff bekommen? "Ein entfernter, anonymer Angreifer kann eine Schwachstelle in wget ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen." ja aber erst wenn der User aktiv handelt. Der gleichen Logik folgend müsste jede Firewall ebenfalls einen Maximal CVSS Score von 10 bekommen. Schliesslich kann sich da ja auch jemand versehentlich in den Fuß schießen oder ganz ausschalten.
Hatten wir die Gefahr des falsche URL Parsings nicht auch schon bei den neuen .zip Domains? Als plötzlich bisher angenommene Dateinamen in URLs zur gleichen Gefahr werden konnten, wenn geschickt platziert? Und by the way, wer Dateien mit Credentials in der URL versendet und Signaturen von Downloads nicht überprüft, dem kann nicht mehr geholfen werden.
Die Sache erscheint mir recht mysteriös, vielleicht fehlen da noch ein paar Details.
>>> Wie kann jemand von außen ohne Interaktion via wget Zugriff bekommen? "Ein entfernter, anonymer Angreifer kann eine Schwachstelle in wget ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen." ja aber erst wenn der User aktiv handelt. <<<
Cum grano salis (!), quick 'n dirty: Schau Dir mal (1) an, dort heisst es u. a. "Attackers might craft URLs that, due to incorrect parsing by wget 1.x, lead to connections to unintended hosts."
Und diese unintended hosts sind dann eben malicious bzw. rogue und nicht einfach nur 'falsche adresse, hier gibt 's nichts zu sehen, bitte gehen sie weiter'. Die rogue server können dir u. a. secrets (Passwörter etc.) abluchsen oder maliziösen Code in network responses schicken. Material zu rogue servern – wenngleich in anderem Zusammenhang! – s. (2), (3).
Ohne Eulen nach Athen tragen zu wollen: Der Angriff erfolgt in der Weise, dass Du bspw. eingeladen wirst, ein kostenloses, cooles Tool von einem von Dir nicht als bösartig erkannten FTP-Server (per se, nicht unbedingt mit bösartigen files/payloads/downloads) herunterzuladen. Ich verstünde "wurmable" (wo hast du das gelesen?) dann so, dass je mehr Benutzer den Server mit verwundbaren wegt-Clients besuchen, desto grösser wird die Infektion (klar, das ist eigentlich nicht das was einen Wurm im Kern mein/ausmacht).
(1) lists.gnu.org/archive/html/bug-wget/2024-06/msg00005.html
(2) attack.mitre.org/techniques/T1207/
(3) attack.mitre.org/techniques/T0848/
Ah ein Lateiner ;-) Das von Dir geschilderte Szenario läuft aber ins Leere denn Credentials können ja schlimmstenfalls nur von der aufgerufenen URL selbst kommen. Doch wer macht heute noch soas? Name/Passwort direkt in URLs packen, wo jedes Log, jeder Prozess und jeder Proxy dazwischen mitlesen können? Der "untergeschobene" Link müsste diese ja ebenfalls enthalten, also wo soll da der Diebstahl dieses "Secrets" (in Anführungsstrichen) sein. Bliebe einzig und allein noch eine manipulierte Payload. Diese wird aber a) nicht direkt ausgeführt sondern muss explizit gestartet werden und b) würde diese nach einem Signaturcheck schnell auffliegen, was hoffentlich jeder Linux-Admin bei solchen direkten Downloads macht.
IMHO rechtfertigt das nach vorliegenden Informationen keinen Score von 10. Weder führt ein Aufruf einer URL zu einem automatisch gestarteten Programm, der sich dann auch noch Rechte elevaten müsste, noch sehe ich da ein Diebstahl von Zugangsdaten, da diese in URLs eh noch nie geheim oder sicher waren.
Das mit "wurmable" könnte ich jetzt mit dem Microsoft Score durcheinanderbringen. Dort habe ich aufgeschnappt, dass erst wurmable einen maximal Score ermöglicht.
>>> … denn Credentials können ja schlimmstenfalls nur von der aufgerufenen URL selbst kommen. <<<
Nein, grosser Irrtum. Ich bin zu lange weg vom Thema, ich kann mich aber an Fälle in den beginnenden Zehnerjahren erinnern. Da konnten übelwollende Betreiber von kerberisierten Sambaservern den Nutzern ihr LDAP-Passwort abluchsen! Auch dies nur cum grano salis ;-); recherchiere ggf. in diese Richtung.
Und betr. aus (1) stammender Passage "if a URL contains credentials such as user:pass or user;pass, misinterpretation could lead to … the exposure of sensitive information.": Das ist definitiv ein Problem! Du scheinst da der Ansicht aufzusitzen, dass root bzw. der Administrator einer Zielmaschine ohnehin von Clients kommende Passwörter mitlesen können. Das ist nicht richtig und ein grundlegendes Missverständnis. Aber auch hier bin ich zu lange von der Materie weg, um aus dem Stegreif Belege und Erläuterungen liefern zu können. Wenn mir über Nacht noch spontan was einfällt reiche ich es nach.
(1) lists.gnu.org/archive/html/bug-wget/2024-06/msg00005.html
Ich vermute, dass der hohe Score dadurch zustande kommt, dass wget mit vielen anderen Software-Komponenten betrieben wird und diese sich darauf verlassen, dass die Parameter, die an wget übergeben werden nur eine bestimmte Funktion beeinflussen. Z.B. dass ein Parameter für das Übertragen von Zugangsdaten nicht den Server beeinflussen kann, an den die Anfrage geschickt wird. Das scheint in der verwundbaren Version nicht garantiert zu sein.
Wenn die Parameter die an wget übergeben werden vom Angreifer beeinflusst werden können wäre es z.B. möglich, dass die Anfrage anstelle eines von einer Anwendung vordefinierten Servers an einen Server des Angreifers geschickt werden können. Das Ergebnis der Anfrage könnte im folgenden automatisch ausgeführt und so einem Angreifer z.B. Remote Code-Ausführung auf dem System geben.
"…und diese sich darauf verlassen…" – Autsch!
Wenn sich Skripte oder Software auf in URLs übergebene Credentials und aus dem Netz geladener Payload ohne weitere Überprüfung verlässt, dann kann es sich nur nur um Schrott handeln.
C:\>dir /s wget.exe
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: xxxx-yyyy
Verzeichnis von C:\Program Files\Dell\SysMgt\rac5
19.09.2017 18:43 319.488 wget.exe
1 Datei(en), 319.488 Bytes
Anzahl der angezeigten Dateien:
1 Datei(en), 319.488 Bytes
0 Verzeichnis(se)
C:\>wget –help
GNU Wget 1.10.2, a non-interactive network retriever.
Usage: wget [OPTION]… [URL]…
Das ist Bestandteil des Dell DRAC Command Line Tools, was man gerne auf Servern des Herstellers installiert. Die Path-variable wird um dieses Dell-verzeichnis erweitert, so dass es in CMD und PS und im Startmenü/Ausführen problemlos gestartet werden kann. Die "aktuelle" Version dieses Pakets ist 9.3.0 aus dem Jahr 2019…
>>> rac5 <<<
Hardware aus den Nullerjahren, passend dazu GNU Wget 1.10.2 aus 2005 (gem.ftp.gnu.org/gnu/wget/). Aus (1) ergibt sich, dass DELL schon etliche Male Anlass gehabt haben müsste, zu aktualisieren. Dass sie es nicht gemacht haben, führe ich auf entsprechende 'Freistellungsklauseln' in ihren AGBs, Lizenzbestimmungen etc. zurück.
(1) http://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-332/GNU-Wget.html
wget für Windows kannst du dir dort runterladen:
eternallybored[.]org/misc/wget
Die alte Version in deinem Dell-Ordner irgendwohin sichern und dann mit dem neueren Download überschreiben.
Der aktuelle Bug ist zwar noch nicht gefixt, dafür aber ein paar andere.
Auf der angegebenen Homepage wird auch nur v1.21.4 angeboten.
Also auch veraltet.
Das ist grundsätzlich eine gute Idee! Aber erst, wenn eine bereinigte wget.exe vorliegt, wie Bolko schreibt.
Die Dell DRAC Command Line Tools installiert man übrigens auch auf ganz aktueller Hardware, ein sehr praktisches Tool, um zum Beispiel gescripted die iDRAC-Konfiguration automatisch durchzuführen.
Zitat:
"CVSS Base Score 10.0"
—
Bei Red Hat ist der Score mit 5.4 statt 10.0 angegeben:
access[.]redhat[.]com/security/cve/cve-2024-38428
(Last Modified: 18. Juni, Postet 16. Juni)
Wurde der Score runtergestuft?
Wäre plausibel, den Score von 10.0 kann ich beim besten Willen nicht nachvollziehen. Mit dem First CVSS 3.1 Calculator käme ich realistisch betrachtet auf einen Score von 5.3
>>> Wurde der Score runtergestuft? <<<
Vermutlich nicht, aus (1): "Inwieweit CVSS dahingehend verlässlich ist, dass unterschiedliche Personen zu einheitlichen Bewertungen kommen, untersucht derzeit eine Forschungsgruppe …".
(1) http://www.heise.de/hintergrund/Von-niedrig-bis-kritisch-Schwachstellenbewertung-mit-CVSS-5031983.html?seite=all
eine 5 irgendwas klingt für mich ebenfalls realistischer.
Ich würde aber jeder Software eine 9 geben, die automatisch mit irgendwelchen Installer/Setup/Update Programmen/Skripten mit wget/curl Zeugs aus dem Netz nachlädt und ungeprüft ausführt.
Am 02.Juni gab es bereits einen Patch (url.c):
git[.]savannah[.]gnu[.]org/cgit/wget.git/commit/?id=ed0c7c7e0e8f7298352646b2fd6e06a11e242ace
Warum ist der jetzt nach 16 Tagen immer noch nicht in den Distributionen bzw im Github enthalten?
github[.]com/mirror/wget/blob/master/src/url.c
(ab Zeile 529)
Ganz spannendes Thema. wget ist in so vielen open Source Paketen als Download-Tool mit im Umfang. Gerade bei den Windows Binäries ist es nicht gerade einfach, die Version herauszulesen, da diese nicht gepflegt wurde. Unter Eigenschaften Details findet man leider nur das Erstelldatum, das kann das Datum sein an dem die Datei heruntergeladen wurde oder umkopiert. Danach kann man also nicht gehen.
Da die "NEUESTE" Windows Version von https://eternallybored.org/misc/wget/ mit der Versionsnummer 1.21.4 und älteren Librarys auch ungepflegt ist, OpenSSL 3.1.0, ZLib 1.2.13, gpgme-1.20.0, pcre2 10.42, libpsl 0.21.2, c-ares 1.19.0 sollte man hier die Notbremse ziehen und wget.ext auf die Blacklist setzen und die Ausführung verbieten.
Die Abfrage der Versionsnummer unter Windows kann leider nur per cmd mit wget –version erfolgen.
Das BSI hat mittlerweile auf CVSS base score 6.3 (5.5 temporal) heruntergestuft.