Kiedy aplikacja mówi za dużo. Information Exposure w CVAT (Brak CVE)

Dlaczego błędy wycieku informacji są groźne?

Zanim przejdziemy do konkretów, warto zaznaczyć jedno: rzadko kiedy wyciek informacji (Information Disclosure) prowadzi bezpośrednio do przejęcia serwera (RCE). Jest to jednak fundament rekonesansu.

Z perspektywy atakującego każda informacja o ścieżkach systemowych, używanych technologiach czy wewnętrznej adresacji sieci to jak znalezienie planów architektonicznych banku przed napadem. Pozwala precyzyjniej dobrać kolejne exploity.

W CVAT znalazłem dwa wektory wycieku wrażliwych danych diagnostycznych.

Wektor 1: Nieprawidłowy „Remote Source” i wyciek ścieżek z serwera

Podczas tworzenia nowego zadania (Task) w CVAT, możemy jako źródło plików wskazać „Remote Source” (np. link do zasobu w sieci). Co się jednak stanie, gdy podamy tam złośliwy lub śmieciowy URL do domeny, która nie zwraca żadnych poprawnych plików do sparsowania?

Zamiast standardowego błędu „Nie można pobrać pliku”, backend (oparty na frameworku Django) „wykrzacza się” i rzuca w interfejs użytkownika oraz bezpośrednio do odpowiedzi API pełnym błędem systemowym:

Tym prostym sposobem dowiedziałem się dokładnie, w jakim katalogu na serwerze uruchomiona jest aplikacja, pod jakimi uprawnieniami (lub na jakiej strukturze) działa, oraz jak wewnętrznie mapuje identyfikatory zadań na foldery na dysku twardym.

Dla atakującego szukającego np. podatności typu Local File Inclusion (LFI) czy Path Traversal, to cenna wskazówka.

Wektor 2: Wewnętrzna architektura odkryta przez Lambda Functions

Drugi wektor był nieco sprytniejszy i dotyczył funkcjonalności funkcji Lambda. Wykorzystałem zwykłą iterację (brute-force) identyfikatorów zapytań do API:

Kiedy aplikacja nie potrafiła znaleźć funkcji o danym numerze (ponieważ np. nie istniała lub nie miałem do niej dostępu), serwer odpowiadał kodem HTTP 404 Not Found. Nie był to jednak standardowy, krótki komunikat. Odpowiedź serwera zawierała szczegółowy log:

• Wiemy, że do obsługi serverless/lambd pod spodem używany jest framework Nuclio.
• Wiemy, że komunikacja odbywa się bez szyfrowania po HTTP na porcie 8070.
• Poznaliśmy adresację sieci wewnętrznej (Internal Domain): nuclio-dashboard.internal.cvat.ai.

Jak zamknąć usta zbyt gadatliwej aplikacji? (Remediacja)

Nawet jeśli deweloperzy zignorowali raport, zasady bezpiecznego programowania (i obsługi błędów) pozostają niezmienne.

• Przechwytywanie wyjątków (Exception Handling) - Błędy i wyjątki systemowe nigdy nie powinny wypływać na wierzch (do widoku użytkownika końcowego). Należy stosować bloki try/catch w sposób zaplanowany.
• Generyczne komunikaty błędów - Gdy aplikacja nie potrafi sprocesować ścieżki lub połączyć się z mikroserwisem, użytkownik powinien zobaczyć wyłącznie bezpieczny, ogólny komunikat: „Wystąpił błąd podczas przetwarzania pliku” lub „Zasób nie został znaleziony”.
• Logowanie po stronie serwera - Zrzuty pamięci (Stack Traces), błędy [Errno 21] oraz informacje o portach (8070) powinny trafiać wyłącznie do logów systemowych, do których dostęp mają tylko administratorzy lub zespoły SOC/QA.
• Automatyczna analiza kodu (SAST) - Narzędzia klasy Static Application Security Testing potrafią łatwo wyłapać, gdzie w kodzie brakuje sanitacji wyrzucanych na zewnątrz błędów aplikacyjnych.