Podatności Chartbrew

W wersji 4.9.0 aplikacji Chartbrew występuje luka, która pozwala atakującym z niskimi uprawnieniami na dostęp do danych z innych projektów w tym samym zespole. Luka ta umożliwia odczyt, wykonanie, tworzenie, aktualizację oraz usuwanie zestawów danych i żądań danych, do których atakujący nie powinien mieć dostępu.

W wersji 4.9.0 aplikacji Chartbrew występuje luka, która pozwala na dostęp do punktu końcowego POST /api/chart/:chart_id/query bez uwierzytelnienia. Atakujący, znając identyfikator wykresu, może odświeżyć dane i uzyskać dostęp do prywatnych wykresów.

W wersji 4.9.0 aplikacji Chartbrew, uwierzytelnieni użytkownicy mający dostęp do jednego projektu mogą aktualizować lub usuwać rekord SharePolicy należący do innego projektu. Problem wynika z braku weryfikacji, czy policy_id należy do danego projektu.

W wersji 4.9.0 aplikacji Chartbrew występuje luka, która pozwala na publiczny dostęp do danych wykresów, nawet jeśli są one ukryte. Luka ta wynika z niewłaściwej weryfikacji uprawnień dostępu do wykresów w projektach publicznych.

Chartbrew przed wersją 5.2.3 zawiera podatność na wstrzyknięcie SQL w protokole ClickHouse, ponieważ funkcja applySqlVariables() jest wywoływana bez opcji escapeBackslash. Atakujący może dostarczyć backslash przed cudzysłowem, aby obejść podwajanie cudzysłowów i wykonać dowolny SQL ClickHouse, co może prowadzić do ujawnienia danych lub, przy odpowiedniej konfiguracji bazy, dostępu do plików lub zasobów wewnętrznych. Publiczne pulpity nawigacyjne mogą być wykorzystywane bez uwierzytelnienia.

Chartbrew przed wersją 5.2.2 zawiera podatność w implementacji runQuery() w server/modules/ai/orchestrator/tools/runQuery.js, gdzie parametr row_limit narzędzia AI jest interpolowany do klauzuli LIMIT SQL bez walidacji liczby całkowitej w czasie wykonywania. Kontrola słów kluczowych tylko do odczytu jest wykonywana przed dodaniem tej wartości, więc uwierzytelniony użytkownik, który może wpłynąć na niecałkowitą wartość row_limit generowaną przez model, może dodać SQL, który omija wcześniejszą kontrolę. Skuteczne wykorzystanie może wykonać dowolne instrukcje względem podłączonej bazy danych, w tym odczytywać lub zmieniać dane oraz, jeśli uprawnienia bazy danych na to pozwalają, uzyskać dostęp do plików lub wykonać polecenia systemu operacyjnego. Problem został naprawiony w wersji 5.2.2.

Chartbrew przed wersją 5.2.2 zawiera podatność w implementacji runQuery() w server/modules/ai/orchestrator/tools/runQuery.js, która próbuje egzekwować dostęp tylko do odczytu za pomocą listy blokującej zawierającej tylko siedem słów kluczowych SQL. Uwierzytelniony użytkownik z dostępem do funkcji AI może przesłać niebezpieczne instrukcje lub funkcje bazodanowe, których nie ma na liście blokującej, powodując ich wykonanie bez użycia technik SQL injection lub obfuskacji słów kluczowych. W zależności od silnika bazy danych, konfiguracji i uprawnień użytkownika bazy danych, może to ujawnić lub zapisać pliki, uzyskać dostęp do wewnętrznych zasobów sieciowych, zmienić uprawnienia bazy danych, wykonać polecenia lub zmienić dane. Problem został naprawiony w wersji 5.2.2.

Chartbrew przed wersją 5.2.2 zawiera podatność w server/modules/safeRequest.js, gdzie funkcja validateOutboundUrl() rozwiązuje i waliduje docelową nazwę hosta, ale request-promise wykonuje oddzielną rozdzielczość DNS dla rzeczywistego połączenia. Uwierzytelniony użytkownik, który może tworzyć lub testować połączenia API i kontroluje docelową nazwę DNS, może zwrócić publiczny adres podczas walidacji i prywatny adres podczas żądania, omijając zabezpieczenia zaimplementowane w server/modules/outboundTargetPolicy.js. Ten warunek ponownego wiązania DNS może ujawnić wewnętrzne usługi, zasoby localhost lub punkty końcowe metadanych chmury. Problem został naprawiony w wersji 5.2.2.