Greenbone AG

Schwachstellen-Erkennung durch Greenbone: trotz NIST NVD-Ausfall stark

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

Threat Report März 2025: Wem vertrauen Sie?

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Dirk Boeing

Der Prozessor als Schwachstelle: Hardware-Risiken souverän managen

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

Schwachstelle mit CVSS 10: CVE-2024-54085 macht AMI BMC zur Gefahr

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

PHP-CGI für Windows: Angriffe auf CVE-2024-4577 eskalieren

„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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

Apache Camel: Schwachstellen großgeschrieben

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Markus Feilner

Dennis-Kenji Kipker über die Zukunft von NIS2 in Deutschland und Europa

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!

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

Februar 2025 Threat Report: Rumoren im Untergrund

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

Maximales Desaster für Zyxel: EOL-Router und Ransomware-Angriffe

Jedes Produkt hat ein Ablaufdatum, aber die Kunden haben oft nur eine kurze Vorwarnung und keinen Regressanspruch, wenn ein Anbieter beschließt, ein Produkt auslaufen zu lassen. Sobald ein Anbieter ein Produkt mit End-of-Life (EOL) oder End-of-Service (EOS) kennzeichnet, wird das Management der damit verbundenen Risiken komplexer. Das Risiko vergrößert sich, wenn Cyberkriminelle Schwachstellen finden und ausnutzen, die nie gepatcht werden. Wenn ein EOL-Produkt zukünftig anfällig wird, müssen seine Benutzer selbst zusätzliche Sicherheitskontrollen einführen.

Digitale Darstellung von Gewitterwolken und einem Mülleimer mit Router-Symbol – Sinnbild für Sicherheitsrisiken durch veraltete IT-Produkte und Ransomware-Bedrohungen.

Wenn sich herausstellt, dass der Anbieter diese anfälligen EOL-Produkte immer noch verkauft, kann dies als „perfekter Sturm“ oder größte Katastrophe angesehen werden. In diesem Artikel werden wir mehrere Sicherheitswarnungen für Zyxel-Produkte untersuchen, darunter einige, die als EOL-Produkte eingestuft sind, und eine weitere Schwachstelle, die bei Ransomware-Angriffen ausgenutzt wird.

Jüngste Sicherheitslücken in Zyxel-Produkten

CVE-2024-40891 (CVSS 8.8), eine schwerwiegende Schwachstelle zur Remote Code Execution (RCE) in der Telnet-Implementierung von Zyxel, ist seit Mitte 2024 bekannt. Dennoch hat Zyxel auch fast sechs Monate später noch keinen Patch veröffentlicht und behauptet, die betroffenen Produkte seien EOS und EOL. Anfang 2025 beobachtete GreyNoise die aktive Ausnutzung von CVE-2024-40891 gegen anfällige Zyxel CPE-Netzwerkgeräte. Diese CVE (Common Vulnerabilities and Exposures) und eine weitere RCE-Schwachstelle, CVE-2024-40890 (CVSS 8.8), wurden beide Mitte Februar in die KEV-Liste (Known Exploited Vulnerabilities) der CISA (Cybersecurity and Infrastructure Security Agency) aufgenommen. Während es sich bei den beiden CVEs um RCE-Schwachstellen nach der Authentifizierung handelte, lieferte eine dritte Sicherheitslücke, CVE-2025-0890 (CVSS 9.8), die am 4. Februar veröffentlicht wurde, das letzte Puzzleteil: extrem schwache Standardanmeldeinformationen für per Fernzugriff zugängliche Dienste – und zwar zusätzlich zum ohnehin unverschlüsselten Telnet-Authentifizierungsprozess.

Die Forscher von VulnCheck, die die Schwachstellen ursprünglich entdeckt hatten, wiesen darauf hin, dass der Hersteller die fehlerhaften Geräte weiterhin verkauft, obwohl er weiß, dass die Schwachstellen aktiv ausgenutzt werden, und nicht die Absicht hat, Patches herauszugeben. Am 25. Februar 2025 wurden einige der betroffenen Produkte immer noch über den offiziellen von Zyxel-Shop auf Amazon verkauft [1][2]. Darüber hinaus wird eine weitere Sicherheitslücke in Zyxel-Produkten, CVE-2024-11667, aktiv für Ransomware-Angriffe durch den Bedrohungsakteur Helldown ausgenutzt.

Im Bereich der Telekommunikationstechnologien hält Zyxel einen geschätzten Marktanteil von 4,19 % und beliefert rund 2.277 Unternehmen, darunter die größten Tech-Giganten der Welt. Die Zyxel-Gruppe mit Hauptsitz im Hsinchu Science Park, Taiwan, ist ein führender Anbieter von Netzwerklösungen für Unternehmen und Privatanwender und weltweit in über 150 Ländern tätig.

Chronik der Ereignisse

  • 07.2024: VulnCheck informiert Zyxel über Sicherheitslücken in Produkten der CPE-Serie.
  • 07.2024: VulnCheck veröffentlicht Informationen zu CVE-2024-40890 und CVE-2024-40891 im Blog.
  • 01.2025: Aktive Ausnutzung von CVE-2024-40891 wurde von GreyNoise gemeldet.
  • 02.2025: VulnCheck veröffentlichte weitere Informationen, die das Risiko, das von Zyxels Position ausgeht, hervorheben und Beweise dafür liefern, dass anfällige Geräte immer noch von dem Anbieter online verkauft werden.
  • 02.2025: Zyxel veröffentlicht einen Sicherheitshinweis, der die betroffenen Produkte als EOL kennzeichnet und besagt, dass sie keine Updates erhalten werden.

Technische Beschreibungen der jüngsten Zyxel-Schwachstellen

Abgesehen von der langsamen Reaktion von Zyxel auf Sicherheitsforscher und der Entscheidung, weiterhin Produkte mit ausnutzbaren Schwachstellen zu verkaufen, gibt es noch weitere Lehren aus der technischen Bewertung der Schwachstellen selbst zu ziehen. Nämlich, wie Produktanbieter weiterhin Produkte mit unverzeihlichen Sicherheitsmängeln vermarkten und sich dabei vor der Verantwortung drücken.

  • CVE-2024-40891 (CVSS 8.8 Hoch): Authentifizierte Benutzer können eine Telnet-Command-Injection aufgrund einer unsachgemäßen Eingabevalidierung in `libcms_cli.so` Befehle werden ungeprüft an eine Shell-Ausführungsfunktion weitergegeben, was eine beliebige RCE ermöglicht. Abgesehen von der Überprüfung, ob der Befehlsstring mit einem zugelassenen Befehl beginnt, hat die Funktion `prctl_runCommandInShellWithTimeout` keine Filterung, was die Verkettung von Befehlen und das Einschleusen beliebiger Befehle ermöglicht.
  • CVE-2024-40890 (CVSS 8.8 Hoch): Eine Post-Authentication Command-Injection-Schwachstelle im CGI-Programm der Legacy-DSL Zyxel VMG4325-B10A Firmware Version 1.00(AAFR.4)C0_20170615 könnte es einem authentifizierten Angreifer ermöglichen, Betriebssystembefehle auf einem betroffenen Gerät auszuführen, indem er eine manipulierte HTTP-POST-Anfrage sendet.
  • CVE-2025-0890 (CVSS 9.8 Kritisch): Die Geräte verwenden schwache Standard-Anmeldeinformationen wie die Benutzernamen und Passwörter admin:1234, zyuser:1234 und supervisor:zyad1234. Keines dieser Konten ist über die Weboberfläche sichtbar, kann aber in der Datei `/etc/default.cfg` des Geräts gefunden werden. Diese Standard-Anmeldeinformationen sind Angreifern bekannt. Die Konten „supervisor“ und „zyuser“ können beide über Telnet aus der Ferne auf Geräte zugreifen. „supervisor“ hat versteckte Rechte, die vollen Systemzugriff gewähren, während „zyuser“ immer noch CVE-2024-40891 für RCE ausnutzen kann. Die Verwendung solcher Standard-Anmeldeinformationen verstößt gegen die CISA-Verpflichtung “Secure by Design“ und gegen den kommenden Cyber Resilience Act (CRA) der EU.

Zu den betroffenen Produkten gehören die Zyxel VMG1312-B Serie (VMG1312-B10A, VMG1312-B10B, VMG1312-B10E, VMG3312-B10A, VMG3313-B10A, VMG3926-B10B, VMG4325-B10A, VMG4380-B10A, VMG8324-B10A, VMG8924-B10A) und zwei Router der Zyxel Business Gateway Serie (SBG3300 und SBG3500). Die Geräte der Zyxel CPE-Serie (Customer Premises Equipment) sind für die Internetanbindung von Privathaushalten und kleinen Unternehmen konzipiert, z. B. als DSL-, Glasfaser- und Wireless-Gateways. Als solche werden sie in der Regel beim Kunden installiert, um ihn mit dem Netzwerk eines Internet Service Providers (ISP) zu verbinden, und sind daher nicht ohne weiteres durch Firewalls vor dem Internet geschützt. In Anbetracht der Art der Zyxel CPE-Geräte und der fraglichen Schwachstellen wäre es nicht überraschend, wenn Zehntausende oder mehr Zyxel-Geräte an bösartigen Botnet-Aktivitäten beteiligt wären.

Greenbone kann EOL Zyxel-Geräte erkennen, die für die oben genannten CVEs anfällig sind.

CVE-2024-11667: Zyxel-Firewalls für Ransomware-Angriffe ausgenutzt

CVE-2024-11667 (CVSS 9.8 Critical), veröffentlicht Ende Dezember 2024, ist ein Path-Traversal-Fehler [CWE-22] in der Web-Management-Konsole der Zyxel ATP- und USG FLEX-Firewall-Serie. Die Schwachstelle wird bekanntermaßen ausgenutzt vom Helldown-Bedrohungsakteur in Ransomware-Angriffen und ist Gegenstand mehrerer nationaler Cybersicherheitshinweise [1][2].

Die Ransomware-Gruppe Helldown tauchte im August 2024 als bemerkenswerter Bedrohungsakteur in der Cybersicherheitslandschaft auf. Diese Gruppe wendet eine doppelte Erpressungsstrategie an, bei der sie sensible Daten von Zielorganisationen exfiltriert und anschließend Ransomware zur Verschlüsselung der Systeme der Opfer einsetzt. Wenn die Lösegeldforderungen nicht erfüllt werden, droht Helldown damit, die gestohlenen Daten auf ihrer Data Leak Site zu veröffentlichen. Helldown nutzt nicht nur diese Zyxel-Schwachstellen aus, sondern ist auch dafür bekannt, Schwachstellen in Windows-Betriebssystemen, VMware ESX und Linux-Umgebungen auszunutzen, wobei häufig kompromittierte VPN-Anmeldedaten verwendet werden, um sich seitlich in Netzwerken zu bewegen.

Zyxel hat einen Hinweis auf die Ransomware-Angriffe und Patches für die betroffenen Produkte veröffentlicht. Greenbone kann Zyxel-Produkte, die von CVE-2024-11667 betroffen sind, mit drei separaten produktspezifischen Versionserkennungstests erkennen [1][2][3].

Zusammenfassung

Die Situation mit Zyxel scheint ein perfekter Sturm zu sein, der zu einer wichtigen Frage führt: Welche Möglichkeiten haben Kunden, wenn ein Anbieter eine Sicherheitslücke in seinem Produkt nicht schließt? Die EOL-Netzwerkgeräte von Zyxel werden nach wie vor aktiv ausgenutzt, mit Schwachstellen, die für unautorisierte willkürliche RCE und andere unautorisierte Aktionen kombiniert werden können. CVE-2024-40891, CVE-2024-40890 und CVE-2025-0890 stehen jetzt auf der KEV-Liste der CISA, während CVE-2024-11667 mit Ransomware-Angriffen in Verbindung gebracht wurde. Die Forscher von VulnCheck, die mehrere dieser CVEs entdeckt haben, haben Zyxel für die schlechte Kommunikation und den Verkauf von ungepatchten EOL-Geräten kritisiert. Greenbone erkennt betroffene Produkte, und mit dem proaktiven Ansatz für das Schwachstellenmanagement können Benutzer die Gefährdung verringern.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

Greenbone erkennt CVE-2025-0994: Aktiv ausgenutzte Schwachstelle in Trimble Cityworks

Trimble Cityworks, eine Software für das Enterprise Asset Management (EAM) und die Verwaltung öffentlicher Gebäude, wird aktiv angegriffen. Die Kampagne begann als unbekannte Schwachstelle (Zero Day), wird aber jetzt als CVE-2025-0994 mit einem CVSS-Wert von 8.6 geführt. Es handelt sich um einen Fehler bei der Deserialisierung [CWE-502], der einem authentifizierten Angreifer ermöglichen könnte, beliebigen Code aus der Ferne auszuführen (Remote Code Execution; RCE). Greenbone enthält eine Erkennung für CVE-2025-0994 im Enterprise Feed.

Die aktive Ausnutzung von CVE-2025-0994 ist eine reale und gegenwärtige Gefahr. Trimble hat eine Erklärung veröffentlicht, in der die Angriffe auf das Produkt bestätigt werden. Dank der Transparenz des Herstellers hat die CISA (Cybersecurity and Infrastructure Security Agency) CVE-2025-0994 in ihren Katalog der bekannten ausgenutzten Schwachstellen (KEV) aufgenommen und einen ICS-Hinweis sowie ein CSAF-2.0-Dokument veröffentlicht. CSAF 2.0-Advisorys sind maschinenlesbare Dokumente mit Hinweisen auf Schwachstellen für den dezentralen Austausch von Cybersicherheitsinformationen.

Obwohl viele Medienberichte und einige Plattformen, die Bedrohungsinformationen sammeln, darauf hinweisen, dass es einen öffentlichen Proof-of-Concept (PoC) gibt, ist das einzige Suchergebnis auf GitHub lediglich ein Versionserkennungstest. Das bedeutet, dass es unwahrscheinlich ist, dass wenig qualifizierte Hacker leicht an Angriffen teilnehmen können. Die Fehlinformationen sind vermutlich auf schlecht konzipierte Algorithmen in Verbindung mit mangelnder menschlicher Kontrolle vor der Veröffentlichung von Bedrohungsdaten zurückzuführen.

Wer ist durch CVE-2025-0994 gefährdet?

Trimble Cityworks wurde vor allem für Kommunalverwaltungen und Anbieter kritischer Infrastrukturen wie Wasser- und Abwassersysteme, Energie, Verkehrssysteme, staatliche Industrieanlagen und Kommunikationsagenturen entwickelt und wird von ihnen genutzt. Cityworks erweitert geografische Informationssysteme (GIS) durch die Integration von Lösungen für die Verwaltung von Anlagen und öffentlichen Arbeiten direkt in Esri ArcGIS. Die Software soll Organisationen bei der Verwaltung der Infrastruktur, der Planung von Wartungsarbeiten und der Verbesserung der betrieblichen Effizienz helfen. Neben der CISA haben auch mehrere andere Regierungsbehörden Warnungen zu dieser Sicherheitslücke herausgegeben, darunter die US-Umweltschutzbehörde (EPA), das kanadische Zentrum für Cybersicherheit und der Bundesstaat New York.

Eigenen Angabe zufolge bediente Trimble Cityworks im Jahr 2019 über 700 Kunden in Nordamerika, Europa, Australien und dem Nahen Osten. Während spezielle Zahlen für Kommunalverwaltungen in den USA, Kanada und der EU nicht öffentlich bekannt gegeben werden, zeigen eine Suche auf Shodan und eine Censys-Karte jeweils nur etwa 100 öffentlich zugängliche Instanzen von Cityworks. Es wird jedoch davon ausgegangen, dass die Anwendung eine hohe Akzeptanz bei Kommunalverwaltungen und Versorgungsunternehmen hat. Wenn CVE-2025-0994 öffentlich zugänglich ist, könnte ein Angreifer einen ersten Zugang erhalten [T1190]. Für Angreifer, die bereits Fuß gefasst haben, ist die Schwachstelle eine Gelegenheit für laterale Bewegungen [TA0008] und stellt eine leichte Beute für Insider-Angriffe dar.

Technische Beschreibung von CVE-2025-0994

CVE-2025-0994 ist eine Schwachstelle in der Deserialisierung [CWE-502], die in Versionen von Trimble Cityworks vor 15.8.9 und Cityworks mit Office Companion vor 23.10 gefunden wurde. Sie entsteht durch die unsachgemäße Deserialisierung von nicht vertrauenswürdigen serialisierten Daten, die es einem authentifizierten Angreifer ermöglicht, beliebigen Code aus der Ferne auf dem Microsoft Internet Information Services (IIS) Webserver des Ziels auszuführen.

Die Serialisierung ist ein Prozess, bei dem Softwarecode oder Objekte kodiert werden, um zwischen Anwendungen übertragen und dann in dem von einer Programmiersprache verwendete Originalformat rekonstruiert zu werden. Wenn Trimble Cityworks serialisierte Objekte verarbeitet, werden nicht vertrauenswürdige Eingaben nicht ordnungsgemäß validiert oder bereinigt. Dieser Fehler ermöglicht es einem Angreifer mit authentifiziertem Zugriff, speziell gestaltete serialisierte Objekte zu senden, die eine beliebige Codeausführung auf dem zugrunde liegenden IIS-Server auslösen können. Die Deserialisierung von Daten aus nicht authentifizierten Quellen scheint an sich schon ein signifikanter Designfehler zu sein, aber das Versäumnis, serialisierte Daten ordnungsgemäß zu bereinigen, ist eine besondere Unsicherheit.

Konsequenzen der Ausnutzung von CVE-2025-0994 könnten sein:

  • Unbefugter Zugriff auf sensible Daten
  • Unterbrechung der Dienste für kritische Infrastruktursysteme
  • Mögliche vollständige Kompromittierung des betroffenen IIS-Webservers

Abhilfe gegen CVE-2025-0994 in Trimble Cityworks

Trimble hat gepatchte Versionen von Cityworks veröffentlicht, die die Schwachstelle in der Deserialisierung beheben. Diese Patches umfassen Cityworks 15.8.9 und Cityworks 23.10. On-premise-Anwender müssen sofort auf die gepatchte Version aktualisieren, während Kunden von Cityworks Online (CWOL) diese Updates automatisch erhalten.

Trimble wies darauf hin, dass bei einigen Vor-Ort-Installationen IIS mit überprivilegierten Identitätsberechtigungen ausgeführt wird, was die Angriffsfläche vergrößert. IIS sollte weder auf lokaler noch auf Domänenebene über administrative Berechtigungen verfügen. Befolgen Sie die Anweisungen von Trimble in den neuesten Cityworks-Versionshinweisen, um die IIS-Identitätskonfigurationen richtig anzupassen.

Empfohlene Aktionen für On-premises-Anwender von Trimble Cityworks:

  • Aktualisieren Sie die Cityworks 15.x-Versionen auf 15.8.9 und die 23.x-Versionen auf 23.10.
  • Prüfen Sie die IIS-Identitätsberechtigungen, um sicherzustellen, dass sie mit dem Prinzip der geringsten Rechte übereinstimmen.
  • Beschränken Sie die Stammkonfiguration des Anhangsverzeichnisses auf Ordner, die nur Anhänge enthalten.
  • Verwenden Sie eine Firewall, um den Zugriff auf den IIS-Server nur auf vertrauenswürdige interne Systeme zu beschränken.
  • Verwenden Sie ein VPN, um den Fernzugriff auf Cityworks zu ermöglichen, anstatt den Dienst öffentlich zugänglich zu machen.

Zusammenfassung

CVE-2025-0994 stellt ein ernsthaftes Sicherheitsrisiko für Trimble Cityworks-Benutzer dar, die größtenteils aus Behörden und kritischen Infrastrukturumgebungen stammen. Da bereits eine aktive Ausnutzung beobachtet wurde, müssen Organisationen sofortige Patches und Sicherheitsmaßnahmen implementieren, um das Risiko zu minimieren. Greenbone hat die Erkennung von CVE-2025-0994 zum Enterprise Feed hinzugefügt, sodass Kunden einen Überblick über ihre Gefährdungslage erhalten.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von