Privilege Escalation

Fast jede Anwendung kennt mehrere Arten von Benutzern: Kunde, Mitarbeiter, Administrator. Solange die Anwendung selbst festlegt, wer welche Rolle hat, funktioniert das. Überlässt sie diese Entscheidung der eingehenden Anfrage oder sichert sie den Administrationsbereich nicht gesondert ab, befördert sich ein gewöhnlicher Benutzer selbst. Im Folgenden lesen Sie, wie Privilege Escalation entsteht und was Sie dagegen tun.

Was ist Privilege Escalation?

Privilege Escalation ist eine Schwachstelle, bei der ein Benutzer Rechte erlangt, die ihm nie zugewiesen wurden, weil die Anwendung seine Rolle aus einer nicht vertrauenswürdigen Quelle übernimmt oder eine privilegierte Funktion nicht gesondert absichert. Unter Testern wird Privilege Escalation meist zu Privesc verkürzt.

Ein Vergleich aus dem Alltag: ein Besucherausweis, auf dem Sie Ihre Funktion selbst eintragen. An der Tür zur Vorstandsetage schaut der Wachdienst nur auf den Ausweis und nie in das Personalsystem. Wer dort “Vorstand” hineinschreibt, geht hinein.

Fachleute unterscheiden zwei Richtungen. Bei horizontaler Eskalation erreicht ein Benutzer die Daten eines Gleichgestellten, was im Kern einer IDOR entspricht. Bei vertikaler Eskalation, dem Thema dieses Artikels, steigt er eine Stufe auf, meist direkt zum Administrator. In den OWASP Top 10 fallen beide unter A01:2021, Broken Access Control; MITRE führt den zugrunde liegenden Fehler als CWE-269, Improper Privilege Management.

Zwei Ursachen erklären die meisten Befunde: eine Rolle, die die Anwendung ungeprüft aus der Anfrage übernimmt, und eine Admin-Route, die zwar verborgen, aber nicht geschützt ist.

Wie funktioniert ein Privilege-Escalation-Angriff?

Ein Angreifer braucht nicht mehr als ein eigenes, legitimes Konto. Taucht in einer Antwort ein Feld wie role, isAdmin oder permissions auf, sendet er es in seiner nächsten Anfrage einfach mit.

Verwundbar:

// PATCH /api/profile: der Benutzer aktualisiert sein eigenes Profil
app.patch("/api/profile", requireLogin, async (req, res) => {
  // Der gesamte Anfragekörper geht ungefiltert in die Datenbank
  await db.users.update({ id: req.session.userId }, req.body);
  res.json({ ok: true });
});

// GET /admin/users: die Administratorübersicht
app.get("/admin/users", requireLogin, async (req, res) => {
  // Angemeldet zu sein genügt; die Rolle wird nirgends geprüft
  res.json(await db.users.findAll());
});

Die erste Route schreibt alles Eingehende in den Benutzerdatensatz: Der Entwickler dachte an Namen und Telefonnummer, akzeptiert wird aber auch das Rollenfeld. Der Angreifer sendet dies:

PATCH /api/profile HTTP/1.1
Host: app.example.com
Content-Type: application/json
Cookie: session=8f2a4c1b

{"displayName":"Mark","role":"admin"}

Die Antwort ist eine gewöhnliche 200, und ab der nächsten Anfrage liest die Anwendung die Administratorrolle aus der eigenen Datenbank. Diese Variante heißt Mass Assignment: Ein Framework, das Felder automatisch an ein Objekt bindet, bindet auch jene, die der Benutzer nie setzen durfte.

Die zweite Route zeigt das andere Muster: Sie prüft, ob jemand angemeldet ist, aber nicht, wer er ist. Der Pfad fehlt im Menü gewöhnlicher Benutzer, und genau darauf verlässt sich der Entwickler. Angreifer finden solche Pfade im JavaScript-Bundle, das die Admin-Oberflächen oft gleich mitliefert, oder mit einer Liste gängiger Namen. Das nennt man Forced Browsing.

Die sichere Variante dreht beides um: Die Schreibseite akzeptiert nur, was ein Benutzer über sich selbst setzen darf, die Leseseite bestimmt die Rolle serverseitig.

Sicher:

const PROFILFELDER = ["displayName", "locale", "phone"];

app.patch("/api/profile", requireLogin, async (req, res) => {
  // Allowlist: nur diese Felder erreichen die Datenbank, role gehört nicht dazu
  const patch = {};
  for (const feld of PROFILFELDER) {
    if (feld in req.body) patch[feld] = req.body[feld];
  }
  await db.users.update({ id: req.session.userId }, patch);
  res.json({ ok: true });
});

// Die Rolle stammt aus dem Speicher, anhand der Sitzung, bei jeder Anfrage neu
function requireRole(rolle) {
  return async (req, res, next) => {
    const user = await db.users.findById(req.session.userId);
    if (!user || !user.roles.includes(rolle)) return res.status(404).end();
    next();
  };
}

// Deny by default für den gesamten Admin-Baum, nicht je einzelner Route
app.use("/admin", requireLogin, requireRole("admin"));

app.get("/admin/users", async (req, res) => {
  res.json(await db.users.findAll());
});

Die Allowlist macht es unmöglich, dass ein unbekanntes Feld die Datenbank erreicht. Die Rollenprüfung lädt den Benutzer bei jeder Anfrage aus dem Speicher und sieht sich die dort hinterlegten Rollen an, nicht etwas, was der Client mitgeschickt hat. Weil die Prüfung am gesamten Admin-Baum hängt, ist eine neue Route geschützt, bevor jemand daran denkt; die Antwort 404 statt 403 verrät zudem nicht, welche Admin-Pfade existieren.

Welche Auswirkungen hat Privilege Escalation?

Vertikale Eskalation übergibt dem Angreifer die Schlüssel zur Anwendung: sämtliche Kundendaten einsehen und exportieren, Konten anlegen und löschen, Rechnungen ändern. Häufig legt er als Erstes ein zweites Administratorkonto an, damit sein Zugang bestehen bleibt, nachdem die ursprüngliche Lücke geschlossen ist.

Es bleibt selten bei der Anwendung. Administrationsbereiche bieten Funktionen, die tiefer reichen: ein Datei-Upload, ein Template-Editor, eine Einstellung, die einen Systembefehl aufruft. Solche Funktionen werden weniger streng getestet, gerade weil nur vertrauenswürdige Mitarbeiter sie erreichen sollten, und werden so zum Sprungbrett für Remote Code Execution.

Geschäftlich bedeutet das eine meldepflichtige Datenschutzverletzung, Betrug überall dort, wo sich Zahlungen ändern lassen, und einen Audit-Trail, der seinen Wert verliert, weil Handlungen unter einem scheinbar gewöhnlichen Benutzer protokolliert werden. Die Einstufung reicht von hoch bis kritisch, je nachdem, wie weit die übernommene Rolle reicht. Ein Benutzer, der Moderator seines eigenen Teams wird, ist ärgerlich; derselbe Fehler dort, wo die Administratorrolle über alle Kunden reicht, wiegt ungleich schwerer.

Wie erkennen Sie Privilege Escalation?

Beginnen Sie bei den Feldern, die die Anwendung über einen Benutzer zurückgibt: Rufen Sie Ihr eigenes Profil ab und achten Sie auf alles, was nach Berechtigungen aussieht, etwa role, isAdmin oder permissions. Schicken Sie diese Felder anschließend in einer Aktualisierung mit, auch wenn das Formular sie nicht anzeigt, und prüfen Sie, ob sie bestehen bleiben. Dasselbe gilt für die Registrierung, die oft ein vollständiges Objekt annimmt.

Prüfen Sie danach die Routen selbst. Zeichnen Sie den Verkehr eines Administratorkontos auf, wiederholen Sie jede Anfrage mit der Sitzung eines gewöhnlichen Benutzers und notieren Sie alles, was anders als mit 401 oder 403 beantwortet wird; Burp Suite mit der Erweiterung Autorize erledigt das systematisch. Suchen Sie Admin-Pfade im JavaScript-Bundle und in alten API-Versionen, und wechseln Sie auch die Methode: Mal ist der GET geschützt und der POST auf demselben Pfad nicht.

Scanner finden eine Administrationsseite, die ohne Anmeldung erreichbar ist, aber sie kennen Ihr Rollenmodell nicht und sehen daher nicht, dass Benutzer B darf, was nur Administrator A durfte. Das bleibt Handarbeit. AssistSec prüft diesen Bereich im Rahmen eines Penetrationstests, standardmäßig mit Konten unterschiedlicher Berechtigungsstufen.

Wie verhindern Sie Privilege Escalation?

• Bestimmen Sie die Rolle serverseitig aus der Sitzung. Lesen Sie sie bei jeder Anfrage aus Ihrem eigenen Speicher und übernehmen Sie nie eine Rolle oder Rechteliste aus der Anfrage.
• Arbeiten Sie mit einer Allowlist beschreibbarer Felder. Binden Sie einen Anfragekörper nie direkt an Ihr Datenmodell, sondern benennen Sie ausdrücklich, welche Felder ein Benutzer über sich selbst setzen darf.
• Verweigern Sie standardmäßig. Hängen Sie die Autorisierung an den gesamten Admin-Baum statt an einzelne Routen, damit eine neue Route geschützt ist, bevor jemand daran denkt.
• Prüfen Sie je Aktion, nicht je Oberfläche. Eine ausgeblendete Schaltfläche ist keine Autorisierung; jeder Aufruf dahinter braucht seine eigene Prüfung.
• Verlangen Sie eine erneute Authentifizierung bei schweren Aktionen. Das Zuweisen einer Rolle oder das Ändern einer E-Mail-Adresse verdient einen zusätzlichen Schritt.
• Halten Sie Rechte aktuell und Tokens kurz. Eine entzogene Rolle muss sofort wirken, und Sie müssen Sitzungen und Tokens aktiv widerrufen können.
• Protokollieren Sie Rollenänderungen und testen Sie das Szenario. Ein Benutzer, der sich selbst zum Administrator macht, sollte einen Alarm auslösen; ein Integrationstest, der die Admin-Routen mit Konto B abruft, verhindert Rückfälle.