Podatności MaxKB

MaxKB to open-source'owy asystent AI dla przedsiębiorstw. Przed wersją 2.10.5-lts uwierzytelnieni członkowie workspace mogą wstrzykiwać znaki kontrolne do pól access_key_id i secret_access_key AWS Bedrock, które funkcja _update_aws_credentials zapisuje do /root/.aws/credentials bez bezpiecznego parsowania. Atakujący może dopisać nowy profil AWS zawierający credential_process, a następnie wybrać go podczas późniejszej walidacji modelu, aby botocore wykonał kontrolowane przez atakującego polecenie jako root.

MaxKB to open-source'owy asystent AI dla przedsiębiorstw. Przed wersją 2.10.5-lts asystenci z narzędziem, narzędziem MCP, umiejętnością lub podaplikacją używają SandboxShellBackend, który udostępnia narzędzie execute shell bez jego wykluczenia i pomija execute w interrupt_on, więc zatwierdzenie przez człowieka nie jest wymagane. Niezaufany czat lub przetworzona treść mogą zatem wywołać wykonanie polecenia; wdrożenia źródłowe z wyłączonym MAXKB_SANDBOX uruchamiają polecenia bezpośrednio jako użytkownik aplikacji, a oficjalny kontener root z opakowaniem gosu opartym na łańcuchach pozwalał na wykonanie metaznaków powłoki poza zamierzonym sandboxem.

W MaxKB przed wersją 2.10.6-lts kod biblioteki funkcji działający w sandboxie LD_PRELOAD może wywołać ctypes.CDLL z callbacku importlib.abc.MetaPathFinder, tak aby heurystyka stosu wywołań dlopen zobaczyła ramkę importu Pythona, a następnie użyć niepodpiętego dlsym z RTLD_NEXT do rozwiązania prawdziwego wywołania systemowego glibc i obejścia czarnej listy wywołań systemowych sandboxa.

W MaxKB przed wersją 2.10.6-lts sandbox LD_PRELOAD w ToolExecutor przechwytuje execve, execvpe i execveat, aby zapobiec tworzeniu podprocesów, ale nie przechwytuje fexecve. Uwierzytelniony atakujący zdolny do wykonania kodu narzędzia może wywołać fexecve, aby uruchomić proces poza zamierzoną polityką podprocesów sandboxa.

W MaxKB w wersjach 2.7.0 do 2.10.4-lts endpoint POST /chat/api/{application_id}/chat/{chat_id}/share_chat sprawdza jedynie istnienie konwersacji, ale nie weryfikuje, czy należy ona do uwierzytelnionego chat_user_id ani do aplikacji powiązanej z tokenem wywołującego. Atakujący z dowolnym tokenem czatu i znanym chat_id ofiary może utworzyć publiczny link ChatShareLink ujawniający konwersację oraz stan PublicFileAccess umożliwiający pobranie powiązanych plików bez poświadczeń, bez możliwości cofnięcia.

W MaxKB w wersji 2.10.2-lts i wcześniejszych trasy zarządzania rekordami czatu autoryzują application_id ze ścieżki, ale ładują rekordy używając globalnych wartości chat_id i chat_record_id bez potwierdzenia, że czat należy do autoryzowanej aplikacji. Zwykły użytkownik w tym samym workspace, znając chat_id utrwalonego rekordu ofiary, może odczytać rekordy czatu ofiary, a także skopiować odpowiedzi ofiary poprzez add_knowledge.

MaxKB, asystent AI dla przedsiębiorstw, w wersji 2.10.3-lts i wcześniejszych, ma podatność w trasie formularza parametrów modelu. Uwierzytelniony użytkownik z uprawnieniami do odczytu modelu w przestrzeni kontrolowanej przez atakującego może odczytać lub nadpisać model_params_form ofiary w innej przestrzeni, używając znanego model_id, bez uwzględnienia workspace_id w zapytaniu.

W MaxKB w wersji 2.10.3-lts i wcześniejszych import i synchronizacja dokumentów web przekazuje URL uwierzytelnionego użytkownika do Fork.fork, który wywołuje requests.get z verify=False i bez ograniczeń schematów, adresów loopback, link-local, prywatnych ani zarezerwowanych. Treść odpowiedzi staje się treścią importowanego dokumentu, co pozwala niskouprzywilejowanemu użytkownikowi na odczyt metadanych chmury lub wewnętrznych usług HTTP przez serwer MaxKB.

W MaxKB w wersji 2.10.2-lts i wcześniejszych zwykły użytkownik w tym samym workspace może uzyskać application_id innego użytkownika z endpointu rankingu pytań aplikacji na stronie głównej, gdy opublikowana aplikacja ofiary ma aktywność rankingową w wybranym zakresie dat. Atakujący mogący tworzyć i publikować aplikacje workflow może umieścić ujawniony identyfikator w węźle aplikacji workflow, uruchomić go, otrzymać dane wyjściowe ofiary i utworzyć trwałe rekordy application_chat pod aplikacją ofiary.

W MaxKB w wersji 2.10.2-lts i wcześniejszych ścieżka uwierzytelniania /chat/api/mcp wyszukuje ApplicationApiKey tylko po sekrecie i statusie aktywności, bez egzekwowania sprawdzeń is_permanent i expire_time używanych przez standardowe API czatu. Wcześniej ważny, niepermanentny klucz aplikacji, który pozostaje aktywny po wygaśnięciu, może zainicjować endpoint MCP, wyświetlić metadane narzędzi opublikowanej aplikacji, wywołać tools/call i utworzyć trwałe rekordy application_chat.

W MaxKB w wersji 2.10.2-lts i wcześniejszych zwykły użytkownik workspace znający tool_id aktywnego narzędzia MCP innego użytkownika może pobrać ukryte narzędzie przez trasę szczegółów narzędzia, która nie stosuje autoryzacji per-zasób używanej przez trasę listy. Odpowiedź zawiera Tool.code, który może zawierać konfigurację serwera MCP i nagłówki, a atakujący mogący tworzyć lub edytować własny workflow może umieścić obcy mcp_tool_id w węźle mcp workflow, aby debug użył konfiguracji MCP właściciela.

W MaxKB od wersji 2.0.0 do 2.10.2-lts trasy operacji na dokumentach i akapitach autoryzują tylko knowledge_id ze ścieżki żądania, a następnie pobierają Document po document_id lub Paragraph po paragraph_id bez potwierdzenia, że obiekt należy do tej bazy wiedzy. Zwykły użytkownik workspace znający UUID dokumentu lub akapitu ofiary może odczytać lub zmodyfikować treść w bazie wiedzy innego użytkownika.

W MaxKB od wersji 2.0.0 do 2.9.2 najniższy rangą członek workspace, któremu odmówiono dostępu do narzędzia przez WorkspaceUserResourcePermission, może nadal powiązać jego identyfikator przez tool_ids, skill_tool_ids lub mcp_tool_ids i wykonać je przez ścieżkę dyspozycji agenta lub workflow. Ścieżka dyspozycji nie stosuje ponownie uprawnień per-narzędzie, a wykonanie narzędzia odszyfrowuje init_params po stronie serwera, co pozwala wywołującemu otrzymać poświadczenia przenoszone przez zabronione narzędzie.

MaxKB od wersji 2.0.0 do 2.10.4-lts w funkcji UpdateStoreTool.update_tool przekazuje wartości download_url i download_callback_url do requests.get bez walidacji zaufanych hostów i przekierowań. Uwierzytelniony użytkownik workspace może zmusić serwer do żądania wewnętrznych, pętli zwrotnej, link-local lub adresów metadanych chmury.

W MaxKB przed wersją 2.10.0-lts funkcja importowania narzędzi oraz tryb odwoływania MCP nie walidują spójnie typu transportu MCP, co pozwala uwierzytelnionemu użytkownikowi zaimportować plik .tool z transportem stdio zawierającym złośliwe polecenia i uruchomić je przez węzeł AI Chat, prowadząc do wykonania dowolnych poleceń systemowych.

Podatność SSRF w MaxKB przed wersją 2.10.0 pozwala uwierzytelnionym użytkownikom na wykonywanie dowolnych żądań serwerowych poprzez niezweryfikowane parametry downloadCallbackUrl i download_url w endpointach tworzenia i aktualizacji narzędzi. Atakujący z domyślną rolą USER mogą wykorzystać tę lukę do uzyskania dostępu do wewnętrznych usług sieciowych.

MaxKB, asystent AI dla przedsiębiorstw, przechowuje hasła użytkowników za pomocą niesolonych skrótów MD5, co umożliwia ich łatwe złamanie przy użyciu tablic tęczowych lub ataku brute-force z akceleracją GPU.

MaxKB przed wersją 2.9.1 jest podatny na SSRF (Server-Side Request Forgery) poprzez import work_flow_template. Uwierzytelnieni użytkownicy mogą podać dowolne adresy URL w polu work_flow_template.downloadUrl, które są pobierane po stronie serwera bez walidacji URL ani filtrowania wewnętrznych adresów IP.

MaxKB przed wersją 2.9.0 udostępnia endpoint webhooka (/api/trigger/v1/webhook/{trigger_id}) bez uwierzytelniania. Klasa WebhookAuth zwraca (None, {}), co jest interpretowane jako pomyślne uwierzytelnienie. Nieuwierzytelniony atakujący znający identyfikator triggera może wywołać webhook i wykonać powiązane zadania.

MaxKB w wersji 2.8.0 i wcześniejszych jest podatny na naruszenie kontroli dostępu w API pobierania URL plików OSS (chat/api/oss/get_url). Endpoint używa application_id z ścieżki URL bez walidacji własności, co pozwala atakującym na wykonywanie operacji w ramach polityk innych aplikacji.

MaxKB 2.8.0 i wcześniejsze wersje są podatne na Server-Side Request Forgery (SSRF) w funkcji pobierania URL plików OSS z powodu niespójnego rozwiązywania DNS między walidacją a rzeczywistym wykonaniem żądania, co pozwala atakującym na dostęp do wewnętrznych usług sieciowych.

MaxKB przed wersją 2.8.1 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w punkcie końcowym pobierania adresu URL pliku OSS. Niezgodność w parsowaniu URL między funkcją walidacyjną a klientem HTTP pozwala atakującemu na dostęp do wewnętrznych usług sieciowych.