Podatności LobeChat

LobeChat (LobeHub) 2.2.1 nie weryfikuje poprawnie podpisów webhooków przychodzących z platform czatu w adapterach QQ i Feishu. Trasa webhooka (/api/agent/webhooks/:platform) jest z założenia nieuwierzytelniona i deleguje weryfikację do każdego adaptera; adapter QQ nie wykonuje żadnej weryfikacji podpisu Ed25519 na wysyłanych zdarzeniach wiadomości, a adapter Feishu wykonuje tylko opcjonalne porównanie statycznego tokena, które jest pomijane, gdy token nie jest skonfigurowany (domyślnie) i nie jest podpisem treści. Nieuwierzytelniony atakujący, który zna publiczny adres URL webhooka, może wysłać sfałszowane przychodzące wiadomości z tożsamością nadawcy wybraną przez atakującego i dowolnym tekstem, powodując, że agent właściciela bota przetworzy dane kontrolowane przez atakującego i potraktuje atakującego jako zaufanego nadawcę platformy.

LobeChat w wersji do 2.2.9 zawiera podatność związaną z uszkodzoną autoryzacją na poziomie obiektu, która umożliwia uwierzytelnionym atakującym dostęp i modyfikację danych agentów grup czatu innych użytkowników poprzez podanie dowolnych identyfikatorów grup. Atakujący mogą wywoływać operacje getGroupAgents, updateAgentInGroup i removeAgentsFromGroup bez predykatów ograniczających do zakresu użytkownika, co pozwala na odczyt list agentów, zmianę ich ról i kolejności oraz usuwanie agentów z grup czatu należących do innych użytkowników.

LobeChat do wersji 2.2.9 zawiera podatność związaną z niespójną kontrolą dostępu w funkcji wyszukiwania semantycznego RAG. Uwierzytelnieni atakujący mogą uzyskać dostęp do danych innych użytkowników, wykorzystując brak predykatów identyfikujących użytkownika w metodzie semanticSearch modelu chunk.

LobeChat przed wersją 2.2.10-canary.18 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF). Uwierzytelniony atakujący może kierować wewnętrzne żądania HTTP do dowolnych adresów URL, wykorzystując punkty końcowe importu umiejętności (importFromUrl) i aktualizacji okładki tematu (fetchImageFromUrl), które używają globalnego fetch bez ochronnego wrappera ssrf-safe-fetch.

LobeChat w wersji do 2.2.9 z wdrożeniem serwer-baza danych jest podatny na naruszenie autoryzacji na poziomie obiektu w modelu MessageModel. Metody updateMessagePlugin, updatePluginState, updatePluginError, updateTTS i updateTranslate filtrują docelowe wiersze wyłącznie po identyfikatorze wiadomości, pomijając zakres userId stosowany w innych metodach, a findMessagePlugin odczytuje dane wyłącznie po identyfikatorze. Uwierzytelniony użytkownik znający identyfikator wiadomości innego użytkownika może nadpisać metadane wywołań narzędzi pluginu, stan/błąd pluginu, rekordy zamiany tekstu na mowę i tłumaczenia ofiary, a zmodyfikowana treść jest zwracana ofierze.

LobeChat przed wersją 2.2.10-canary.15 zawiera podatność na atak typu ReDoS (Regular Expression Denial of Service). Uwierzytelniony atakujący może zablokować pętlę zdarzeń Node.js poprzez dostarczenie złośliwego wzorca katastroficznego cofania w ścieżce URL repozytorium GitHub podczas importu umiejętności. Atakujący może skonstruować złośliwą wartość basePath zawierającą nieuciekające metaznaki wyrażeń regularnych, które są wstrzykiwane do dynamicznie tworzonego wyrażenia regularnego w funkcji findSkillMd i wykonywane synchronicznie na wpisach archiwum, powodując odmowę usługi dla wszystkich współbieżnych użytkowników na dziesiątki sekund na żądanie.