Vertikale Rechteausweitung

Was ist Vertikale Rechteausweitung?

Die horizontale Eskalation bewegt sich seitwärts in die Daten eines anderen Benutzers. Die vertikale Eskalation erklimmt die Leiter, da das Autorisierungstor einem Wert vertraut, den der Angreifer besitzt. Sie werden feststellen, dass Ihre Rolle innerhalb eines JWT-Sitzungscookies wandert, den Anspruch vom Betrachter zum Administrator umschreibt und ohne gestohlenes Passwort und ohne Exploit-Code in eine Betriebskonsole gelangt. Das Gate dekodiert den Token und liest den Anspruch, ohne die Signatur zu prüfen, und die Dekodierung beweist nichts. Der Fix überprüft zunächst die Signatur, wobei die Berechtigungen serverseitig von vertrauenswürdigen Datensätzen als Backstop neu abgeleitet werden.

Was Sie lernen in Vertikale Rechteausweitung

• Vertikale von horizontaler Rechteausweitung anhand der Bewegung des Angreifers in der Rollenhierarchie unterscheiden
• Erkennen, dass Authentifizierung (Nachweis, wer Sie sind) von Autorisierung (Nachweis, dass Sie dies tun dürfen) getrennt ist
• Verstehen, dass jede Rolle, Stufe oder Berechtigung in einem clientseitig gehaltenen Token oder Cookie vom Angreifer kontrollierbar ist, bis ihre Integrität geprüft wurde
• Die Lösung anwenden, die die Signatur eines Tokens prüft, bevor sie einem Claim vertraut, damit eine gefälschte Rolle abgelehnt wird
• Eine serverseitige Absicherung hinzufügen, indem Berechtigungen aus vertrauenswürdigen Datensätzen erneut abgeleitet und minimale Rechte durchgesetzt werden

Vertikale Rechteausweitung — Trainingsschritte

1. Konto mit Lesezugriff

   Bob verfügt über ein legitimes Konto mit geringen Rechten in Talveyns Operations Console: ein Konto eines externen Mitarbeiters mit reinem Lesezugriff. Er meldet sich mit seinen eigenen Zugangsdaten an, genau wie er es darf. Kein Passwort wurde gestohlen, kein Konto geknackt. Er gelangt auf seine Übersichtsseite für den Lesezugriff. Er kann seine Support-Warteschlangen sehen und eine Kachel, die er nicht öffnen soll: die Admin Console.

2. Die verschlossene Tür

   Bob öffnet die Admin Console dennoch über sein Dashboard, nur um zu sehen, wie weit er mit seinem Konto kommt. Der Server weist ihn mit einem Hinweis auf die Einschränkung ab. Das Gate ist real. Die interessante Frage ist, was dieses Gate tatsächlich prüft.

3. Die Rolle im Token

   Bob öffnet den Cookie-Inspektor des Browsers. Seine Sitzung ist ein JWT, und die Konsole hat es in lesbare Claims dekodiert: als wer er angemeldet ist und welche Rolle ihm erteilt wird. Da steht es deutlich sichtbar: ein Rollen-Claim mit dem Wert viewer. Genau der Wert, den das Gate prüft, befindet sich in einem Token, das sein eigener Browser hält.

4. Die Rolle fälschen

   Wenn die Konsole seine Rolle direkt aus dem Token liest und sich das Token in seinem Browser befindet, kann er es umschreiben. Bob ändert den Rollen-Claim von viewer zu admin. Der Inspektor kodiert das Token mit dem neuen Claim erneut. Die Signatur stimmt nicht mehr mit der Payload überein, aber das ist nur relevant, wenn der Server sich die Mühe macht, es zu prüfen.

5. In der Admin Console

   Bob lädt den Admin-Bereich erneut, diesmal mit dem gefälschten Token. Das Gate liest admin aus seinen Claims und öffnet die Tür. Er hat nun Zugriff auf die gesamte Administratoroberfläche: die Datensätze aller Benutzer, die Möglichkeit, jede Rolle zu ändern, das gesamte Verzeichnis zu exportieren sowie auf Abrechnung und Auszahlungen zuzugreifen. Vor zwanzig Sekunden hatte er noch ein Konto mit Lesezugriff.

6. Den Vorfall einordnen

   Bevor Bobs Chaos Alices Morgen bestimmt, ordnen Sie die Rechteausweitung präzise ein.

7. Ein Viewer mit Admin-Rechten

   Alice verantwortet die Zugriffskontrollen der Konsole. Über Nacht hat das Monitoring etwas markiert, das unmöglich sein sollte: eine Sitzung mit Lesezugriff, die Aktionen ausführt, die nur Administratoren vorbehalten sind. Security Operations hat ihr den Fund per E-Mail gemeldet.

8. Das Admin-Gate öffnen

   Alle Admin-Routen verwenden dasselbe Gate, require-admin.js . Alice öffnet es, um genau nachzuvollziehen, wie es entscheidet, wer als Administrator gilt.

9. Das Gate vertraut dem Token

   Das Gate liest die Rolle des Aufrufers aus dem Session-Token und vergleicht sie mit admin. Was es nie tut, ist zu prüfen, ob das Token echt ist. Eine im Browser umgeschriebene Payload lässt sich problemlos dekodieren, daher wird eine gefälschte Rolle direkt akzeptiert.

10. Die tatsächliche Lösung auswählen

    Sie haben den Fehler gesehen. Wählen Sie die Änderung, die ihn tatsächlich behebt.