Missbrauch von Instanzmetadaten

Was ist Missbrauch von Instanzmetadaten?

Ist das ältere tokenlose v1-Protokoll zugelassen, beantwortet der Instanzmetadatendienst jede einfache Anfrage aus der Instanz, auch die nach den temporären Zugangsdaten der Instanzrolle. So kann aus einer gewöhnlichen SSRF-Schwachstelle ein Diebstahl von Cloud-Zugangsdaten werden. Sie richten source_url in einer Importfunktion auf 169.254.169.254, lesen Zugriffsschlüssel, geheimen Schlüssel und Sitzungstoken und greifen damit über die Cloud-API auf Daten zu, die die Benutzeroberfläche nicht freigibt. Anschließend verlangen Sie IMDSv2-Sitzungstoken und begrenzen die Netzwerk-Hops der Token-Antwort.

Was Sie lernen in Missbrauch von Instanzmetadaten

• Bei zugelassenem v1 gibt der Metadatendienst Rollenzugangsdaten an alles aus, was von innerhalb der Instanz eine Anfrage stellen kann, ohne selbst zu authentifizieren.
• Eine SSRF-Schwachstelle in der Anwendung kann zum Diebstahl von Cloud-Zugangsdaten und anschließend zum Zugriff auf die Cloud-Steuerungsebene führen.
• Ein verpflichtendes Sitzungstoken macht aus einer einzelnen gefälschten Anfrage einen zweistufigen Ablauf, den die meisten einfachen SSRF-Schwachstellen nicht ausführen können.
• Den Metadatendienst in der Instanzkonfiguration absichern, weil das jede SSRF-Schwachstelle abdeckt und nicht nur die gefundene.

Missbrauch von Instanzmetadaten — Trainingsschritte

1. Ein Server, der URLs für Sie abruft

   Bob nimmt Vurloch ins Visier. Die Software des Unternehmens unterstützt Gebäudeinspektionen mit Terminplänen, Berichten und Zugangsinformationen für die Besichtigungen. Eine Funktion fällt Bob besonders auf: Sie ruft fremde Inhalte selbst ab. Inspektoren können einen Bericht importieren, indem sie eine URL einfügen. Vurlochs Server lädt den Bericht herunter. So kann Bob den Server veranlassen, Adressen aufzurufen, die er selbst nicht direkt erreicht.

2. Die Importfunktion verstehen

   Bob liest zunächst die Beschreibung: Wer eine URL zu einem Inspektionsbericht einfügt, kann diesen dem jeweiligen Objekt zuordnen lassen. Entscheidend ist, wer den Bericht herunterlädt.

3. Die Funktion regulär nutzen

   Zunächst geht Bob wie ein Inspektor vor: Er fügt die URL eines Partnerberichts ein und lässt Vurloch die Datei abrufen. So kann er die ausgelöste Anfrage im Netzwerkbereich des Browsers untersuchen.

4. Die URL als Parameter

   Der Import hat funktioniert. Bob öffnet den Netzwerkbereich des Browsers und prüft, was die Seite gesendet hat. Für seinen Angriff muss er die abgerufene URL ändern können.

5. Den Metadatendienst ansprechen

   Eine feste linklokale IP-Adresse ist nur von einer Cloud-Instanz aus erreichbar: die des Instanzmetadatendienstes. Solange er noch das ältere tokenlose v1-Protokoll zulässt, liefert er die eigenen temporären Rollenzugangsdaten der Instanz an alles auf der Instanz, was mit einem einfachen GET fragt. Bob ersetzt in der aufgezeichneten Anfrage die Partner-URL durch diese Adresse und sendet sie erneut.

6. Die Zugangsdaten wurden abgerufen

   Der Server rief die angegebene Adresse auf und gab die Antwort zurück.

7. Wem gehören diese Zugangsdaten?

   Bob speichert die drei Werte in einem lokalen Profil und fragt die Cloud-API, unter welcher Identität er jetzt handelt.

8. Daten, die die App nicht offenlegt

   In der Anwendung lassen sich Berichte einem Objekt zuordnen. Die Rolle des Servers darf aber viel mehr. Bob sucht nach Daten, die die Benutzeroberfläche nicht preisgibt, und liest das Inspektionsarchiv direkt im Terminal. Bob hat Angaben zum physischen Zugang zu Zehntausenden Objekten erbeutet, und zwar über eine Funktion, die lediglich URLs abruft.

9. Woher die Zugangsdaten stammen

10. Die Serveridentität in fremden Händen

    Vurlochs Überwachung meldet, dass die Rolle der Anwendungsinstanz auf Speicher zugreift, den sie im normalen Betrieb nicht lesen sollte.