In einem kürzlich durchgeführten Kundenprojekt stießen wir auf eine Apache ActiveMQ-Instanz, die für die Schwachstelle CVE-2023-46604 verwundbar war. Diese erlaubt es Angreifern mit Netzwerkzugriff auf die OpenWire-Schnittstelle (üblicherweise TCP-Port 61616), beliebige Befehle auf Betriebssystemebene auszuführen, ohne dabei ein Passwort oder einen Schlüssel angeben zu müssen.

Eine solche sogenannte “Remote-Code-Execution”-Schwachstelle, kurz “RCE”, stellt häufig ein hohes Risiko dar, da Angreifer mit einem solchen Zugriff oft in der Anwendung selbst implementierte Zugangsbeschränkungen umgehen können sowie potenziell Angriffe gegen andere Systeme durchführen können. Auch die Schwachstelle CVE-2023-46604 wurde mit einem maximalen CVSS-Risiko-Score von 10.0 bewertet. Schwachstellendetails sowie Proof-of-Concept-Exploits waren zum Testzeitpunkt bereits publik, mittlerweile hat das BSI sogar eine Warnung herausgegeben, da die Schwachstelle im Internet aktiv ausgenutzt wird.

Nachdem wir die Verwundbarkeit im vorliegenden Fall manuell verifiziert haben, berichteten wir unserem Kunden von diesem Teilergebnis. Für Schwachstellen mit hohem Risiko ist dies die Standardvorgehensweise, damit für die Behebung der Schwachstelle nicht auf den Abschluss des Projekts gewartet werden muss. Der Kunde war über dieses Finding sehr verwundert und versicherte uns, alle Sicherheitsupdates installiert zu haben – wie konnte es sein, dass eine solch kritische Schwachstelle übersehen wurde? Lag hier etwa ein systemisches Problem mit den Aktualisierungsprozessen vor?

Also gingen wir auf die Suche nach Antworten. In der offiziellen Beschreibung der Schwachstelle heißt es:

Users are recommended to upgrade both brokers and clients to version 5.15.16, 5.16.7, 5.17.6, or 5.18.3 which fixes this issue.

Damit ist der Fall klar – oder etwa nicht? Nun ja, offenbar nur aus dieser Perspektive. Denn in den offiziellen Release-Notes für ActiveMQ-Version 5.18.3, der Version, die die Schwachstelle behebt, findet sich kein Wort über die Schwachstelle:

Eher im Gegenteil, denn es heißt sogar ausdrücklich, dass es sich um ein “Maintenance-Release”, also eine reines Wartungsupdate handelt:

It’s a maintenance release on the ActiveMQ 5.18.x series […]

Und auch in den verlinkten ausführlicheren Release-Notes ist keine Rede von einer Schwachstelle oder der Sicherheit der Software. Dasselbe gilt für die Release-Notes der anderen Minor-Versionen, die diese kritische Schwachstelle beheben.

Dies ist ein gutes Beispiel dafür, warum wir unseren Kunden empfehlen, nicht nur alle Sicherheitsupdates, sondern generell alle Aktualisierungen für ein Produkt zu installieren. Denn für Softwarehersteller gibt es verschiedene Motivationen, Behebungen von Schwachstellen zu verschweigen, zum Beispiel:

  • Angst, dass der eigene Ruf durch die Veröffentlichung einer Schwachstelle Schaden nimmt
  • Versuch, zu verhindern, dass Angreifer auf die Schwachstelle aufmerksam werden
  • Versehentliche Behebung der Schwachstelle als Nebenprodukt anderer Änderungen

Diese Strategien sind aus unserer Sicht jedoch nicht zielführend, da Angreifer andere Möglichkeiten haben, auf Schwachstellen aufmerksam zu werden. So ist beispielsweise das sogenannte “Patch-Diffing”, also die Analyse von Aktualisierungspaketen sehr effektiv.

Im Falle von Open-Source-Software können die Quelltextänderungen besonders nachvollzogen werden, weshalb Open-Source-Projekte üblicherweise verhältnismäßig offen mit Schwachstellen umgehen. Auch in diesem Fall veröffentlichte die Apache Foundation einen News-Artikel über die Schwachstelle. Warum sie also in den Release-Notes nicht erwähnt wird, bleibt ein Rätsel…

Kommen Sie auf uns zu, wenn auch wir Ihre IT-Infrastruktur testen sollen! Wir bieten verschiedenen Arten von IT-Security-Tests an, wir beraten Sie gerne!