IAM-Fehlkonfigurationen

In der Cloud ist die Identität der neue Perimeter. IAM (Identity and Access Management) legt fest, wer was tun darf. Ein Fehler in IAM ermöglicht es einem Angreifer, sich von einem Ausgangspunkt mit geringen Berechtigungen bis zur vollständigen Kontrolle über das Konto vorzuarbeiten.

• Benutzer, Rollen und Servicekonten sind Identitäten
• Richtlinien definieren Berechtigungen
• Fehlkonfigurierte Richtlinien sind das größte Cloud-Risiko

Die meisten Rechteausweitungen in der Cloud sind ein IAM-Problem.

AWS IAM umfasst drei grundlegende Bausteine, die Sie verstehen müssen:

• Benutzer — langlebige Identitäten mit Zugriffsschlüsseln
• Rollen — temporäre Identitäten, die von Benutzern oder Diensten übernommen werden können
• Richtlinien — JSON-Dokumente, die Aktionen für Ressourcen erlauben oder verweigern

Eine zu weit gefasste Richtlinie führt zu übermäßigen Berechtigungen.

Das gefährlichste IAM-Muster ist eine Wildcard-Richtlinie. Sie gewährt jede Aktion für jede Ressource.

Wenn ein Angreifer eine Identität mit dieser Richtlinie kompromittiert, kontrolliert er das gesamte Konto.

Sobald Sie über eine Zugangsdaten verfügen, listen Sie auf, was damit möglich ist. IAM verfügt über Lese-APIs, die zugewiesene Richtlinien offenlegen.

Manche Konten gewähren gewöhnlichen Benutzern sogar iam:Get* und iam:List* und liefern Ihnen damit eine kostenlose Übersicht.

Ein klassischer Eskalationsweg: Ein Benutzer verfügt über iam:PassRole und eine Berechtigung zum Erstellen von Diensten. Er kann eine Ressource starten, die eine Rolle mit hohen Berechtigungen übernimmt, und deren Zugriff erben.

• Der Benutzer verfügt über ec2:RunInstances + iam:PassRole
• Er startet eine EC2-Instanz, der eine Administratorrolle zugewiesen ist
• Die Instanz besitzt nun Administrator-Zugangsdaten, die der Benutzer abruft

Der Benutzer hatte nie direkt Administratorrechte, hat sie aber durch Rechteausweitung erlangt.

Einzelne Berechtigungen können harmlos sein, aber in Kombination zu Wegen der Rechteausweitung werden. Zu den bekannten riskanten Kombinationen gehören:

• iam:CreatePolicyVersion — eine vorhandene Richtlinie so umschreiben, dass sie Administratorrechte gewährt
• iam:AttachUserPolicy — sich selbst AdministratorAccess zuweisen
• iam:CreateAccessKey für einen anderen Benutzer — dessen Identität übernehmen
• sts:AssumeRole für eine Rolle mit zu weitreichendem Vertrauen

Tools erfassen diese Kombinationen automatisch.

Rollen verfügen über eine Vertrauensrichtlinie, die festlegt, wer sie übernehmen darf. Eine zu weit gefasste Vertrauensrichtlinie ist eine Hintertür.

Wenn eine Rolle versehentlich dem gesamten Konto oder sogar einem externen Konto vertraut, kann ein Angreifer sie übernehmen.

Jede Kombination von Richtlinien manuell zu prüfen, ist mühsam. Tools ermitteln die Wege der Rechteausweitung für Sie.

• Pacu — AWS-Exploitation-Framework mit Modulen zur Rechteausweitung
• PMapper — stellt IAM-Beziehungen als Graph dar und findet Kanten zur Rechteausweitung
• enumerate-iam — probiert per Brute-Force aus, welche API-Aufrufe ein Schlüssel ausführen kann

Berechtigungen können auf zwei Arten gewährt werden, und Angreifer prüfen beide:

• Verwaltete Richtlinien — wiederverwendbar und mehreren Identitäten zugewiesen
• Inline-Richtlinien — direkt in einen einzelnen Benutzer oder eine einzelne Rolle eingebettet

Inline-Richtlinien werden bei Audits leicht übersehen und verbergen daher häufig übermäßige Berechtigungen. Erfassen Sie bei der Bewertung einer Identität immer beide Arten.

Die Lösung für IAM-Fehlkonfigurationen ist Least Privilege: Gewähren Sie nur die exakt benötigten Berechtigungen.

• Ersetzen Sie Wildcards durch explizite Aktionen und Ressourcen-ARNs
• Verwenden Sie Rollen mit kurzlebigen Zugangsdaten statt langlebiger Schlüssel
• Prüfen Sie ungenutzte Berechtigungen mit Access Analyzer
• Erzwingen Sie MFA für privilegierte Identitäten

Ihr Bericht sollte jeden Befund einer Behebung nach dem Least-Privilege-Prinzip zuordnen.

Das Testen von Rechteausweitungen verändert aktiv den Kontostatus. Gehen Sie vorsichtig vor:

• Das Erstellen von Richtlinien, Schlüsseln oder Rollen ist ein Eingriff; holen Sie dafür eine schriftliche Genehmigung ein
• Dokumentieren Sie jede Änderung, damit sie rückgängig gemacht werden kann
• Bevorzugen Sie die schreibgeschützte Erfassung, um einen Weg zunächst nachzuweisen, bevor Sie ihn ausnutzen

Oft reicht der Nachweis, dass ein Weg zur Rechteausweitung existiert; Sie müssen ihn nicht immer vollständig ausnutzen.

Welche Kombination von Berechtigungen stellt einen klassischen AWS-Weg zur Rechteausweitung dar?

Sie haben gelernt, warum IAM der tatsächliche Perimeter der Cloud ist und wie Angreifer ihn ausnutzen.

• Richtlinien mit Wildcards wie Action:* Resource:* sind katastrophal
• iam:PassRole + das Erstellen von Diensten ermöglicht eine Rechteausweitung
• Zu weit gefasste Vertrauensrichtlinien ermöglichen es Angreifern, Rollen zu übernehmen
• Tools wie Pacu und PMapper automatisieren die Erkennung von Angriffswegen
• Die Behebung besteht immer in der Umsetzung von Least Privilege

Als Nächstes sehen wir uns S3 und die Offenlegung von Storage an.