German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Organisationshierarchie

Konten

In AWS gibt es ein Stammkonto, das der übergeordnete Container für alle Konten Ihrer Organisation ist. Sie müssen jedoch nicht dieses Konto verwenden, um Ressourcen bereitzustellen. Sie können andere Konten erstellen, um verschiedene AWS-Infrastrukturen voneinander zu trennen.

Dies ist aus Sicherheitssicht sehr interessant, da ein Konto nicht auf Ressourcen eines anderen Kontos zugreifen kann (außer es werden speziell erstellte Brücken verwendet), sodass Sie Grenzen zwischen Bereitstellungen erstellen können.

Daher gibt es zwei Arten von Konten in einer Organisation (wir sprechen von AWS-Konten und nicht von Benutzerkonten): ein einzelnes Konto, das als Verwaltungskonto festgelegt ist, und ein oder mehrere Mitgliedskonten.

  • Das Verwaltungskonto (das Stammkonto) ist das Konto, das Sie zur Erstellung der Organisation verwenden. Vom Verwaltungskonto der Organisation aus können Sie Folgendes tun:

  • Konten in der Organisation erstellen

  • Andere vorhandene Konten zur Organisation einladen

  • Konten aus der Organisation entfernen

  • Einladungen verwalten

  • Richtlinien auf Entitäten (Stämme, OUs oder Konten) innerhalb der Organisation anwenden

  • Integration mit unterstützten AWS-Diensten aktivieren, um Dienstfunktionalität in allen Konten der Organisation bereitzustellen.

  • Es ist möglich, sich als Root-Benutzer mit der E-Mail-Adresse und dem Passwort anzumelden, die zur Erstellung dieses Stammkontos/der Organisation verwendet wurden.

Das Verwaltungskonto hat die Verantwortlichkeiten eines Zahlungskontos und ist dafür verantwortlich, alle Gebühren zu zahlen, die von den Mitgliedskonten angefallen sind. Sie können das Verwaltungskonto nicht ändern.

  • Mitgliedskonten bilden alle anderen Konten in einer Organisation. Ein Konto kann gleichzeitig nur Mitglied einer Organisation sein. Sie können einem Konto eine Richtlinie zuweisen, um Steuerungen nur auf dieses eine Konto anzuwenden.

  • Mitgliedskonten müssen eine gültige E-Mail-Adresse verwenden und können einen Namen haben. Im Allgemeinen können sie die Abrechnung nicht verwalten (aber ihnen könnte der Zugriff darauf gewährt werden).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Organisationseinheiten

Konten können in Organisationseinheiten (OU) gruppiert werden. Auf diese Weise können Sie Richtlinien für die Organisationseinheit erstellen, die auf alle Unterkonten angewendet werden. Beachten Sie, dass eine OU andere OUs als Unterkonten haben kann.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Service Control Policy (SCP)

Eine Service Control Policy (SCP) ist eine Richtlinie, die die Dienste und Aktionen spezifiziert, die Benutzer und Rollen in den Konten verwenden können, die von der SCP betroffen sind. SCPs sind ähnlich wie IAM-Berechtigungsrichtlinien, gewähren jedoch keine Berechtigungen. Stattdessen legen SCPs die maximalen Berechtigungen für eine Organisation, eine organisatorische Einheit (OU) oder ein Konto fest. Wenn Sie eine SCP an Ihre Organisationswurzel oder eine OU anhängen, beschränkt die SCP die Berechtigungen für Entitäten in Mitgliedskonten.

Dies ist der EINZIGE Weg, um selbst den Root-Benutzer daran zu hindern, etwas zu tun. Zum Beispiel könnte es verwendet werden, um Benutzer daran zu hindern, CloudTrail zu deaktivieren oder Backups zu löschen. Der einzige Weg, dies zu umgehen, besteht darin, auch das Masterkonto zu kompromittieren, das die SCPs konfiguriert (das Masterkonto kann nicht blockiert werden).

Beachten Sie, dass SCPs nur die Prinzipale im Konto einschränken, sodass andere Konten nicht betroffen sind. Dies bedeutet, dass das Verweigern von s3:GetObject durch eine SCP Personen nicht daran hindert, auf einen öffentlichen S3-Bucket in Ihrem Konto zuzugreifen.

Beispiele für SCPs:

  • Root-Konto vollständig verweigern

  • Nur bestimmte Regionen zulassen

  • Nur weiße Dienste zulassen

  • Deaktivieren von GuardDuty, CloudTrail und S3 Public Block Access verweigern

  • Löschen oder Ändern von Sicherheits-/Incident-Response-Rollen verweigern

  • Löschen von Backups verweigern

  • Erstellen von IAM-Benutzern und Zugriffsschlüsseln verweigern

Finden Sie JSON-Beispiele unter https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name ist der eindeutige Name, den jede Ressource innerhalb von AWS hat, er ist wie folgt aufgebaut:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Hinweis: In AWS gibt es 4 Partitionen, aber nur 3 Möglichkeiten, sie zu benennen:

  • AWS Standard: aws

  • AWS China: aws-cn

  • AWS US öffentliches Internet (GovCloud): aws-us-gov

  • AWS Secret (US Classified): aws

IAM - Identitäts- und Zugriffsverwaltung

IAM ist der Dienst, der es Ihnen ermöglicht, Authentifizierung, Autorisierung und Zugriffskontrolle innerhalb Ihres AWS-Kontos zu verwalten.

  • Authentifizierung - Prozess zur Definition einer Identität und deren Überprüfung. Dieser Prozess kann unterteilt werden in: Identifizierung und Überprüfung.

  • Autorisierung - Bestimmt, auf welche Ressourcen eine Identität innerhalb eines Systems zugreifen kann, sobald sie authentifiziert wurde.

  • Zugriffskontrolle - Die Methode und der Prozess, wie der Zugriff auf eine sichere Ressource gewährt wird.

IAM kann durch seine Fähigkeit definiert werden, Authentifizierungs-, Autorisierungs- und Zugriffskontrollmechanismen von Identitäten für Ihre Ressourcen innerhalb Ihres AWS-Kontos zu verwalten, zu steuern und zu regeln.

AWS-Konto Root-Benutzer

Wenn Sie ein Amazon Web Services (AWS)-Konto erstellen, beginnen Sie mit einer einzelnen Anmeldeidentität, die vollen Zugriff auf alle AWS-Dienste und Ressourcen im Konto hat. Dies ist der AWS-Konto Root-Benutzer und wird durch die Anmeldung mit der E-Mail-Adresse und dem Passwort, die Sie zur Kontoerstellung verwendet haben, aufgerufen.

Beachten Sie, dass ein neuer Admin-Benutzer weniger Berechtigungen hat als der Root-Benutzer.

Aus Sicherheitssicht wird empfohlen, andere Benutzer zu erstellen und diesen nicht zu verwenden.

IAM-Benutzer

Ein IAM-Benutzer ist eine Entität, die Sie in AWS erstellen, um die Person oder Anwendung darzustellen, die sie verwendet, um mit AWS zu interagieren. Ein Benutzer in AWS besteht aus einem Namen und Anmeldeinformationen (Passwort und bis zu zwei Zugriffsschlüssel).

Wenn Sie einen IAM-Benutzer erstellen, erteilen Sie ihm Berechtigungen, indem Sie ihn zu einem Mitglied einer Benutzergruppe machen, die entsprechende Berechtigungsrichtlinien angehängt hat (empfohlen), oder indem Sie Richtlinien direkt an den Benutzer anhängen.

Benutzer können MFA aktiviert haben, um sich anzumelden. API-Token von Benutzern mit MFA sind nicht durch MFA geschützt. Wenn Sie den Zugriff von Benutzer-API-Schlüsseln mit MFA einschränken möchten, müssen Sie in der Richtlinie angeben, dass für bestimmte Aktionen MFA erforderlich ist (Beispiel hier).

CLI

  • Zugriffsschlüssel-ID: 20 zufällige Großbuchstaben und Zahlen wie AKHDNAPO86BSHKDIRYT

  • Geheimer Zugriffsschlüssel: 40 zufällige Groß- und Kleinbuchstaben: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Es ist nicht möglich, verlorene geheime Zugriffsschlüssel abzurufen).

Wenn Sie den Zugriffsschlüssel ändern müssen, sollten Sie diesem Prozess folgen: Einen neuen Zugriffsschlüssel erstellen -> Den neuen Schlüssel auf System/Anwendung anwenden -> Den ursprünglichen als inaktiv markieren -> Neuen Zugriffsschlüssel testen und überprüfen, ob er funktioniert -> Alten Zugriffsschlüssel löschen

MFA - Multi-Faktor-Authentifizierung

Es wird verwendet, um eine zusätzliche Authentifizierungsmethode neben Ihren bestehenden Methoden wie Passwort zu erstellen und somit eine Multi-Faktor-Authentifizierungsebene zu schaffen. Sie können eine kostenlose virtuelle Anwendung oder ein physisches Gerät verwenden. Sie können kostenlose Apps wie Google Authenticator verwenden, um eine MFA in AWS zu aktivieren.

Richtlinien mit MFA-Bedingungen können an Folgendes angehängt werden:

  • Einen IAM-Benutzer oder eine Gruppe

  • Eine Ressource wie einen Amazon S3-Bucket, eine Amazon SQS-Warteschlange oder ein Amazon SNS-Thema

  • Die Vertrauensrichtlinie einer IAM-Rolle, die von einem Benutzer angenommen werden kann

Wenn Sie auf eine Ressource über CLI zugreifen möchten, die MFA überprüft, müssen Sie GetSessionToken aufrufen. Dadurch erhalten Sie ein Token mit Informationen zur MFA. Beachten Sie, dass AssumeRole-Anmeldeinformationen diese Informationen nicht enthalten.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Wie hier angegeben, gibt es viele verschiedene Fälle, in denen MFA nicht verwendet werden kann.

IAM-Benutzergruppen

Eine IAM-Benutzergruppe ist eine Möglichkeit, Richtlinien gleichzeitig an mehrere Benutzer anzuhängen, was es einfacher machen kann, die Berechtigungen für diese Benutzer zu verwalten. Rollen und Gruppen können nicht Teil einer Gruppe sein.

Sie können eine Identitätsbasierte Richtlinie an eine Benutzergruppe anhängen, sodass alle Benutzer in der Benutzergruppe die Berechtigungen der Richtlinie erhalten. Sie können eine Benutzergruppe nicht als Principal in einer Richtlinie (wie einer ressourcenbasierten Richtlinie) identifizieren, da Gruppen sich auf Berechtigungen beziehen, nicht auf Authentifizierung, und Prinzipale authentifizierte IAM-Entitäten sind.

Hier sind einige wichtige Merkmale von Benutzergruppen:

  • Eine Benutzer gruppe kann viele Benutzer enthalten, und ein Benutzer kann mehreren Gruppen angehören.

  • Benutzergruppen können nicht verschachtelt werden; sie können nur Benutzer, keine anderen Benutzergruppen enthalten.

  • Es gibt keine Standardbenutzergruppe, die automatisch alle Benutzer im AWS-Konto einschließt. Wenn Sie eine Benutzergruppe wie diese haben möchten, müssen Sie sie erstellen und jedem neuen Benutzer zuweisen.

  • Die Anzahl und Größe der IAM-Ressourcen in einem AWS-Konto, wie die Anzahl der Gruppen und die Anzahl der Gruppen, denen ein Benutzer angehören kann, sind begrenzt. Weitere Informationen finden Sie unter IAM- und AWS STS-Quotas.

IAM-Rollen

Eine IAM-Rolle ist sehr ähnlich zu einem Benutzer, da es sich um eine Identität mit Berechtigungsrichtlinien handelt, die bestimmen, was es in AWS tun kann und nicht kann. Eine Rolle hat jedoch keine Anmeldeinformationen (Passwort oder Zugriffsschlüssel), die damit verbunden sind. Anstatt eindeutig einer Person zugeordnet zu sein, soll eine Rolle von jedem angenommen werden können, der sie benötigt (und ausreichende Berechtigungen hat). Ein IAM-Benutzer kann eine Rolle vorübergehend übernehmen, um unterschiedliche Berechtigungen für eine bestimmte Aufgabe zu erhalten. Eine Rolle kann einem föderierten Benutzer zugewiesen werden, der sich mithilfe eines externen Identitätsanbieters und nicht über IAM anmeldet.

Eine IAM-Rolle besteht aus zwei Arten von Richtlinien: Eine Vertrauensrichtlinie, die nicht leer sein kann und festlegt, wer die Rolle annehmen kann, und eine Berechtigungsrichtlinie, die nicht leer sein kann und festlegt, auf was sie zugreifen kann.

AWS Security Token Service (STS)

Der AWS Security Token Service (STS) ist ein Webdienst, der die Ausstellung temporärer, eingeschränkter Berechtigungen erleichtert. Er ist speziell für:

Temporäre Anmeldeinformationen in IAM

Temporäre Anmeldeinformationen werden hauptsächlich mit IAM-Rollen verwendet, aber es gibt auch andere Verwendungen. Sie können temporäre Anmeldeinformationen anfordern, die über einen eingeschränkteren Satz von Berechtigungen als Ihr Standard-IAM-Benutzer verfügen. Dies verhindert, dass Sie versehentlich Aufgaben ausführen, die von den eingeschränkteren Anmeldeinformationen nicht erlaubt sind. Ein Vorteil temporärer Anmeldeinformationen ist, dass sie automatisch nach einer festgelegten Zeitdauer ablaufen. Sie haben die Kontrolle darüber, wie lange die Anmeldeinformationen gültig sind.

Richtlinien

Richtlinienberechtigungen

Werden verwendet, um Berechtigungen zuzuweisen. Es gibt 2 Arten:

  • Von AWS verwaltete Richtlinien (von AWS vorab konfiguriert)

  • Kundenverwaltete Richtlinien: Von Ihnen konfiguriert. Sie können Richtlinien basierend auf von AWS verwalteten Richtlinien erstellen (eine davon ändern und Ihre eigene erstellen), den Richtliniengenerator verwenden (eine grafische Benutzeroberfläche, die Ihnen beim Gewähren und Verweigern von Berechtigungen hilft) oder Ihre eigene schreiben.

Standardmäßig ist der Zugriff verweigert, der Zugriff wird gewährt, wenn eine explizite Rolle angegeben wurde. Wenn ein einziger "Deny" existiert, wird das "Allow" außer Kraft gesetzt, außer für Anfragen, die die Root-Sicherheitsanmeldeinformationen des AWS-Kontos verwenden (die standardmäßig zugelassen sind).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Die globalen Felder, die für Bedingungen in jedem Dienst verwendet werden können, sind hier dokumentiert. Die spezifischen Felder, die für Bedingungen pro Dienst verwendet werden können, sind hier dokumentiert.

Inline-Richtlinien

Diese Art von Richtlinien wird direkt einem Benutzer, einer Gruppe oder einer Rolle zugewiesen. Sie erscheinen dann nicht in der Richtlinienliste, da sie von jedem anderen verwendet werden können. Inline-Richtlinien sind nützlich, wenn Sie eine streng eins-zu-eins-Beziehung zwischen einer Richtlinie und der Identität aufrechterhalten möchten, auf die sie angewendet wird. Wenn Sie beispielsweise sicherstellen möchten, dass die Berechtigungen in einer Richtlinie nicht versehentlich einer anderen Identität als der vorgesehenen zugewiesen werden. Wenn Sie eine Inline-Richtlinie verwenden, können die Berechtigungen in der Richtlinie nicht versehentlich an die falsche Identität angehängt werden. Darüber hinaus werden die Richtlinien, die in der Identität eingebettet sind, gelöscht, wenn Sie die Identität mit der AWS Management Console löschen. Das liegt daran, dass sie Teil der Hauptentität sind.

Ressourcen-Bucket-Richtlinien

Dies sind Richtlinien, die in Ressourcen definiert werden können. Nicht alle Ressourcen von AWS unterstützen sie.

Wenn einem Haupt keine explizite Verweigerung vorliegt und eine Ressourcenrichtlinie ihnen Zugriff gewährt, sind sie erlaubt.

IAM-Grenzen

IAM-Grenzen können verwendet werden, um die Berechtigungen zu beschränken, auf die ein Benutzer oder eine Rolle Zugriff haben sollte. Auf diese Weise schlägt der Vorgang fehl, selbst wenn einem Benutzer durch eine andere Richtlinie ein anderes Berechtigungsset gewährt wird, wenn er versucht, sie zu verwenden.

Eine Grenze ist nur eine Richtlinie, die einem Benutzer angehängt ist und den maximalen Berechtigungsgrad angibt, den der Benutzer oder die Rolle haben kann. Also, selbst wenn der Benutzer Administratorzugriff hat, wenn die Grenze angibt, dass er nur Lesezugriff auf S3-Buckets hat, ist das das Maximum, was er tun kann.

Dies, SCPs und das Befolgen des Prinzips des geringsten Privilegs sind die Möglichkeiten, um sicherzustellen, dass Benutzer nicht mehr Berechtigungen haben als die, die sie benötigen.

Sitzungsrichtlinien

Eine Sitzungsrichtlinie ist eine Richtlinie, die festgelegt wird, wenn eine Rolle angenommen wird. Dies wird wie eine IAM-Grenze für diese Sitzung sein: Das bedeutet, dass die Sitzungsrichtlinie keine Berechtigungen gewährt, sondern sie auf die in der Richtlinie angegebenen beschränkt (wobei die maximalen Berechtigungen diejenigen sind, die die Rolle hat).

Dies ist nützlich für Sicherheitsmaßnahmen: Wenn ein Administrator eine sehr privilegierte Rolle übernimmt, könnte er die Berechtigung auf nur die in der Sitzungsrichtlinie angegebenen beschränken, falls die Sitzung kompromittiert wird.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Hinweis: Standardmäßig kann AWS Sitzungsrichtlinien zu Sitzungen hinzufügen, die aufgrund von Drittanbietergründen generiert werden. Zum Beispiel generiert AWS standardmäßig in nicht authentifizierten Cognito angenommenen Rollen (bei Verwendung der erweiterten Authentifizierung) Sitzungsanmeldeinformationen mit einer Sitzungsrichtlinie, die die Dienste einschränkt, auf die die Sitzung zugreifen kann zu der folgenden Liste.

Daher, wenn Sie irgendwann den Fehler "..., weil keine Sitzungsrichtlinie den ..." erhalten und die Rolle Zugriff auf die Aktion hat, liegt dies daran, dass eine Sitzungsrichtlinie dies verhindert.

Identitätsföderation

Die Identitätsföderation ermöglicht es Benutzern von externen Identitätsanbietern, sicher auf AWS-Ressourcen zuzugreifen, ohne AWS-Benutzeranmeldeinformationen von einem gültigen IAM-Benutzerkonto bereitzustellen. Ein Beispiel für einen Identitätsanbieter kann Ihr eigenes Unternehmens-Microsoft Active Directory(über SAML) oder OpenID-Dienste (wie Google) sein. Durch den föderierten Zugriff können die Benutzer darin auf AWS zugreifen.

Um dieses Vertrauen zu konfigurieren, wird ein IAM-Identitätsanbieter (SAML oder OAuth) generiert, der dem anderen Plattform vertraut. Dann wird mindestens eine IAM-Rolle (Vertrauen) dem Identitätsanbieter zugewiesen. Wenn ein Benutzer von der vertrauenswürdigen Plattform auf AWS zugreift, geschieht dies als die genannte Rolle.

Normalerweise möchten Sie jedoch je nach Benutzergruppe in der Drittanbieterplattform eine unterschiedliche Rolle zuweisen. Dann können mehrere IAM-Rollen dem Drittanbieter-Identitätsanbieter vertrauen, und die Drittanbieterplattform wird den Benutzern ermöglichen, die eine oder andere Rolle anzunehmen.

IAM-Identitätszentrum

Das AWS IAM-Identitätszentrum (Nachfolger von AWS Single Sign-On) erweitert die Möglichkeiten von AWS Identity and Access Management (IAM), um einen zentralen Ort bereitzustellen, der die Verwaltung von Benutzern und deren Zugriff auf AWS-Konten und Cloud-Anwendungen zusammenführt.

Die Anmeldedomäne wird etwas wie <user_input>.awsapps.com sein.

Zum Anmelden können 3 Identitätsquellen verwendet werden:

  • Identitätszentrum-Verzeichnis: Reguläre AWS-Benutzer

  • Active Directory: Unterstützt verschiedene Connector

  • Externer Identitätsanbieter: Alle Benutzer und Gruppen stammen von einem externen Identitätsanbieter (IdP)

Im einfachsten Fall des Identitätszentrum-Verzeichnisses wird das Identitätszentrum eine Liste von Benutzern & Gruppen haben und wird in der Lage sein, Richtlinien für sie einem der Konten der Organisation zuzuweisen.

Um einem Identitätszentrum-Benutzer/Gruppe Zugriff auf ein Konto zu gewähren, wird ein SAML-Identitätsanbieter, der dem Identitätszentrum vertraut, erstellt, und eine Rolle, die dem Identitätsanbieter mit den angegebenen Richtlinien vertraut, wird im Zielskonto erstellt.

AwsSSOInlinePolicy

Es ist möglich, Berechtigungen über Inline-Richtlinien für im IAM-Identitätszentrum erstellte Rollen zu erteilen. Die in den Konten erstellten Rollen, die im AWS-Identitätszentrum Inline-Richtlinien haben, haben diese Berechtigungen in einer Inline-Richtlinie namens AwsSSOInlinePolicy.

Daher bedeutet selbst wenn Sie 2 Rollen mit einer Inline-Richtlinie namens AwsSSOInlinePolicy sehen, bedeutet dies nicht, dass sie die gleichen Berechtigungen haben.

Vertrauen und Rollen zwischen Konten

Ein Benutzer (Vertrauender) kann eine Cross-Account-Rolle mit bestimmten Richtlinien erstellen und dann einem anderen Benutzer (Vertrauenswürdigen) den Zugriff auf sein Konto erlauben, jedoch nur mit den im neuen Rollenrichtlinien angegebenen Zugriffen. Um dies zu erstellen, erstellen Sie einfach eine neue Rolle und wählen Sie Cross-Account-Rolle aus. Rollen für den Zugriff zwischen AWS-Konten bieten zwei Optionen. Bereitstellung von Zugriff zwischen AWS-Konten, die Ihnen gehören, und Bereitstellung von Zugriff zwischen einem Konto, das Ihnen gehört, und einem AWS-Konto eines Drittanbieters. Es wird empfohlen, den vertrauenswürdigen Benutzer zu spezifizieren und keine generische Bezeichnung zu verwenden, da andernfalls auch andere authentifizierte Benutzer wie föderierte Benutzer dieses Vertrauen missbrauchen können.

AWS Simple AD

Nicht unterstützt:

  • Vertrauensbeziehungen

  • AD-Verwaltungszentrum

  • Vollständige PS-API-Unterstützung

  • AD-Papierkorb

  • Gruppenverwaltete Dienstkonten

  • Schemaerweiterungen

  • Kein direkter Zugriff auf das Betriebssystem oder Instanzen

Web-Föderation oder OpenID-Authentifizierung

Die App verwendet AssumeRoleWithWebIdentity, um temporäre Anmeldeinformationen zu erstellen. Dies gewährt jedoch keinen Zugriff auf die AWS-Konsole, sondern nur Zugriff auf Ressourcen innerhalb von AWS.

Weitere IAM-Optionen

  • Sie können eine Kennwortrichtlinie festlegen und Optionen wie Mindestlänge und Kennwortanforderungen festlegen.

  • Sie können einen "Credential Report" herunterladen mit Informationen zu aktuellen Anmeldeinformationen (wie Benutzererstellungszeit, ist Kennwort aktiviert...). Sie können einen Anmeldeinformationsbericht so oft wie alle vier Stunden generieren.

AWS Identity and Access Management (IAM) bietet feinkörnige Zugriffssteuerung für alle AWS-Dienste. Mit IAM können Sie festlegen, wer auf welche Dienste und Ressourcen zugreifen kann und unter welchen Bedingungen. Mit IAM-Richtlinien verwalten Sie Berechtigungen für Ihre Mitarbeiter und Systeme, um Berechtigungen mit minimalen Rechten zu gewährleisten.

IAM-ID-Präfixe

Auf dieser Seite finden Sie die IAM-ID-Präfixe von Schlüsseln je nach ihrer Art:

ABIA

AWS STS-Dienstträgertoken

ACCA

Kontextspezifische Anmeldeinformationen

AGPA

Benutzergruppe

AIDA

IAM-Benutzer

AIPA

Amazon EC2-Instanzprofil

AKIA

Zugriffsschlüssel

ANPA

Verwaltete Richtlinie

ANVA

Version in einer verwalteten Richtlinie

APKA

Öffentlicher Schlüssel

AROA

Rolle

ASCA

Zertifikat

ASIA

Temporäre (AWS STS) Zugriffsschlüssel-IDs verwenden dieses Präfix, sind jedoch nur in Kombination mit dem geheimen Zugriffsschlüssel und dem Sitzungstoken eindeutig.

Empfohlene Berechtigungen zur Überprüfung von Konten

Die folgenden Berechtigungen gewähren verschiedene Lesezugriffe auf Metadaten:

  • arn:aws:iam::aws:policy/SecurityAudit

  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

  • codebuild:ListProjects

  • config:Describe*

  • cloudformation:ListStacks

  • logs:DescribeMetricFilters

  • directconnect:DescribeConnections

  • dynamodb:ListTables

Sonstiges

CLI-Authentifizierung

Damit ein regulärer Benutzer sich über die CLI bei AWS authentifizieren kann, benötigen Sie lokale Anmeldeinformationen. Standardmäßig können Sie sie manuell in ~/.aws/credentials konfigurieren oder durch Ausführen von aws configure. In dieser Datei können Sie mehr als ein Profil haben. Wenn beim aws cli kein Profil angegeben ist, wird dasjenige namens [default] in dieser Datei verwendet. Beispiel für eine Anmeldeinformationsdatei mit mehr als 1 Profil:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Wenn Sie auf verschiedene AWS-Konten zugreifen müssen und Ihr Profil Zugriff erhalten hat, um eine Rolle in diesen Konten anzunehmen, müssen Sie nicht jedes Mal manuell STS aufrufen (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) und die Anmeldeinformationen konfigurieren.

Sie können die Datei ~/.aws/config verwenden, um anzugeben, welche Rollen angenommen werden sollen, und dann den --profile-Parameter wie gewohnt verwenden (die assume-role wird transparent für den Benutzer durchgeführt). Ein Beispiel für eine Konfigurationsdatei:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Mit dieser Konfigurationsdatei können Sie dann aws cli wie folgt verwenden:

aws --profile acc2 ...

Wenn Sie etwas Ähnliches wie dies, aber für den Browser suchen, können Sie die Erweiterung AWS Extend Switch Roles überprüfen.

Referenzen

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousAWS PentestingNextAWS - Federation Abuse

Last updated