Zwei reale Beispiele dafür, warum die Begrenzung von Berechtigungen funktioniert: Lehren aus dem AWS Customer Incident Response Team

von Richard Billington, übersetzt durch David Surey

Willkommen zu einem weiteren Blogbeitrag des AWS Customer Incident Response Teams (CIRT)! In diesem Beitrag betrachten wir zwei Ereignisse, an denen das Team beteiligt war. Dabei blicken wir auf ein Thema, das regelmäßig diskutiert, aber manchmal auch missverstanden wird: Minimale Berechtigungen. Genauer gesagt betrachten wir die Idee, dass die Vorteile der Reduzierung von Berechtigungen in praxisnahen Anwendungsfällen nicht immer die Verwendung des absolut minimalen Satzes an Berechtigungen erfordern. Stattdessen müssen Sie die Kosten und den Aufwand der Erstellung und Verwaltung von Berechtigungen gegen die damit erreichte Risikoreduktion abwägen, um sicherzustellen, dass Ihre Berechtigungen für Ihre Bedürfnisse angemessen sind.

Um den VP und Distinguished Engineer bei Amazon Security, Eric Brandwine[EN], zu zitieren [EN,extern]: „Minimale Berechtigungen bedeuten maximalen Aufwand.“ Dies bedeutet, dass das Erstellen und Verwalten des kleinstmöglichen Satzes an Berechtigungen, der für eine bestimmte Aufgabe erforderlich ist, den größten Aufwand erfordern wird. Insbesondere dann, wenn sich die Kundenbedürfnisse und Service Features im Laufe der Zeit ändern. Der Zusammenhang zwischen Aufwand und Berechtigungsreduzierung ist jedoch nicht linear. Daher sollten Sie sich fragen: Wie bringen Sie den Aufwand der Berechtigungsreduzierung mit den daraus resultierenden Vorteilen in Einklang?

Leider ist dies keine einfach zu beantwortende Frage. Sie müssen die Wahrscheinlichkeit eines unerwünschten Ereignisses, die Auswirkungen, falls dieses Ereignis eintritt, sowie die Kosten und den Aufwand für die Verhinderung (oder Erkennung und Wiederherstellung) dieses Ereignisses berücksichtigen. Auch Anforderungen wie Ihre Unternehmensziele und regulatorischen Anforderungen müssen in Ihren Entscheidungsprozess einfließen. Natürlich müssen Sie sich nicht nur mit einem möglichen Problem befassen, sondern mit vielen. Oft kann es sinnvoll sein, mit einem groben Satz von Berechtigungen zu beginnen und sie dann zu verfeinern, wenn Sie mehr Kenntnisse darüber haben, welches Sicherheitsniveau erforderlich ist. Sie können auch Service-Control-Policies (SCPs) [EN] verwenden, um einen Satz von Berechtigungsleitplanken bereitzustellen, wenn Sie AWS Organizations nutzen. In diesem Beitrag erzählen wir zwei reale Geschichten. In diesen Fällen trug die Begrenzung der AWS Identity and Access Management (IAM)-Berechtigungen dazu bei, die Auswirkungen von Sicherheitsereignissen zu begrenzen. Allerdings erforderte der verwendete Berechtigungssatz nicht den maximalen Aufwand.

Geschichte 1: Auf der Jagd nach Anmeldedaten

In dieser Geschichte des AWS CIRT sehen wir, wie ein Angreifer sein Ziel nicht erreichen konnte, da die Zugriffsrechte, die er erlangt hatte – die eines Datenbankadministrators – nicht über die IAM-Berechtigungen verfügten, die er suchte.

Hintergrund und AWS CIRT-Engagement

Ein Kunde wandte sich an uns. Er hatte in seinen lokalen Systemen und in einigen seiner AWS-Konten unbefugte Aktivitäten entdeckt. Der Kunde verfügte grundsätzlich über eigene Bewältigungsstrategien. Er suchte aber nach einem zusätzlichen Team mit AWS-Kenntnissen, um Ihm bei seiner Untersuchung zu helfen. Die von unserem Team bereitgestellte Unterstützung ermöglichte es dem Kunden, sich auf die Analyse der lokalen Systeme zu konzentrieren.

Vor unserem Engagement hatte der Kunde bereits erste Eindämmungsmaßnahmen ergriffen. Dazu gehörten die Rotation von Anmeldedaten, der Widerruf temporärer Anmeldedaten und die Isolierung betroffener Systeme. Außerdem hatten sie eine gute Vorstellung davon, auf welche Konten föderierter Benutzer der Angreifer zugegriffen hatte.

Der Schlüsselpunkt jedes AWS CIRT-Engagements ist die Anfrage des Kunden. Alles, was unser Team tut, fällt in den Bereich der Kundenseite des AWS Shared Responsibility Model, daher wollen wir sicherstellen, dass wir auf das gewünschte Ergebnis des Kunden fokussiert sind. In diesem Fall war die Anfrage klar – überprüfen Sie den potenziell unbefugten Zugriff durch föderierte Benutzer und untersuchen Sie die unerwünschten AWS-Aktionen, die von diesen Benutzern während des bekannten Zeitraums durchgeführt wurden. Um besser zu verstehen, was „unerwünscht“ war, sprachen wir mit dem Kunden. Wir wollten herausfinden, was einen typischen Arbeitstag für diese Benutzer ausmachte. So konnten wir einschätzen, welche Aktionen normalerweise zu erwarten gewesen wären. Die Benutzer konzentrierten sich in erster Linie auf die Arbeit mit Amazon Relational Database Service (RDS).

Analyse und Ergebnisse

Für diesen Teil der Geschichte werden wir uns auf einen einzigen föderierten Benutzer konzentrieren, dessen scheinbare Aktionen wir untersucht haben, da die anderen föderierten Benutzer vom Angreifer nicht in nennenswerter Weise missbraucht worden waren. Wir kannten die ungefähren Start- und Enddaten, auf die wir uns konzentrieren konnten, und hatten herausgefunden, dass der Angreifer eine Reihe unerwünschter Aktionen durchgeführt hatte.

Nach der Überprüfung der Aktionen war klar, dass der Angreifer innerhalb eines Zeitraums von 2 Stunden zu drei separaten Gelegenheiten eine Anmeldung in der Konsole vorgenommen hatte. Jedes Mal versuchte der Angreifer, eine Teilmenge der folgenden Aktionen durchzuführen:

• CreateAccessKey – Erstellen eines neuen AWS-Geheimschlüssels
• CreateLoginProfile – Erstellen eines Konsolenpassworts für einen bestimmten IAM-Benutzer
• UpdateAccessKey – Ändern eines Zugriffsschlüssels von inaktiv zu aktiv (oder umgekehrt)
• DeleteAccessKey – Löschen eines Zugriffsschlüsselpaares
• PutRolePolicy – Hinzufügen oder Aktualisieren einer Inline-IAM-Richtlinie
• CreatePolicyVersion – Erstellen einer neuen Version einer vorhandenen verwalteten Richtlinie

Hinweis: Diese Liste enthält nur die Aktionen, die in AWS CloudTrail als readOnly = false angezeigt werden, da diese Aktionen oft (aber nicht immer) die

wirkungsvolleren sind, und das Potenzial haben, die AWS-Umgebung aktiv zu verändern.

Hier wurde der Nutzen der Berechtigungsbeschränkung deutlich. Sobald diese Liste erstellt war, fiel uns auf, dass für alle aufgelisteten Aktionen zwei Felder vorhanden waren:

"errorCode": "Client.UnauthorizedOperation",
"errorMessage": "Sie sind nicht berechtigt, diesen Vorgang durchzuführen. [Rest der Nachricht]"

Wie sich herausstellte, wurde jede einzelne nicht-lesbare Aktion, die vom Angreifer versucht wurde, abgelehnt, da das Konto des föderierten Benutzers nicht über die erforderlichen IAM-Berechtigungen verfügte.

Kommunikation mit dem Kunden und Ergebnis

Nachdem wir die Ergebnisse bestätigt hatten, führten wir ein Telefonat mit dem Kunden, um die Ergebnisse zu besprechen. Wie Sie sich vorstellen können, waren sie erfreut, dass die Ergebnisse keine wesentlichen Auswirkungen auf ihre Daten zeigten, und sagten, dass zu diesem Zeitpunkt keine weiteren Untersuchungen oder Maßnahmen erforderlich seien.

Welche IAM-Berechtigungen hatte der föderierte Benutzer, die das Ausführen der vom Angreifer versuchten Aktionen verhinderten?

Die Antwort bestand tatsächlich nicht darin, den absolut minimalen Satz an Berechtigungen zu verwenden, der für die Aufgaben des Benutzers erforderlich war. Stattdessen hatte der föderierte Benutzer eine Rolle, die keine Erlaubnis (Allow-Anweisung) für die IAM-Aktionen hatte, die der Angreifer versuchte – die Arbeitsaufgaben des Benutzers erforderten diese nicht. Ohne eine explizite Erlaubnis wurden die versuchten IAM-Aktionen abgelehnt, da IAM-Richtlinien jede Aktion standardmäßig nicht erlauben. In diesem Fall bedeutete das einfache Fehlen der gewünschten IAM-Berechtigungen, dass der Angreifer sein Ziel nicht erreichen konnte und den Zugriff beendete. Wir werden nie erfahren, was sein eigentliches Ziel war, aber der Versuch, Zugriffsschlüssel und Passwörter zu erstellen sowie Richtlinien zu aktualisieren, lässt vermuten, dass er versucht haben könnte, einen anderen Zugriffsweg auf dieses AWS-Konto zu schaffen.

Geschichte 2: Mehr Instanzen für Kryptomining

In dieser Geschichte des AWS CIRT sehen wir, wie das Unvermögen eines Angreifers, zusätzliche Amazon Elastic Compute Cloud (Amazon EC2)-Instanzen zu erstellen, dazu führte, dass der Angreifer sein Ziel nicht erreichen konnte und seine Ambitionen aufgab.

Hintergrund und AWS CIRT-Engagement

Unsere zweite Geschichte handelt von einem Kunden, der ein AWS-Konto nutzte, um neue Drittanbieter-Software zu testen, die den Amazon Elastic Container Service (Amazon ECS) verwendet. Dieser Kunde hatte Amazon GuardDuty aktiviert und stellte fest, dass er GuardDuty-Warnungen für Erkennungen im Zusammenhang mit CryptoCurrency:EC2/BitcoinTool [EN] erhielt.

Da dieses Konto neu war und nur für Softwaretests genutzt wurde, erkannte der Kunde, dass die Erkennung mit dem Amazon ECS-Cluster zusammenhing. Daraufhin beschloss er, alle Ressourcen im Konto zu löschen und neu aufzubauen. Kurze Zeit später erhielt er eine ähnliche GuardDuty-Warnung für den neuen Amazon ECS-Cluster, den er eingerichtet hatte. Diese zweite Erkennung führte dazu, dass das Sicherheitsteam des Kunden und von AWS einbezogen wurden, um zu versuchen, herauszufinden, was diese Erkennung verursacht hatte. Das Sicherheitsteam des Kunden konzentrierte sich darauf, die Tasks zu überprüfen, die auf dem Cluster ausgeführt wurden, während das AWS CIRT die Aktionen im AWS-Konto überprüfte und Einblicke in die GuardDuty-Erkennung und deren mögliche Ursache gab.

Analyse und Ergebnisse

Bei der Zusammenarbeit mit dem Kunden stellten wir schnell fest, dass die Amazon ECS-Taskdefinition des Drittanbieters, die der Kunde verwendete, unbeabsichtigt eine Webschnittstelle für das Internet offenlegte. Diese Schnittstelle ermöglichte es unauthentifizierten Benutzern, Befehle auf dem System auszuführen. Dies erklärte, warum die gleiche Warnung kurz nach der Neueinrichtung ebenfalls empfangen wurde.

An dieser Stelle nimmt die Geschichte eine positivere Wendung. Die Analyse der AWS CloudTrail-Protokolle durch die AWS CIRT-Mitarbeiter ergab, dass es eine Reihe von Versuchen gab, die Anmeldedaten der mit der Amazon ECS-Aufgabe verknüpften Task-IAM-Rolle zu verwenden. Die meisten Aktionen versuchten, über RunInstances-Aufrufe mehrere Amazon EC2-Instanzen zu starten. Jede dieser Aktionen sowie die anderen versuchten Aktionen schlugen jedoch mit einer Client.UnauthorizedOperation– oder AccessDenied-Fehlermeldung fehl.

Anschließend arbeiteten wir mit dem Kunden zusammen, um die Berechtigungen der Task-IAM-Rolle zu verstehen. Auch hier hätten die Berechtigungen stärker eingeschränkt werden können. Diesmal entsprach das Ziel des Angreifers – das Ausführen einer Reihe von Amazon EC2-Instanzen (höchstwahrscheinlich für heimliches Kryptomining) – jedoch nicht der der Rolle zugewiesenen Richtlinie:

{
    "Version": "2012-10-17",
    "Statement": [
        {
          "Effect": "Allow",
          "Action": "s3:*",
          "Resource": "*"
        }
    ]
}

Das AWS CIRT empfahl, Richtlinien zu erstellen, um die zulässigen Aktionen weiter einzuschränken, spezifische Ressourcen soweit wie möglich anzugeben und möglicherweise auch einige Bedingungen hinzuzufügen, um andere Aspekte des Zugriffs zu begrenzen (die beiden im letzten Jahr eingeführten Bedingungsschlüssel, um den Ort zu begrenzen, von dem aus Amazon EC2-Instanzanmeldedaten verwendet werden können [EN]). Allein die Beschränkung des Zugriffs auf Amazon Simple Storage Service (Amazon S3) in der Richtlinie führte jedoch dazu, dass der Angreifer sich entschied, nur mit dem einen laufenden Amazon ECS-Task Kryptomining zu betreiben, anstatt einer größeren Zahl von Amazon EC2-Instanzen.

Kommunikation mit dem Kunden und Ergebnis

Nach der Berichterstattung der Ergebnisse an den Kunden gab es zwei klare nächste Schritte: Erstens, entfernen Sie die jetzt unerwünschte und nicht vertrauenswürdige Amazon ECS-Ressource aus Ihrem AWS-Konto. Zweitens, überprüfen und überarbeiten Sie den Amazon ECS-Task so, dass der Zugriff auf die Webschnittstelle nur autorisierten Benutzern gewährt wird. Im Rahmen dieser Neukonzeption wurde eine Amazon S3-Richtlinie ähnlich wie „Erlaubt Lese- und Schreibzugriff auf Objekte in einem S3-Bucket“ [EN] empfohlen. Hierdurch werden Amazon S3-Bucket-Aktionen von Amazon S3-Objekt-Aktionen getrennt. Wenn Anwendungen die Notwendigkeit haben, Objekte in Amazon S3 zu lesen und zu schreiben, haben sie normalerweise nicht die Notwendigkeit, ganze Buckets zu erstellen oder zu löschen (oder die Versionierungseinstellungen dieser Buckets zu verändern).

Einige hilfreiche Werkzeuge

Wir haben gerade gesehen, wie die Begrenzung von Berechtigungen bei zwei verschiedenen Sicherheitsereignissen geholfen hat. Lassen Sie uns nun betrachten, was Ihnen dabei helfen kann, Ihre IAM-Berechtigungen auf ein angemessenes Maß zu reduzieren. Es gibt eine Reihe von Ressourcen, die verschiedene Ansätze dafür aufzeigen:

Der erste Ansatz besteht darin, AWS IAM Access Analyzer zu verwenden, um IAM-Richtlinien basierend auf Zugriffsaktivitäten aus Protokolldaten zu generieren. Diese können dann durch das Hinzufügen von Bedingungselementen [EN] weiter verfeinert werden. Wir haben bereits ein paar Blogbeiträge zu genau diesem Thema:

• AWS IAM Access Analyzer erleichtert die Umsetzung von Berechtigungen mit minimalsten Rechten, indem er IAM-Richtlinien auf Basis von Zugriffsaktivitäten generiert [EN]
• Verwenden Sie AWS IAM Access Analyzer, um IAM-Richtlinien basierend auf in Ihren Organisationstraces gefundenen Zugriffsaktivitäten zu generieren [EN]

Der zweite Ansatz ist ähnlich und besteht darin, den Richtlinienumfang basierend auf den letzten Zugriffen zu reduzieren:

• Überprüfen Sie die Informationen zum letzten Zugriff, um ungenutzte EC2-, IAM- und Lambda-Berechtigungen zu identifizieren und den Zugriff für Ihre IAM-Rollen zu verschärfen [EN]

Der dritte Ansatz ist eine manuelle Methode zum Erstellen und Verfeinern von Richtlinien, um den erforderlichen Aufwand zu reduzieren. Dafür können Sie mit einer geeigneten AWS-verwalteten IAM-Richtlinie [EN] oder einem von AWS bereitgestellten Beispiel für eine Richtlinie als Ausgangspunkt beginnen. Anschließend können Sie Aktionen, Ressourcen und Bedingungen hinzufügen oder entfernen – nach Bedarf unter Verwendung von Platzhaltern -, um Ihren Aufwand und die Berechtigungsreduzierung in Einklang zu bringen.

Ein Beispiel für die Abstimmung von Aufwand und Berechtigungen finden Sie im IAM-Tutorial „Erstellen und Anfügen Ihrer ersten kundenspezifischen Richtlinie“ [EN]. In dem Beispiel erstellen die Autoren eine Richtlinie, die iam:Get* und iam:List:* Aktionen erlaubt.

Möglicherweise sind nicht alle diese Aktionen tatsächlich erforderlich. Dennoch ist dies eine gute Herangehensweise. So können ähnliche Aktionen zusammengefasst werden. Gleichzeitig werden Aktionen minimiert, die unerwünschten Zugriff ermöglichen – wie iam:Create* oder iam:Delete*. Ein weiteres Beispiel für diese Abstimmung wurde zuvor im Zusammenhang mit Amazon S3 [EN] erwähnt, bei dem der Zugriff zum Erstellen, Löschen und Lesen von Objekten, aber nicht zum Ändern der Konfiguration des Buckets, in dem sich diese Objekte befinden, erlaubt wurde.

Neben der Einschränkung von Berechtigungen empfehlen wir Ihnen auch, eine geeignete Erkennungs- und Reaktionsfähigkeit einzurichten. Dies ermöglicht es Ihnen, zu erkennen, wenn ein Problem aufgetreten ist, und die Werkzeuge bereitzustellen, um das Problem einzudämmen und zu beheben. Weitere Einzelheiten zur Durchführung von Incident-Response in einem AWS-Konto finden Sie im AWS-Leitfaden zur Sicherheitsvorfall-Reaktion [EN].

Es gibt auch zwei Dienste, die bei den hier vorgestellten Geschichten verwendet wurden – Amazon GuardDuty und AWS CloudTrail. Amazon GuardDuty ist ein Bedrohungserkennungsdienst, der Ihre AWS-Konten und Workloads kontinuierlich auf schädliche Aktivitäten überwacht. Es ist ein hervorragender Weg, um nach unerwünschter Aktivität in Ihren AWS-Konten zu suchen. AWS CloudTrail protokolliert Aktivitäten in Ihrer gesamten AWS-Infrastruktur. Diese Protokolle wurden vom AWS CIRT-Team für die Analyse der beiden Geschichten verwendet. Stellen Sie sicher, dass beide korrekt eingerichtet sind. Dies ist ein wirkungsvoller erster Schritt zur Verbesserung Ihrer Bedrohungserkennung und Incident-Response-Fähigkeit in AWS.

Fazit

In diesem Beitrag haben wir zwei Beispiele betrachtet, in denen die Begrenzung von Berechtigungen während eines Sicherheitsereignisses positive Ergebnisse lieferte. Im zweiten Fall hätte die verwendete Richtlinie die Berechtigungen wahrscheinlich noch weiter einschränken sollen, aber selbst so war sie eine effektive präventive Kontrolle, um den unbefugten Benutzer daran zu hindern, sein vermutetes Ziel zu erreichen.

Hoffentlich bieten diese Geschichten neue Erkenntnisse für die Art und Weise, wie Ihre Organisation über das Setzen von Berechtigungen nachdenkt, und dabei den Aufwand für die Erstellung der Berechtigungen berücksichtigt. Diese Geschichten sind ein gutes Beispiel dafür, wie der Einstieg in den Weg zu minimalen Berechtigungen dabei helfen kann, unbefugte Benutzer aufzuhalten. Keines der Szenarien hatte Richtlinien, die den minimalen Berechtigungen entsprachen, aber die verwendeten Richtlinien waren restriktiv genug, um zu verhindern, dass die unbefugten Benutzer ihre Ziele erreichten, was zu minimalen Auswirkungen für die Kunden führte. Das AWS CIRT empfahl in beiden Fällen jedoch eine weitere Reduzierung des Geltungsbereichs der verwendeten IAM-Richtlinien.

Schließlich haben wir ein paar Möglichkeiten aufgezeigt, wie Sie Berechtigungen reduzieren können – zum einen durch den Einsatz von Werkzeugen zur Unterstützung bei der Richtlinienerstellung und zum anderen durch das Bearbeiten vorhandener Richtlinien, damit sie besser zu Ihren spezifischen Bedürfnissen passen. Sie können damit beginnen, Ihre bestehenden Richtlinien mit den Empfehlungen von Access Analyzer abzugleichen [EN], inhaltslose Platzhalter-Zeichen (*) in einigen Ihrer bestehenden IAM-Richtlinien zu entfernen oder Ihre SCPs zu implementieren und zu verfeinern.

Über die Autoren

Richard Billington ist der Incident Response Watch Lead für die Region Asien-Pazifik im AWS Customer Incident Response Team (einem Team, das AWS-Kunden bei laufenden Sicherheitsereignissen unterstützt). Außerdem hilft er Kunden dabei, sich mithilfe von Ereignissimulationen auf Sicherheitsereignisse vorzubereiten. Privat ist er begeisterter Tierfotograf und Fan von Dr Pepper (was in Australien nur schwer in größeren Mengen zu bekommen ist).