Podatności AWX

Wada w AWX: pole pod_spec_override w grupie kontenerów używa niekompletnej listy blokującej, która ogranicza tylko automountServiceAccountToken, umożliwiając wstrzyknięcie initContainers, nadpisań serviceAccountName i projected service account token volumes. Administrator platformy AAP może to wykorzystać do eskalacji uprawnień do dostępu na poziomie przestrzeni nazw OpenShift i eksfiltracji sekretów przestrzeni nazw.

W CopyAPIView (awx/awx/api/generics.py:873) ustawiono permission_classes = (IsAuthenticated,), więc get_object() DRF nie wykonuje kontroli RBAC na poziomie obiektu. Handler get() jawnie sprawdza request.user.can_access(obj._class_, 'read', obj), ale post() tego nie robi — sprawdza jedynie can_access(model, 'add', create_kwargs_check) oraz can_access(model, 'copy_related', obj). Dla JobTemplate uprawnienia can_add i can_copy_related nie implikują prawa odczytu źródłowego szablonu zadania.

LaunchConfigurationBaseSerializer.scm_branch nie ma walidacji validate_scm_branch() sprawdzającej wiodący myślnik, w przeciwieństwie do serializatorów Project/JobTemplate/JobLaunch. Schedule i WFJT Node akceptują --upload-pack=/bin/id jako scm_branch. Obecnie blokowane w czasie działania przez sprawdzenie ValueError w jobs.py:1502 (obrona w głąb), ale luka w walidacji API oznacza poleganie wyłącznie na zabezpieczeniu warstwy zadań. Usunięcie tego zabezpieczenia podczas refaktoryzacji przekształciłoby to w RCE.

Biała lista AST Jinja szablonów powiadomień sprawdza tylko statyczne węzły Getattr. Dynamiczne indeksy (job['job'+'_env']) i warunkowe bramkowanie {% if job.id > 100 %} omijają zarówno sprawdzenie AST, jak i test-render (stub ma mały job.id). W czasie działania bramkowana gałąź wykonuje się, a wyjątki zapisują pełne ślady stosu do treści powiadomienia, które jest wysyłane POSTem do kontrolowanego przez atakującego URL webhooka. Ujawnia ścieżki instalacji, wersję Pythona, numery linii źródłowych.

Metoda StringListPathField.to_internal_value() wywołuje os.path.exists() na nieograniczonych ścieżkach podanych przez użytkownika. Różnica w odpowiedziach 200 vs 400 ujawnia istnienie dowolnych ścieżek bezwzględnych w podzie controller-web, w tym plików wrażliwych jak SECRET_KEY czy tokeny konta serwisowego.

Metoda HostList.list() łapie wyjątek Exception i zwraca str(e) bezpośrednio. Poprzez host_filter, każdy uwierzytelniony użytkownik może wywołać Django FieldError (ujawniający pełny graf relacji modelu Host) lub PostgreSQL DataError (ujawniający surowe błędy bazy danych).

Endpoint /api/v2/config/ jest chroniony tylko przez IsAuthenticated, co oznacza, że każdy uwierzytelniony użytkownik otrzymuje license_info, w tym numery kont, ID subskrypcji, pool_id, SKU, poziom wsparcia i liczbę instancji. Brama superuser/auditor obejmuje tylko inne pola, nie license_info.

Widok JobJobEventsChildrenSummary nie ma modelu ani parent_model, co powoduje, że ModelAccessPermission.check_get_permissions() zwraca True dla każdego uwierzytelnionego użytkownika. Widok używa surowego get_object_or_404(Job, pk) bez sprawdzenia uprawnień na poziomie obiektu DRF, co pozwala użytkownikowi bez uprawnień odczytywać strukturę drzewa zdarzeń i enumerować ID zadań.

URLModificationMiddleware rozwiązuje nazwane URL-e względem nieprzefiltrowanego Model.objects przed RBAC. Shim 403→404 tylko przepisuje odpowiedzi 403, pozostawiając ścieżkę pk=0 z innym komunikatem 404. Różnica między "Not found." a "No <Model> matches..." ujawnia, czy nazwany zasób istnieje na platformie.

Znaleziono podatność typu Server-Side Request Forgery (SSRF) w wielu backendach powiadomień AWX. Backendy webhook, Mattermost, Rocket.Chat i Grafana używają adresów URL z szablonów powiadomień jako bezpośrednich celów żądań HTTP bez walidacji adresu docelowego pod kątem prywatnych, pętli zwrotnej lub zastrzeżonych zakresów IP. Administrator powiadomień organizacji może tworzyć szablony powiadomień wskazujące na wewnętrzne adresy lub adresy pętli zwrotnej, powodując, że węzeł kontrolny AWX wysyła żądania HTTP do usług, które nie są dostępne z zewnątrz. Dodatkowo backend webhook podąża za przekierowaniami HTTP i ponownie wysyła skonfigurowane poświadczenia Basic Authentication do celów przekierowania niezależnie od zmiany hosta, co pozwala atakującemu na eksfiltrację poświadczeń powiadomień poprzez przekierowanie na kontrolowany przez atakującego host. Backend Grafana wysyła swój klucz API w nagłówku Authorization do skonfigurowanego docelowego adresu URL.

Znaleziono podatność typu path traversal w ekstrakcji archiwów projektów w AWX. Wtyczka akcji project_archive rozpakowuje elementy archiwów zip i tar, łącząc ścieżkę katalogu projektu z nazwą pliku elementu bez normalizacji ścieżki, walidacji granic lub odrzucania sekwencji traversal. Złośliwe archiwum zawierające elementy z sekwencjami traversal może zapisywać pliki w dowolnych lokalizacjach w systemie plików węzła wykonawczego poza zamierzonym katalogiem projektu. Atakujący, który kontroluje zawartość archiwum, czy to poprzez skompromitowane źródło nadrzędne, złośliwy adres URL archiwum, czy atak man-in-the-middle na zwykłym połączeniu HTTP, może osiągnąć dowolny zapis plików jako użytkownik wykonujący ekstrakcję, potencjalnie prowadząc do zdalnego wykonania kodu poprzez mechanizmy takie jak pliki cron, klucze autoryzowane SSH lub wstrzyknięcie treści playbooka.

Znaleziono podatność na server-side request forgery (SSRF) w mechanizmie wywołań zwrotnych webhooków w AWX. Podczas przetwarzania webhooków GitHub pull request, AWX wyodrębnia URL wywołania zwrotnego statusu (pull_request.statuses_url) z ładunku webhooka bez walidacji hosta docelowego względem oczekiwanego dostawcy Git. Ten URL jest zapisywany w zmiennych dodatkowych zadania i później używany do wysyłania uwierzytelnionych aktualizacji statusu. Użytkownik z rolą administratora w szablonie zadania z włączonym webhookiem może odczytać klucz podpisywania webhooka szablonu, sfałszować podpisany ładunek webhooka GitHub z dowolnym statuses_url i spowodować, że AWX wyśle aktualizacje statusu na URL kontrolowany przez atakującego lub wewnętrzny. Żądanie aktualizacji statusu zawiera skonfigurowany Personal Access Token (PAT) Git w nagłówku Authorization, co prowadzi do wycieku poświadczeń do punktu końcowego wskazanego przez atakującego.

W AWX funkcja websocket event consumer wykonuje kontrolę autoryzacji RBAC tylko dla grup zdarzeń zmapowanych w funkcji consumer_access(). Trzy grupy zdarzeń (inventory_update_events, project_update_events, system_job_events) nie są zmapowane, co powoduje pominięcie kontroli autoryzacji. Każdy uwierzytelniony użytkownik może subskrybować te grupy i otrzymywać dane wyjściowe z zadań należących do organizacji, do których nie ma dostępu.