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