Podatności Crawl4AI

Crawl4AI przed wersją 0.8.7 zawiera podatność umożliwiającą dowolny zapis plików w endpointach /screenshot i /pdf serwera API Docker. Parametr output_path akceptuje dowolne ścieżki systemowe bez walidacji, co pozwala atakującemu na nadpisanie plików serwera i spowodowanie odmowy usługi.

Crawl4AI przed wersją 0.9.0 zawiera podatność w API Dockera, która pozwala na wstrzyknięcie argumentów do przeglądarki Chromium. Atakujący może wykorzystać przełączniki Chromium do podmiany polecenia uruchomienia procesu potomnego, co prowadzi do wykonania dowolnego kodu w kontenerze.

W bibliotece Crawl4AI przed wersją 0.9.0 wykryto podatność na zapis dowolnego pliku. Atakujący może wpłynąć na nazwę pliku docelowego poprzez nagłówek Content-Disposition lub sugerowaną nazwę pliku, co umożliwia zapis pliku poza katalogiem docelowym. Może to prowadzić do zdalnego wykonania kodu.

Crawl4AI przed wersją 0.8.7 zawiera podatność w funkcji _safe_eval_expression() w mechanizmie computed fields. Walidator AST blokuje tylko atrybuty zaczynające się od podkreślenia, ale atrybuty obiektów generatora i ramki (gi_frame, f_back, f_builtins) nie zaczynają się od podkreślenia, co umożliwia całkowitą ucieczkę z sandboksa i wykonanie dowolnego kodu. Atak nie wymaga uwierzytelnienia (JWT domyślnie wyłączone) i jest wyzwalany przez POST /crawl z spreparowanym schematem ekstrakcji.

Crawl4AI w wersjach przed 0.8.0 zawiera podatność zdalnego wykonania kodu w API Docker. Punkt końcowy /crawl akceptuje parametr hooks zawierający kod Python, który jest wykonywany za pomocą exec(). Dozwolone wbudowane funkcje obejmowały __import__, co pozwala nieuwierzytelnionym atakującym na importowanie dowolnych modułów i wykonywanie poleceń systemowych.

Crawl4AI przed 0.9.5 zawiera podatność blind server-side request forgery w serwerze Docker, która pozwala klientom API obejść proxy wyjściowe poprzez włączenie check_cache_freshness. Atakujący mogą zapisać w pamięci podręcznej kontrolowany URL, a następnie wywołać CacheValidator, aby podążał za przekierowaniami 302 lub DNS rebinding do adresów wewnętrznych i metadanych chmury w celu odkrywania portów i usług.

Crawl4AI od 0.9.0 do 0.9.4 zawiera podatność wstrzyknięcia JavaScript w serwerze API Docker, która pozwala uwierzytelnionym klientom API uruchomić dowolny JavaScript na stronie crawlowej poprzez pola css_selector i wait_for z listy dozwolonych. Atakujący mogą wstrzyknąć cudzysłowy do css_selector lub dostarczyć warunki js: w wait_for, omijając blokadę js_code, aby zmienić stan strony i zwracaną treść crawlowania.

Crawl4AI w wersjach od 0.9.0 do 0.9.5 nie filtruje pola model_name w CosineStrategy w niezaufanych treściach żądań API Docker. Uwierzytelniony klient może wybrać model HuggingFace ładowany przez serwer, wskazując złośliwe repozytorium z plikiem wag pickle.

Crawl4AI przed wersją 0.9.5 zawiera podatność na odmowę usługi w serwerze API Docker, gdzie funkcja _clamp_untrusted() nie ogranicza pól delay_before_return_html, mean_delay i max_range w niezaufanych treściach CrawlerRunConfig. Nieuwierzytelniony atakujący może wysyłać ogromne wartości do /crawl lub /crawl/stream.

Crawl4AI w wersji przed 0.9.5 zawiera podatność na nieprawidłową walidację certyfikatów, ponieważ Chromium jest zawsze uruchamiany z flagą --ignore-certificate-errors. Atakujący w sieci (man-in-the-middle lub kontrolujący DNS) mogą dostarczać sfałszowaną treść do crawlera oraz odczytywać wysyłane ciasteczka i nagłówki. Dodatkowo twardo zakodowana flaga --no-sandbox nadpisuje ustawienie CRAWL4AI_CHROMIUM_SANDBOX.

Crawl4AI w wersjach od 0.7.0 przed 0.9.5 zawiera podatność na nadmierną złożoność wyrażeń regularnych w serwerze API Dockera, pozwalającą uwierzytelnionym klientom API na przesyłanie nieograniczonych wyrażeń regularnych w treści żądań /crawl. Atakujący mogą przesyłać wzorce powodujące katastrofalne cofanie poprzez RegexExtractionStrategy.custom, RegexChunking.patterns lub pola schematów JsonCss, JsonXPath i JsonLxml przeciwko spreparowanej stronie, aby zamrozić cały serwer, w tym /health.

Crawl4AI w wersjach od 0.8.7 do 0.9.5 zawiera lukę SSRF w serwerze API Dockera, umożliwiającą nieuwierzytelnionym atakującym obejście kontroli miejsca docelowego poprzez różnice w parsowaniu userinfo w URL. Atakujący mogą ustawić fetch_ssl_certificate=true ze spreparowanymi adresami URL, aby połączyć się z wewnętrznymi hostami na porcie 443 i ujawnić szczegóły certyfikatów.

Crawl4AI przed 0.9.4 zawiera podatność ślepego fałszerstwa żądań po stronie serwera w RobotsParser.can_fetch, która pozwala nieuwierzytelnionym atakującym ominąć kontrolę egress Docker. Atakujący mogą włączyć check_robots_txt i użyć przekierowań lub rebindingu DNS, aby dotrzeć do wewnętrznych, pętli zwrotnej lub adresów metadanych chmury w celu wykrywania usług.

Crawl4AI w wersjach od 0.7.0 do 0.9.4 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF), która pozwala klientom API na dostęp do wewnętrznych adresów poprzez włączenie link_preview_config w żądaniach /crawl. Atakujący mogą dostarczyć kontrolowaną stronę z ustawionymi include_external i include_patterns, co powoduje, że AsyncUrlSeeder pobiera wewnętrzne, prywatne i cloud-metadata linki i zwraca ich sparsowane dane nagłówka.

Crawl4AI w wersjach od 0.9.0 do 0.9.4 zawiera podatność na obejście bramki niezaufanej konfiguracji, która pozwala nieadministracyjnym klientom API na konstruowanie zabronionych obiektów konfiguracji poprzez opakowanie ich w typy dyktujące. Atakujący mogą wysłać wyprany LLMConfig z api_token ustawionym na referencję środowiskową przez /config/dump, aby odczytać SECRET_KEY i klucze dostawców, umożliwiając fałszowanie JWT administratora.

crawl4ai w wersjach przed 0.9.3 zawiera podatność na DOM-based cross-site scripting w interfejsie Playground UI, gdzie funkcja forceHighlightElement() przypisuje textContent z powrotem do innerHTML, ponownie parsując odpowiedzi JSON jako HTML. Atakujący mogą wstrzyknąć złośliwe skrypty poprzez zawartość przeglądanej strony, taką jak tytuł strony.

Crawl4AI przed wersją 0.9.3 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w strategii PDFContentScrapingStrategy, gdzie funkcja _get_pdf_path() ponownie pobiera cele za pomocą Python requests bez walidacji egress. Uwierzytelnieni atakujący mogą dostarczyć adresy URL, które przekierowują na wewnętrzne adresy lub użyć DNS rebinding, aby uzyskać dostęp do wewnętrznych usług, eksfiltrując odpowiedzi poprzez ekstrakcję tekstu PDF w wynikach przeszukiwania.

crawl4ai przed 0.9.3 zawiera podatność na DOM-based cross-site scripting w interfejsie Docker Playground UI, który przypisuje niezaufane wyniki przeglądania do element.innerHTML. Atakujący mogą spreparować złośliwe pliki PDF ze znacznikami obsługi zdarzeń, aby wykonać JavaScript w origin Playground.

Crawl4AI przed wersją 0.9.3 zawiera podatność na niekontrolowane zużycie zasobów w strategii PDFContentScrapingStrategy, która pozwala niezaufanym klientom na spowodowanie odmowy usługi. Atakujący mogą wybrać strategię skrobania PDF w żądaniach POST, aby pobierać duże zdalne pliki PDF bez ograniczeń rozmiaru lub liczby stron, wyczerpując dysk, CPU i pasmo na współdzielonych workerach.

crawl4ai przed wersją 0.9.3 zawiera podatność na dowolny zapis plików w strategii PDFContentScrapingStrategy, gdzie funkcja _filter_untrusted_fields nie waliduje niezaufanych pól konfiguracyjnych. Atakujący mogą przesłać spreparowane ciała konfiguracji ze złośliwymi ścieżkami image_save_dir, aby zapisać kontrolowane przez atakującego bajty w dowolnym katalogu dostępnym dla konta usługi.

Crawl4AI przed wersją 0.8.8 zawiera podatność umożliwiającą wyciek poświadczeń przez nieuwierzytelnione endpointy API Dockera. Atakujący może przekierować wywołania API LLM na kontrolowany przez siebie serwer i odczytać zmienne środowiskowe, w tym klucze API i sekrety JWT.

Crawl4AI przed wersją 0.8.7 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w endpointach API Dockera /crawl/job i /llm/job, które akceptują adresy URL webhook bez walidacji docelowego miejsca. Atakujący może dostarczyć adresy URL webhook wskazujące na prywatne lub wewnętrzne zakresy IP, sieci Docker lub punkty końcowe metadanych chmury (np. 169.254.169.254), powodując, że serwer wysyła żądania do wewnętrznych usług i potencjalnie ujawnia metadane chmury.

Crawl4AI przed wersją 0.9.0 zawiera podatność SSRF w ścieżce strumieniowej API Dockera. Niezautoryzowany zdalny klient może wysłać żądanie POST do /crawl/stream lub /crawl z parametrem stream=true, wskazując URL na adres wewnętrzny, prywatny lub link-local, a serwer pobierze i przekaże odpowiedź.

Crawl4AI przed wersją 0.8.7 zawiera podatność umożliwiającą wykonanie dowolnego kodu JavaScript przez endpoint /execute_js w serwerze API Docker. Atakujący może przesłać złośliwy skrypt, który zostanie wykonany w kontekście przeglądarki serwera z wyłączonymi zabezpieczeniami sieciowymi.

Crawl4AI przed wersją 0.8.9 zawiera podatność SSRF, która pozwala nieuwierzytelnionemu atakującemu na ominięcie sprawdzania docelowego adresu URL i skierowanie ruchu przez proxy na wewnętrzne adresy IP. Atakujący może wykorzystać tę lukę do uzyskania dostępu do wewnętrznych usług i punktów końcowych metadanych chmury, podając prawidłowy adres URL do przeszukania.

Crawl4AI przed wersją 0.8.8 zawiera podatność SSRF w serwerze API Docker, która pozwala atakującemu ominąć blokadę CIDR i uzyskać dostęp do wewnętrznych usług oraz endpointów metadanych chmury (np. 169.254.169.254) poprzez kodowanie adresu IPv4 w formie przejściowej IPv6 lub użycie adresu nieokreślonego IPv6. Ponieważ API Docker jest domyślnie nieuwierzytelnione, atak nie wymaga żadnych poświadczeń.

Crawl4AI przed wersją 0.8.8 zawiera podatność na dowolne zapisywanie plików w punktach końcowych zrzutów ekranu i PDF, co pozwala nieautoryzowanym atakującym na zapis plików poza zamierzonym katalogiem.

Crawl4AI przed wersją 0.8.7 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w endpointach /crawl, /crawl/stream, /md i /llm, które pobierają dowolne adresy URL podane przez użytkownika bez walidacji. Nieuwierzytelnieni atakujący mogą ominąć blokadę adresów wewnętrznych za pomocą adresów IPv6 mapowanych na IPv4, aby uzyskać dostęp do wewnętrznych usług i punktów końcowych metadanych chmury.

Crawl4AI w wersjach przed 0.8.0 zawiera podatność na lokalne dołączanie plików w API Docker. Punkty końcowe /execute_js, /screenshot, /pdf i /html akceptują adresy URL z protokołem file://, co pozwala nieuwierzytelnionym atakującym na odczyt dowolnych plików z systemu plików serwera.