Podatności Froxlor

Froxlor w wersjach od 0.10.0 przed 2.3.15 zawiera podatność braku autoryzacji w komendzie API SubDomains.delete, która pozwala uwierzytelnionym klientom usuwać główne domeny przydzielone przez resellera poprzez podanie identyfikatora domeny głównej. Atakujący mogą obejść ograniczenia interfejsu webowego, usunąć domeny, osierocić rekordy vhost, DNS i subdomen oraz doprowadzić licznik subdomains_used poniżej zera, aby uzyskać dodatkowy limit subdomen.

Froxlor w wersjach od 0.10.0 przed 2.3.15 zawiera podatność obejścia autoryzacji w komendzie API Admins.get, która pozwala resellerom odczytać dowolny rekord administratora poprzez pomieszanie identyfikatorów. Atakujący mogą wysłać własną nazwę logowania z numerycznym identyfikatorem innego administratora, aby uzyskać adres e-mail kontaktowy, listy dozwolonych adresów IP, limity zasobów, notatki i historię logowania.

Froxlor w wersjach od 2.0.0 do 2.3.14 zawiera podatność przechowywanego skryptu krzyżowego (XSS), która pozwala uwierzytelnionym klientom na wstrzyknięcie HTML i JavaScript poprzez ustawienie złośliwej wartości motywu w customer_index.php. Skrypt wykonuje się, gdy administrator przegląda przegląd klientów z włączoną kolumną Theme, co pozwala atakującym na wykorzystanie tokenu CSRF do tworzenia kont administratorów lub zmiany ustawień serwera.

Froxlor do wersji 2.3.10 wyłącza dwuskładnikowe uwierzytelnianie (2FA) użytkownika natychmiast po nieuwierzytelnionym żądaniu GET do strony zarządzania 2FA (np. /customer_index.php?page=2fa&action=delete), bez potwierdzenia, ponownego uwierzytelnienia ani tokena CSRF. Globalny middleware CSRF obejmuje tylko żądania POST/PUT/PATCH/DELETE, a ciasteczko sesji ma SameSite=Lax, więc nawigacja między witrynami (kliknięcie linku lub przekierowanie) przenosi sesję ofiary i cicho czyści type_2fa/data_2fa. Dotyczy to zarówno handlerów 2FA klienta, jak i administratora. Atakujący, który zwabi zalogowanego użytkownika panelu do kliknięcia spreparowanego linku, redukuje konto do uwierzytelniania tylko hasłem, co można połączyć z przejętym hasłem do przejęcia konta. Naprawione w 2.3.12.

Froxlor przed wersją 2.3.12 nie unieważnia istniejących sesji panelu, kluczy API i ciasteczek zaufania 2FA po zmianie hasła użytkownika. Atakujący posiadający przejęte sesje, ważne klucze API lub tokeny zaufania 2FA zachowują pełny dostęp do konta po rotacji hasła, omijając działania związane z reagowaniem na incydenty.

Froxlor przed wersją 2.3.13 zwraca kolumnę ssl_key_file — która przechowuje surową zawartość prywatnego klucza TLS w formacie PEM — bezpośrednio w odpowiedziach JSON poleceń API Certificates.get i Certificates.listing, ponieważ wyniki zapytań domain_ssl_settings są przekazywane przez ApiCommand::response() bez żadnego usuwania pól ani listy dozwolonych. Nisko uprzywilejowany uwierzytelniony klient API może pobrać klucze prywatne certyfikatów swoich domen, w tym klucze Let's Encrypt generowane przez Froxlor po stronie serwera i przechowywane z uprawnieniami root-only (0600), do których klient nie ma dostępu do systemu plików; konta reseller i customers_see_all admin mogą zrzucić klucze prywatne innych podmiotów przez ten sam mechanizm. Ujawnione klucze umożliwiają podszywanie się pod domenę, pasywne deszyfrowanie przechwyconego ruchu TLS oraz aktywne ataki typu man-in-the-middle.

Froxlor przed wersją 2.3.15 zawiera podatność podążania za symlinkami w Statistics::makeChownWithNewStats, która pozwala uwierzytelnionym klientom przejąć własność dowolnych katalogów hosta poprzez nadużycie uruchamianego jako root crona ruchu. Atakujący może zastąpić katalog statystyk goaccess w swoim document root symlinkiem, powodując, że chown -R przekaże im drzewa katalogów należące do roota.

Froxlor w wersjach 2.3.10 i wcześniejszych zawiera niekompletną poprawkę podatności GHSA-c3p2 — funkcja Validate::validateUrl odrzuca znaki CR/LF tylko w ścieżce, zapytaniu i fragmencie, a nie sprawdza części userinfo (user:pass@). Uwierzytelniony klient z uprawnieniami do tworzenia subdomen może podać adres URL przekierowania subdomeny z ładunkiem CR/LF w części userinfo, który przechodzi walidację i jest zapisywany dosłownie w konfiguracji vhost nginx lub Apache. Froxlor regeneruje i przeładowuje konfigurację jako root, więc wstrzyknięte dyrektywy działają w całym serwerze.

Froxlor w wersjach 2.3.10 i wcześniejszych zawiera niekompletną poprawkę podatności GHSA-75h4-... — cron eksportu danych klienta (DataDump) nie waliduje pośrednich komponentów ścieżki docelowej. Funkcja Froxlor\FileDir::makeCorrectDir() ma błąd off-by-one w przechodzeniu komponentów ścieżki, pomijając pierwszy segment poniżej katalogu domowego klienta, a zabezpieczenie w ExportCron.php sprawdza tylko ostatni komponent przez is_link(). Uwierzytelniony klient z włączonym eksportem może zaplanować eksport do podkatalogu swojego webspace, a następnie zastąpić pośredni komponent ścieżki dowiązaniem symbolicznym przed uruchomieniem crona jako root. Wtedy 'chown -R' rekurencyjnie zmienia właściciela drzewa katalogów (np. /etc) na UID klienta, co prowadzi do przejęcia uprawnień roota i kompromitacji między dzierżawcami.

Froxlor w wersjach do 2.3.10 jest podatny na dowolne usuwanie plików poprzez podążanie za dowiązaniami symbolicznymi w zadaniu cron usuwania danych FTP. Zadanie cron 8 (deleteFtpData), kolejkowane przy usuwaniu konta FTP, wywołuje FileDir::makeCorrectDir() bez argumentu $fixed_homedir, więc przechodzenie komponentów ścieżki jest pomijane, a następnie wykonuje 'rm -rf' jako root na wynikowej ścieżce z jedynie tekstowymi zabezpieczeniami. Ponieważ makeCorrectDir() dodaje końcowy ukośnik, GNU rm podąża za dowiązaniem symbolicznym użytym jako pośredni lub końcowy komponent ścieżki. Uwierzytelniony klient mogący zapisywać w katalogu domowym FTP może umieścić dowiązanie symboliczne między wstawieniem zadania a wykonaniem crona, powodując rekurencyjne usunięcie dowolnych drzew katalogów przez zadanie roota.

Froxlor w wersjach przed 2.3.12 nie ogranicza ani nie escapuje ustawienia system.letsencryptchallengepath — w przeciwieństwie do innych ustawień wzmocnionych w GHSA-33mp, pole nie ma zabezpieczenia string_regexp ani required_otp, a jego wartość jest dołączana bez escapowania do wiersza poleceń acme.sh budowanego w lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php i wykonywanego przez cron roota przez FileDir::safe_exec. Ponieważ safe_exec blokuje tylko metaznaki powłoki takie jak ; | & > < \ $ ~ ?, spacje i cudzysłowy przechodzą, a wartość jest dzielona na dodatkowe argumenty acme.sh. Administrator lub dowolny podmiot mogący zapisywać ustawienia (np. przez API importu ustawień) może wstrzyknąć opcje acme.sh takie jak --renew-hook, --pre-hook lub --post-hook, aby uzyskać wykonanie dowolnych poleceń jako root przy następnym uruchomieniu crona Let's Encrypt, albo użyć --config-home/--cert-home do zapisu dowolnych plików.

Froxlor w wersjach przed 2.2.5 nie waliduje znaków nowej linii w adresach URL przekierowań subdomen, co pozwala uwierzytelnionym klientom wstrzyknąć dowolne dyrektywy konfiguracji nginx lub Apache. Złośliwe adresy URL z literalnymi znakami nowej linii są zapisywane dosłownie do plików konfiguracji vhost podczas przebudowy cron, umożliwiając uszkodzenie konfiguracji serwera WWW, atak odmowy usługi lub przejęcie odpowiedzi HTTP dla hostowanych domen.

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.

Froxlor przed wersją 2.3.14 zawiera podatność typu insecure direct object reference w edytorze szablonów e-mail (admin_templates.php), ponieważ treść wiadomości pobierana jest przez mailbodyid bez sprawdzenia właściciela (adminid). Uwierzytelnieni administratorzy reseller mogą łączyć własny subjectid z obcymi, sekwencyjnymi wartościami mailbodyid, aby odczytać szablony e-mail innych administratorów, w tym pełnego administratora.

Froxlor w wersji od 0.10.0 do 2.3.14 zawiera podatność braku autoryzacji, która pozwala kontom resellerów na odczyt konfiguracji serwera MySQL i zadań cron przeznaczonych tylko dla pełnego administratora poprzez polecenia API. Resellerzy mogą wywołać MysqlServer.listing, MysqlServer.get lub Cronjobs.listing przez api.php, aby uzyskać nazwy użytkowników zarządzających, hosty, porty, ustawienia TLS i metadane cron.

Froxlor w wersjach od 0.10.0 do 2.3.14 zawiera podatność wstrzykiwania nowej linii, która pozwala uwierzytelnionym klientom na wstrzyknięcie dowolnych wpisów do bazy danych grup NSS należącej do roota poprzez niezwalidowany parametr additional_members w API Ftps.add. Atakujący mogą osadzić znaki nowej linii, które cron REBUILD_NSSUSERS zapisuje bez sanityzacji do /var/lib/extrausers/group, tworząc uprzywilejowane wpisy grupowe dla lokalnej eskalacji uprawnień.

Froxlor 2.0.0 do 2.3.10 jest podatny na przechowywany cross-site scripting. Gdy klient (najniżej uprzywilejowana rola) przesyła certyfikat SSL dla własnej domeny, metody add()/update() API Certificates parsują go funkcją openssl_x509_parse() i przechowują wartość issuer organization bez sanityzacji. Renderer tabel Froxlor emituje komórki skalarne przez filtr `raw` Twig, wyłączając automatyczne escapowanie HTML, więc gdy administrator lub reseller otworzy Domeny > Certyfikaty SSL, wartość issuer dostarczona przez atakującego wykonuje się jako skrypt w sesji uprzywilejowanego użytkownika. Problem przekracza granicę uprawnień od klienta do administratora i może prowadzić do pełnego przejęcia konta administratora; ponieważ administrator Froxlor kontroluje serwer WWW, DNS i konfigurację PHP stosowaną przez cron działający jako root, problem może być dalej eskalowany do wykonania poleceń jako root na zarządzanym serwerze. Problem naprawiono w Froxlor 2.3.12.

Podatność ujawnienia poświadczeń w Froxlor przed wersją 2.3.12 w komendzie API DirProtections.listing, która zwraca hashe haseł htpasswd. Uwierzytelnieni użytkownicy API mogą pobrać hashe bcrypt haseł użytkowników katalogów chronionych, co umożliwia ataki offline i ujawnienie ponownie użytych poświadczeń.

Froxlor do wersji 2.3.10 nie egzekwuje polityki mail.allow_external_domains w poleceniu API EmailSender.add. Gdy administrator włączył funkcję dozwolonych nadawców, ale wyłączył zewnętrzne domeny (mail.enable_allow_sender = 1, mail.allow_external_domains = 0), uwierzytelniony klient z dostępem do API może nadal użyć EmailSender.add do zarejestrowania dowolnego zewnętrznego adresu nadawcy dla swojej skrzynki, który jest przechowywany mimo polityki. Tworzy to obejście między konfiguracją UI/administratora a API i — tam gdzie wygenerowana konfiguracja poczty korzysta z tabeli dozwolonych nadawców — umożliwia klientowi autoryzację tożsamości nadawcy spoza hostowanych domen, ułatwiając podszywanie się pod nadawcę. Naprawiono w wersji 2.3.12.

Froxlor 2.3.10 i wcześniejsze zawierają wyścig TOCTOU w synchronizacji kluczy SSH (lib/Froxlor/Cron/System/SshKeys.php, SshKeys::generateFiles). Walidacja zawartości/symlinków wykonywana przez FileDir::makeCorrectDir()/makeCorrectFile() jest tylko w czasie sprawdzenia; ścieżka pliku jest ponownie rozwiązywana jako root w czasie zapisu, bez przypinania ścieżki lub deskryptora pliku. Na instalacjach z włączonym system.allow_customer_shell=1, klient może podmienić swój katalog ~/.ssh na symlink po sprawdzeniu, co powoduje, że cron działający jako root dopisuje klucz publiczny klienta do /root/.ssh/authorized_keys i zmienia właściciela /root/.ssh na klienta, prowadząc do pełnego przejęcia hosta panelu. Naprawiono w Froxlor 2.3.12.

Froxlor do wersji 2.3.10 nie filtruje wrażliwych kolumn z odpowiedzi API: Domains::get(), Domains::listing(), SubDomains::get() oraz gałąź admina SubDomains::listing() wykonują SELECT z użyciem wildcard na tabeli panel_domains i zwracają wiersz bez modyfikacji, w tym pole panel_domains.dkim_privkey. Uwierzytelniony administrator niebędący superadminem z flagą customers_see_all może odczytać prywatne klucze DKIM domen innych dzierżawców przez Domains.get, Domains.listing, SubDomains.get lub SubDomains.listing, a jedno wywołanie listing ujawnia klucz każdej widocznej domeny. Ujawnione klucze pozwalają atakującemu podpisywać e-maile przechodzące weryfikację DKIM i wyrównanie DMARC dla dotkniętych domen. To następstwo niepełnej poprawki, która usunęła hasło i data_2fa, ale nie dkim_privkey. Problem naprawiony w 2.3.12.

Froxlor do 2.3.10 przechowuje w tokenach remembered-2FA (panel_2fa_tokens) tylko numeryczny identyfikator użytkownika bez przestrzeni nazw konta, a wyszukiwanie tokena przy logowaniu nie jest ograniczone do typu konta klienta lub administratora. Ponieważ identyfikatory klientów i administratorów pochodzą z oddzielnych przestrzeni, token wystawiony klientowi o danym ID pasuje także do administratora o tym samym ID, co pozwala obejść drugi składnik TOTP administratora przy znanym haśle.

Froxlor przed wersją 2.3.7 nie ogranicza poprawnie wyszukiwania aliasów nadawców do bieżącego klienta w pliku customer_email.php. Uwierzytelnieni atakujący mogą wyliczać globalne identyfikatory aliasów nadawców i odczytywać dozwolone wartości nadawców innych klientów, podając dowolne parametry senderid w żądaniach potwierdzenia usunięcia.

Froxlor przed wersją 2.3.7 nie weryfikuje parametru mysql_server względem listy dozwolonych serwerów (allowed_mysqlserver) klienta w poleceniu API Mysqls.add. Atakujący mogą podać niedozwolony indeks serwera, aby tworzyć bazy danych i użytkowników MySQL na zabronionych serwerach, omijając kontrolę dostępu per klient.

Froxlor przed wersją 2.2.0 (dotyczy do 2.2.0-rc3 włącznie) generuje plik /etc/pure-ftpd/db/mysql.conf z uprawnieniami 0644 poprzez szablony konfiguracji XML w lib/configfiles/, mimo że plik zawiera hasło użytkownika SQL Froxlor. W systemach, w których katalogi nadrzędne są czytelne dla wszystkich (domyślnie w Debian 12), każdy nieuprzywilejowany lokalny użytkownik mogący wykonywać polecenia lub kod na hoście — w tym użytkownicy wirtualni bez dostępu SSH, którzy mogą przesyłać skrypty PHP/CGI — może odczytać plik i uzyskać poświadczenia bazy danych Froxlor. Dostęp do bazy danych można następnie wykorzystać do zmiany hasha hasła administratora i ziarna TOTP, zalogowania się jako administrator Froxlor i ostatecznie uzyskania uprawnień roota. Dotyczy tylko instancji skonfigurowanych do używania pure-ftpd.

Froxlor przed wersją 2.3.12 nie waliduje poprawnie wieloliniowych kluczy publicznych SSH w punkcie końcowym SshKeys::add(). Umożliwia to klientom wstrzyknięcie dowolnych linii do plików authorized_keys, w tym złośliwych wpisów z dyrektywami opcji.

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.