Forschung an Embedded-Geräten zeigt, dass versteckte, undokumentierte Schnittstellen routinemäßig sicherheitskritische Funktionen unauthentisierten Nutzern exponieren. Endpunkte, die nie in der API-Dokumentation erscheinen, aber in der Produkt-Firmware ausgeliefert werden. Debug-CGIs, veraltete Diagnose-Routen, interne Service-Endpunkte: Die Management-Fläche ist typischerweise größer als die offizielle.
Selbst wo jeder Endpunkt dokumentiert und authentisiert ist, ist die Autorisierungs-Durchsetzung ungleich. Authentisierung gelingt und liefert eine Session; was diese Session darf, hängt davon ab, welcher Handler den Request verarbeitet. In der Praxis werden Rollen-Checks pro Handler implementiert, manche prüfen die Rolle, manche nur die Authentisierung, manche wurden von einem Nutzer-Endpunkt kopiert und nie angepasst. Das Ergebnis ist eine Fläche, auf der die meisten Pfade korrekt regiert sind, und einige still alles gewähren.
Der Produkt-Kontext macht das schlimmer als in einer Web-Applikation. Eine Management-API auf einem Gerät kann Firmware-Installation, Key-Management, Geräte-Konfiguration oder physische Aktuation kontrollieren. Eine administrative Operation zu erreichen ist kein Privilegien-Eskalations-Trophäe, es ist Kontrolle über das Produkt.
Privilegierter Zugang hängt von mehreren technischen Annahmen ab.
- Flächen-Inventar Welche Management-Endpunkte, Dienste und Schnittstellen existieren in der Firmware, einschließlich undokumentierter und Debug-Routen?
- Rollen-Modell Welche Rollen existieren und welche Operationen autorisiert jede?
- Durchsetzungs-Konsistenz Ist der Rollen-Check zentral implementiert oder pro Handler, und wurde jeder Handler verifiziert?
- Versteckte Endpunkte Existieren Debug-, Diagnose- oder veraltete Routen, die das dokumentierte Autorisierungs-Modell umgehen?
- Session-Scope Leakt eine Nutzer-Session Privilegien über Endpunkte, oder trägt die Session selbst mehr Rechte, als die Rolle gewähren sollte?
- Privilegien-Grenzen Was ist die mächtigste Operation, die mit der niedrigsten legitimen Identität erreichbar ist?
- Physischer Impact Welche Management-Operationen übersetzen sich in physische Produkt-Kontrolle, Firmware-Änderung oder Key-Operationen?
Jeder Endpunkt prüfte die Authentisierung. Einer vergaß die Rolle.
Die Management-API authentisiert jeden Request. Die meisten Handler verifizieren die Rolle des Callers, bevor sie handeln. Ein Handler, spät hinzugefügt für ein Diagnose-Feature, prüft nur, ob die Session gültig ist.
Ein authentisierter Normal-Nutzer erreicht die administrative Operation über diesen Handler. Die Session ist legitim, der Endpunkt ist echt, das Produkt akzeptiert die Instruktion. Kein Alarm feuert, потому nichts fehlschlug: Der Autorisierungs-Check lief einfach nie.
Die echte Fläche mappen, dann Rollen-Grenzen auf jedem Pfad testen.
Wir enumerieren die Management-Fläche aus Firmware und Live-Produkt, einschließlich Routen, die nicht in der Dokumentation erscheinen, und testen dann das Autorisierungs-Modell darüber: Welche Operationen jede legitime Identität erreicht, wo Durchsetzung inkonsistent ist, und wie der Pfad mit den niedrigsten Rechten zur mächtigsten Operation aussieht.
- Neue Management-Schnittstelle oder Admin-API
- Rollen- oder Privilegien-Modell eingeführt oder geändert
- Diagnose- oder Debug-Features in Produktions-Firmware
- Firmware-Source oder -Binary zeigt undokumentierte Routen
- Eine gemeldete Schwachstelle betrifft Management-Zugang
- Compliance verlangt Nachweise zur Access-Control-Durchsetzung