Podatności Kiteworks

Nieuwierzytelniony atakujący mógł spowodować zapisanie pliku o treści kontrolowanej przez atakującego w systemie plików urządzenia przez moduł obsługi przesyłania administracyjnego, który nie uwierzytelniał prawidłowo żądania. To samo w sobie nie prowadziło do wykonania kodu, co wymagałoby osobnej podatności umożliwiającej umieszczenie pliku w lokalizacji wykonywalnej.

Szablon powiadomień systemowych na urządzeniu Kiteworks był renderowany przez silnik szablonów, który ewaluował wyrażenia zawarte w treści przechowywanego szablonu. Uwierzytelniony Administrator Systemowy mógł potencjalnie zapisać spreparowany szablon, który wykonywał polecenia systemu operacyjnego na urządzeniu przy następnym wysłaniu powiadomienia.

Uwierzytelniony administrator może obejść walidację treści stosowaną przy przesyłaniu plików administracyjnych i zapisać na urządzeniu plik zawierający niebezpieczną treść. Sama ta podatność nie prowadzi do wykonania kodu — do uruchomienia zapisanego pliku potrzebna jest osobna luka.

W środowiskach wielowęzłowych atakujący, który uzyskał już wykonanie kodu na jednym węźle urządzenia, może przesłać przez wewnętrzny interfejs klastra wartość zapisywaną do konfiguracji monitoringu na innym węźle bez wystarczającej walidacji, co potencjalnie pozwala na wykonanie poleceń systemowych na tym węźle. Wykonanie ograniczone jest do nieuprzywilejowanego konta usługi na tym węźle.

Piaskownica izolująca konwersję dokumentów na urządzeniu Kiteworks nie w pełni ograniczała wykonywany kod, co mogło pozwolić na ucieczkę z piaskownicy i działanie z uprawnieniami konta usługowego. Atakujący mógł odczytać lub zmodyfikować dane i konfigurację aplikacji lub zakłócić działanie usługi.

Interfejs konfiguracji urządzenia Kiteworks nie wymuszał uwierzytelniania po zakończeniu wstępnej konfiguracji urządzenia. Nieuwierzytelniony atakujący z dostępem sieciowym do urządzenia mógł odczytać i zmodyfikować ograniczony zestaw rekordów konfiguracyjnych, w tym nazwę kontaktu i adres e-mail zapisane podczas wstępnej konfiguracji.

Interfejs konfiguracji urządzenia Kiteworks nie ograniczał ścieżki pliku do zamierzonego katalogu, co mogło pozwolić nieuwierzytelnionemu atakującemu na zapis pliku w dowolnym miejscu zapisywalnym przez konto usługowe. Wykorzystanie wymaga dostępu sieciowego do interfejsu, który w domyślnej konfiguracji nie jest osiągalny po pełnym skonfigurowaniu urządzenia.

Kiteworks nie egzekwował poprawnie, jakie role menedżer folderu współdzielonego może przypisywać. W domyślnej konfiguracji uwierzytelniony użytkownik z rolą Menedżera folderu mógł nadać rolę Właściciela sobie lub innym członkom tego folderu.

Podatność na eskalację uprawnień w Kiteworks mogła pozwolić atakującemu z wykonaniem kodu na jednym węźle klastra na uruchamianie poleceń systemu operacyjnego z podwyższonymi uprawnieniami na innym węźle. Niewystarczająca walidacja danych w wewnętrznej funkcji zarządzania klastrem umożliwiła przekazanie wartości do uprzywilejowanego kontekstu wykonania.

Podatność na przechodzenie po ścieżkach w opcjonalnej, niedomyślnej funkcji administracyjnej umożliwiała uwierzytelnionemu administratorowi przenoszenie plików do nieprzewidzianych lokalizacji poza wyznaczonym katalogiem. Może to zostać wykorzystane do wykonania dowolnego kodu na systemie.

Lokalna podatność na eskalację uprawnień w Kiteworks mogła pozwolić atakującemu z istniejącą powłoką w niskouprzywilejowanym koncie usługowym na eskalację do uprawnień root na urządzeniu.

W przypadku wdrożeń z włączoną i licencjonowaną funkcją zdalnego wsparcia, uwierzytelniony administrator systemu posiadający klucz chroniący przesyłane dane mógł przekierować wychodzące połączenie wsparcia do wybranego miejsca docelowego. To miejsce mogło następnie wykonywać polecenia systemu operacyjnego na węźle i otrzymywać ich wyniki, co mogło prowadzić do zdalnego wykonania kodu z uprawnieniami lokalnego konta usługowego.

Podatność na wstrzyknięcie poleceń w Kiteworks mogła pozwolić uwierzytelnionemu administratorowi z wysokimi uprawnieniami na wykonanie dowolnych poleceń systemu operacyjnego jako root na dotkniętym węźle. Wykorzystanie wymaga konta administracyjnego z podwyższonymi uprawnieniami.

Podatność na eskalację uprawnień w Kiteworks umożliwia atakującemu, który uzyskał już wykonanie kodu jako nieuprzywilejowane konto usługi backendowej, eskalację do roota. Przywilejowana procedura niebezpiecznie obsługiwała ścieżkę pliku, którą mogło wpływać konto o niższych uprawnieniach, co pozwalało na wykonanie dowolnych poleceń z najwyższymi uprawnieniami. Wymaga to istniejącego lokalnego dostępu do tego konta usługi.

Podatność na eskalację uprawnień w Kiteworks umożliwia atakującemu, który uzyskał już wykonanie kodu jako nieuprzywilejowane konto usługi backendowej, eskalację do roota i wykonanie dowolnych poleceń z najwyższymi uprawnieniami. Wymaga to istniejącego lokalnego dostępu do tego konta usługi.

Kiteworks nie egzekwował maksymalnej dozwolonej wartości dla konfigurowalnego ustawienia zasad bezpieczeństwa. Uwierzytelniony administrator mógł ustawić tę wartość poza zamierzonym zakresem, przez co powiązana kontrola nigdy się nie aktywowała, mimo że w interfejsie administracyjnym i dzienniku audytu nadal wyglądała na włączoną, co pozwalało na ciche unieszkodliwienie mechanizmu ochronnego.

Endpoint używany podczas początkowej konfiguracji urządzenia nie wymagał uwierzytelnienia i nie egzekwował poprawnie warunku stanu, więc w oknie początkowej aktywacji nieuwierzytelniony atakujący z sieci mógł wielokrotnie wywoływać uprzywilejowany proces aktywacji. To mogło zakłócić konfigurację i pozostawić urządzenie w niekompletnie skonfigurowanym stanie. Problem jest osiągalny tylko podczas pierwszej aktywacji urządzenia, gdy nie jest jeszcze w pełni skonfigurowane.

Wielokrotne podatności SQL Injection w Kiteworks Secure Data Forms. Uwierzytelniony atakujący z rolą FormBuilder może odczytywać i modyfikować definicje formularzy innych użytkowników oraz parametry konfiguracyjne.

W Kiteworks przed wersją 9.3.0 wykryto podatność IDOR (Insecure Direct Object Reference). Uwierzytelniony użytkownik może uzyskać dostęp do metadanych zasobów innych użytkowników z powodu niewystarczającej kontroli uprawnień.

Podatność Insecure Direct Object Reference (IDOR) w Kiteworks Secure Data Forms przed wersją 9.3.0 umożliwia uwierzytelnionemu użytkownikowi modyfikację zasobów należących do innych użytkowników z powodu niewystarczających kontroli autoryzacji.

Kiteworks przed wersją 9.3.0 ma podatność IDOR (Insecure Direct Object Reference) w Secure Data Forms, która pozwala uwierzytelnionemu użytkownikowi na modyfikację uprawnień do zasobów innych użytkowników z powodu niewystarczającej kontroli autoryzacji.

Kiteworks przed wersją 9.3.0 ma podatność na trwały atak XSS w Secure Data Forms, która pozwala uwierzytelnionemu atakującemu na wykonanie dowolnego kodu JavaScript w sesjach innych użytkowników.

Kiteworks (prywatna sieć danych) przed wersją 9.3.0 zawiera podatność IDOR (Insecure Direct Object Reference) w Secure Data Forms, która pozwala uwierzytelnionemu użytkownikowi modyfikować zasoby należące do innych użytkowników z powodu niewystarczających kontroli autoryzacji.

Podatność Reflected XSS w Kiteworks Secure Data Forms przed wersją 9.3.0. Zewnętrzny atakujący może nakłonić użytkownika do wykonania dowolnego kodu JavaScript poprzez spreparowany link.

Kiteworks przed wersją 9.3.0 zawiera odbitą podatność XSS w Secure Data Forms, umożliwiającą zewnętrznemu atakującemu nakłonienie użytkownika do wykonania dowolnego kodu JavaScript. Problem naprawiony w wersji 9.3.0.

Kiteworks przed wersją 9.3.0 zawiera podatność IDOR w Secure Data Forms. Uwierzytelniony atakujący może modyfikować konfiguracje przepływu zatwierdzania formularzy innych użytkowników z powodu niewystarczającej kontroli własności zasobów.

W Kiteworks przed wersją 9.1.0 występuje niewłaściwa walidacja danych wejściowych podczas zarządzania rolami udostępnionego folderu. Może to prowadzić do nieoczekiwanego podniesienia uprawnień innego użytkownika na udostępnieniu. Problem został naprawiony w wersji 9.1.0.