Ray 2.56.0: podatność Directory Traversal i LFI w endpointcie /api/v0/logs - Security Bez Tabu

Ray 2.56.0: podatność Directory Traversal i LFI w endpointcie /api/v0/logs

Cybersecurity news

Wprowadzenie do problemu / definicja

W środowiskach rozproszonych bezpieczeństwo interfejsów administracyjnych i diagnostycznych ma kluczowe znaczenie. Podatność typu Directory Traversal pozwala atakującemu manipulować ścieżką pliku tak, aby uzyskać dostęp do zasobów znajdujących się poza przewidzianym katalogiem. Jeżeli podatny mechanizm dodatkowo zwraca zawartość wskazanego pliku, incydent przyjmuje formę Local File Inclusion (LFI), co może prowadzić do ujawnienia konfiguracji, logów, sekretów oraz informacji systemowych.

W opisywanym przypadku problem dotyczy platformy Ray 2.56.0 i mechanizmu pobierania logów przez endpoint /api/v0/logs. Błąd wynika z niewystarczającej walidacji parametru odpowiedzialnego za filtrowanie plików, co tworzy realne ryzyko nieautoryzowanego odczytu danych z systemu plików hosta.

W skrócie

  • Podatność dotyczy Ray 2.56.0 oraz endpointu /api/v0/logs.
  • Błąd umożliwia Directory Traversal i skutkuje scenariuszem Local File Inclusion.
  • Wektor ataku wykorzystuje parametr glob, który może zawierać sekwencje przejścia do katalogów nadrzędnych.
  • Według opisu materiału źródłowego exploit może działać bez uwierzytelnienia, jeśli interfejs jest dostępny z sieci.
  • Ryzyko obejmuje wyciek plików systemowych, konfiguracji, logów i danych pomocnych w dalszej kompromitacji środowiska.

Kontekst / historia

Ray jest szeroko wykorzystywany do uruchamiania obciążeń rozproszonych, w tym zadań data processing, machine learning oraz workloadów klastrowych. Funkcje związane z diagnostyką i dostępem do logów są operacyjnie niezbędne, ale jednocześnie należą do najbardziej wrażliwych elementów interfejsów zarządzających. Każdy błąd w walidacji danych wejściowych w tym obszarze może skutkować ekspozycją informacji o wysokiej wartości dla atakującego.

Publicznie udostępniony opis podatności zawiera techniczne szczegóły problemu, przykładowy proof of concept oraz informacje o zgłoszeniu błędu upstream. Z perspektywy bezpieczeństwa jest to klasyczny przykład podatności wynikającej z błędnej sanitacji wejścia oraz nadmiernego zaufania do parametrów użytkownika podczas budowania ścieżek lub wzorców wyszukiwania plików.

Analiza techniczna

Technicznie problem koncentruje się wokół endpointu /api/v0/logs, który przyjmuje między innymi parametry node_id oraz glob. Jeżeli aplikacja interpretuje wartość glob bez odpowiedniego ograniczenia do bezpiecznego katalogu bazowego, możliwe staje się wymuszenie dostępu do plików znajdujących się poza katalogiem logów. W praktyce oznacza to wykorzystanie sekwencji traversal, takich jak przejścia do katalogów nadrzędnych, aby odwołać się do innych lokalizacji systemu plików.

Mechanizm nadużycia można opisać w kilku krokach. Atakujący wysyła żądanie HTTP do interfejsu pobierania logów, następnie przekazuje spreparowaną wartość parametru glob, po czym aplikacja interpretuje ją jako wzorzec wyszukiwania plików. Jeżeli po stronie serwera brakuje skutecznej normalizacji ścieżki i walidacji zakresu dostępu, odpowiedź API może zawierać dane spoza dozwolonego katalogu.

Istotne jest to, że problem nie ogranicza się wyłącznie do listowania nazw plików. Opis exploitu wskazuje na możliwość odczytu zwracanej zawartości, co nadaje podatności charakter praktycznego LFI lub nieautoryzowanego odczytu lokalnych plików. W środowisku serwera aplikacyjnego mogą to być pliki systemowe, konfiguracje usług, dane diagnostyczne, a także artefakty ułatwiające dalsze etapy ataku.

W klastrach i środowiskach wielowęzłowych zagrożenie jest szczególnie istotne, ponieważ informacje pozyskane z jednego komponentu mogą pomóc w mapowaniu całej infrastruktury. Jeżeli interfejs jest wystawiony poza zaufaną sieć lub udostępniony przez niewłaściwie skonfigurowany reverse proxy, podatność może stać się punktem wejścia do szerszej kompromitacji.

Konsekwencje / ryzyko

Wpływ podatności zależy od sposobu wdrożenia Ray, ekspozycji interfejsu oraz rodzaju danych obecnych na hoście i w logach. Nawet jeśli początkowo błąd wydaje się ograniczony do warstwy diagnostycznej, jego skutki mogą być znacznie szersze z punktu widzenia bezpieczeństwa operacyjnego i ciągłości działania.

  • ujawnienie plików systemowych i danych pomocnych w fingerprintingu hosta,
  • wyciek konfiguracji aplikacji oraz usług towarzyszących,
  • dostęp do logów zawierających tokeny, identyfikatory sesji lub dane tymczasowe,
  • pozyskanie informacji o topologii klastra i aktywnych komponentach,
  • ułatwienie ruchu bocznego oraz przygotowania kolejnych etapów ataku.

W środowiskach AI, ML oraz data pipelines ryzyko rośnie, ponieważ logi i pliki konfiguracyjne często zawierają ścieżki robocze, nazwy usług, identyfikatory zasobów oraz informacje integracyjne z chmurą. Tego rodzaju dane mogą nie wystarczyć do bezpośredniego przejęcia środowiska, ale znacząco zwiększają skuteczność dalszej eskalacji działań przez operatora zagrożeń.

Rekomendacje

Organizacje korzystające z Ray powinny potraktować ten problem priorytetowo i możliwie szybko ocenić zakres ekspozycji. Najważniejsze działania powinny obejmować zarówno aktualizację komponentu, jak i ograniczenie dostępności interfejsów administracyjnych.

  • zweryfikować, czy w środowisku działa podatna wersja Ray,
  • zastosować poprawkę producenta lub wersję zawierającą usunięcie błędu,
  • ograniczyć dostęp do endpointów administracyjnych i diagnostycznych wyłącznie do zaufanych segmentów sieci,
  • wymusić uwierzytelnianie i autoryzację dla API związanych z logami oraz zarządzaniem klastrem,
  • wdrożyć filtrowanie żądań zawierających sekwencje traversal na warstwie reverse proxy lub WAF,
  • przeanalizować logi pod kątem nietypowych wywołań /api/v0/logs, zwłaszcza z parametrami zawierającymi ../,
  • przeprowadzić rotację sekretów, jeśli istnieje podejrzenie ujawnienia danych w logach lub plikach konfiguracyjnych,
  • zweryfikować kod pod kątem normalizacji ścieżek i twardego ograniczenia dostępu do katalogu bazowego.

Dobrą praktyką jest także wdrożenie bezpiecznego modelu obsługi plików, obejmującego kanonikalizację ścieżki przed użyciem, porównanie wyniku z dozwolonym katalogiem bazowym oraz stosowanie jawnych list dozwolonych plików lub rozszerzeń. Warstwa prezentacji logów nie powinna zapewniać niekontrolowanego, bezpośredniego dostępu do systemu plików.

Podsumowanie

Podatność w Ray 2.56.0 pokazuje, że nawet pozornie pomocnicze funkcje, takie jak przeglądanie logów, mogą stać się krytycznym wektorem ataku. Błąd Directory Traversal prowadzący do LFI w endpointcie /api/v0/logs może umożliwić nieautoryzowany odczyt plików spoza katalogu logów, a tym samym wyciek informacji operacyjnych i przygotowanie gruntu pod dalszą kompromitację środowiska.

Kluczowe znaczenie mają szybka identyfikacja podatnych wdrożeń, ograniczenie ekspozycji interfejsów zarządzających oraz stały monitoring prób nadużycia parametrów odpowiedzialnych za dostęp do plików. W środowiskach produkcyjnych opartych na klastrach nawet pojedynczy błąd walidacji wejścia może przełożyć się na istotne ryzyko dla całej infrastruktury.

Źródła