W życiu pentestera bywa tak, że wpadasz na świetny błąd, zacierasz ręce, piszesz raport, po czym dowiadujesz się... że ktoś inny wpadł na to chwilę przed Tobą. Zgłoszone przeze mnie podatności w platformie Computer Vision Annotation Tool (CVAT) okazały się duplikatem, ale na tyle istotnym, że zostały podpięte pod oficjalny biuletyn bezpieczeństwa GHSA-p3c9-m7jr-jxxj i ostatecznie ujęte w CVE-2024-45393.
Luka otrzymała punktację 6.4 (Moderate) z wektorem CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N. Przyjrzyjmy się, jak po raz kolejny przewidywalne identyfikatory i brak autoryzacji na pobocznych endpointach pozwoliły na kradzież danych, a nawet stworzyły ryzyko ataku DoS.
TL;DR - Najważniejsze wnioski
- Webhooki pod lupą
- Wektor 1: Złośliwy Ping i ryzyko DoS
- Wektor 2: Historia dostarczeń (Deliveries)
- Jak załatać takie błędy? (Remediacja)
Webhooki pod lupą
CVAT pozwala użytkownikom na tworzenie projektów i podpinanie do nich Webhooków. To przydatna funkcja, gdy w projekcie coś się dzieje, aplikacja wysyła powiadomienie pod wskazany przez nas adres URL.
Aplikacja (w testowanych wersjach m.in. Server: 2.16.3) posiada dwa interesujące endpointy do zarządzania webhookami:
Obie te funkcjonalności skrywały klasyczny błąd Insecure Direct Object Reference (IDOR) oraz Horizontal Privilege Escalation.
- Służący do testowania (pingowania) webhooka.
- Służący do sprawdzania historii dostarczeń (deliveries).
Wektor 1: Złośliwy Ping i ryzyko DoS
Gdy tworzysz Webhook, aplikacja wysyła żądanie POST, aby sprawdzić, czy podany URL odpowiada. Ruch ten leci na endpoint:
Parametr <ID> to oczywiście... zwykła liczba całkowita (np. 765). Wystarczyło przechwycić to żądanie w Burp Suite i zmienić ID na należące do innego użytkownika. Wynik?
Zamiast błędu 403, serwer posłusznie "pingował" cudzy webhook i zwracał nam soczystą odpowiedź JSON. Wyciekały z niej m.in.:
target_url(często zawierające wewnętrzne adresy firmowe lub tokeny w URL-ach),project_idoraz organizacja,- Dane właściciela:
username,first_name,last_name.
Ryzyko DoS
Skoro identyfikatory to zwykłe liczby, można użyć Intruder’a i iterować webhook_id tysiące razy. Poza masową kradzieżą danych (Data Leak), zmuszamy w ten sposób serwer CVAT do wysyłania tysięcy żądań HTTP do serwerów trzecich. Przy użyciu zrównoleglonych zapytań (np. z botnetu) moglibyśmy doprowadzić do wyczerpania zasobów aplikacji, wywołując klasyczny stan Denial of Service (DoS).
Wektor 2: Historia dostarczeń (Deliveries)
Drugi problem znajdował się w historii logów webhooków. Służył do tego endpoint:
Podobnie jak w przypadku pingu, zmiana <ID> pozwalała na czytanie cudzej historii zdarzeń. Co jednak najciekawsze w tym wektorze, to zagnieżdżone endpointy.
Aplikacja pozwalała na odpytanie o konkretne dostarczenie, gdzie oba identyfikatory (webhook_ID i delivery_ID) to sekwencyjne liczby.
Ciekawostka pentestera
Często zdarza się, że programiści po zgłoszeniu IDOR-a łatają główny endpoint (np. listowanie /deliveries), ale zapominają o nałożeniu Listy Kontroli Dostępu (ACL) na zagnieżdżony endpoint odpytujący o konkretny element (/deliveries/<delivery_ID>). Będąc w stanie odgadnąć (lub zbrute-force’ować) delivery_ID, atakujący wciąż mógłby dobierać się do danych!
Jak załatać takie błędy? (Remediacja)
Nawet jeśli zgłoszenie okazało się duplikatem, lekcja płynąca z tej podatności (teraz oficjalnie łatanej pod flagą CVE-2024-45393) jest uniwersalna:
- Konsekwentna Kontrola Dostępu (ACL): Sama weryfikacja sesji to za mało. Serwer przy każdym żądaniu musi sprawdzić regułę: "Czy użytkownik X ma prawo dostępu do zasobu Y?". I musi to zrobić na każdym endpoincie, od głównego
/webhookspo głęboko zagnieżdżone/webhooks/ID/deliveries/ID. - Koniec z sekwencyjnymi identyfikatorami: Gdyby CVAT używało długich, losowych ciągów znaków (np. UUID v4) zamiast wartości takich jak
784czy310, masowe skanowanie zasobów za pomocą Burp Intrudera byłoby po prostu niemożliwe. To doskonały przykład wdrożenia mechanizmu Defense-in-depth. Nawet jeśli logika ACL zawiedzie, atakujący i tak nie odgadnie identyfikatora cudzego zasobu.
Sekwencyjne ID = trywialne do odgadniecia (brute-force)
UUID v4 = 2122 mozliwych wartosci (Defense-in-depth)
Podsumowanie
CVE-2024-45393 to podwójny IDOR w mechanizmie webhooków platformy CVAT. Pierwszy wektor pozwalał na pingowanie cudzych webhooków i kradzież wrażliwych danych (target_url, username, project_id), a przy masowej eksploatacji stwarzał ryzyko DoS. Drugi wektor umożliwiał czytanie historii dostarczeń innych użytkowników, włącznie z zagnieżdżonymi endpointami. Luka została zgłoszona odpowiedzialnie i załatana, kluczowa lekcja to konieczność wdrożenia spójnej kontroli dostępu na wszystkich endpointach oraz rezygnacji z sekwencyjnych identyfikatorów.
Bibliografia
Oficjalny wpis w bazie NIST NVD opisujący podwójną podatność IDOR w webhookach CVAT z oceną CVSS 6.4.
Biuletyn bezpieczeństwa opublikowany na GitHubie przez zespół CVAT, zawierający szczegóły podatności i informacje o poprawce.
Kategoria OWASP opisująca podatności związane z nieprawidłową kontrolą dostępu na poziomie obiektów, dokładnie ten typ błędu, który został wykorzystany w CVE-2024-45393.
Repozytorium open-source narzędzia CVAT do adnotacji danych w projektach uczenia maszynowego i Computer Vision.