Am 4. Oktober 2023 gaben die Betreuer des curl-Projekts eine Vorankündigung heraus, dass die Version 8.4.0 von curl, die voraussichtlich am 11. Oktober (gegen 06:00 UTC) veröffentlicht wird, die schwerwiegendste Sicherheitslücke der letzten Jahre schließen wird. Curl ist ein De-facto-Standard in der Softwarebranche, wenn es um Webanfragen geht, und unterstützt eine breite Palette von Kommunikationsprotokollen. Je nach Schwachstelle könnte dies weitreichende Auswirkungen haben.

Was ist Curl?

Curl wird von sehr vielen Softwareprogrammen verwendet, sowohl als Komponente als auch eingebettet in den Code als Softwarebibliothek. Curl wird häufig in Automatisierungstools, Skripten und anderen verwaltungsbezogenen Anwendungen verwendet, die im Hintergrund der Arbeitsabläufe von Unternehmen stehen. Es kann auch in eingebetteten Geräten, IOT-Einheiten und mehr vorhanden sein. Seine weite Verbreitung und die Tendenz, tief mit automatisierten Prozessen verbunden zu sein, bedeutet, dass das Risiko in vielen seltener betreuten oder aktualisierten Systemen schlummern wird – höchstwahrscheinlich für eine beträchtliche Zeitspanne, während wir wahrscheinlich ein relativ schnelles erstes Patching sehen werden.

Dies ist doch nicht das neue Log4j, oder?

Nein, das ist es nicht, nicht einmal annähernd. Der Grund dafür ist, dass curl eine clientseitige Bibliothek und Software ist. Sie wird verwendet, um Anfragen an andere Systeme zu senden. Da wir die Art der Schwachstelle noch nicht kennen, ist es noch zu früh, um darüber zu spekulieren, wie sich das Risiko auf Unternehmen auswirken wird, da die Ausnutzung der Schwachstelle von der Fähigkeit abhängt, mit den betroffenen Systemen zu interagieren.

Damit ähnelt die Schwachstelle eher der kürzlich bekannt gewordenen CVE-2023-4863, da es sich um eine unter der Oberfläche schlummernde Schwachstelle handelt, die für Angreifer noch einen Schritt schwieriger zu erreichen ist.

Wie lässt sich die Sicherheitslücke erkennen?

Es handelt sich um ein Standardprodukt und eine Standardbibliothek, aber es ist eine clientseitige Sicherheitslücke. Das bedeutet, dass ein authentifiziertes Scannen oder die Verwendung eines installierten Agenten erforderlich ist. Es kann einige Abweichungen geben, z. B. Fälle, in denen festgestellt wird, dass curl in eine Software eingebettet ist, die ihrerseits durch bekannte Signaturen oder Netzwerkdienste beobachtet werden kann, und das Vorhandensein von curl anhand dieser Elemente abgeleitet werden kann. Die wichtigste Schlussfolgerung wird sein, dass ein authentifizierter Zugang zu einem System erforderlich ist.

Was können Unternehmen tun, um sich vorzubereiten?

Wenn Ihr Unternehmen Software oder Distributionen für andere bereitstellt, müssen Sie zunächst die Abhängigkeiten Ihrer Produkte von curl ermitteln. Bereiten Sie sich darauf vor, am Tag der Veröffentlichung auf Version 8.4.0 zu aktualisieren, da Ihre Kunden die von Ihnen bereitgestellte Lösung ohne solche Updates nicht selbst patchen können. Zweitens müssen Sie sicherstellen, dass alle Systeme, die curl verwenden, rechtzeitig gepatcht werden.

Wenn Sie ein HIAB- oder OUTSCAN NX-Kunde sind und die NETSEC-Lösungen verwenden, ist dies relativ einfach. Rufen Sie die Berichtsansicht auf, wählen Sie Erweiterte Filter, und geben Sie curl ein. Dadurch erhalten Sie zunächst Ergebnisse für alle Schwachstellen und nicht nur für installierte Software. Wenn Sie dies auf einen Eintrag pro Host reduzieren möchten, filtern Sie in der Berichtsansicht nach der Skript-ID „1221985“ oder dem Namen „Installierte Produkte“.

Die obigen Informationen geben Ihnen einen guten Einblick, wo curl bereits in Ihren Umgebungen vorhanden sein könnte. Dies hilft Ihnen nicht dabei, Abhängigkeiten zu identifizieren oder festzustellen, wo es in andere Software eingebettet ist, aber diese Erkennungsmöglichkeiten werden folgen, sobald diese Informationen von den betroffenen Anbietern verfügbar sind.

Was ist als nächstes zu tun?

Planen Sie einige Zeit für Patches und Wartungsarbeiten ein. Wenn Sie Systeme haben, die curl gegenüber nicht vertrauenswürdigen Quellen verwenden, sollten Sie diese Prozesse nicht ausführen, bevor der Patch installiert ist. Vergessen Sie auch nicht virtuelle Maschinen in etwaigen Containern.

Diesem Beitrag wird eine eingehendere Analyse folgen, sobald der Bericht über die Sicherheitslücke von den veröffentlicht wurde.