Podatności Froxlor

Froxlor 2.3.7 do 2.3.8 w poleceniach API Customers.get, Customers.listing, Admins.get, Admins.listing, Ftps.get i Ftps.listing zwraca pełne wiersze bazy danych bez usuwania pól haseł i data_2fa. Uwierzytelniony wywołujący API z uprawnieniami do tych punktów końcowych może uzyskać hasze haseł klientów, administratorów i FTP oraz zakodowane w Base32 sekrety TOTP dla kont administratorów i klientów. Hasze haseł można złamać offline, a sekrety TOTP mogą generować ważne kody drugiego czynnika, dopóki uwierzytelnianie dwuskładnikowe nie zostanie zresetowane. Ujawnienie obu wartości dla konta może umożliwić przejęcie panelu hostingowego lub hostowanych zasobów i może pokonać oba czynniki uwierzytelniania. Problem naprawiono w wersji 2.3.8.

Froxlor w wersji przed 0.9.33.2 z domyślną konfiguracją może umożliwić zdalnym atakującym uzyskanie hasła do bazy danych poprzez odczytanie pliku /logs/sql-error.log.

Froxlor w wersjach przed 0.9.35 wykorzystuje funkcję PHP rand do generowania liczb losowych, co ułatwia zdalnym atakującym odgadnięcie tokena resetowania hasła poprzez przewidywanie wartości.

Podatność w oprogramowaniu Froxlor przed wersją 2.3.8. Punkt wejścia lib/ajax.php omija centralną walidację żądań, a akcja editapikey nie sprawdza tokenu CSRF. Nieuwierzytelniony atakujący może nakłonić przeglądarkę administratora do wysłania sfałszowanego żądania, które dodaje adres atakującego do listy allowed_from klucza API lub usuwa jego wygaśnięcie, osłabiając zabezpieczenia klucza.

Froxlor przed wersją 2.3.8 zawiera podatność w komendzie API DomainZones.add, która nie odrzuca znaków nowej linii, tabulacji, średników ani nieobsługiwanych typów rekordów DNS przed zapisem do pliku strefy BIND. Uwierzytelniony klient z uprawnieniami do stref DNS może wstrzyknąć dodatkowe linie rekordów, omijając walidację pól. BIND akceptuje wstrzyknięte rekordy, co pozwala na modyfikację danych DNS i może wpłynąć na dostępność DNS w strefie.

Froxlor przed wersją 2.3.8 zawiera podatność SQL Injection w endpointach Admins.add i Admins.update, gdzie atakujący administrator może zapisać tablicę ipaddress z dowolnymi elementami, które później są łączone w klauzulę SQL IN bez parametryzacji. Uwierzytelniony administrator z uprawnieniami change_serversettings może wykorzystać to do odczytania danych z bazy, w tym loginów i hashy haseł administratorów.

Froxlor przed wersją 2.3.8 zawiera podatność Stored XSS w treści rekordów DNS TXT, gdzie zawartość nie jest odpowiednio escapowana przed renderowaniem w panelu administratora. Uwierzytelniony klient z dostępem do edycji DNS może umieścić złośliwy JavaScript w rekordzie TXT, który wykona się w sesji administratora podczas przeglądania konfiguracji DNS.

Froxlor przed wersją 2.3.7 zawiera podatność w ścieżce uwierzytelniania API, która nie wymaga drugiego czynnika (2FA) dla kont z włączoną weryfikacją dwuetapową. Atakujący, który zdobędzie klucz API i sekret, może uzyskać pełny dostęp do funkcji API bez podania kodu TOTP, co może prowadzić do ujawnienia lub modyfikacji danych klientów, domen, kont e-mail i FTP, baz danych, rekordów DNS i materiałów certyfikatów.

Froxlor w wersji 2.3.6 i wcześniejszych zawiera podatność w walidacji rekordów DNS LOC, TLSA i innych. Wyrażenie regularne dla LOC dopuszcza znaki nowej linii, TLSA z matchingType=0 nie ma ograniczenia długości danych hex, a walidatory zwracają surowe dane bez odpowiedniego escapowania.

Froxlor w wersji 2.3.6 zawiera podatność na podążanie za dowiązaniami symbolicznymi (symlink following) w ścieżce synchronizacji kluczy SSH należących do roota, używanej dla klientów FTP. Atakujący z kontem shell może podmienić plik authorized_keys na dowiązanie do /root/.ssh/authorized_keys, co pozwala na dodanie własnego klucza i uzyskanie dostępu SSH jako root.

Froxlor 2.3.6 nie wymusza listy dozwolonych powłok systemowych dla kont FTP. Uwierzytelniony klient z delegacją powłoki może ustawić dowolną powłokę, np. /bin/bash, co w domyślnej integracji nssextrausers prowadzi do rzeczywistego dostępu do powłoki hosta.

Froxlor przed wersją 2.3.7 zawiera podatność w endpointcie API DomainZones.add, która nie oczyszcza znaków nowej linii w treści rekordów TXT. Uwierzytelniony klient z włączonym edytowaniem DNS może wstrzyknąć nowe linie, co umożliwia wstrzyknięcie dowolnych dyrektyw BIND i rekordów DNS do pliku strefy.