Schlagwortarchiv für: Sicherheitslücke

Sicherheitsexperten beobachten eine Besorgnis erregende Entwicklung: Die Time to Exploit (TTE), also die Zeit zwischen dem Bekanntwerden einer Sicherheitslücke und ihrem Ausnutzen durch böswillige Akteure, sinkt in der letzten Zeit massiv.

Gleichzeitig zeigen Angreifer immer größere Kompetenz beim Verbergen ihrer Anwesenheit in einem erfolgreich gehackten Netzwerk. Die Zeit, um sich einzunisten und sodann unbefugt auf Unternehmensressourcen zuzugreifen, bevor sie entdeckt (und entfernt) werden, nennen Experten „Dwell time“, also Verweildauer. Je kürzer diese ist, umso besser für die Angegriffenen. Auch der begabteste Hacker braucht Zeit und kann umso mehr (dauerhaften) Schaden anrichten, je länger er unbemerkt und unbeobachtet bleibt.

Der Feind hört mit – und ist vielleicht schon da

Erschreckenderweise erreicht die Dwell Time immer häufiger Monate oder gar Jahre, so wie bereits bei Sony oder im US-Office for Personal Management. Dort konnten Angreifer mehr als zwölf Monate ungestört agieren. Bei dem japanischen Technologiekonzern flossen in der Folge sogar über 10 Terabyte an Daten ab.

Die Angst vor verborgenen Eindringlingen ist groß, schließlich kann niemand mit Sicherheit sagen, ob sich nicht bereits ein bösartiger Zuhörer im eigenen Netzwerk befindet. Das kommt vor. Schon beim Bundestagshack 2015 zum Beispiel informierte nicht das eigene Monitoring, sondern ein „befreundeter“ Geheimdienst die deutschen Behörden über seltsame Aktivitäten Dritter (russische APT-Hackergruppen) im Bundestagsnetz. Wie lange und wie viele Akteure zu dem Zeitpunkt sich bereits im Netzwerk getummelt hatten, blieb offen. Klar war nur: Es waren mehr als einer, und die befreundeten Geheimdienste hatten schon länger zugeschaut.

Erkennung, Prävention und Reaktion immer kritischer

Umso wichtiger ist es, dafür Sorge zu tragen, dass die Angreifer erst gar nicht ins System gelangen. Das aber wird immer schwieriger: Wie unter anderen die Experten von Googles Mandiant berichten, ist in den letzten fünf Jahren die Reaktionszeit, die Unternehmen und Softwarebetreibern zwischen dem Bekanntwerden einer Schwachstelle und dem Exploit bleibt, in den letzten Jahren rapide gefallen: von 63 Tagen 2018 auf gut einen Monat.

Immer weniger Zeit zum Reagieren

2023 blieben Administratoren schon nur mehr fünf Tage im Durchschnitt, um Schwachstellen zu bemerken und zu schließen. Heute sind es bereits weniger als drei Tage.

Damit nicht genug. Früher wurden Sicherheitslücken häufiger erst ausgenutzt, nachdem Patches verfügbar waren, also nachdem sich erfahrene Administratoren bereits abgesichert und die aktuellen Patches eingespielt hatten. Eigentlich sollten diese so genannten „N-day Vulnerabilities“ also gar kein Problem sein, gibt es doch Fixes dafür.

Verbesserte Disziplin mit Nebenwirkungen: Angreifer lernen

Leider war in der Vergangenheit die Disziplin (und die Aufmerksamkeit) in vielen Unternehmen nicht so ausgeprägt, man vernachlässigte das Thema und sorgte so unfreiwillig auch für weitere Verbreitung von automatisierten Angriffsmethoden, etwa mithilfe von Würmern und Viren. Gerade hier gibt es auch gute Nachrichten: 2022 machten die Attacken über die N-Day-Schwachstellen noch 38 % aller Angriffe aus, 2023 nur noch 30 %.

Auf den ersten Blick klingt das gut, weil Administratoren bekannte Schwachstellen, für die es Patches gibt, schneller und besser finden und fixen. Nach Jahren mit eher schlecht ausgeprägter Disziplin und mangelnder Update- und Patch-Strategie haben sicher auch die großen und erfolgreichen Ransomware-Vorfälle dazu beigetragen, einer Mehrheit von Verantwortlichen die Tragweite und Bedeutung von ordentlichem Schwachstellenmanagement zu vermitteln.

Zwei Drittel sind mittlerweile Zero-Days

Aber die Zahlen haben auch eine Kehrseite: Mehr als zwei Drittel aller Angriffe basieren mittlerweile auf „Zero-Day“-Schwachstellen, also Sicherheitslücken, für die es noch keinen Patch gibt – 2023 waren das sogar schon 70 %. Die kriminellen Gruppen und Angreifer haben reagiert, gelernt und ihre Machenschaften professionalisiert, automatisiert und gewaltig beschleunigt.

Ohne Automatisierung und Standardisierung von Prozessen, ohne moderne, gepflegte und kontrollierte Open-Source-Software können Admins der Entwicklung kaum mehr Paroli gebieten. Wer kann schon behaupten, er sei in der Lage, binnen drei Tagen auf eine neue Bedrohung zu reagieren?

Machtlos? Nicht mit Greenbone

Wenn Angreifer schneller auf neue, bis dato unbekannte Schwachstellen reagieren können und sich dann auch noch besser zu verstecken gelernt haben, kann es nur eine Antwort geben: den Einsatz eines professionellen Schwachstellenmanagements. Mit Lösungen von Greenbone lässt sich das Netzwerk automatisiert testen. Mit Berichten über den Erfolg von Maßnahmen erhalten Administratoren damit einen schnellen Überblick über den aktuellen Sicherheitsstatus Ihres Unternehmens.

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

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

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

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

Was ist Commvault Command Center?

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

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

Technische Beschreibung von CVE-2025-34028

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

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

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

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

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

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

CVE-2025-34028 entschärfen

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

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

Zusammenfassung

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

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

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

Microcode-Updates

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

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

Fehler auf verschiedenen Ebenen

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

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

Leistung oder Sicherheit?

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

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

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

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

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

CVE-2024-54085 ermöglicht einem Angreifer:

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

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

Potenzielles Ausmaß der Auswirkungen

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

CVE-2024-54085 technisch gesehen

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

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

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

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

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

Schritte zur Eindämmung von CVE-2024-54085

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

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

Zusammenfassung

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

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

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

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

So wird CVE-2024-4577 ausgenutzt

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

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

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

CVE-2024-4577 technisch gesehen

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

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

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

CVE-2024-4577 wird dieses Jahr weltweit ausgenutzt

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

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

Abhilfe für CVE-2024-4577

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

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

Zusammenfassung

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

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

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

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

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

Was ist Apache Camel?

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

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

Zwei CVEs in Apache Camel erlauben Header-Injection

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

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

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

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

Was ist der geeignete CVSS-Score?

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

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

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

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

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

Behandlung der CVEs in Apache Camel

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

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

Zusammenfassung

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

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.