Auswirkungen der AuthN/AuthZ-Lücke

Es gilt inzwischen als Allgemeinwissen, dass in der Cloud „Identität der neue Perimeter“ ist. Das ist ein griffiger Satz, den man leicht in eine Präsentation oder einen Artikel einbauen kann, doch daraus umsetzbare Handlungsempfehlungen abzuleiten, ist etwas schwieriger. Heute möchte ich mich auf nur einen Aspekt von Cloud-IAM konzentrieren, den ich die „AuthN/AuthZ-Lücke“ nenne. Tatsächlich tritt dieses Problem bei jeder Form von Föderation auf, doch in der Cloud steht mehr auf dem Spiel, da die Cloud-Management-Ebene stets mit dem Internet verbunden ist.

Zunächst eine kurze Einführung zu AuthN und AuthZ:

• AuthN steht für Authentifizierung. Also der Nachweis, dass Sie eine bestimmte Entität sind. Für uns Normalsterbliche sind das in der Regel ein Benutzername, ein Passwort und eventuell MFA.
• AuthZ steht für Autorisierung. Also die Prüfung, ob eine Aktion zulässig ist. Bei IaaS-Cloud lässt sich das nahezu immer auf einen API-Aufruf zurückführen, selbst wenn Sie die Web-Konsole bzw. das Portal verwenden.

Authentifizierung und Autorisierung sind unterschiedliche Vorgänge mit unterschiedlichen Abläufen. Wenn wir uns auf einer Website anmelden, authentifizieren wir uns, und dadurch entsteht in der Regel eine Sitzung. Wir müssen unsere Anmeldedaten nicht bei jedem Klick erneut eingeben, der Browser sendet einfach ein Token mit, das für einen bestimmten Zeitraum gültig ist. Autorisierungen werden dagegen üblicherweise bei jeder Aktion geprüft, um sicherzustellen, dass wir die erforderlichen Berechtigungen besitzen.

Wenn Sie darüber nachdenken: Sobald Sie dieses Sitzungstoken besitzen, wird es nicht erneut geprüft, sofern nicht etwas im Code eine neue Prüfung erzwingt. Ihre Authentifizierung gilt für die gesamte Sitzung, und damit können Sie alles tun, was im Rahmen Ihrer Autorisierungen liegt. Je nach Plattform bzw. System funktionieren diese temporären Anmeldedaten selbst dann weiter, wenn sie widerrufen wurden oder das Konto vollständig gelöscht ist. Das ist die AuthN/AuthZ-Lücke.

Ich widme diesem Thema viel Zeit, wenn ich Cloud Incident Response unterrichte, denn ich habe festgestellt, dass selbst erfahrene Security-Responder die Konsequenzen nicht immer verstehen. Stellen Sie sich den Fall gestohlener Cloud-Anmeldedaten vor: Sie widerrufen oder löschen die Anmeldedaten, doch der Angreifer verfügt über eine aktive, offene Sitzung und kann möglicherweise weiterhin autorisierte Aktionen ausführen. Das ist … schlecht.

Wie lösen Sie das?

Je nachdem, wie Sie diese Anmeldedaten einsetzen, besteht die einfachste Option meist darin, die Autorisierung zu ändern. Legen Sie einfach eine Deny-Richtlinie für die Entität fest (oder entfernen Sie erlaubte Aktionen), denn diese wird bei jedem API-Aufruf des Angreifers ausgewertet. Das ist zwar die einfachste Option, aber nicht immer die beste, da laufende Aufgaben unterbrochen werden können (gestohlene Anmeldedaten sind nicht immer nur an Benutzer gebunden). Weitere Optionen, abhängig von der Unterstützung durch Ihren Cloud-Anbieter, sind unter anderem:

• Bedingungen hinzufügen, um die Ursprungs-IP für die API-Aufrufe einzuschränken.
• Alle Sitzungen ablehnen, die vor einem bestimmten Datum bzw. einer bestimmten Uhrzeit erstellt wurden.

Dieses Problem tritt eher bei der Föderation in einen Cloud-Anbieter hinein auf als innerhalb des Anbieters. Ich habe gerade einen Test in AWS durchgeführt und verlor den Zugriff auf offene Sitzungen recht schnell, nachdem ich einen IAM-Benutzer gelöscht hatte. Bei der Föderation von einem externen Identitätsanbieter gilt das jedoch nicht zwangsläufig, und selbst innerhalb von AWS prüfen manche Dienste die Anmeldedaten während aktiver Sitzungen nicht erneut (z. B. blieb meine Session-Manager-Sitzung noch etwa 15+ Minuten aktiv, nachdem ich die Rolle gelöscht hatte, die den Zugriff erlaubte).

Das ist keine große unbekannte Schwachstelle, sondern etwas, das Sie bei der Entwicklung Ihrer Cloud-Sicherheitskontrollen und Incident-Response-Playbooks berücksichtigen sollten. Unterschiedliche Arten von Anmeldedaten haben unterschiedliche Lebensdauern – zwischen Cloud-Anbietern ebenso wie innerhalb eines Anbieters. Auch Ihr Identitätsanbieter spielt eine Rolle, ebenso die Stelle, an der Sie versuchen, Anmeldedaten zu widerrufen. Wenn Sie beispielsweise einen Benutzer in Active Directory haben, den Sie dann in AWS föderieren, und dieser Benutzer in AWS eine Rolle annimmt und Sitzungsanmeldedaten für diese Rolle abruft, müssen Sie die Anmeldedaten der angenommenen Rolle widerrufen oder einschränken, auch wenn Sie den Benutzer im AD einschränken. AWS wird nicht wissen, dass die Sitzung des Benutzers aus dem AD nicht mehr gültig ist – erst am Ende der Sitzung, wenn die Authentifizierung erneut validiert wird.

Intern sind wir auf unser Tool Authorization Control umgestiegen, das die Erstellung von Sitzungen mit Einschränkungen per ChatOps unterstützt, ohne Reibungsverluste zu erzeugen, die unsere Entwickler ausbremsen könnten. Es ist noch nicht allgemein verfügbar. Wenn Sie es im Rahmen des Early Access ausprobieren möchten, schreiben Sie mir direkt an rich.mogull@firemon.com.