Tailworms AppSec-Lektion: Privilegiengrenzen prüfen statt nur den Login
Ein praktischer Ablauf für Autorisierungstests, nachvollziehbaren Codekontext und überprüfbare Behebung mit Plexicus.
Mehr als ASPM
Proof-Driven AppSec für Teams, die mit KI entwickeln
Plexicus nutzt AI Swarm Pentest, um autorisierte Anwendungspfade zu erkunden, ausnutzbare Risiken zu validieren und Teams Belege für die Priorisierung der Remediation zu geben.
AI Swarm Pentest ansehenEin erfolgreicher Login ist erst der Anfang eines Sicherheitstests. Er beweist nicht, dass eine angemeldete Identität ausschließlich die vorgesehenen Aktionen ausführen kann. Entscheidend ist die nächste Frage: Was kann diese Identität eine stärker privilegierte Komponente ausführen lassen?
Die Tailworm-Forschenden berichten über Privilegiengrenzen in Tailscale v1.104.2 und headscale v0.29.5. Das sind Forschungsaussagen, keine von Plexicus unabhängig reproduzierten Befunde. Forschungsbericht.
Dieser Beitrag leitet daraus einen Prüfplan für eigene Anwendungen ab. Er behauptet weder eine Schwachstelle in Ihrer Umgebung noch eine Erkennung durch Plexicus. Veröffentlichte Hinweise des Herstellers finden Sie in dessen Sicherheitsmeldungen.
Die Aktion nach der Anmeldung untersuchen
Ein Supportmitarbeiter darf beispielsweise einen Kundenexport ansehen. Der Hintergrundprozess besitzt jedoch Zugangsdaten für sämtliche Kunden. Auch bei korrekter Anmeldung muss dieser Prozess den zulässigen Mandanten des Mitarbeiters berücksichtigen. Login und Auftrag können erfolgreich sein, obwohl die Mandantentrennung versagt.
Dasselbe Prüfmodell passt auf KI-Assistenten mit privilegierten Werkzeugen, Deployment-Webhooks und APIs mit Dienstkonten. Halten Sie fest, wer eine Aktion anfordert, welche Ressource betroffen ist und welche Identität sie tatsächlich ausführt. Die Tailscale-SSH-Dokumentation erläutert dessen eigenes Zugriffsmodell; sie belegt kein identisches Verhalten anderer Anwendungen.
Eine Testmatrix für die Grenze erstellen
Verwenden Sie synthetische Konten und entbehrliche Ressourcen im autorisierten Umfang. Definieren Sie das erwartete Ergebnis vor dem Test.
| Identität | Aktion | Erwarteter Nachweis |
|---|---|---|
| Eigentümer in Mandant A | Eigenen Export lesen | Synthetische Daten und protokollierter Eigentümer |
| Mitglied in Mandant A | Administrator-Export lesen | Abweisung; kein Auftrag angelegt |
| Eigentümer in Mandant B | Export von A lesen | Abweisung; keine fremden Daten |
| Gesperrtes Konto | Alten Downloadlink verwenden | Ergebnis entspricht dokumentierter Sperrregel |
| Privilegierter Hintergrundprozess | Auftrag außerhalb der Rechte des Aufrufers | Rechteprüfung bei der tatsächlichen Aktion |
Ein HTTP-Status reicht nicht aus. Eine abgewiesene Anfrage könnte trotzdem Arbeit einreihen. Prüfen Sie Antwort, erzeugte Ressource und Auditereignis. OWASP empfiehlt minimale Rechte, standardmäßige Verweigerung und Autorisierungsprüfungen bei jeder Anfrage. Autorisierungsleitfaden.
Zustandsänderungen zwischen Prüfung und Ausführung testen
Mitgliedschaften, Eigentümer und Freigaben können sich ändern. MITRE beschreibt die anfällige Trennung zwischen Prüfung und Nutzung als TOCTOU-Rennbedingung. CWE-367.
Bei einem Export ist festzulegen, welche Prüfungen beim Eingang, beim Start und beim Download erforderlich sind. Welche Änderung muss einen wartenden Auftrag ungültig machen? Testen Sie diese Entscheidung gezielt mit künstlichen Daten. Begrenzen Sie parallele Tests, damit andere Nutzer unbeeinträchtigt bleiben.
Validierung, Code und Behebung verbinden
Plexicus beschreibt AI Swarm Pentest für abgegrenzte Prüfungen mit Nachweisen und Deep Code Analysis für Codefluss und Auswirkungskontext. Diese Beschreibungen ermöglichen die Planung dieses Ablaufs. Sie garantieren keine Abdeckung jedes Infrastrukturprozesses, Protokolls oder zeitabhängigen Fehlers.
Beginnen Sie mit einer konkreten Frage: Kann ein Mitglied den Exportprozess zum Lesen eines synthetischen Datensatzes eines anderen Mandanten bewegen? Vereinbaren Sie Identitäten, Systeme, ausgeschlossene Aktionen und Abbruchbedingungen. Das Ergebnis muss den getesteten Build und die Konfiguration nennen. Ungeprüfte Pfade bleiben ungeprüft.
Verknüpfen Sie anschließend das beobachtete Verhalten mit dem Code für Mandantenauswahl, Ressourcenauflösung und Auftragserstellung. Ein Änderungsvorschlag sollte zeigen, wo die Rechte des Aufrufers verloren gehen. Wiederholen Sie nach der Änderung sowohl die verbotene als auch die erlaubte Anfrage. Wenn beide scheitern, ist die Funktion nicht korrekt repariert.
Bewahren Sie bereinigte Anfrage und Antwort, beobachtete Wirkung, Codestelle, erwartete Regel und Nachtest auf. Unterscheiden Sie gemeldet, reproduziert, Änderung vorgeschlagen, zusammengeführt und erneut geprüft. Ein Merge belegt noch keine wirksame Grenze im Produktivstand.
Nachgewiesene Grenzen messen
Erfassen Sie, wie viele kritische Abläufe eine ausdrückliche Regel, einen reproduzierbaren Negativtest und ein geprüftes Ergebnis auf der bereitgestellten Version besitzen. Daraus lassen sich nächste Maßnahmen ableiten.
Möchten Sie diesen Ablauf anwenden? AI Swarm Pentest anfragen oder Deep Code Analysis kennenlernen. Bringen Sie einen kritischen Ablauf und sein Rollenmodell mit, um eine konkrete Grenze zu definieren.
