Ansible Tower / AWX / Automation controller Security

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.

Podstawowe informacje

Ansible Tower lub jego wersja open source AWX jest znany jako interfejs użytkownika Ansible, pulpit nawigacyjny i REST API. Dzięki kontroli dostępu opartej na rolach, harmonogramowaniu zadań i graficznemu zarządzaniu inwentarzem, możesz zarządzać swoją infrastrukturą Ansible z nowoczesnego interfejsu. REST API Towera i interfejs wiersza poleceń ułatwiają integrację z obecnymi narzędziami i przepływami pracy.

Automation Controller to nowsza wersja Ansible Tower z większymi możliwościami.

Różnice

Zgodnie z tym, główne różnice między Ansible Tower a AWX to otrzymywane wsparcie, a Ansible Tower ma dodatkowe funkcje, takie jak kontrola dostępu oparta na rolach, wsparcie dla niestandardowych API oraz definiowane przez użytkownika przepływy pracy.

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 zapewniał wizualizacje pomagające w zrozumieniu stanu i wyników twoich 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 (zazwyczaj 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ń.
• Redis: Redis służy jako pamięć podręczna i zaplecze dla kolejki zadań.

Komponenty logiczne

• Inwentarze: Inwentarz to zbiór hostów (lub węzłów), na których mogą być uruchamiane zadania (playbooki Ansible). AWX/Tower pozwala na definiowanie i grupowanie inwentarzy oraz wspiera dynamiczne inwentarze, które mogą pobierać listy hostów z innych systemów takich jak AWS, Azure itp.
• Projekty: Projekt to zasadniczo zbiór playbooków Ansible pozyskiwanych z systemu kontroli wersji (takiego jak Git), aby pobierać najnowsze playbooki w razie potrzeby.
• Szablony: Szablony zadań definiują jak dany playbook będzie uruchamiany, określając inwentarz, poświadczenia i inne parametry dla zadania.
• Poświadczenia: AWX/Tower zapewnia bezpieczny sposób zarządzania i przechowywania sekretów, takich jak klucze SSH, hasła i tokeny API. Te poświadczenia mogą być powiązane z szablonami zadań, aby playbooki miały niezbędny dostęp podczas uruchamiania.
• Silnik zadań: To tutaj dzieje się magia. Silnik zadań oparty jest na Ansible i odpowiada za uruchamianie playbooków. Zadania są przekazywane do silnika zadań, który następnie uruchamia playbooki Ansible na wyznaczonym inwentarzu, używając określonych poświadczeń.
• Harmonogramy i wywołania zwrotne: To zaawansowane funkcje w AWX/Tower, które pozwalają na harmonogramowanie zadań do uruchamiania w określonych czasach lub wyzwalane przez zdarzenia zewnętrzne.
• Powiadomienia: AWX/Tower może wysyłać powiadomienia w zależności od sukcesu lub niepowodzenia zadań. Obsługuje różne metody powiadomień, takie jak e-maile, wiadomości Slack, webhooki itp.
• Playbooki Ansible: Playbooki Ansible to narzędzia do konfiguracji, wdrażania i orkiestracji. Opisują pożądany stan systemów w sposób zautomatyzowany i powtarzalny. Napisane w YAML, playbooki używają deklaratywnego języka automatyzacji Ansible do opisywania konfiguracji, zadań i kroków, które muszą być wykonane.

Przepływ wykonania zadań

1. Interakcja użytkownika: Użytkownik może interagować z AWX/Tower za pośrednictwem Interfejsu Webowego lub REST API. Te zapewniają dostęp front-end do wszystkich funkcji oferowanych przez AWX/Tower.
2. Inicjacja zadania:

• Użytkownik, za pośrednictwem Interfejsu Webowego lub API, inicjuje zadanie na podstawie Szablonu Zadań.
• Szablon Zadań zawiera odniesienia do Inwentarza, Projektu (zawierającego playbook) i Poświadczeń.
• 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.

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 wyznaczonych 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 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 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.

Tworzenie laboratorium AWX do testowania

Zgodnie z dokumentacją możliwe jest użycie docker-compose do uruchomienia AWX:

git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version

cd awx

# Build
make docker-compose-build

# Run
make docker-compose

# Or to create a more complex env
MAIN_NODE_TYPE=control EXECUTION_NODE_COUNT=2 COMPOSE_TAG=devel make docker-compose

# Clean and build the UI
docker exec tools_awx_1 make clean-ui ui-devel

# Once migrations are completed and the UI is built, you can begin using AWX. The UI can be reached in your browser at https://localhost:8043/#/home, and the API can be found at https://localhost:8043/api/v2.

# Create an admin user
docker exec -ti tools_awx_1 awx-manage createsuperuser

# Load demo data
docker exec tools_awx_1 awx-manage create_preload_data

RBAC

Obsługiwane role

Najbardziej uprzywilejowaną rolą jest Administrator Systemu. Każdy, kto ma tę rolę, może modyfikować wszystko.

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ę pierwszą.

Enumeracja i mapowanie ścieżek ataku z AnsibleHound

AnsibleHound to open-source’owy kolektor BloodHound OpenGraph napisany w Go, który przekształca token API Ansible Tower/AWX/Automation Controller w pełny graf uprawnień gotowy do analizy w BloodHound (lub BloodHound Enterprise).

Dlaczego to jest przydatne?

1. REST API Tower/AWX jest niezwykle bogate i ujawnia każdy obiekt i relację RBAC, o których wie twoja instancja.
2. Nawet z najniższym uprawnieniem (Read) możliwe jest rekurencyjne enumerowanie wszystkich dostępnych zasobów (organizacje, inwentarze, hosty, poświadczenia, projekty, szablony zadań, użytkownicy, zespoły…).
3. Gdy surowe dane są konwertowane na schemat BloodHound, uzyskujesz te same możliwości wizualizacji ścieżek ataku, które są tak popularne w ocenach Active Directory – ale teraz skierowane na twoje zasoby CI/CD.

Zespoły bezpieczeństwa (i atakujący!) mogą zatem:

• Szybko zrozumieć kto może stać się administratorem czego.
• Zidentyfikować poświadczenia lub hosty, które są osiągalne z konta bez uprawnień.
• Łączyć wiele krawędzi „Read ➜ Use ➜ Execute ➜ Admin”, aby uzyskać pełną kontrolę nad instancją Tower lub podstawową infrastrukturą.

Wymagania wstępne

• Ansible Tower / AWX / Automation Controller dostępny przez HTTPS.
• Token API użytkownika ograniczony do Read (utworzony z Szczegóły Użytkownika → Tokeny → Utwórz Token → zakres = Read).
• Go ≥ 1.20 do kompilacji kolektora (lub użyj wstępnie zbudowanych binariów).

Budowanie i uruchamianie

# Compile the collector
cd collector
go build . -o build/ansiblehound

# Execute against the target instance
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"

Wewnątrz AnsibleHound wykonuje stronicowane żądania GET przeciwko (przynajmniej) następującym punktom końcowym i automatycznie podąża za linkami related zwróconymi w każdym obiekcie JSON:

/api/v2/organizations/
/api/v2/inventories/
/api/v2/hosts/
/api/v2/job_templates/
/api/v2/projects/
/api/v2/credentials/
/api/v2/users/
/api/v2/teams/

Wszystkie zebrane strony są scalane w jeden plik JSON na dysku (domyślnie: ansiblehound-output.json).

Transformacja BloodHound

Surowe dane Tower są następnie przekształcane na BloodHound OpenGraph przy użyciu niestandardowych węzłów z prefiksem AT (Ansible Tower):

• ATOrganization, ATInventory, ATHost, ATJobTemplate, ATProject, ATCredential, ATUser, ATTeam

I krawędzie modelujące relacje / uprawnienia:

• ATContains, ATUses, ATExecute, ATRead, ATAdmin

Wynik można zaimportować bezpośrednio do BloodHound:

neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json

Opcjonalnie możesz przesłać niestandardowe ikony, aby nowe typy węzłów były wizualnie odróżnialne:

python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"

Rozważania defensywne i ofensywne

• Token Read jest zazwyczaj uważany za nieszkodliwy, ale nadal ujawnia pełną topologię i metadane dotyczące wszystkich poświadczeń. Traktuj go jako wrażliwy!
• Wprowadź zasadę najmniejszych uprawnień i rotuj / unieważniaj nieużywane tokeny.
• Monitoruj API pod kątem nadmiernej enumeracji (wiele sekwencyjnych żądań GET, wysoka aktywność paginacji).
• Z perspektywy atakującego jest to doskonała technika początkowego przyczółka → eskalacji uprawnień w ramach pipeline’u CI/CD.

Odniesienia

• AnsibleHound – BloodHound Collector for Ansible Tower/AWX
• BloodHound OSS

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.