CVE-2025-34028 (CVSS 10) ist eine Schwachstelle mit maximaler Schweregradbewertung in Commvault Command Center, einer beliebten Verwaltungskonsole für IT-Security-Services wie Datenschutz und Backups in Unternehmensumgebungen. Am 28. April meldete die Cybersecurity and Infrastructure Security Agency (CISA), dass sie aktiv ausgenutzt wird. CVE-2025-34028 stellt außerdem ein erhöhtes Risiko dar, da öffentlich zugänglicher PoC-Exploit-Code (Proof of Concept) existiert und Command Center die Backups und andere Sicherheitskonfigurationen vieler namhafter Unternehmen verwaltet.

Die Schwachstelle ermöglicht es nicht authentifizierten Angreifern, Remote Code Execution (RCE) durchzuführen und die vollständige Kontrolle über eine Command Center-Umgebung zu erlangen. Angesichts der Sensibilität und Kritikalität der von Commvault verwalteten IT-Aufgaben birgt der Verlust der vollständigen Kontrolle ein hohes Potenzial für katastrophale Auswirkungen. Wenn beispielsweise Backups deaktiviert werden, könnte ein Unternehmen seine Fähigkeit zur Wiederherstellung nach einem Ransomware-Angriff verlieren. Das macht CVE-2025-34028 zu einem attraktiven Eintrittspunkt für Ransomware-Betreiber und finanziell motivierte Angreifer.

Die von Sonny Macdonald von watchTowr Labs entdeckte Schwachstelle nutzt eine SSRF-Lücke (Server Side Request Forgery) [CWE-918] im Endpunkt deployWebpackage.do von Command Center aus. Bei einem erfolgreichen Angriff lädt ein Angreifer ein infiziertes ZIP-Archiv in einen öffentlich zugänglichen Pfad hoch. Die schädliche ZIP-Datei wird automatisch extrahiert, sodass Angreifer die Ausführung über eine HTTP-GET-Anfrage an die extrahierte Nutzlast auslösen können.

CVE-2025-34028 betrifft die Versionen 11.38.0 bis 11.38.19 auf Linux- und Windows-Plattformen. Greenbone kann CVE-2025-34028 mit einer aktiven Überprüfung erkennen, die eine speziell gestaltete HTTP-POST-Anfrage sendet und überprüft, ob das Ziel eine Verbindung zum Scanner-Host herstellt, was darauf hindeutet, dass es für eine Ausnutzung anfällig ist. Benutzer der betroffenen Versionen werden dringend gebeten, die Patches sofort zu installieren. Sehen wir uns das Risiko durch CVE-2025-34028 genauer an!

Was ist Commvault Command Center?

Commvault Command Center ist eine webbasierte Schnittstelle in Java, mit der Unternehmen Datensicherungs-, Backup- und Recovery-Maßnahmen in großen Umgebungen verwalten können. Commvault vermarktet sich als einzige Plattform mit modularen Komponenten wie Complete Backup & Recovery, HyperScale X und Disaster Recovery. Die meisten Produkte von Commvault nutzen das Command Center als primäre Verwaltungsschnittstelle. Daher wird es zur Konfiguration von Sicherungsaufträgen, Überwachung von Systemen, Wiederherstellung von Daten und zur Verwaltung von Benutzerrollen und Zugriffsrechten verwendet.

Im Jahr 2025 hält Commvault einen Marktanteil von rund 6,2 % bei Backup und Recovery und bedient weltweit über 10.000 Unternehmen aus verschiedenen Branchen wie Banken, Gesundheitswesen, Behörden und Technologie. Die meisten Kunden sind große Unternehmen, von denen 42 % mehr als 1.000 Mitarbeiter beschäftigen. Da Commvault in kritischen Bereichen wie dem Gesundheitswesen, der Regierung und Fortune-500-Unternehmen eingesetzt wird, sind die möglichen Auswirkungen dieser Schwachstelle weitreichend und erheblich.

Technische Beschreibung von CVE-2025-34028

Die Entdeckung und Offenlegung von CVE-2025-34028 wurde von einer vollständigen technischen Beschreibung und einem PoC-Code begleitet. Hier eine kurze Zusammenfassung der Ursache und des Angriffsvektors für CVE-2025-34028:

Die Ursache von CVE-2025-34028 wird als Server Side Request Forgery (SSRF) [CWE-918] klassifiziert. SSRF-Schwachstellen entstehen, wenn eine Anwendung dazu gebracht wird, auf eine Ressource remote zuzugreifen, ohne diese ordnungsgemäß zu validieren. Durch Ausnutzen von SSRF-Schwachstellen kann ein Angreifer möglicherweise Zugriffskontrollen [CWE-284] wie Firewalls umgehen, die den direkten Zugriff auf die URLs verhindern. Man kann sich das so vorstellen, als würde der Angreifer den Server als „Sprungbrett“ benutzen, um Sicherheitsmaßnahmen zu überlisten. Im Fall von CVE-2025-34028 ermöglicht die SSRF-Schwachstelle das uneingeschränkte Hochladen von gefährlichen Dateien [CWE-434].

So funktioniert der Exploit-Prozess für CVE-2025-34028:

Unter den Endpunkten der Command Center-Anwendung fanden die Forscher 58 APIs, die keinerlei Authentifizierung erfordern. Bei der Untersuchung dieser uneingeschränkt nutzbaren APIs entdeckten die Forscher, dass der Endpunkt deployWebpackage.do einen Parameter namens commcellName enthielt, der zur Definition des Hostnamens einer URL verwendet wurde und nicht nach dem Geltungsbereich gefiltert war. Ein weiterer Parameter, servicePack, definiert den lokalen Pfad, in dem die HTTP-Antwort auf diese URL gespeichert werden soll.

Mithilfe einer einfachen Directory-Traversal-Technik, d. h. durch Voranstellen des Parameters „servicePack“ mit „../../“, konnten die Forscher beliebige Dateien an einen benutzerdefinierten Zielort hochladen. Die Command Center-Anwendung verwendete einen fest definierten Dateinamen „dist-cc.zip“, was darauf hindeutete, dass das Programm ein ZIP-Archiv erwartete.

Bei der Bereitstellung einer ZIP-archivierten, ausführbaren Java-Datei (.jsp-Datei) und der Angabe einer nicht authentifizierten Route über den Parameter „servicePack“ wurde eine bösartige .jsp-Nutzlast hochgeladen, automatisch extrahiert und konnte direkt über eine HTTP-GET-Anfrage aufgerufen werden. Dies führte zur Ausführung der .jsp-Datei durch den Apache Tomcat-Webserver von Command Center und zu einer nicht authentifizierten, beliebigen RCE im Namen des Angreifers.

CVE-2025-34028 entschärfen

CVE-2025-34028 betrifft Commvault Command Center Versionen 11.38.0 bis 11.38.19 auf Linux- und Windows-Plattformen und wurde in den Versionen 11.38.20 und 11.38.25 behoben, wobei die Patches am 10. April 2025 veröffentlicht wurden. Für diejenigen, die nicht sofort aktualisieren können, empfiehlt Commvault als vorübergehende Abhilfemaßnahme, die Command Center-Installation vom externen Netzwerkzugriff zu isolieren.

Die Innovation-Releases von Commvault sind häufige, funktionsreiche Update-Tracks, die in der Regel automatisch vom System nach einem vordefinierten Zeitplan aktualisiert werden, ohne dass eine Aktion des Benutzers erforderlich ist. Dies steht im Gegensatz zu LTS-Versionen (Long Term Support), die manuelle Updates erfordern.

Zusammenfassung

CVE-2025-34028 ist eine kritische, nicht authentifizierte RCE-Sicherheitslücke in Commvault Command Center, die keine Benutzerinteraktion erfordert. Die Schwachstelle wurde von der CISA im April 2025 als aktiv ausgenutzt gemeldet. CVE-2025-34028 betrifft Command Center-Versionen 11.38.0 bis 11.38.19 und ermöglicht es Angreifern, die vollständige Kontrolle über Backup-Systeme zu erlangen. CommVault wird von vielen großen Unternehmen weltweit für wichtige Backup- und Wiederherstellungsfunktionen eingesetzt, was CVE-2025-34028 zu einem beliebten Ziel für Ransomware-Angreifer macht. Greenbone kann betroffene Command Center-Instanzen mit einem aktiven Test erkennen, der eine HTTP-POST-Anfrage verwendet, um die Schwachstelle zu überprüfen.

Unser neuentwickeltes Produkt OPENVAS REPORT integriert die Daten von praktisch beliebig vielen Greenbone Enterprise Appliances und bringt sie auf einem klar strukturierten Dashboard in einen übersichtlichen Zusammenhang. Die benutzerfreundliche und umfangreiche Oberfläche vereinfacht den Schutz und die Absicherung auch großer Netzwerke erheblich.

Die Greenbone AG entwickelt seit 2008 führende Open-Source-Technologien für automatisiertes Schwachstellen-Management. Mehr als 100.000 Installationen weltweit vertrauen auf die Greenbone-Community und Enterprise-Editionen, um ihre Cyber-Resilienz zu stärken.

„OPENVAS REPORT steht für Innovation vom Open Source Market Leader.“

Mit unserem neuen Produkt verkürzen wir entscheidend den Weg von aktuellen Sicherheitserkenntnissen zur Handlungsfähigkeit– schneller, übersichtlicher und flexibler als je zuvor“, erklärt Dr. Jan-Oliver Wagner, CEO der Greenbone AG.

Gefährdungslagen schneller und effektiver erkennen

Für den Schutz Ihrer digitalen Infrastrukturen ist es entscheidend, über sicherheitsrelevante Ereignisse stets auf dem Laufenden zu bleiben und die Reaktionszeit auf kritische Vorkommnisse so kurz wie möglich zu halten.

OPENVAS REPORT schafft einen tagesaktuellen, vollständigen Überblick über die Sicherheitssituation Ihrer IT-Infrastruktur – für alle Entscheidungsebenen.

Durch die verbundenen Greenbone Enterprise Appliances erkennt OPENVAS REPORT automatisch Rechner und Software im Unternehmen. Anwender können diese mit Schlagworten markieren und sie beliebig gruppieren und sortieren – so bleibt auch in sehr großen Netzen die Übersicht erhalten.

Modernes, benutzerfreundliches Dashboard

Das OPENVAS REPORT Dashboard bietet einen modernen, benutzerfreundlichen und hochgradig flexiblen Zugang für die Anwender, die tagtäglich damit arbeiten. So ist beispielsweise eine Filterung oder Sortierung nach dem allgemeinen Schweregrad oder des spezifischen Risikos der Schwachstellen möglich. Unternehmen können sich so maßgeschneiderte Ansichten selbst zusammenstellen, die ein stets aktuelles Bild der Gefährdungslage im Firmennetz zeigen.

Vollständiger Überblick

OPENVAS REPORT erlaubt es Ihnen, die Sicherheitslage Ihres Unternehmens mit einem Blick zu erfassen und zu bewerten. Dank der einfachen, klaren Benutzerführung bereitet es auch komplexeste Daten lesbar und verständlich auf und beschleunigt damit die Entscheidungsfindung in kritischen Situationen.

Mit flexiblen und individuell gestaltbaren Filtermöglichkeiten vereinfacht OPENVAS REPORT die alltägliche Arbeit von Administratoren und Sicherheitsbeauftragten erheblich.

Flexible Schnittstellen

Die umfangreichen Export-Funktionen erlauben es, OPENVAS REPORT noch tiefer in die Infrastruktur zu integrieren, beispielsweise um externe Daten mit OPENVAS REPORT zu verarbeiten.

Funktion Mehrwert für Ihr Unternehmen
Umfassende Asset-Sichtbarkeit Vollständiger Überblick über sämtliche IT-Assets und deren Schwachstellen in einer einzigen Oberfläche – für eine lückenlose Bewertung Ihrer aktuellen Sicherheitslage.
Benutzerfreundliche Dashboards Ein klar strukturiertes, interaktives Dashboard macht komplexe Schwachstelleninformationen auf einen Blick verständlich und beschleunigt fundierte Entscheidungen.
Flexible Datenverarbeitung Vielfältige Export-, API- und Automationsoptionen lassen sich nahtlos in bestehende Workflows integrieren und an individuelle Betriebsanforderungen anpassen.
Effiziente Datenkonsolidierung Aggregiert Ergebnisse aus mehreren Scannern und Standorten in einer zentralen Datenbank – reduziert administrativen Aufwand und verbessert die Reaktionsgeschwindigkeit.
Anpassbare Klassifizierung von Schwachstellen Die Schweregrade sowie frei definierbare Tags ermöglichen es, interne Compliance- und Risiko-Modelle exakt abzubilden.
Erweiterte Reporting-Funktionen Zielgruppengerechte Berichte (C-Level, Audit, Operations) auf Knopfdruck erstellbar: Filter und Drill-down-Links sorgen für fokussierte Einblicke in kritische Sicherheitsprobleme.

Mehr erfahren

Haben Sie Interesse an einer Demo oder einem Angebot? Kontaktieren Sie unser Vertriebsteam und erfahren Sie mehr über OPENVAS REPORT. Schreiben Sie uns: sales@greenbone.net oder kontaktieren uns direkt. Wir helfen Ihnen gerne weiter!

Trotz des Ausfalls der „National Vulnerability Database” (NVD) des amerikanischen „National Institute of Standards and Technology“ (NIST) ist die Greenbone-Engine zur Erkennung von Schwachstellen weiterhin voll funktionsfähig. Sie bietet zuverlässige Schwachstellen-Scans, ohne auf fehlende CVE-Anreicherungsdaten angewiesen zu sein.

Seit 1999 stellt die MITRE Corporation mit Common Vulnerabilities and Exposures (CVE) kostenlose öffentliche Informationen über Schwachstellen zur Verfügung, indem sie Informationen über Software-Schwachstellen veröffentlicht und verwaltet. Das NIST hat diese CVE-Berichte seit 2005 fleißig erweitert und mit Kontext angereichert, um die Bewertung von Cyberrisiken zu verbessern. Anfang 2024 wurde die Cybersecurity-Gemeinschaft überrascht, als die NIST-NVD zum Stillstand kam. Etwa ein Jahr später war der Ausfall noch immer nicht vollständig behoben [1][2]. Bei einer jährlich steigenden Zahl von CVE-Einreichungen haben die Schwierigkeiten des NIST dazu geführt, dass ein großer Prozentsatz ohne Kontext blieb, wie z. B. bei der Bewertung des Schweregrads (CVSS), den Listen betroffener Produkte (CPE) und den Einstufungen von Schwachstellen (CWE).

Die jüngsten von der Trump-Administration angestoßenen politischen Veränderungen haben die Unsicherheit über die Zukunft des Austauschs von Schwachstelleninformationen und der vielen Sicherheitsanbieter, die davon abhängig sind, vergrößert. Der Haushaltsplan für das Geschäftsjahr der CISA enthält bemerkenswerte Kürzungen in bestimmten Bereichen, wie z. B. 49,8 Millionen Dollar weniger für Beschaffung, Bau und Verbesserungen sowie 4,7 Millionen Dollar weniger für Forschung und Entwicklung. Als Reaktion auf die Finanzierungsprobleme hat die CISA Maßnahmen zur Kürzung der Ausgaben ergriffen, darunter Anpassungen bei Verträgen und Beschaffungsstrategien.

Um es klar zu sagen: Das CVE-Programm ist noch nicht ausgefallen. Am 16. April erließ die CISA in letzter Minute eine Anweisung, ihren Vertrag mit MITRE zu verlängern, um den Betrieb des CVE-Programms für weitere elf Monate sicherzustellen, nur wenige Stunden bevor der Vertrag auslaufen sollte. Niemand kann jedoch vorhersagen, wie sich die zukünftigen Ereignisse entwickeln werden. Die potenziellen Auswirkungen auf den Austausch von Informationen sind alarmierend und deuten vielleicht auf eine neue Dimension von „kaltem Cyberkrieg“ hin.

Dieser Artikel enthält einen kurzen Überblick über die Funktionsweise des CVE-Programms und darüber, wie die Erkennungsfunktionen von Greenbone auch während des NIST NVD-Ausfalls aufrechterhalten werden.

Ein Überblick über den Betrieb des CVE-Programms

Die MITRE Corporation ist eine gemeinnützige Organisation, die die Aufgabe hat, die innere Sicherheit der USA an mehreren Fronten zu unterstützen, einschließlich der Verteidigungsforschung zum Schutz kritischer Infrastrukturen und der Cybersicherheit. MITRE betreibt das CVE-Programm, fungiert als primäre CNA (CVE Numbering Authority) und unterhält die zentrale Infrastruktur für die CVE-ID-Zuweisung, die Veröffentlichung von Datensätzen, die Kommunikationsabläufe zwischen allen CNAs und ADPs (Authorized Data Publishers) sowie die Programmverwaltung. MITRE stellt der Öffentlichkeit CVE-Daten über die Website CVE.org und das GitHub-Repository cvelistV5 zur Verfügung, das alle CVE-Datensätze im strukturierten JSON-Format enthält. Das Ergebnis ist eine hocheffiziente, standardisierte Berichterstattung zu Schwachstellen und ein nahtloser Datenaustausch im gesamten Cybersicherheitsökosystem.

Nachdem eine Schwachstellen-Beschreibung von einem CNA an MITRE übermittelt wurde, hat das NIST in der Vergangenheit immer etwas hinzugefügt:

  • CVSS (Common Vulnerability Scoring System): Ein Schweregrad und ein detaillierter Vektorstring, der den Risikokontext für Angriffskomplexität (AC), die Auswirkungen auf Vertraulichkeit (C), Integrität (I) und Verfügbarkeit (A) sowie andere Faktoren enthält.
  • CPE (Common Platform Enumeration): Eine speziell formatierte Zeichenfolge, die zur Identifizierung betroffener Produkte dient, indem sie den Produktnamen, den Hersteller, die Versionen und andere architektonische Spezifikationen weitergibt.
  • CWE (Common Weakness Enumeration): Eine Ursachenklassifizierung nach der Art des betreffenden Softwarefehlers.

CVSS ermöglicht es Unternehmen, den Grad des Risikos einer bestimmten Schwachstelle leichter zu bestimmen und dementsprechend strategische Abhilfemaßnahmen zu ergreifen. Da die ersten CVE-Berichte nur eine nicht standardisierte Deklaration des betroffenen Produkts erfordern, ermöglicht es die Ergänzung von CPE durch NIST den Plattformen für das Schwachstellenmanagement, den CPE-Abgleich als schnelle, wenn auch etwas unzuverlässige Methode durchzuführen, um festzustellen, ob eine CVE in der Infrastruktur eines Unternehmens existiert oder nicht.

Einen detaillierteren Einblick in die Funktionsweise des Verfahrens zur Offenlegung von Schwachstellen und wie CSAF 2.0 eine dezentralisierte Alternative zum CVE-Programm von MITRE bietet, finden Sie in unserem Artikel: Wie CSAF 2.0 automatisiertes Schwachstellenmanagement vorantreibt. Als Nächstes wollen wir uns den NIST NVD-Ausfall genauer ansehen und verstehen, was Greenbones Erkennung gegen diesen Ausfall widerstandsfähig macht.

Der NIST-NVD-Ausfall: Was ist passiert?

Seit dem 12. Februar 2024 hat die NVD die Anreicherung von CVEs mit wichtigen Metadaten wie CVSS-, CPE- und CWE-Produktkennungen drastisch reduziert. Das Problem wurde zuerst vom VP of Security von Anchore erkannt. Im Mai 2024 waren etwa 93 % der nach dem 12. Februar hinzugefügten CVEs nicht angereichert. Im September 2024 hatte das NIST seine selbst gesetzte Frist nicht eingehalten; 72,4 % der CVEs und 46,7 % der neu hinzugefügten KEVs (Known Exploited Vulnerabilities) der CISA waren immer noch nicht angereichert [3].

Die Verlangsamung des NVD-Anreicherungsprozesses hatte erhebliche Auswirkungen auf die Cybersecurity-Gemeinschaft, nicht nur, weil angereicherte Daten für Verteidiger entscheidend sind, um Bedrohungen effektiv zu priorisieren, sondern auch, weil einige Schwachstellen-Scanner auf diese angereicherten Daten angewiesen sind, um ihre Erkennungstechniken einzusetzen.

Als Verteidiger der Cybersicherheit lohnt es sich zu fragen: War Greenbone vom Ausfall des NIST NVD betroffen? Die kurze Antwort lautet: Nein. Lesen Sie weiter, um herauszufinden, warum die Erkennungsfähigkeiten von Greenbone gegen den NIST NVD-Ausfall resistent sind.

Greenbone-Erkennungsrate trotz NVD-Ausfall hoch

Ohne angereicherte CVE-Daten werden einige Lösungen für das Schwachstellenmanagement unwirksam, da sie auf den CPE-Abgleich angewiesen sind, um festzustellen, ob eine Schwachstelle in der Infrastruktur eines Unternehmens vorhanden ist.  Greenbone ist jedoch gegen den Ausfall der NIST NVD gewappnet, da unsere Produkte nicht vom CPE-Abgleich abhängen. Die OPENVAS-Schwachstellentests von Greenbone können auf der Grundlage von nicht angereicherten CVE-Beschreibungen erstellt werden. Greenbone erkennt sogar bekannte Schwachstellen und Fehlkonfigurationen, für die es nicht einmal CVEs gibt, wie z. B. CIS-Compliance Benchmarks [4][5].

Für die Erstellung von Schwachstellentests (VT) beschäftigt Greenbone ein engagiertes Team von Software-Ingenieuren, die die zugrunde liegenden technischen Aspekte von Schwachstellen identifizieren. Greenbone verfügt über eine CVE-Scanner-Funktion, die einen herkömmlichen CPE-Abgleich ermöglicht. Im Gegensatz zu Lösungen, die sich ausschließlich auf die CPE-Daten der NIST NVD stützen, um Schwachstellen zu identifizieren, setzt Greenbone jedoch Erkennungstechniken ein, die weit über den grundlegenden CPE-Abgleich hinausgehen. Daher bleiben die Fähigkeiten von Greenbone zur Erkennung von Schwachstellen auch angesichts von Herausforderungen wie dem jüngsten Ausfall der NIST NVD robust.

Um eine hoch belastbare, branchenführende Schwachstellen-Erkennung  zu erreichen, interagiert die Greenbone-Komponente OPENVAS Scanner aktiv mit exponierten Netzwerkdiensten, um eine detaillierte Karte der Angriffsfläche eines Zielnetzwerks zu erstellen. Dies beinhaltet die Identifizierung von Diensten, die über Netzwerkverbindungen zugänglich sind, die Untersuchung dieser Dienste zur Ermittlung von Produkten und die Ausführung individueller Schwachstellentests (VT) für jede CVE- oder Nicht-CVE-Sicherheitslücke, um aktiv zu überprüfen, ob diese vorhanden sind. Der Enterprise Vulnerability Feed von Greenbone enthält über 180.000 VTs, die täglich aktualisiert werden, um die neuesten veröffentlichten Schwachstellen zu identifizieren und eine schnelle Erkennung der neuesten Bedrohungen zu gewährleisten.

Zusätzlich zu seinen aktiven Scan-Funktionen unterstützt Greenbone die agentenlose Datenerfassung über authentifizierte Scans. Greenbone sammelt detaillierte Informationen von den Endpunkten und bewertet die installierten Softwarepakete anhand der veröffentlichten CVEs. Diese Methode ermöglicht eine präzise Erkennung von Schwachstellen, ohne auf die angereicherten CPE-Daten der NVD angewiesen zu sein.

Wichtige Erkenntnisse:

  • Unabhängigkeit von angereicherten CVE-Daten: Die Schwachstellenerkennung von Greenbone ist nicht auf angereicherte CVE-Daten angewiesen, die von der NVD des NIST bereitgestellt werden, wodurch eine unterbrechungsfreie Leistung bei Ausfällen gewährleistet ist. Anhand einer grundlegenden Beschreibung einer Schwachstelle können die Ingenieure von Greenbone ein Erkennungsmodul entwickeln.
  • Erkennung über CPE-Abgleich hinaus: Obwohl Greenbone eine CVE-Scanner-Funktion für den CPE-Abgleich enthält, gehen die Erkennungsfähigkeiten weit über diesen grundlegenden Ansatz hinaus und nutzen mehrere Methoden, die aktiv mit Scan-Zielen interagieren.
  • Angriffsflächen-Mapping: Der OPENVAS-Scanner interagiert aktiv mit exponierten Diensten, um die Angriffsfläche des Netzwerks abzubilden und alle im Netzwerk erreichbaren Dienste zu identifizieren. Greenbone führt auch authentifizierte Scans durch, um Daten direkt von den Interna der Endpunkte zu sammeln. Diese Informationen werden verarbeitet, um verwundbare Pakete zu identifizieren. Angereicherte CVE-Daten wie CPE sind nicht erforderlich.
  • Widerstandsfähigkeit bei Ausfällen der NVD-Anreicherung: Die Erkennungsmethoden von Greenbone bleiben auch ohne NVD-Anreicherung wirksam, da sie die von CNAs bereitgestellten CVE-Beschreibungen nutzen, um genaue aktive Prüfungen und versionsbasierte Schwachstellenbewertungen zu erstellen.

Greenbones Ansatz: praktisch, wirksam und widerstandsfähig

Greenbone ist ein Beispiel für den Gold-Standard in Bezug auf Praktikabilität, Effektivität und Widerstandsfähigkeit und setzt damit einen Maßstab, den IT-Sicherheitsteams anstreben sollten. Durch den Einsatz von aktivem Netzwerk-Mapping, authentifizierten Scans und aktiver Interaktion mit der Zielinfrastruktur gewährleistet Greenbone zuverlässige, belastbare Erkennungsfunktionen in unterschiedlichen Umgebungen.

Dieser höhere Standard ermöglicht es Unternehmen, Schwachstellen selbst in komplexen und dynamischen Bedrohungslandschaften sicher zu erkennen. Auch ohne NVD-Anreicherung bleiben die Erkennungsmethoden von Greenbone effektiv. Mit nur einer allgemeinen Beschreibung können die VT-Ingenieure von Greenbone genaue aktive Prüfungen und produktversionsbasierte Schwachstellenbewertungen entwickeln.

Durch einen grundlegend robusten Ansatz zur Erkennung von Schwachstellen gewährleistet Greenbone ein zuverlässiges Schwachstellenmanagement und hebt sich damit von anderen Anbietern im Bereich der Cybersicherheit ab.

Alternativen zu NVD / NIST / MITRE

Die MITRE-Problematik ist ein Weckruf für die digitale Souveränität, und die EU hat bereits (und schnell) reagiert. Eine lang erwartete Alternative, die EuVD der ENISA, der Agentur der Europäischen Union für Cybersicherheit, ist nun verfügbar und wird in einem unserer nächsten Blogbeiträge vorgestellt.

Wem sollten Sie vertrauen, wenn es darum geht, Ihre Organisation vor digitalen Bedrohungen zu schützen? Realität ist, dass eine hoch belastbare IT-Sicherheit aus einem Netzwerk starker Partnerschaften, tiefgreifender Verteidigungsmaßnahmen, mehrstufiger Sicherheitskontrollen und regelmäßiger Audits besteht. Diese Maßnahmen müssen kontinuierlich überwacht, gemessen und verbessert werden. Schwachstellenmanagement war zwar schon immer eine zentrale Instanz für die Sicherheit, ist aber dennoch ein sich schnell veränderndes Instrument. Im Jahr 2025 hat die kontinuierliche und priorisierte Eindämmung von Bedrohungen einen großen Einfluss auf die Schutzwirkung, da die Zeit immer kürzer wird, in der eine Sicherheitslücke von Angreifern ausgenutzt wird.

Im Threat Report vom März heben wir die Bedeutung des Schwachstellenmanagements und der branchenführenden Erkennungsrate von Greenbone hervor, indem wir die neuesten kritischen Bedrohungen untersuchen. Aber diese neuen Bedrohungen sind nur die Spitze des Eisbergs. Im März 2025 hat Greenbone 5.283 neue Schwachstellentests zum Enterprise Feed hinzugefügt. Sehen wir uns einige der wichtigen Erkenntnisse aus einer hochaktiven Bedrohungslandschaft an!

Einbruch ins US-Finanzministerium: Wie kam es dazu?

Ende Dezember 2024 gab das US-Finanzministerium bekannt, dass staatlich unterstützte chinesische Hacker sein Netzwerk angegriffen hatten. Daraufhin verhängte es Anfang Januar 2025 Sanktionen. Bei forensischen Untersuchungen stieß man auf einen gestohlenen BeyondTrust-API-Schlüssel als Ursache. Der Anbieter hat bestätigt, dass 17 weitere Kunden von diesem Fehler betroffen waren. Eingehendere Untersuchungen ergaben, dass der API-Schlüssel unter Ausnutzung einer Sicherheitslücke in einer Funktion zur Umgehung nicht vertrauenswürdiger Eingaben innerhalb von PostgreSQL gestohlen wurde.

Wenn eine ungültige zwei Byte lange UTF-8-Zeichenfolge an eine anfällige PostgreSQL-Funktion übermittelt wird, wird nur das erste Byte umgangen, sodass ein einfaches Anführungszeichen ohne Bereinigung durchgelassen wird, was zum Auslösen eines SQL-Injection-Angriffs [CWE-89] genutzt werden kann. Die ausnutzbaren Funktionen sind PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() und PQescapeStringConn(). Alle Versionen von PostgreSQL vor 17.3, 16.7, 15.11, 14.16 und 13.19 sind betroffen, ebenso wie zahlreiche Produkte, die von diesen Funktionen abhängen.

CVE-2024-12356, (CVSS 9.8) und CVE-2024-12686, (CVSS 7.2) wurden für BeyondTrust Privileged Remote Access (PRA) und Remote Support (RS) herausgegeben, und CVE-2025-1094 (CVSS 8.1) befasst sich mit dem Fehler in PostgreSQL. Das Problem ist Gegenstand mehrerer nationaler CERT-Hinweise, darunter der deutsche BSI Cert-Bund (WID-SEC-2024-3726) und das kanadische Centre for Cybersecurity (AV25-084). Die Schwachstelle wurde in die Liste der bekannten ausgenutzten Schwachstellen (KEV) der CISA (Cybersecurity and Infrastructure Security Agency) aufgenommen, und es ist ein Metasploit-Modul verfügbar, das anfällige BeyondTrust-Produkte ausnutzt – was das Risiko noch erhöht. Greenbone kann die oben genannten CVEs (Common Vulnerabilities and Exposures) sowohl in BeyondTrust-Produkten als auch in PostgreSQL-Instanzen erkennen, die für CVE-2025-1094 anfällig sind.

Advanced: 3,1 Millionen Pfund Geldstrafe wegen fehlender technischer Kontrollen

Diesen Monat verhängte das britische Information Commissioner’s Office (ICO) eine Geldstrafe in Höhe von 3,07 Millionen Britische Pfund gegen die Advanced Computer Software Group Ltd. gemäß der britischen Datenschutz-Grundverordnung (GDPR) wegen Sicherheitsmängeln. Der Fall ist ein Beispiel dafür, wie der durch einen Ransomware-Angriff verursachte finanzielle Schaden durch behördliche Geldbußen noch weiter verschärft werden kann. Der ursprünglich vorgeschlagene Betrag war mit 6,09 Millionen Britische Pfund sogar noch höher. Da das Opfer jedoch nach dem Vorfall mit dem NCSC (National Cyber Security Centre), der NCA (National Crime Agency) und dem NHS (National Health Service) kooperierte, wurde eine freiwillige Einigung in Höhe von 3.076.320 Pfund genehmigt. Die Betriebskosten und Erpressungszahlungen wurden zwar nicht öffentlich bekannt gegeben, dürften aber die Gesamtkosten des Vorfalls um weitere 10 bis 20 Millionen Pfund erhöhen.

Advanced ist ein bedeutender IT- und Softwareanbieter für Gesundheitsorganisationen, darunter auch der NHS. Im August 2022 wurde Advanced kompromittiert. Angreifer verschafften sich Zugang zu seiner Tochtergesellschaft für Gesundheit und Pflege, was zu einem schweren Ransomware-Vorfall führte. Durch den Verstoß wurden kritische Dienste wie NHS 111 unterbrochen und das Gesundheitspersonal daran gehindert, auf personenbezogene Daten von 79.404 Personen zuzugreifen, darunter auch sensible Pflegeinformationen.

Das ICO kam zu dem Schluss, dass Advanced zum Zeitpunkt des Vorfalls über eine unvollständige MFA-Abdeckung verfügte, keine umfassenden Schwachstellen-Scans durchführte und über mangelhafte Patch-Management-Praktiken verfügte – Faktoren, die zusammengenommen ein Versäumnis bei der Umsetzung angemessener technischer und organisatorischer Maßnahmen darstellten. Organisationen, die sensible Daten verarbeiten, müssen Sicherheitskontrollen als nicht verhandelbar betrachten. Unzureichendes Patch-Management ist nach wie vor eine der am häufigsten ausgenutzten Sicherheitslücken in modernen Angriffsketten.

Doppelte Gefahr: Die kritische Rolle von Backups beim Schutz vor Ransomware

Backups sind die letzte Verteidigungslinie einer Organisation gegen Ransomware, und die meisten hochentwickelten APT-Akteure (Advanced Persistent Threat) sind dafür bekannt, dass sie die Backups ihrer Opfer ins Visier nehmen. Sind die Backups kompromittiert, ist es wahrscheinlicher, dass Lösegeldforderungen gestellt werden. Im Jahr 2025 könnte dies Verluste in Höhe von mehreren Millionen Dollar bedeuten. Im März 2025 wurden zwei neue massive Bedrohungen für Backup-Dienste aufgedeckt: CVE-2025-23120, eine neue kritische Sicherheitslücke in Veeam, wurde bekannt, und es wurden Kampagnen beobachtet, die auf CVE-2024-48248 in NAKIVO Backup & Replication abzielten. Betroffene Systeme sollten daher dringend identifiziert und gepatcht werden.

Im Oktober 2024 warnte unser Threat Report vor einer weiteren Schwachstelle in Veeam (CVE-2024-40711), die für Ransomware-Angriffe ausgenutzt wird. Insgesamt ist es für CVEs in Veeam Backup and Replication sehr wahrscheinlich, aktiv für PoC-Exploits (Proof of Concept) und Ransomware-Angriffe verwendet zu werden. Hier sind die Details zu beiden neu auftretenden Bedrohungen:

  • CVE-2024-48248 (CVSS 8.6): Versionen von NAKIVO Backup & Replication vor 11.0.0.88174 ermöglichen nicht autorisierte Remote Code Execution (RCE) über eine Funktion namens getImageByPath, die das Lesen von Dateien remote ermöglicht. Dies schließt Datenbankdateien ein, die Klartext-Anmeldeinformationen für jedes System enthalten, mit dem NAKIVO eine Verbindung herstellt und es sichert. Eine vollständige technische Beschreibung und ein Proof of Concept sind verfügbar, weshalb diese Schwachstelle nun als aktiv ausgenutzt verfolgt wird.
  • CVE-2025-23120 (CVSS 9.9): Angreifer mit Domain User Access können die Deserialisierung von manipulierten Daten via .NET-Remoting auslösen. Veeam versucht, gefährliche Typen über eine Blacklist einzuschränken, aber Forscher haben schon ausnutzbare Klassen entdeckt, die nicht auf der Liste stehen, etwa xmlFrameworkDs und BackupSummary. Diese erweitern die DataSet-Klasse von .NET – ein bekannter RCE-Vektor – und ermöglichen die Ausführung von beliebigem Code als SYSTEM auf dem Backup-Server. Der Fehler ist Gegenstand nationaler CERT-Warnmeldungen weltweit, darunter HK, CERT.be, and CERT-In. Veeam empfiehlt ein Upgrade auf Version 12.3.1, um die Schwachstelle zu beheben. 

Greenbone kann anfällige NAKIVO- und Veeam-Instanzen erkennen. Unser Enterprise Feed verfügt über eine aktive Prüfung und Versionsprüfung für CVE-2024-48248 in NAKIVO Backup & Replication sowie über einen Remote-Versions-Check für den Softwarefehler in Veeam.

IngressNightmare: Unauthentifizierte Übernahme in 43 % der Kubernetes-Cluster

Kubernetes ist das weltweit beliebteste Tool zur Container-Orchestrierung in Unternehmen. Seine Ingress-Funktion ist eine Netzwerkkomponente, die den externen Zugriff auf Dienste innerhalb eines Clusters verwaltet, in der Regel HTTP- und HTTPS-Traffic. Eine Schwachstelle namens IngressNightmare hat schätzungsweise 43 % der Kubernetes-Cluster einem nicht authentifizierten Fernzugriff ausgesetzt – annähernd 6.500 Cluster, darunter auch Fortune-500-Unternehmen. 

Die Ursache sind überzogene Standardberechtigungen [CWE-250] und uneingeschränkter Netzwerkzugang [CWE-284] im Ingress-NGINX-Controller-Tool, das auf dem NGINX Reverse Proxy basiert. IngressNightmare ermöglicht es Angreifern, die vollständige und unbefugte Kontrolle über Workloads, APIs oder sensible Daten in Multi-Tenant- und Produktiv-Clustern zu erlangen. Eine vollständige technische Analyse ist bei den Forschern von Wiz erhältlich, die darauf hinweisen, dass Kubernetes-Admission-Controller standardmäßig ohne Authentifizierung direkt zugänglich sind und Hackern eine attraktive Angriffsfläche bieten.

Der vollständige Angriffsverlauf, um eine beliebige RCE gegen eine betroffene K8-Instanz zu erreichen, erfordert die Ausnutzung von Ingress-NGINX; zunächst CVE-2025-1974 (CVSS 9.8), um eine binäre Datenlast als Anfragetext hochzuladen. Sie sollte größer als 8 KB sein, während ein Content-Length-Header angegeben wird, der größer als die tatsächliche Inhaltsgröße ist. Dadurch wird NGINX veranlasst, den Anfragetext als Datei zu speichern, und der falsche Content-Length-Header bedeutet, dass die Datei nicht gelöscht wird, da der Server auf weitere Daten wartet [CWE-459].

In der zweiten Phase dieses Angriffs müssen CVE-2025-1097, CVE-2025-1098 oder CVE-2025-24514 (CVSS 8.8) ausgenutzt werden. Diese CVEs versagen alle in ähnlicher Weise bei der ordnungsgemäßen Bereinigung von Eingaben [CWE-20], die an Admission Controller übermittelt werden. Ingress-NGINX konvertiert Ingress-Objekte in Konfigurationsdateien und validiert sie mit dem Befehl nginx -t, sodass Angreifer eine begrenzte Anzahl von NGINX-Konfigurationsanweisungen ausführen können. Forscher fanden heraus, dass das Modul ssl_engine so angestoßen werden kann, dass es die in der ersten Phase hochgeladene Binärnutzlast der gemeinsam genutzten Bibliothek lädt. Obwohl die Ausnutzung nicht trivial ist und noch kein öffentlicher PoC-Code existiert, werden erfahrene Bedrohungsakteure die technische Analyse leicht in effektive Exploits umwandeln können.

Das Canadian Centre for Cyber Security hat eine CERT-Empfehlung (AV25-161) für IngressNightmare herausgegeben. Die gepatchten Ingress-NGINX-Versionen 1.12.1 und 1.11.5 sind verfügbar, und Anwender sollten so schnell wie möglich upgraden. Wenn ein Upgrade des Ingress NGINX Controllers nicht sofort möglich ist, können vorübergehende Zwischenlösungen helfen, das Risiko zu verringern. Strenge Netzwerkrichtlinien können den Zugriff auf die Admission Controller eines Clusters einschränken, sodass nur der Kubernetes API Server zugänglich ist. Alternativ kann die Admission Controller-Komponente von Ingress-NGINX vollständig deaktiviert werden.

Greenbone ist in der Lage, IngressNightmare-Schwachstellen mit einem aktiven Test zu erkennen, der das Vorhandensein aller oben genannten CVEs [1][2] überprüft.

CVE-2025-29927: Next.js Framework unter Beschuss

Eine neue Schwachstelle in Next.js, CVE-2025-29927 (CVSS 9.4), wird aufgrund der Beliebtheit des Frameworks und der Einfachheit der Ausnutzung als hohes Risiko eingestuft [1][2]. Das Risiko wird dadurch erhöht, dass Exploit Code als PoC öffentlich verfügbar ist und Forscher von Akamai bereits aktive Scans beobachtet haben, die das Internet nach anfälligen Apps durchsuchen. Mehrere nationale CERTs (Computer Emergency Response Teams) haben Warnmeldungen zu diesem Problem herausgegeben, darunter CERT.NZ, Australian Signals Directorate (ASD), das deutsche BSI Cert-Bund (WID-SEC-2025-062) und das kanadische Centre for Cyber Security (AV25-162).

Next.js ist ein React-Middleware-Framework für die Erstellung von Full-Stack-Webanwendungen. Middleware bezieht sich auf Komponenten, die zwischen zwei oder mehr Systemen sitzen und die Kommunikation und Orchestrierung übernehmen. Bei Webanwendungen wandelt Middleware eingehende HTTP-Anfragen in Antworten um und ist oft auch für die Authentifizierung und Autorisierung verantwortlich. Aufgrund von CVE-2025-29927 können Angreifer die Authentifizierung und Autorisierung der Next.js-Middleware umgehen, indem sie einfach einen schädlichen HTTP-Header setzen.

Wenn die Verwendung von HTTP-Headern für die Verwaltung des internen Prozessablaufs einer Webanwendung eine schlechte Idee zu sein scheint, ist CVE-2025-29927 der Beweis dafür. Da benutzerseitige Header nicht korrekt von internen Headern unterschieden wurden, sollte diese Schwachstelle den Status von eklatanter Fahrlässigkeit erhalten. Angreifer können die Authentifizierung umgehen, indem sie einfach den Header „x-middleware-subrequest“ zu einer Anfrage hinzufügen und ihn mit mindestens so vielen Werten wie der MAX_RECURSION_DEPTH (5) überladen. Zum Beispiel:

„x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware“

Der Fehler wurde in den Next.js-Versionen 15.2.3, 14.2.25, 13.5.9 und 12.3.5 behoben. Benutzer sollten den Upgrade-Leitfaden des Anbieters befolgen. Wenn ein Upgrade nicht möglich ist, wird empfohlen, den Header „x-middleware-subrequest“ aus den HTTP-Anfragen zu filtern. Greenbone ist in der Lage, anfällige Instanzen von Next.js mit einer aktiven Überprüfung und einer Versionsprüfung zu erkennen.

Zusammenfassung

Die Bedrohungslandschaft im März 2025 war geprägt von anfälligen und aktiv ausgenutzten Backup-Systemen, unverzeihlich schwacher Authentifizierungslogik, hohen Bußgeldern und zahlreichen anderen kritischen Software-Schwachstellen. Vom Angriff auf das US-Finanzministerium bis hin zu den Folgen der Ransomware Advanced ist das Thema klar: Vertrauen fällt nicht vom Himmel. Die Widerstandsfähigkeit gegenüber Cyberkriminalität muss verdient werden; sie muss durch mehrstufige Sicherheitskontrollen gefestigt und durch Verantwortlichkeit untermauert werden. 

Greenbone spielt weiter eine entscheidende Rolle mit der Bereitstellung zeitnaher Erkennungstests für neu auftretende Bedrohungen und standardisierter Compliance-Audits, die eine Vielzahl von Unternehmensarchitekturen unterstützen. Organisationen, die der Cyberkriminalität immer einen Schritt voraus sein wollen, müssen ihre Infrastruktur proaktiv scannen und Sicherheitslücken schließen, sobald sie auftreten.

Schwachstellen in IT-Umgebungen treten in vielen Varianten auf. Die häufigsten sind wahrscheinlich nicht gepatchte Software-Schwachstellen. Dann gibt es schwache Passwörter, Fehlkonfigurationen oder Netzwerk-Switches, die seit fünf Jahren veraltet sind. Eine eigene Art von Sicherheitslücke sorgt jedoch manchmal für erhebliche Verwirrung bei den Scans: Hardware-Schwachstellen.

Wir haben uns an das ständige Auftauchen von Software-Schwachstellen gewöhnt, und hoffentlich ist es mittlerweile für jedes Unternehmen Standard, sein Netzwerk regelmäßig auf Schwachstellen zu scannen und Patches zu installieren. Leider sind Fehler nicht auf Softwareentwickler beschränkt – auch CPU-Entwickler sind nicht davor gefeit. Schwachstellen in Prozessoren entstehen oft durch Designfehler, die es böswilligen Akteuren ermöglichen, unbeabsichtigte Nebeneffekte auszunutzen, um auf sensible Daten zuzugreifen. Im Gegensatz zu Software-Schwachstellen, die sich oft durch Patches oder Updates beheben lassen, erfordern Hardware-Schwachstellen entweder sogenannte Microcode-Updates oder auch grundlegende architektonische Änderungen bei zukünftigen Prozessordesigns.

Microcode-Updates

Die einzige Möglichkeit, CPU-Schwachstellen zu beheben, ist die Anwendung von Microcode-Updates, die in der Regel über das Betriebssystem oder manchmal sogar über die Firmware (UEFI/BIOS) verteilt werden. Microcode ist eine Low-Level-Software-Schicht innerhalb des Prozessors, die höherwertige Maschinenbefehle in spezifische interne Operationen übersetzt.

Obwohl Endanwender den Mikrocode normalerweise nicht selbst aktualisieren, bieten Hersteller wie Intel entsprechende Updates an, um bestimmte Schwachstellen zu beheben, ohne dass ein vollständiger Austausch der Hardware erforderlich ist. Diese Updates führen jedoch häufig zu Einbußen bei der Performance, da sie bestimmte CPU-Optimierungen deaktivieren oder ändern, um eine Ausnutzung zu verhindern. In einigen Fällen kann dies sogar zu Leistungseinbußen von bis zu 50 % führen.

Fehler auf verschiedenen Ebenen

Da diese Schwachstellen auf CPU-Ebene bestehen, werden sie von Tools wie der Greenbone Enterprise Appliance erkannt und gemeldet. Dies kann jedoch zu Missverständnissen führen, da Benutzer fälschlicherweise glauben könnten, dass die gemeldeten Schwachstellen vom Betriebssystem stammen. Es ist wichtig zu verstehen, dass es sich hierbei nicht um Schwachstellen des Betriebssystems handelt, sondern um Architekturfehler im Prozessor selbst.

Die Schwachstellen werden erkannt, indem bei der Identifizierung einer betroffenen CPU überprüft wird, ob entsprechende Microcode-Patches vorhanden sind. Wenn ein Scan beispielsweise ein System erkennt, dem das Intel-Mikrocode-Update für Downfall fehlt, wird es als anfällig gemeldet. Dies bedeutet jedoch nicht, dass das Betriebssystem selbst unsicher oder gefährdet ist.

Leistung oder Sicherheit?

Die Behandlung von CPU-Schwachstellen ist immer mit Kompromissen verbunden, und Benutzer müssen entscheiden, welcher Ansatz ihren Anforderungen am besten entspricht. Drei Möglichkeiten stehen prinzipiell zu Auswahl:

  • Mikrocode-Updates anwenden und erhebliche Leistungseinbußen bei rechenintensiven Arbeitslasten in Kauf nehmen.
  • Auf bestimmte Microcode-Updates verzichten und die Risiken in Kauf nehmen, wenn die Wahrscheinlichkeit einer Ausnutzung in ihrer Umgebung gering ist.
  • Die betroffene Hardware durch CPUs ersetzen, die nicht anfällig für diese Probleme sind.

Letztendlich hängt die Entscheidung vom spezifischen Anwendungsfall und der Risikotoleranz der Organisation oder auch der einzelnen Verantwortlichen ab.

Eine Sicherheitslücke der höchsten Gefahrenstufe – CVE-2024-54085, bewertet mit CVSS 10 – ist soeben bekannt geworden. Sie steckt in der weit verbreiteten Software MegaRAC BMC (Baseboard Management Controller) von American Megatrends (AMI) und erlaubt es Angreifern, Authentifizierungsmechanismen zu umgehen und in Systeme einzudringen. AMI ist ein dominanter Player in der Lieferkette für Mainboards – und damit sind potenziell Dutzende namhafter Hardwareanbieter betroffen. Nebst einer ausführlichen technischen Erklärung liegt ein Proof-of-Concept (PoC) bereits vor. Damit ist klar: Die Sicherheitslücke ist nicht mehr nur ein theoretisches Risiko.

Mit dem PoC können Angreifer einen Service Account für die Redfish-Managementkonsole erstellen und damit einen nicht authentifizierten Zugriff auf alle Remote-BMC-Funktionen erhalten. Der Exploit wurde auf HPE Cray XD670, Asus RS720A-E11-RS24U und ASRockRack verifiziert. Andere Analysten haben festgestellt, dass diese CVE zwar im Jahr 2025 veröffentlicht wurde, ihre ID (CVE-2024-54085) aber wahrscheinlich bereits im Jahr 2024 reserviert wurde.

CVE-2024-54085 ermöglicht einem Angreifer:

  • einen Server zu kapern und fernzusteuern
  • Malware auf dem Server zu installieren, einschließlich Ransomware
  • die Firmware für Manipulationen zu ändern
  • Motherboard-Komponenten (BMC oder auch BIOS/UEFI) möglicherweise zu blockieren
  • physischen Schaden durch Überspannung zu verursachen
  • endlose Neustartschleifen einzubringen, die Denial of Service (DoS) hervorrufen

Greenbone kann betroffene Server mit einem Remote-Schwachstellentest erkennen, der aktiv nach einem anfälligen BMC sucht.

Potenzielles Ausmaß der Auswirkungen

Die spezielle Schnittstelle für den MegaRAC BMC, genannt Redfish, ist nur eine von mehreren BMCs, die das Remote-Servermanagement unterstützen. Der Redfish-Standard hat sich auf dem Markt für Unternehmensserver als moderner Ersatz für veraltete Verwaltungsschnittstellen wie IPMI durchgesetzt. Die Auswirkungen werden alle Produkte betreffen, einschließlich OT-, IoT- oder IT-Geräte, die AMIs MegaRAC verwenden. Als früher schon einmal ähnliche Fehler in MegaRAC entdeckt wurden, wirkte sich das auf die Produkte vieler Hersteller aus – angefangen bei Asus, Dell, Gigabyte, Hewlett Packard Enterprise, Lanner und Lenovo, bis zu NVIDIA und Tyan. AMI veröffentlichte am 11. März 2025 Patches, während HPE und Lenovo bereits Updates für die betroffenen Produkte herausgaben.

CVE-2024-54085 technisch gesehen

CVE-2024-54085 ist ein Fehler im SPx-Firmware-Stack (Service Processor) von AMI. Genauer gesagt ist SPx Teil der MegaRAC BMC-Lösung von AMI. BMCs sind Mikrocontroller, die auf der Hauptplatine eines Servers eingebettet sind und Remote Management und Monitoring des Servers ermöglichen, selbst wenn das System ausgeschaltet ist oder nicht reagiert.

CVE-2024-54085 wird als „Authentication Bypass by Spoofing“-Schwachstelle [CWE-290] eingestuft. Die Verwendung der IP-Adresse eines Clients zur Authentifizierung ist ein typisches Szenario, wenn CWE-290 auftritt, da die Quell-IP-Adresse oft vom Absender gefälscht werden kann. Obwohl AMIs Empfehlung nur wenige Details enthält, haben die Forscher von Eclypsium, denen die Entdeckung zugeschrieben wird, einen ausführlichen Artikel zur Erklärung der Ursachen bereitgestellt. CVE-2024-54085 ist in der Tat auf die Verwendung einer IP-Adresse als Authentifizierungsmittel zurückzuführen. Die Lua-basierte Zugriffskontrolllogik von Redfish verwendet HTTP-Header, nämlich entweder den X-Server-Addr-Header oder die Host-Spezifikation, um festzustellen, ob ein HTTP-Request in- oder extern ist, während interne Requests automatisch als authentifiziert gelten.

In BMC-Systemen wie MegaRAC bezieht sich die „Host-Schnittstelle“ auf eine logische und physische Verbindung zwischen dem BMC und dem Hauptserversystem (dem Host). Der Einfachheit halber könnte dies mit der Loopback-Schnittstelle (oft lo genannt) mit der IP-Adresse 127.0.0.1 und dem Hostnamen localhost verglichen werden. In diesem Fall wird der Schnittstelle, die zwischen dem BMC-Chip und dem Host kommuniziert, eine Adresse aus dem Link-Local-IP-Bereich (169.254.0.0 bis 169.254.255.255) zugewiesen. Darüber hinaus ist diese IP-Adresse während des HTTP-Authentifizierungsprozesses von MegaRAC in einer Liste vertrauenswürdiger Adressen enthalten, und ein erfolgreiches Spoofing dieser Adresse führt zu einer Umgehung der Authentifizierung. Durch Reverse Engineering der MegaRAC-Firmware entdeckten Forscher, dass die Link-Local-Adresse 169.254.0.17 auf mehreren BMC-Chips verwendet wird.

Der Fehler hängt auch von der Implementierung eines regulären Ausdrucks ab, der den gesamten Text aus dem X-Server-Addr-Header vor dem ersten Doppelpunkt extrahiert und überprüft, ob dieser Text mit den in einer Redis-Datenbank gespeicherten vertrauenswürdigen IPs übereinstimmt. Die BMC-Chips verwenden Lighttpd als eingebetteten Webserver, der automatisch seinen eigenen X-Server-Addr-Wert hinzufügt. Wenn ein Request bereits diesen vom Client bereitgestellten Header enthält, hängt Lighttpd seinen Wert an den vom Benutzer bereitgestellten Wert an, sodass der Angreifer einen speziell gestalteten Header bereitstellen und den von der Regex extrahierten Wert manipulieren kann. Durch die Bereitstellung eines X-Server-Addr-Werts, der mit der Link-Local-Adresse des Hostsystems übereinstimmt, gefolgt von einem Doppelpunkt (z. B. 169.254.0.17:), kann ein Angreifer den BMC dazu verleiten, die Anfrage so zu behandeln, als käme sie von der internen Host-Schnittstelle, wodurch die Authentifizierung vollständig umgangen wird.

Sobald die Authentifizierung umgangen wurde, wird der Rest der HTTP-Anfrage verarbeitet, sodass der Angreifer beliebige API-Aktionen ausführen kann, z. B. das Erstellen privilegierter Konten, um remote die vollständige Kontrolle über den BMC des Servers zu erlangen und auf dessen Admin-Weboberfläche zuzugreifen.

Schritte zur Eindämmung von CVE-2024-54085

Unternehmen müssen die Hinweise ihrer Hardware-Anbieter genau verfolgen und die richtigen Firmware-Updates herunterladen, sobald sie verfügbar sind. Als vorübergehende Schutzmaßnahme können Unternehmen in ihren Gerätehandbüchern nachsehen, ob Redfish deaktiviert werden kann, wenn es nicht verwendet wird. Da BMCs auch dann aktiv bleiben können, wenn der Hauptserver ausgeschaltet ist, müssen betroffene Systeme als dauerhaft gefährdet behandelt werden, bis die Firmware gepatcht ist, es sei denn, Redfish ist deaktiviert oder das System ist auch vom Netzwerk getrennt (Air-Gap). Sicherheitsteams können auch neue Firewall- oder IPS-Regeln entwickeln, um Versuche zu blockieren, diese Schwachstelle auszunutzen, und anfällige BMC-Managementschnittstellen zu schützen.

Da der Fehler in einer eingebetteten proprietären Firmware liegt, ist das Patchen komplexer als das einfache Anwenden eines routinemäßigen Betriebssystem- oder Anwendungsupdates. Im Gegensatz zu herkömmlicher Software befindet sich die BMC-Firmware auf dem dedizierten Chip des Motherboards. Daher erfordern BMC-Updates in der Regel ein spezielles Software-Utitlity, das vom Gerätehersteller bereitgestellt wird, um die aktualisierte Firmware zu „flashen“. Dieser Prozess führt auch zu Ausfallzeiten, da Administratoren möglicherweise in eine spezielle Umgebung booten und das System nach Abschluss des Firmware-Updates neu starten müssen.

Zusammenfassung

CVE-2024-54085 stellt ein extremes Risiko für die Unternehmensinfrastruktur dar, da es die nicht authentifizierte Fernsteuerung von Servern großer Anbieter wie HPE und Lenovo ermöglicht. Angesichts der dominierenden Präsenz von AMI in Rechenzentren könnte eine Ausnutzung zu Massenausfällen, unbrauchbarer Hardware oder anhaltenden Ausfallzeiten führen, sodass eine sofortige Erkennung und das Patchen der Firmware für alle betroffenen Systeme unerlässlich sind.

Greenbone ist in der Lage, betroffene Server mit einem Remote-Schwachstellentest zu erkennen, der aktiv nach einer ausnutzbaren BMC-Schnittstelle sucht.

CVE-2024-4577“ (CVSS 9.8 Kritisch) erklimmt soeben das Siegertreppchen der bösesten Sicherheitslücken: Anfang Juni 2024 von den Forschern bei Devcore aufgedeckt, wurde sie in nur 48 Stunden als Waffe eingesetzt. Sie ist eine Command Injection-Schwachstelle [CWE-78] im PHP-CGI OS und betrifft PHP für Windows. Sofort wurden Angriffe beobachtet, die die Ransomware „TellYouThePass“ verbreiteten, während sie als CVE (Common Vulnerabilities and Exposures) in die KEV-Liste (Known Exploited Vulnerabilities) der CISA (Cybersecurity and Infrastructure Security Agency) aufgenommen wurde. Monate später nimmt die Ausnutzung von CVE-2024-4577 plötzlich weiter zu.

Greenbone hat Schwachstellentests (VTs) bereitgestellt, um Systeme zu erkennen, die von CVE-2024-4577 betroffen sind, seit sie im Juni 2024 veröffentlicht wurde. So können Verteidiger betroffene Systeme in öffentlichen oder internen Netzwerkinfrastrukturen identifizieren. Sehen wir uns die Bedrohung durch CVE-2024-4577 genauer an.

So wird CVE-2024-4577 ausgenutzt

PoC-Exploit-Code (Proof of Concept) und eine vollständige technische Aufschlüsselung wurden bereits vor langer Zeit von watchTowr Labs veröffentlicht, ebenfalls Mitte 2024 wurde ein Metasploit-Modul veröffentlicht. Zusätzlich gaben kürzlich das CERT New Zealand (CERT NZ) und das Canadian Center for Cyber Security entsprechende Sicherheitswarnungen heraus. Und bereits im Juni 2024 warnten das CERT-EU und das CERT-FR (CERT der französischen Regierung) vor der Schwachstelle.

Aufgrund der Sicherheitslücke CVE-2024-4577 kann das PHP-CGI (Common Gateway Interface) bestimmte Zeichen als PHP-Parameter fehlinterpretieren, wodurch ein böswilliger Benutzer diese an die Binärdatei php.exe übergeben kann. Mit diesem Trick kann der Quellcode von Skripten offengelegt oder beliebiger PHP-Code auf dem Server ausgeführt werden. CVE-2024-4577 gilt als Umgehung einer bereits vor langer Zeit gepatchten Sicherheitslücke in PHP, nämlich CVE-2012-1823.

Für den Fall, dass sich Angreifer zunächst durch Social Engineering oder eine andere Software-Schwachstelle Zugang zum Netzwerk eines Opfers verschaffen, kann CVE-2024-4577 einem Angreifer die Möglichkeit bieten, sich seitlich zu bewegen oder sich heimlich festzusetzen, tiefer in die Infrastruktur eines Opfers einzudringen und den Aktionsradius eines Cyberangriffs zu vergrößern.

CVE-2024-4577 technisch gesehen

Kurz gesagt, arbeitet die Ausnutzung von CVE-2024-4577 mit der Unicode-Zeichenumwandlung, um bösartige Command-Line-Argumente in den php.exe-Prozess einzuschleusen. Auf einer hohen Ebene verhalten sich Webserver anders, wenn der CGI-Modus aktiviert ist. Normalerweise analysiert ein Webserver HTTP-Anfragen und leitet sie zur Verarbeitung an ein PHP-Skript weiter. Wenn jedoch der CGI-Modus aktiviert ist, werden Attribute aus der URL extrahiert und als Argumente an das ausführbare PHP-Binary (php.exe unter Windows) übergeben. Dieser PHP-CGI-Prozess ist dafür bekannt, dass er deutliche Sicherheitsrisiken birgt.

Obwohl PHP-GCI die Shell-Meta-Zeichen (wie Bindestriche, doppelte Bindestriche, das kaufmännische Und sowie Gleichheitszeichen) vor der Übergabe bereinigen soll, öffnet dies immer noch einen Weg zur Command Injection, wenn Angreifer einen Weg finden, den Bereinigungsprozess zu umgehen. Die PHP-CGI-Kodierung war auch das Ziel des Angriffs auf CVE-2012-1823. Darüber hinaus werden ständig ähnliche Kämpfe um die Zeichenkodierung ausgetragen, die den Angreifern neue Möglichkeiten zur Ausführung von XSS- und SQL-Injection-Schwachstellen bieten.

In der aktuellen Iteration dieses Angriffs können Angreifer unter Verwendung eines weichen Bindestrichs (0xAD) anstelle eines Standard-Bindestrichs (0x2D) PHP-Direktiven initiieren, um Remote Code Execution (RCE) zu erreichen. Dies liegt daran, dass Windows den UCS-2-Zeichensatz verwendet, alle Zeichen in den UCS-2-Codepunktwert konvertiert und außerdem eine zusätzliche „Best-Fit“-Konvertierung durchführt. Im Fall von CVE-2024-4577 ist es das Best-Fit-Schema, das weiche Bindestriche in Standard-Bindestriche umwandelt. Dadurch kann php.exe mit Argumenten injiziert werden, um den HTTP-Anfragekörper selbst voranzustellen und auszuführen, indem der Befehl „-d allow_url_include=1 -d auto_prepend_file=php://input“ mit URL-kodierten weichen Bindestrichen zum HTTP-GET-String hinzugefügt wird. Weiche Bindestriche sind in der Regel unsichtbare UTF-8-Zeichen, die zur Angabe von Wortumbrüchen an bestimmten Stellen verwendet werden, aber nur, wenn dies notwendig ist, damit der Text in die Zeile passt. Dank der Best-Fit-Konvertierung von Windows werden sie effektiv in Befehlszeilen-Flags umgewandelt.

CVE-2024-4577 wird dieses Jahr weltweit ausgenutzt

Neuen Berichten zufolge, die im März 2025 veröffentlicht wurden, sind Angriffe, die CVE-2024-4577 ausnutzen, kontinuierlich, weit verbreitet und eskalieren. Cisco entdeckte im Januar 2025 eine Ausnutzung von CVE-2024-4577, die auf japanische Unternehmen aus den Bereichen Bildung, E-Commerce und Telekommunikation abzielte. Nachdem sie sich zunächst über PHP Zugang verschafft hatten, installierten die Angreifer die „TaoWu“-Plugins von Cobalt Strike und änderten Windows Registry-Schlüssel, um über geplante Aufgaben dauerhaften Zugang zu erhalten.

Ein weiterer aktueller Bericht von GreyNoise zeigt, dass sich die massenhafte Ausnutzung von CVE-2024-4577 auf Ziele in den USA, Großbritannien, Singapur, Indonesien, Taiwan, Hongkong, Indien, Spanien und Malaysia ausgeweitet hat. Deutschland und China waren Berichten zufolge die Hauptquellen der Angriffe, die weltweit 43 % ausmachten. GreyNoise unterhält auch ein Honignetz, das allein im Januar 2025 über 1.089 eindeutige IPs mit Exploit-Versuchen entdeckte und 79 öffentlich verfügbare, spezialisierte Exploit-Kits zählte. Das Cybersicherheitsunternehmen warnte vor einem wachsenden Angriffsvolumen im Februar 2025, das durch automatisiertes Scannen angetrieben wird und auf eine schnell eskalierende Cyberbedrohung hinweist.

Abhilfe für CVE-2024-4577

CVE-2024-4577 betrifft alle PHP-Versionen (einschließlich PHP 5 und PHP 7, die am Ende ihrer Lebensdauer sind) vor 8.1.29, 8.2.20 und 8.3.8 unter Windows. Die beste Abhilfemaßnahme ist ein schnelles Upgrade auf eine gepatchte Version. In Umgebungen, in denen ein sofortiges Patchen nicht möglich ist, können Verteidiger die Ausführung des PHP-CGI-Modus zugunsten von PHP-FPM (FastCGI Process Manager) deaktivieren oder alternativ eine Web-Application-Firewall (WAF) einsetzen, um Angriffe zu filtern und zu blockieren. PHP-Systemadministratoren sollten auch einige zusätzliche Sicherheitsrisiken, die mit CGI verbunden sind, beachten und sie auf optimale Sicherheit überprüfen.

Greenbone hat Schwachstellentests (VTs) zur Verfügung gestellt, um Systeme zu erkennen, die von CVE-2024-4577 betroffen sind, seit es im Juni 2024 erstmals veröffentlicht wurde. Diese Früherkennungsfunktion ermöglicht es Verteidigern, betroffene Systeme in öffentlichen oder internen Netzwerken zu identifizieren. Die Erkennungstests von Greenbone umfassen Remote-Versionserkennungen [1][2] und eine aktive Remote-Prüfung [3].

Zusammenfassung

CVE-2024-4577 ist eine kritische PHP-CGI-Schwachstelle, die PHP-Installationen unter Windows betrifft und die RCE ermöglicht. Die Schwachstelle wurde innerhalb von 48 Stunden nach ihrer Offenlegung als Waffe eingesetzt und in TellYouThePass-Ransomware-Angriffen verwendet. Berichten von Cisco und GreyNoise zufolge ist die massenhafte Ausnutzung von CVE-2024-4577 weltweit eskaliert, und es wurden mehrere nationale CERT-Hinweise herausgegeben. Verteidiger müssen herausfinden, wo in ihrer Infrastruktur betroffene Produkte eingesetzt werden, und sofort auf eine korrigierte Version von PHP aktualisieren, PHP-CGI vollständig deaktivieren oder auf PHP-FPM (FastCGI Process Manager) umstellen.

Zwei neue Sicherheitslücken in Apache Camel sollten von Anwendern sofort beachtet werden. Am 9. März 2025 veröffentlichte Apache die Schwachstelle CVE-2025-27636 (CVSS 5.6), eine CVE (Common Vulnerabilities and Exposures) für die Remote Code Execution (RCE). Zwei Tage später, am 11. März, meldete die Security Intelligence Group (SIG) von Akamai eine Technik zur Umgehung des ursprünglichen Patchs, woraufhin CVE-2025-29891 (CVSS 4.2) am 12. März veröffentlicht wurde.

Grüne Grafik mit stilisiertem Kamel in einer Wüstenlandschaft. Rechts daneben ein Button mit der Aufschrift ‚RCE in Apache Camel‘.

Obwohl die beiden Schwachstellen vom Authorized Data Publisher (ADP) der Cybersecurity and Infrastructure Security Agency (CISA) nur mit moderaten CVSS-Scores bewertet wurden, können sie je nach Konfiguration der betroffenen Camel-Instanz schwerwiegende Auswirkungen haben. Beide CVEs haben dieselbe Ursache: eine unsachgemäße Filterung von HTTP-Headern oder HTTP-Parametern bei der Kommunikation mit einer Apache-Camel-Instanz. Wie im Titel angedeutet, geht es um die Groß- und Kleinschreibung. Während diese beim Filtern der Parameter berücksichtigt wurde, wurden die Argumente selbst ohne Berücksichtigung der Groß- und Kleinschreibung angewendet. Darüber hinaus tragen der öffentlich verfügbare PoC-Code (Proof of Concept) und eine relativ vollständige technische Beschreibung zu dem Risiko bei.

Greenbone kann sowohl CVE-2025-27636 als auch CVE-2025-29891 mit Schwachstellentests erkennen, die aktiv nach ausnutzbaren HTTP-Endpunkten suchen. Schauen wir uns die Details an.

Was ist Apache Camel?

Apache Camel ist eine beliebte Open-Source-Java-Bibliothek zur Integration verschiedener Komponenten einer verteilten Unternehmenssystemarchitektur wie APIs oder Microservices. Sie stellt eine vielseitige Plattform für Routing und Datenvermittlung dar, die auf dem Konzept der Enterprise Integration Patterns (EIPs) für das Architekturdesign von Unternehmenssystemen basiert. Apache Camel baut auf EIPs auf und bietet Möglichkeiten zur Implementierung dieser Muster über die domänenspezifischen Sprachen (DSL), die Java, XML, Groovy, YAML und andere umfassen.

Im Jahr 2021 hatte Apache Camel einen Anteil von 3,03 % am Markt für Enterprise Application Integration. Die Software wird von über 5.600 Unternehmen eingesetzt, von denen etwa die Hälfte in den USA ansässig ist. Vertreten ist Camel vor allem bei IT-Technologie- und Dienstleistungen (33 %), in der Softwarebranche (12 %) und bei Finanzdienstleistungen (6 %).

Zwei CVEs in Apache Camel erlauben Header-Injection

Wenn eine der HTTP-basierten Komponenten von Camel Anfragen bearbeitet, soll ein Standardfilter die Offenlegung sensibler Daten oder die Ausführung interner Befehle verhindern. Aufgrund einer fehlerhaften Filterregel, die zwischen Groß- und Kleinschreibung unterscheidet, wurden jedoch nur exakt übereinstimmende Header gefiltert. In der Programmlogik wurden diese Header allerdings nachgelagert ohne Berücksichtigung der Groß- und Kleinschreibung angewendet, wodurch der Filter umgangen werden konnte. Durch die Änderung der Groß- und Kleinschreibung des ersten Zeichens des Headernamens konnte ein Angreifer den Filter umgehen und beliebige Header einschleusen.

Die gute Nachricht ist, dass entweder die camel-bean- oder die camel-exec-Komponente in Kombination mit einer http-basierten Komponente wie camel-http, camel-http4, camel-rest, camel-servlet oder anderen aktiviert werden muss. Außerdem ist die Ausnutzung auf interne Methoden innerhalb des im HTTP-Request-URI angegebenen Bereichs beschränkt. Ein letzter Trost ist, dass diese Schwachstelle nicht als unauthentifizierte Schwachstelle eingestuft wurde. Deshalb ist sie nicht ausnutzbar, wenn die Systementwickler keine Authentifizierung und Autorisierung für eine Camel-HTTP-API implementiert haben.

Am oberen Ende des Risikospektrums kann ein Angreifer, wenn die Camel Exec-Komponente aktiviert und gezielt eingesetzt wird, als Benutzer, der den Camel-Prozess steuert, einen beliebigen RCE ausführen. Dies geschieht, indem der CamelExecCommandExecutable-Header gesendet wird, um einen beliebigen Shell-Befehl anzugeben, der die im Back-End konfigurierten Befehle überschreibt. Wenn die ausnutzbaren Camel-HTTP-APIs über das Internet zugänglich sind, ist das Risiko besonders hoch. Diese Schwachstelle könnte jedoch auch von einem Insider genutzt werden, um sich innerhalb eines Netzwerks seitlich zu bewegen, oder von Angreifern, die sich einen ersten Zugang zum internen Netzwerk einer Organisation verschafft haben.

Eine technische Beschreibung der Exploit-Kette und des Proof of Concept wurde von Akamai zur Verfügung gestellt.

Was ist der geeignete CVSS-Score?

Obwohl CVE-2025-27636 (CVSS 5.6) und CVE-2025-29891 (CVSS 4.2) als mäßig schwer eingestuft wurden, könnten sie kritische Auswirkungen haben, wenn entweder die camel-bean- oder camel-exec-Komponenten in Kombination mit http-basierten Komponenten aktiviert werden. Die Situation macht einige Einschränkungen des CVSS-Scorings (Common Vulnerability Scoring System) deutlich.

Akamai-Forscher berichten, dass die Schwachstelle trivial auszunutzen ist, und haben PoC-Code veröffentlicht, was das Risiko erhöht. Das bedeutet, dass die CVSS-Angriffskomplexität (AC) auf niedrig (L) gesetzt werden sollte. Jedoch hat der CISA-ADP die Angriffskomplexität angesichts dieser Tatsachen als hoch (AC:H) bewertet. Red Hat hat diesen Faktoren Rechnung getragen und den CVSS-Wert für CVE-2025-27636 auf 6,3 erhöht.

Außerdem hat der CISA-ADP für CVE-2025-29891 keine Auswirkungen auf die Vertraulichkeit festgestellt, obwohl die Möglichkeit einer willkürlichen RCE besteht. Wenn jedoch eine Apache Camel-Instanz eine anfällige Konfiguration aufweist, ist eine Bewertung mit hoher Auswirkung für Vertraulichkeit (C), Integrität (I) und Verfügbarkeit (A) gerechtfertigt, wodurch sich die Kritikalität auf CVSS 9.8 erhöht.

Andererseits hat der CISA-ADP den Wert „Keine“ (N) für die erforderlichen Berechtigungen (PR) zugewiesen. Obwohl der PoC von Akamai keine HTTPS-Verbindung oder Authentifizierung verwendet, wäre es äußerst fahrlässig, eine unverschlüsselte und nicht authentifizierte API zu betreiben. Apache Camel unterstützt die Java Secure Socket Extension (JSSE) API für Transport Layer Security (TLS) oder die Verwendung eines KeyCloak Single Sign-On (SSO) Autorisierungsservers. Camel-Instanzen, bei denen eine Form der Client-Authentifizierung aktiviert ist, sind vor einer Ausnutzung geschützt. In den meisten Fällen sollte der PR-Wert auf Niedrig (L) oder Hoch (H) eingestellt werden, was zu einem verminderten CVSS von 7,3 oder 8,8 führt.

Darüber hinaus wurden die CVEs mit dem Scope-Wert Unchanged (UC) versehen. Gemäß der CVSS v3.1 Spezifikation: „Die Scope-Metrik erfasst, ob eine Schwachstelle in einer verwundbaren Komponente Auswirkungen auf Ressourcen in Komponenten außerhalb ihres Sicherheitsbereichs hat.“ Die Ausführung beliebiger Shell-Befehle auf dem kompromittierten System wird normalerweise mit dem Wert Changed (C) bewertet. Wenn der Camel-Prozess dem Linux/Unix-Root oder einem Windows-Administrator-Benutzer gehört, hätte ein Angreifer praktisch unbegrenzte Kontrolle über ein kompromittiertes System. Angesichts der Vielzahl möglicher CVSS-Bewertungen sollten CVE-2025-27636 und CVE-2025-29891 als kritische Sicherheitslücken betrachtet werden, wenn eine Instanz die Konfigurationsanforderungen erfüllt und keine Authentifizierung anwendet.

Behandlung der CVEs in Apache Camel

CVE-2025-27636 und CVE-2025-29891 betreffen Apache Camel Version 4.10 vor 4.10.2, Version 4.8 vor 4.8.5 und Version 3 vor 3.22.4. Benutzer sollten ein Upgrade auf 4.10.2, 4.8.5 oder 3.22.4 durchführen oder eine benutzerdefinierte Header-Filterung mit removeHeader oder removeHeaders in Camel Routes implementieren. Es sollte beachtet werden, dass die Camel Versionen 4.10.0, 4.10.1, 4.8.0 bis 4.8.4 und 3.10.0 bis 3.22.3 immer noch verwundbar sind, obwohl sie als Sicherheitsupdates betrachtet wurden, die den Fehler behoben haben.

Es wird außerdem dringend empfohlen, dass alle HTTP-Endgeräte in einer verteilten Architektur eine starke Authentifizierung verwenden. Für Apache Camel gibt es folgende Optionen: Verwendung der Java Secure Socket Extension (JSSE) API für TLS mit Camel-Komponenten oder Verwendung eines KeyCloak OAuth 2.0 SSO Autorisierungsservers. Für Legacy-Systeme sollte mindestens die HTTP-Basisauthentifizierung konfiguriert werden.

Zusammenfassung

Benutzer von Apache Camel sollten sofort auf die Versionen 4.10.2, 4.8.5 oder 3.22.4 aktualisieren, um die neu veröffentlichten CVEs, die Apache Camel betreffen, zu entschärfen. Alternativ können Sie benutzerdefinierte Header-Filterung mit removeHeader oder removeHeaders in Camel-Routen implementieren. Eine starke Authentifizierung auf allen HTTP-Endpunkten wird ebenfalls dringend empfohlen, um die Sicherheit zu gewährleisten. Apache Camel unterstützt die JSSE API für TLS oder KeyCloak SSO Lösungen. Greenbone kann sowohl CVE-2025-27636 als auch CVE-2025-29891 mit Schwachstellentests erkennen, die aktiv auf ausnutzbare HTTP-Endpunkte prüfen.

Mit den Neuwahlen scheint die NIS2-Umsetzung in Deutschland vorerst gestoppt. Während andere europäische Länder schon bereit sind, müssen deutsche Firmen noch mehrere Monate warten, bis sich Rechtssicherheit einstellt. Dabei ist eigentlich alles gesagt, Vorlagen sind gemacht, doch durch den Regierungswechsel ist ein Neustart notwendig.

Wir haben mit einem der führenden Experten für NIS2 gesprochen: Dennis-Kenji Kipker ist Scientific Director des cyberintelligence.institute in Frankfurt am Main, Professor an der Riga Graduate School of Law und berät regelmäßig als Experte beim Bundesamt für Sicherheit in der Informationstechnologie (BSI) und vielen anderen öffentlichen und wissenschaftlichen Einrichtungen.

Warum hat die Bundesregierung den fertigen NIS2-Entwurf verworfen?

Porträt von Prof. Dr. Dennis-Kenji Kipker, Experte für IT-Recht und Cybersicherheit, im Interview zur Umsetzung der NIS2-Richtlinie

Prof. Dr. Dennis-Kenji Kipker

Kipker: Das liegt am sogenannten Diskontinuitätsprinzip. Genau wie bei der alten Regierung müssen da alle unerledigten Vorhaben archiviert werden. „Aufgrund der vorgezogenen Wahlen konnte das parlamentarische Verfahren zum NIS2UmsuCG nicht abgeschlossen werden“ heißt das im Amtsdeutsch. Im Sinne des Diskontinuitätsprinzips müssen mit der Konstituierung eines neu gewählten Bundestages alle vom alten Bundestag noch nicht beschlossenen Gesetzentwürfe neu eingebracht und verhandelt werden. Da fällt dann auch die bereits geleistete Arbeit zu NIS2 hinten runter. Aber man kann natürlich darauf aufbauen, könnte den fast gleichen Text erneut einbringen.

Wird das geschehen?

Kipker: Es gibt einen internen 100-Tage-Plan aus dem Bundesinnenministerium für die Zeit nach der Wahl. Gerüchten zufolge soll in dem Plan das Thema Cybersecurity sehr hoch aufgehängt sein, und gerade NIS2 soll jetzt sehr schnell umgesetzt werden. Wenn man es schafft, das vor Herbst/Winter 2025 (der eigentlich aktuelle Zeitplan) umzusetzen, vermeidet Deutschland zumindest die Peinlichkeit, hier europäisches Schlusslicht zu werden.

Ist das denn realistisch?

Kipker: Man müsste schon sehr viel recyclen, also trotz Diskontinuitätsprinzip Sachen aus der letzten Legislaturperiode übernehmen. Derzeit scheint es, als wolle das noch amtierende Innenministerium genau das erreichen. Ob das realistisch ist, wissen nur die direkt involvierten Politiker und Amtsträger. 100 Tage scheint mir im Berliner Politikbetrieb da aber schon sehr sportlich, auch wenn alle Beteiligten mitziehen. Man müsste einen Haushalt haben, im aktuellen NIS2UmsuCG-Entwurf Überarbeitungsbedarfe erkennen und angehen, aber auch finalisieren und den deutschen Anwendungsbereich des Gesetzes klarer fassen und an das EU-Recht angleichen. Überdies hat man zum Jahresende 2024 und zu Anfang 2025 noch nach der Expertenanhörung zu NIS2 im Bundestag vieles versucht durchzudrücken, was in Teilen doch eher fraglich ist. Das müsste in jedem Fall politisch neu verhandelt und fachlich bewertet werden.

Was schätzen Sie, wann das kommt?

Kipker: Schwer zu sagen, aber selbst, wenn man die 100-Tage-Frist reißt, sollte das schon machbar sein, eine nationale NIS2-Umsetzung vor dem Winter 2025/2026 fertigzustellen. Aber das ist nur eine sehr vorläufige Annahme, die ich immer wieder mal aus „gewöhnlich gut informierten Kreisen“ höre. Eines der Schlusslichter in der europaweiten Umsetzung werden wir so oder so werden, da ändern auch alle aktuellen Ambitionen nichts mehr dran.

Und wie schaut das in anderen europäischen Ländern aus?

Kipker: Da geschieht gerade auch einiges. Man hat beispielsweise erkannt, dass die unterschiedlichen nationalstaatlichen Umsetzungen von NIS2 zu Reibungsverlusten und Mehraufwänden bei den betroffenen Unternehmen führen – das kommt ja nun nicht wirklich überraschend. Es gibt seit einigen Wochen von der European Union Agency For Cybersecurity (ENISA) einen lesenswerten Bericht, der den Reifegrad und die Kritikalität relevanter NIS2-Sektoren im europäischen Vergleich erläutert und bewertet. „NIS360 soll die Mitgliedstaaten und nationalen Behörden bei der Ermittlung von Lücken und der Priorisierung von Ressourcen unterstützen“, schreibt die EU-Cybersicherheitsbehörde. Und wir als cyberintelligence.institute haben im Auftrag des Schweizer Unternehmens Asea Brown Boveri eine umfassende Studie erstellt, die ebenfalls die EU-weite Umsetzung der NIS2-Richtlinie genauer unter die Lupe nimmt.

Welche zentrale Erkenntnis haben Sie dort gewonnen?

Kipker: Der Comparison Report richtet sich vor allem an transnational agierende Unternehmen, die einen ersten Anlaufpunkt für Cybersecurity-Compliance suchen. Vor allem fehlen zentrale administrativen Zuständigkeiten im Sinne eines „One Stop Shop“, und die auseinanderlaufenden Umsetzungsfristen machen Unternehmen Probleme. Stand Ende Januar hatten nur neun EU-Staaten NIS2 in nationales Recht umgesetzt, während bei 18 weiteren Staaten das Gesetzgebungsverfahren noch nicht abgeschlossen war. Eine weitere zentrale Erkenntnis: Nur weil ich in einem EU-Mitgliedstaat NIS2-konform bin, bedeutet das nicht zwangsläufig, dass dies auch für einen anderen Mitgliedstaat gilt.

Dann ist Deutschland zwar kein Vorreiter, aber auch kein Schlusslicht?

Kipker: Wir sind definitiv nicht vorne dabei, aber wenn wir die nationale Umsetzung noch dieses Jahr schaffen, sind wir vielleicht nicht die letzten, aber doch unter den letzten. Meine Vermutung in dieser Hinsicht ist zurzeit: Erst im vierten Quartal 2025 wird es wirklich belastbare Ergebnisse geben. Es wird also knapp, nicht doch noch die rote Laterne umgehängt zu bekommen. Ob das unserem Anspruch an die Cybersicherheit und digitale Resilienz gerecht werden kann, müssen Politikerinnen und Politiker entscheiden.

Wo können sich betroffene Firmen denn über den aktuellen Stand informieren?

Kipker: Es gibt fortlaufend Veranstaltungen und Beteiligungsmöglichkeiten. Am 18. März beispielsweise findet eine Informationsveranstaltung des BSI statt, wo man auch mal nach den Planungen fragen kann. Dann gibt es im Mai 2025 auch den NIS-2-Congress direkt nebenan bei uns in Frankfurt, für den man übrigens gerade den „anerkanntesten NIS-2 Community Leader“ wählen konnte. Hier wird es mit Sicherheit auch das eine oder andere interessante Informationshäppchen aufzuschnappen geben. Ansonsten: Mich jederzeit gerne anschreiben, wenn es Fragen zu NIS2 gibt!

Cyber-Bedrohungen entwickeln sich in halsbrecherischem Tempo, aber die grundlegenden Schwachstellen, die Angreifer ausnutzen, bleiben auffallend unverändert. Für das Jahr 2025 haben viele Analysten einen Rückblick auf das Jahr 2024 und einen Ausblick auf das Jahr 2025 veröffentlicht. Die Kosten für Cyberverletzungen steigen, aber insgesamt haben sich die Ursachen für Cyberverletzungen nicht geändert. Phishing [T1566] und das Ausnutzen bekannter Software-Schwachstellen [T1190] stehen weiterhin ganz oben auf der Liste. Eine weitere wichtige Beobachtung ist, dass Angreifer öffentliche Informationen immer schneller als Waffe einsetzen und Enthüllungen von CVEs (Common Vulnerabilities and Exposures) innerhalb von Tagen oder sogar Stunden in brauchbaren Exploit-Code umwandeln. Sobald sie in das Netzwerk eines Opfers eingedrungen sind, führen sie ihre präzisen Absichten in der zweiten Phase ebenfalls schneller aus und setzen Ransomware innerhalb von Minuten ein.

In diesem Threat Report gehen wir kurz auf die aufgedeckten Chats der Ransomware-Gruppe Black Basta ein und werfen einen Blick darauf, wie Greenbone vor deren offengelegten Machenschaften schützt. Wir werden auch einen Bericht von Greynoise über die massenhafte Ausnutzung von Schwachstellen, eine neue, aktiv genutzte Schwachstelle in der Zimbra Collaboration Suite und neue Bedrohungen für Edge-Networking-Geräte unter die Lupe nehmen.

Das Zeitalter der tektonischen Technologien

Wenn Sicherheitskrisen wie Erdbeben sind, dann entspricht das globale Technologie-Ökosystem den zugrunde liegenden tektonischen Platten. Dieses Ökosystem lässt sich am besten als das Paläozoikum der Erdgeschichte darstellen. Die rasanten Innovations- und Wettbewerbskräfte des Markts schieben und zerren an der Struktur der IT-Sicherheit wie die kollidierenden Superkontinente von Pangäa; ständige Erdbeben zwingen die Kontinente zu permanenten Verschiebungen.

Völlig neue Computerparadigmen wie die generative KI und das Quantencomputing schaffen Vorteile und Risiken; Vulkane von Wert und instabilem Boden. Globale Regierungen und Tech-Giganten ringen um den Zugang zu den sensiblen persönlichen Daten der Bürger und erhöhen damit die Schwerkraft. Diese Kämpfe haben erhebliche Auswirkungen auf die Privatsphäre und die Sicherheit und beeinflussen letztendlich die Entwicklung der Gesellschaft. Hier sind einige der wichtigsten Kräfte, die die IT-Sicherheit heute destabilisieren:

  • Sich schnell entwickelnde Technologien treiben die Innovation voran und erzwingen den technischen Wandel.
  • Unternehmen sind zum einen gezwungen, sich zu ändern, da Technologien und Standards an Wert verlieren, und zum anderen sind sie motiviert, sich zu ändern, um am Markt fortzubestehen.
  • Der harte Wettbewerb beschleunigt die Produktentwicklung und die Veröffentlichungszyklen.
  • Strategisch geplante Obsoleszenz hat sich als Geschäftsstrategie zur Erzielung finanzieller Gewinne etabliert.
  • Der weit verbreitete Mangel an Verantwortlichkeit für Softwareanbieter hat dazu geführt, dass Leistung Vorrang vor dem Grundsatz „Security First“ hat.
  • Nationalstaaten setzen Waffentechnologien für Cyber Warfare, Information Warfare und Electronic Warfare ein.

Dank dieser Kräfte finden gut ausgestattete und gut organisierte Cyber-Kriminelle eine praktisch unbegrenzte Anzahl von Sicherheitslücken, die sie ausnutzen können. Das Zeitalter des Paläozoikums dauerte 300 Millionen Jahre. Hoffentlich müssen wir nicht so lange warten, bis die Produkthersteller Verantwortung zeigen und sichere Konstruktionsprinzipien anwenden [1][2][3], um sogenannte „unverzeihliche“ Schwachstellen durch Fahrlässigkeit zu verhindern [4][5]. Unternehmen müssen daher technische Flexibilität und effiziente Patch-Management-Programme entwickeln. Ein kontinuierliches, priorisiertes Schwachstellenmanagement ist ein Muss.

Mit Greenbone gegen Black Basta

Durchgesickerte interne Chat-Protokolle der Ransomware-Gruppe Black Basta lassen in die Taktik und die inneren Abläufe der Gruppe blicken. Die Protokolle wurden von einer Person unter dem Pseudonym „ExploitWhispers“ veröffentlicht, die behauptet, die Veröffentlichung sei eine Reaktion auf die umstrittenen Angriffe von Black Basta auf russische Banken, die angeblich zu internen Konflikten innerhalb der Gruppe führten. Seit seinem Auftauchen im April 2022 hat Black Basta Berichten zufolge über 100 Millionen US-Dollar an Lösegeldzahlungen von mehr als 300 Opfern weltweit erhalten. 62 CVEs, auf die in den geleakten Dokumenten verwiesen wird, offenbaren die Taktik der Gruppe zur Ausnutzung bekannter Schwachstellen. Von diesen 62 CVEs unterhält Greenbone Erkennungstests für 61, was 98 % der CVEs abdeckt.

Greynoise-Report über massenhafte Ausnutzung von Schwachstellen

Mass-Exploitation-Angriffe sind vollautomatische Angriffe auf Dienste im Netzwerk, die via Internet zugänglich sind. Diesen Monat hat Greynoise einen umfassenden Bericht veröffentlicht, der die Mass-Exploitation-Landschaft zusammenfasst, einschließlich der 20 wichtigsten CVEs, die von den größten Botnets angegriffen werden (eindeutige IPs) und der Anbieter der am häufigsten angegriffenen Produkte. Hinzu kommen die wichtigsten der in den KEV-Katalog (Known Exploited Vulnerabilities) der CISA (Cybersecurity and Infrastructure Security Agency) aufgenommenen CVEs, die von Botnets ausgenutzt werden. Der Greenbone Enterprise Feed bietet Erkennungstests für 86 % aller CVEs (86 insgesamt), auf die im Bericht verwiesen wird. Wenn nur CVEs berücksichtigt werden, die im Jahr 2020 oder später veröffentlicht wurden (insgesamt 66), deckt unser Enterprise Feed 90 % davon ab.

Weitere Ergebnisse sind:

  • 60 % der CVEs, die bei Massenangriffen ausgenutzt wurden, wurden 2020 oder später veröffentlicht.
  • Angreifer nutzen Schwachstellen innerhalb von Stunden nach ihrer Veröffentlichung aus.
  • 28 % der Schwachstellen in CISA KEV werden von Ransomware-Gruppen ausgenutzt.

Zimbra Collaboration Suite

CVE-2023-34192 (CVSS 9.0) ist eine hoch gefährliche Cross-Site-Scripting (XSS)-Schwachstelle in der Zimbra Collaboration Suite (ZCS) Version 8.8.15. Sie erlaubt authentifizierten Angreifern die Ausführung von beliebigem Code über manipulierte Skripte, die auf die Funktion „/h/autoSaveDraft“ abzielen. Die CISA hat CVE-2023-34192 in ihren KEV-Katalog aufgenommen, was darauf hindeutet, dass die Schwachstelle aktiv in realen Angriffen ausgenutzt wurde. Der PoC-Exploit-Code (Proof of Concept) ist öffentlich verfügbar, sodass auch weniger erfahrene Angreifer hier mitmischen können. CVE-2023-34192 hat seit ihrer Aufdeckung im Jahr 2023 einen sehr hohen EPSS-Score. Für Verteidiger, die EPSS (Exploit Prediction Scoring System) für die Priorisierung von Abhilfemaßnahmen nutzen, bedeutet dies, mit hoher Priorität zu patchen.

Die Zimbra Collaboration Suite (ZCS) ist eine Open-Source-Plattform für Office-Anwendungen, die E-Mail, Kalender, Kontakte, Aufgaben und Tools für die Zusammenarbeit integriert, aber einen Nischenmarktanteil von weniger als 1 % aller E-Mail- und Messaging-Plattformen hält.

„Living on the Edge“: kritische Schwachstellen in Netzwerkgeräten

In unserem monatlichen Threat Report haben wir die anhaltende Bedrohung von Edge-Netzwerkgeräten nachvollzogen. Anfang dieses Monats berichteten wir über das maximale Desaster, das die Auslaufmodelle der Zyxel-Router und -Firewalls heraufbeschwören. In diesem Abschnitt befassen wir uns mit neuen Sicherheitsrisiken, die in die Kategorie „Edge Networking“ fallen. Greenbone verfügt über Erkennungsfunktionen für alle im Folgenden beschriebenen CVEs.

Chinesische Hacker nutzen PAN-OS von Palo Alto für Ransomware

CVE-2024-0012 (CVSS 9.8), eine Sicherheitslücke in Palo Alto PAN-OS, die im November letzten Jahres bekannt wurde, gilt als eine der am häufigsten ausgenutzten Sicherheitslücken des Jahres 2024. Die CVE wird Berichten zufolge auch von staatlich unterstützten chinesischen Bedrohungsakteuren für Ransomware-Angriffe genutzt. Eine weitere neue Schwachstelle, die PAN-OS betrifft, CVE-2025-0108 (CVSS 9.1), wurde erst diesen Monat bekannt gegeben und von der CISA sofort als aktiv ausgenutzt eingestuft. Mit CVE-2025-0108 lässt sich die Authentifizierung in der Webmanagement-Schnittstelle umgehen. Sie kann mit gekoppelt werden mit CVE-2024-9474 (CVSS 7.2), einer separaten Schwachstelle für die Ausweitung von Privilegien, um unauthentifizierte Kontrolle über Root-Dateien in einem ungepatchten PAN-OS-Gerät zu erlangen.

SonicWall flickt kritische, aktiv ausgenutzte Schwachstelle in SonicOS

CVE-2024-53704, eine kritische Sicherheitslücke in SonicWall-Geräten, wurde kürzlich in die KEV-Liste der CISA aufgenommen. Erstaunlicherweise listet die CISA acht CVEs bei SonicWall auf, von denen bekannt ist, dass sie aktiv in Ransomware-Angriffen ausgenutzt werden. Die neue Bedrohung, CVE-2024-53704 (CVSS 9.8) ist eine Schwachstelle, die durch einen unsauberen Authentifizierungsmechanismus [CWE-287] im SSLVPN der SonicOS-Versionen 7.1.1-7058 und älter, 7.1.2-7019 und 8.0.0-8035 von SonicWall entsteht. Sie ermöglicht es Angreifern, die Authentifizierung zu umgehen und aktive SSL-VPN-Sitzungen zu kapern, wodurch sie möglicherweise unbefugten Zugriff auf das Netzwerk erhalten. Eine vollständige technische Analyse ist bei BishopFox verfügbar. In einem Security Advisory von SonicWall werden außerdem weitere CVEs mit hohem Schweregrad in SonicOS genannt, die zusammen mit CVE-2024-53704 gepatcht wurden.

CyberoamOS und EOL XG Firewalls von Sophos aktiv ausgenutzt

Der Security-Anbieter Sophos, der Cyberoam im Jahr 2014 übernommen hat, hat eine Warnung und einen Patch für CVE-2020-29574 herausgegeben. CyberoamOS ist Teil des Produkt-Ökosystems von Sophos. Abgesehen von diesem CVE ist auch die Sophos XG Firewall, die bald auslaufen wird, Gegenstand einer Warnung über eine mögliche aktive Ausnutzung.

  • CVE-2020-29574 (CVSS 9.8): Eine kritische SQL-Injection-Schwachstelle [CWE-89] wurde in der WebAdmin-Schnittstelle von CyberoamOS-Versionen bis zum 4. Dezember 2020 entdeckt. Dieser Fehler ermöglicht es nicht authentifizierten Angreifern, beliebige SQL-Anweisungen aus der Ferne auszuführen und möglicherweise vollständigen administrativen Zugriff auf das Gerät zu erlangen. Es wurde ein Hotfix-Patch veröffentlicht, der auch für einige betroffene End-of-Life (EOL) Produkte gilt.
  • CVE-2020-15069 (CVSS 9.8) ist eine kritische Buffer-Overflow-Schwachstelle in den Sophos XG Firewall-Versionen 17.x bis v17.5 MR12, die nicht authentifizierte Remote Code Execution (RCE) über die HTTP/S-Lesezeichen-Funktion für den clientlosen Zugriff ermöglicht. Diese 2020 veröffentlichte Sicherheitslücke wird nun aktiv ausgenutzt und wurde in die CISA KEV aufgenommen, was auf ein erhöhtes Risiko hinweist. Sophos veröffentlichte 2020, als die Sicherheitslücke bekannt wurde, einen Hinweis zusammen mit einem Hotfix für betroffene Firewalls. Die Hardware-Appliances der XG-Serie werden voraussichtlich bald, am 31. März 2025, das Ende ihrer Lebensdauer (EOL) erreichen.

PrivEsc- und Auth-Umgehungen in Fortinet FortiOS und FortiProxy

Fortinet hat zwei kritische Sicherheitslücken bekannt gegeben, die beide FortiOS und FortiProxy betreffen. Das Canadian Center for Cybersecurity und das Belgian Center for Cybersecurity haben Hinweise veröffentlicht. Fortinet räumt ein, dass CVE-2024-55591 aktiv ausgenutzt wird, und hat eine offizielle Anleitung veröffentlicht, die Details zu den betroffenen Versionen und empfohlenen Updates enthält.

  • CVE-2024-55591 (CVSS 9.8): Ein Authentication Bypass unter Verwendung eines alternativen Pfads oder Kanals [CWE-288], die FortiOS betrifft, ermöglicht es einem Angreifer, remote über manipulierte Anfragen an das Node.js-Websocket-Modul Super-Admin-Rechte zu erlangen. Es stehen mehrere PoC-Exploits zur Verfügung [1][2], die das Risiko einer Ausnutzung durch weniger erfahrene Angreifer erhöhen.
  • CVE-2024-40591 (CVSS 8.8): Ermöglicht es einem authentifizierten Administrator mit Security Fabric-Berechtigungen, seine Privilegien zum Super-Administrator zu erweitern, indem er das betroffene FortiGate-Gerät mit einem kompromittierten Upstream-FortiGate unter seiner Kontrolle verbindet.

Cisco-Schwachstellen als erste Zugangsvektoren bei Telekom-Hacks

In den letzten Monaten hat die chinesische Spionagegruppe Salt Typhoon routinemäßig mindestens zwei kritische Schwachstellen in Cisco IOS XE-Geräten ausgenutzt, um sich dauerhaft Zugang zu Telekommunikationsnetzen zu verschaffen. Zu den Opfern gehören italienische ISPs, eine südafrikanische und eine große thailändische Telekommunikationsgesellschaft sowie zwölf Universitäten weltweit, darunter die UCLA, die indonesische Universitas Negeri Malang und die mexikanische UNAM. Zuvor hatte Salt Typhoon mindestens neun US-amerikanische Telekommunikationsunternehmen angegriffen, darunter Verizon, AT&T und Lumen Technologies. Die US-Behörden behaupten, Salt Typhoons Ziel sei die Überwachung von hochrangigen Personen, politischen Persönlichkeiten und Beamten, die mit chinesischen politischen Interessen in Verbindung stehen.

Zu den CVEs, die von Salt Typhoon ausgenutzt werden, gehören:

  • CVE-2023-20198 (CVSS 10): Eine Schwachstelle zur Privilegien-Erweiterung in der Web-Schnittstelle von Cisco IOS XE. Sie wird für den anfänglichen Zugriff verwendet und ermöglicht es Angreifern, ein Admin-Konto zu erstellen.
  • CVE-2023-20273 (CVSS 7.2): Eine weitere Schwachstelle, die zur Erweiterung von Privilegien führt. Nach Erlangung des Admin-Zugriffs wird sie dazu genutzt, den privilegierten Zugriff auf Root-Dateien zu erweitern und einen GRE-Tunnel (Generic Routing Encapsulation) für den dauerhaften Verbleib im Netzwerk einzurichten.

Außerdem wurden im Februar 2025 zwei weitere CVEs in Cisco-Produkten bekannt:

  • CVE-2023-20118 (CVSS 7.2): Eine Command-Injection-Schwachstelle in der webbasierten Management-Oberfläche von Cisco Small Business Routern erlaubt es authentifizierten, entfernten Angreifern, beliebige Befehle mit Root-Rechten auszuführen, indem sie manipulierte HTTP-Anfragen senden. Die CISA hat CVE-2023-20118 in ihren KEV-Katalog aufgenommen, was darauf hindeutet, dass die Schwachstelle aktiv ausgenutzt wird.
  • CVE-2023-20026 (CVSS 7.2): Eine Command-Injection-Schwachstelle in der webbasierten Management-Oberfläche der Cisco Small Business Router der RV042-Serie erlaubt authentifizierten, entfernten Angreifern mit gültigen administrativen Anmeldeinformationen, beliebige Befehle auf dem Gerät auszuführen. Die Schwachstelle ist auf eine unsachgemäße Validierung von Benutzereingaben in eingehenden HTTP-Paketen zurückzuführen. Es ist zwar nicht bekannt, dass CVE-2023-20026 in aktiven Kampagnen ausgenutzt wird, aber dem Product Security Incident Response Team (PSIRT) von Cisco ist bekannt, dass PoC-Exploit-Code für diese Sicherheitslücke existiert.

Ivanti patcht vier kritische Schwachstellen

Es wurden vier kritische Schwachstellen identifiziert, die Ivanti Connect Secure (ICS), Policy Secure (IPS) und Cloud Services Application (CSA) betreffen. Bisher sind keine Berichte über aktive Angriffe in freier Wildbahn oder PoC-Exploits aufgetaucht. Ivanti rät Anwendern, umgehend auf die neuesten Versionen zu aktualisieren, um diese kritischen Sicherheitslücken zu schließen.

Hier ist eine kurze technische Zusammenfassung:

  • CVE-2025-22467 (CVSS 8.8): Angreifer mit Anmeldeinformationen können aufgrund eines Stack-basierten Buffer Overflow in ICS-Versionen vor 22.7R2.6 Remote Code Execution (RCE) erreichen [CWE-121].
  • CVE-2024-38657 (CVSS 9.1): Angreifer mit Anmeldeinformationen können beliebige Dateien schreiben aufgrund einer externen Kontrolle des Dateinamens in ICS-Versionen vor 22.7R2.4 und IPS-Versionen vor 22.7R1.3.
  • CVE-2024-10644 (CVSS 9.1): Ein Code-Injection-Fehler in ICS (vor 22.7R2.4) und IPS (vor 22.7R1.3) ermöglicht beliebige RCE für authentifizierte Administratoren.
  • CVE-2024-47908 (CVSS 7.2): Eine Schwachstelle in der Command Injection des Betriebssystems [CWE-78] in der Admin-Webkonsole von CSA (Versionen vor 5.0.5) erlaubt beliebige RCE für authentifizierte Administratoren.

Zusammenfassung

Der Threat Report dieses Monats beleuchtet wichtige Entwicklungen im Bereich der Cybersicherheit, darunter die sich weiterentwickelnden Taktiken von Ransomware-Gruppen wie Black Basta und die allgegenwärtige kritische Bedrohung für Edge-Netzwerkgeräte. Unterstützt durch KI-Tools nutzen Angreifer Schwachstellen immer schneller aus – manchmal schon wenige Stunden nach ihrer Entdeckung. Unternehmen müssen wachsam bleiben, indem sie proaktive Sicherheitsmaßnahmen ergreifen, ihre Abwehr kontinuierlich aktualisieren und Bedrohungsdaten nutzen, um neuen Gefahren einen Schritt voraus zu sein.