HashiCorp Vault & CyberArk Conjur kompromittiert – Source: www.csoonline.com

Alexsander Ovsyannikov | shutterstock.com

In Enterprise-Umgebungen übersteigt die Anzahl nicht-menschlicher Identitäten (wie sie beispielsweise von Anwendungen und Maschinen verwendet werden), die Anzahl menschlicher Identitäten schätzungsweise um das 150-Fache. Damit sind Credential- oder Secrets-Management-Systeme eine kritische Komponente der IT-Infrastruktur. Umso fataler sind die Erkenntnisse, die Sicherheitsexperten des Identity-Spezialisten Cyata bei der Analyse zweier weit verbreiteter Open-Source-Lösungen in diesem Bereich gewonnen haben.

Demnach wiesen verschiedene Komponenten von HashiCorp Vault und CyberArk Conjur insgesamt 14 logische Schwachstellen auf. Diese ermöglichten den Forschern zufolge unter anderem,

• Authentifizierungsprüfungen zu umgehen,
• auf die in den Systemen gespeicherten Zugangsdaten zuzugreifen, und
• aus der Ferne Code auszuführen.

“Weil Secrets-Management-Systeme die Anmeldedaten, Token und Zertifikate speichern, die den Zugriff auf Systeme, Dienste, APIs und Daten regeln, sind sie nicht nur Teil des Trust Model. Sie sind das Trust Model. Ist Ihr Vault also kompromittiert, ist Ihre Infrastruktur bereits verloren”, warnen die Sicherheitsexperten in ihrem Blogbeitrag. Ihre Erkenntnisse präsentierten sie auch auf der Security-Konferenz Black Hat USA in Las Vegas.

Auch wenn die Schwachstellen in HashiCorp Vault und CyberArk Conjur inzwischen gepatcht wurden, sind die Erkenntnisse der Forscher beängstigend. Schließlich speichern die beiden Secrets-Management-Systeme nicht nur Zugangsdaten und andere geheime Informationen. Sie ermöglichen den Anwendern auch, Richtlinien für den Zugriff auf und die Verwendung dieser Secrets zu definieren, Audits durchzuführen und vieles mehr.

Wie CyberArk Conjur gehackt wurde

Die Attack Chain, die die Cyata-Experten in Zusammenhang mit CyberArk Conjur entdeckt haben, begann mit einem einfachen Fehler im Code, der zum Einsatz kommt, um AWS-IAM-Identitäten zu validieren. Dabei unterstützt Conjur für AWS-Instanzen die Authentifizierung über den hauseigenen Security Token Service (STS). Das ermöglicht es, Workflows ohne fest codierte Anmeldedaten zu authentifizieren. Dazu generiert eine AWS-Instanz einen signierten Header, den Conjur dann an den STS weiterleitet.

Der Service validiert die Signatur und gibt die Identität der Instanz zurück. Allerdings sind STS-Server regionsspezifisch: Instanzen in us-east-1 müssen beispielsweise sts.us-east-1.amazonaws.com verwenden. Conjur ermittelt die richtige STS-Region anhand des im signierten Header enthaltenen Hostnamens der Instanz. Das Problem: Der Hostname im Header kann von Angreifern kontrolliert werden. Das wäre normalerweise kein Problem, weil eine gefälschte Signatur im Regelfall die Validierungsprüfung einer legitimen STS-Instanz nicht bestehen würde.

Allerdings konnte Conjur wegen des Fehlers im Code keine Sonderzeichen im Hostnamen bereinigen. So war es den Forschern möglich, eine Anfrage mit einem Hostnamen wie sts.cyata.ai? zu erstellen, den Conjur anschließend in sts.cyata.ai?.amazonaws.com umwandelte. In der Praxis wird jedoch der Teil nach dem hinzugefügten Fragezeichen in URLs ignoriert, sodass die Anfragen an sts.cyata.ai gesendet wurden (einen maliziösen STS-Server, der unter der Kontrolle der Forscher stand) und die Validierung bestanden. “Das war der erste Schritt in der Kette, der es nicht-authentifizierten Angreifern ermöglicht, in das System einzudringen und dabei als legitime AWS-Identität zu erscheinen”, konstatieren die Sicherheitsexperten.  

Die Forscher untersuchten zudem, wie sich das Ressourcenmodell von Conjur missbrauchen lässt. Dieses verwendet drei Parameter, die auch bei API-Abfragen zum Einsatz kommen:

• Account (Conjur-Konto-Name),
• Kind (Ressourcentyp – Host, Benutzer, Variable, Richtlinie, etc.) sowie
• Identifier (eindeutiger Ressourcenname).

Diesbezüglich fanden die Forscher heraus, dass die Authentifizierungslogik von Conjur den Ressourcentyp-“Teil” einer Identität nicht validierte. So war es ihnen dann möglich, ihre gefälschte AWS-Identität zu verwenden, um sich als Benutzer oder Richtlinie im System zu authentifizieren – anstelle eines Hosts. “Dieser Schritt hat ein neues Level eröffnet und aus einem nicht-authentifiziertem Zugriff eine signifikante Angriffsfläche in Conjur geschaffen”, unterstreichen die Experten. “Durch die Kombination einer gefälschten STS-Antwort, einer Richtlinienidentität anstelle eines Hosts und Schwachstellen im Host-Factory-Ablauf konnten wir neue Hosts erstellen, deren Namen und Ownership vollständig unter unserer Kontrolle standen.”

Im nächsten Schritt nahmen die Cyata-Experten auch die Policy Factory von Conjur in Augenschein – einen Mechanismus, mit dem Administratoren wiederverwendbare Richtlinienvorlagen auf neue Ressourcen anwenden können. Diese Templates können auch Embedded Ruby (ERB)-Code enthalten. Das Ziel der Forscher: Ein Template mit beliebigem ERB-Code zu erstellen und den Code remote auszuführen. Die Forscher stellten fest, dass Richtlinien-Templates in der Secrets-Tabelle von Conjur gespeichert waren. Dabei sollten diese lediglich Ressourcen vom Typ “Variable” zugewiesen werden. In der Praxis wurde diese Einschränkung in CyberArks Secrets-Management-Tool allerdings nicht durchgesetzt: “Das war der letzte Schritt, der für eine vollumfängliche Remote Code Execution nötig war. Wir haben Conjur dazu gebracht, einen Host so abzurufen, als wäre er eine Variable. Wir haben ERB als Secret zugewiesen und Conjur hat es wie vorgesehen ausgeführt”, erklären die Experten.

CyberArk hat die beschriebenen Schwachstellen im Juni 2025 behoben und fünf separate CVEs veröffentlicht.

Wie HashiCorp Vault gehackt wurde

HashiCorps Open-Source-System Vault erfüllt einen ähnlichen Zweck wie CyberArk Conjur und ist auch in einer Enterprise-Edition erhältlich. Anwender legen hier geheime Informationen ab, die eingesetzt werden, um sich in verteilten Systemen innerhalb von Multi- und Hybrid-Cloud-Umgebungen zu authentifizieren. Wie bei Conjur überprüften die Cyata-Forscher auch den Code von Vault manuell und konzentrierten sich dabei auf Logikfehler in Komponenten, die für die Authentifizierung und die Durchsetzung von Richtlinien verantwortlich sind. Das förderte neun Schwachstellen zutage, darunter auch eine, über die Remote Code Execution möglich war.

Die Forscher untersuchten zunächst die am häufigsten verwendeten Authentifizierungsmethoden von Vault:

• das herkömmliche Benutzername-Passwort-Verfahren (Userpass-Methode),
• LDAP, das auf Directory Services wie Active Directory oder OpenLDAP basiert, sowie
• die Zertifikat-basierte Authentifizierung über TLS, die häufig für die Kommunikation zwischen Maschinen verwendet wird.

Bei der Userpass-Methode fanden sie eine Schwachstelle, die es Angreifern einerseits ermöglichte, festzustellen, ob ein Benutzername existiert. Andererseits auch die Möglichkeit eröffnete, Brute-Force-Schutzmaßnahmen zu umgehen, die nach mehreren fehlgeschlagenen Anmeldeversuchen das betreffende Konto sperren sollten. Ähnliche Umgehungsmöglichkeiten deckten die Forscher auch in Zusammenhang mit LDAP auf – insbesondere mit Blick auf Multi-Faktor Authentifizierung (MFA): Bugs in dem in vielen Deployments aktivierten TOTP-Methode (zeitlich begrenzte Einmalpasswörter) ermöglichten es ebenfalls, Brute-Force-Schutzmaßnahmen zu umgehen und MFA-Codes zu “erraten” ohne eine Kontosperrung zu triggern.

Bei der Authentifizierung auf Zertifikatbasis entdeckten die Forscher einen weiteren Logikfehler. So überprüfte HashiCorp Vault in diesem Fall lediglich, ob der Public Key des TLS-Client-Zertifikats mit dem angehefteten Zertifikat übereinstimmt – ließ dabei aber den Zertifikatsnamen (ZN) außen vor. Da Vault den ZN-Wert verwendet, um eine interne EntityID zuzuordnen, könnten Angreifer mit Zugriff auf den Private Key einen gültigen Public Key und eine gefälschte ZN erstellen und sich so mit einer falschen Identität “schmücken”. Eine weitere Schwachstelle ermöglichte laut den Sicherheitsprofis außerdem eine Rechteausweitung, die Administrator-Konten mit Root-Zugriff ausstattete. Das sollte das HashiCorp-Tool standardmäßig eigentlich verhindern, um das Risiko einer vollständigen Kompromittierung zu minimieren.

Die laut den Forschern kritischste Schwachstelle fand sich bei HashiCorp Vault allerdings im Logging-System. Das ermöglichte, die Funktionalität des Open-Source-Tools über Plugins, beziehungsweise Binärdateien von Drittanbietern, so zu erweitern, dass es ebenfalls möglich war, remote Code auszuführen. Dazu mussten die Forscher im ersten Schritt Code in eine Datei im Plugin-Verzeichnis schreiben und Execution-Rechte definieren. Das gelang ihnen, indem sie die Audit-Komponente des Tools manipulierten und mithilfe eines benutzerdefinierten Präfixes bösartigen Code in Protokolle einfügten. Diese wurden dann in das Verzeichnis der Plugins geschrieben.

Diese Schwachstelle (CVE-2025-6000) war also das Ergebnis mehrerer logischer Fehler und bestand offensichtlich bereits seit den Anfängen des Vault-Projekts. Nachdem Cyata die Infos zu den gefundenen Schwachstellen an HashiCorp weitergegeben hat, wurden diese per Softwareaktualisierung geschlossen. Der Anbieter veröffentlichte zudem Sicherheits-Bulletins mit detaillierten Informationen zu den Problemen. “Unsere Untersuchung bestätigt eine wichtige Erkenntnis: Selbst Software, die ‘memory-safe’ ist, kann auf logischer Ebene versagen – und wenn es dazu kommt, können die Folgen gravierend ausfallen”, warnen die Forscher und fügen hinzu: “Unsere Arbeit demonstriert wie subtile Logikfehler in Authentifizierungsprozessen, Identity Resolution und Policy Enforcement heimlich still und leise das Trust Model zerstören.” (fm)

Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox.