Podatności Nginx UI

Nginx UI to internetowy interfejs użytkownika dla serwera Nginx. Od wersji 2.2.0 do 2.6.0, wbudowany odwrotny proxy nie zachowuje tożsamości zewnętrznego klienta używanej przez Gin, ponieważ backend nie ma konfiguracji zaufanego proxy. Żądania zarządzania mogą być przypisywane do loopback i przechodzić wyjątek listy dozwolonych IP dla loopback, chociaż nadal wymagane są prawidłowe poświadczenia. Nieudane logowania z różnych zewnętrznych klientów są również przypisywane do tego samego adresu loopback, co pozwala nieuwierzytelnionemu atakującemu na wywołanie wspólnego tymczasowego banu logowania dla uwierzytelniania hasłem lub OTP bez unieważniania istniejących sesji. Problem został naprawiony w wersji 2.6.0.

Nginx UI, interfejs webowy dla serwera Nginx, przed wersją 2.3.8, udostępniał punkt końcowy przywracania kopii zapasowej (POST /api/restore), który był całkowicie nieautoryzowany przez pierwsze 10 minut po uruchomieniu procesu na świeżej instalacji. Nieautoryzowany zdalny atakujący mógł przesłać spreparowaną archiwum kopii zapasowej, co prowadziło do nadpisania pliku konfiguracyjnego aplikacji oraz bazy danych SQLite.

Nginx UI przed wersją 2.4.1 używa stałej wartości OAuth state w GetCasdoorUri i nie weryfikuje stanu w CasdoorCallback, co pozwala nieuwierzytelnionemu atakującemu na przejęcie sesji użytkownika.

Nginx UI to interfejs webowy dla serwera Nginx. Przed wersją 2.4.1 trasy mutacji konfiguracji HTTP wymagają RequireSecureSession, ale /mcp i /mcp_message wymagają tylko zwykłego uwierzytelnienia przed udostępnieniem nginx_config_add i nginx_config_modify. Użytkownik z włączonym OTP, posiadający zwykły JWT, ale bez ważnego X-Secure-Session-ID, może tworzyć lub modyfikować konfigurację Nginx i wywoływać przeładowanie przez MCP, omijając zamierzoną kontrolę step-up. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1 zawiera podatność, w której wygenerowane krótkie tokeny nie mają powiązanej długiej wartości Token, a funkcja DeleteUserTokens unieważnia wpisy w pamięci podręcznej tylko wtedy, gdy długie pole Token nie jest puste. Odwołany krótki token może pozostać w pamięci podręcznej i ponownie uwierzytelnić użytkownika, jeśli konto zostanie ponownie włączone przed wygaśnięciem wpisu, przywracając dostęp do tras HTTP lub WebSocket akceptujących uwierzytelnianie krótkim tokenem.

Nginx UI przed wersją 2.4.3 zawiera podatność polegającą na tym, że funkcja AutoBackup.GetName zwraca nazwę kontrolowaną przez użytkownika bez odrzucania separatorów ścieżek lub komponentów katalogu nadrzędnego, a dalsze formatowanie nazwy pliku osadza ten wynik w końcowej nazwie archiwum. Uwierzytelniony użytkownik może spowodować, że filepath.Join rozwiąże wygenerowaną ścieżkę archiwum poza zwalidowanym katalogiem przechowywania, umożliwiając zapis archiwów kopii zapasowych z uprawnieniami procesu Nginx UI.

Nginx UI przed wersją 2.4.1 odrzuca w zwykłym API konfiguracji HTTP ograniczone dyrektywy Nginx, takie jak load_module, js_import i js_content. Jednak interfejs konfiguracji MCP pozwala uwierzytelnionemu użytkownikowi zapisać i zastosować równoważną ograniczoną zawartość konfiguracji. Umożliwia to załadowanie ngx_http_js_module.so, importowanie kontrolowanego przez atakującego JavaScriptu, przeładowanie Nginx i wykonanie NJS w kontekście workerów Nginx. Problem naprawiono w wersji 2.4.1.

Nginx UI od wersji 2.0.0-rc.6 do 2.4.1, narzędzie MCP nginx_config_add zapisuje pliki konfiguracyjne Nginx na dysk i wyzwala przeładowanie Nginx bez wywołania config.ValidateConfigFile. Identyczny przepływ w API REST (POST /api/configs) wywołuje tę funkcję i poprawnie odrzuca niebezpieczne dyrektywy. Uwierzytelniony atakujący może wykorzystać tę lukę do zapisania plików konfiguracyjnych zawierających dowolną zablokowaną dyrektywę (perl, js_import, load_module, user root itp.), omijając całą warstwę bezpieczeństwa nginx-ui. Na serwerze z modułem Perl, njs lub Lua Nginx jest to zdalne wykonanie kodu po uwierzytelnieniu. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, wewnętrzny plik config/validation.go (ValidateConfigFile) jest kontrolą bezpieczeństwa blokującą niebezpieczne dyrektywy nginx — js_*, perl_*, load_module modułów njs/perl oraz user root. Jest egzekwowany na trzech z czterech ścieżek zapisu konfiguracji: api/config/add.go, api/config/modify.go i mcp/config/config_modify.go. Czwarta ścieżka — narzędzie MCP nginx_config_add (mcp/config/config_add.go) — NIE wywołuje tej funkcji: zapisuje dostarczoną przez wywołującego zawartość bezpośrednio na dysk i przeładowuje nginx. Uwierzytelniony wywołujący MCP (lub agent MCP zaindukowany przez prompt injection) może więc wstrzyknąć dokładnie te dyrektywy, które kontrola ma blokować, prowadząc do wykonania kodu nginx na wdrożeniach, gdzie dostępny jest moduł njs/perl (np. oficjalny obraz Docker). Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, config.ValidateConfigDirectives dzieli konfigurację po nowych liniach i sprawdza tylko pierwszy token dyrektywy w każdej linii, mimo że Nginx dopuszcza wiele dyrektyw oddzielonych średnikami w jednej linii. Uwierzytelniony wywołujący może umieścić nieszkodliwą dyrektywę na początku, a później w tej samej linii ograniczoną dyrektywę load_module, js_import, perl lub user root, albo użyć nieograniczonej dyrektywy include do załadowania ograniczonej zawartości. Te mechanizmy omijają walidację na ścieżkach zapisu REST, nginx_config_modify, site i stream; gdy dostępny jest moduł wykonywalny, wstrzyknięta konfiguracja może wykonać kod w kontekście workerów Nginx. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1 nie stosuje RequireSecureSession do wielu uwierzytelnionych tras mutacji, mimo że użytkownicy z włączonym OTP powinni przedstawić świeży X-Secure-Session-ID do wrażliwych działań. Wykradziona uwierzytelniona sesja może zatem tworzyć lub zmieniać automatyczne kopie zapasowe, dane uwierzytelniające i rekordy DNS, certyfikaty i użytkowników ACME, ustawienia sterowania Nginx oraz automatyzację site lub stream bez ukończenia kroku OTP lub passkey. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, endpoint POST /api/users/:id umożliwia uwierzytelnionemu użytkownikowi zmianę hasła innego użytkownika bez przejścia RequireSecureSession, mimo że ścieżka samodzielnej zmiany hasła wymaga tego kroku. Atakujący z uwierzytelnionym kontem może zmienić hasło początkowego administratora, unieważnić istniejące tokeny administratora, a następnie uwierzytelnić się jako administrator. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, POST /api/otp_enroll i POST /api/finish_passkey_register są zarejestrowane poza RequireSecureSession i akceptują normalną uwierzytelnioną sesję bez weryfikacji bieżącego hasła. Atakujący z wykradzionym JWT może powiązać kontrolowany przez siebie sekret TOTP, gdy ofiara nie włączyła jeszcze TOTP, lub zarejestrować kontrolowany passkey, ponieważ ta ścieżka nie ma odpowiedniego zabezpieczenia istniejącej rejestracji. Te zmiany tworzą trwały dostęp do konta, który może przetrwać zmianę hasła i zakłócić uwierzytelnianie prawowitego użytkownika. Problem naprawiono w wersji 2.4.1.

W Nginx UI od wersji 2.0.0 do 2.5.0 router api/cluster udostępnia operacje modyfikacji węzłów i przestrzeni nazw oraz globalne przeładowanie/restart Nginx z wymogiem AuthRequired, ale bez RequireSecureSession. Uwierzytelniony użytkownik z włączonym OTP, posiadający skradziony lub trwały token JWT, może wykonywać operacje CRUD na węzłach, odczytywać lub podmieniać poświadczenia węzłów, zmieniać przestrzenie nazw oraz wywoływać przeładowanie/restart Nginx bez ponownego uwierzytelnienia drugim składnikiem.

W Nginx UI od wersji 2.0.0 do 2.5.0 mechanizm samodzielnej aktualizacji weryfikuje pobrany plik binarny wyłącznie za pomocą skrótu pochodzącego z tego samego serwera aktualizacji. Skompromitowane lustro lub atakujący w sieci mogą dostarczyć złośliwy plik wykonywalny wraz z pasującym skrótem, a aplikacja zainstaluje i uruchomi ten kod w kontekście procesu Nginx UI przy następnej aktualizacji.

W Nginx UI od wersji 2.0.0 do 2.5.0 zwykli uwierzytelnieni użytkownicy mogą uzyskać dostęp do /api/nodes i /api/nodes/:id, których odpowiedzi zawierają pole tokenu węzła. Ten sam token jest akceptowany jako X-Node-Secret przez AuthRequired i mapuje żądanie na initUser, co pozwala użytkownikowi podszyć się pod zaufany węzeł wobec osiągalnego członka klastra.

W Nginx UI od wersji 2.0.0 do 2.5.0 plik internal/backup/restore.go rozpakowuje wewnętrzne archiwa przed zastosowaniem flag restore_nginx i restore_nginx_ui oraz zezwala na dowiązania symboliczne wskazujące na aktywną ścieżkę konfiguracji Nginx. Uwierzytelniony użytkownik mogący tworzyć i przywracać kopie zapasowe może przygotować kopię, która umieszcza dowiązanie symboliczne w drzewie tymczasowym, a następnie zapisuje przez nie zwykły plik, nawet gdy obie flagi przywracania są wyłączone.

W Nginx UI od wersji 2.0.0 do 2.5.0 mechanizm AuthRequired akceptuje token cookie zarządzany przez przeglądarkę jako poświadczenie API, po tym jak front end zapisze JWT w tym cookie. Ponieważ punkty końcowe zarządzania nie wymagają powszechnie tokenu CSRF ani nie wykonują walidacji Origin lub Referer, zdalny atakujący może nakłonić przeglądarkę zalogowanego administratora do wysłania uwierzytelnionych żądań zmieniających stan z innej witryny, w tym POST /api/configs.

W Nginx UI od wersji 2.0.0 do 2.5.0 punkt końcowy POST /api/login sprawdza EnabledOTP, ale nie wymaga asercji WebAuthn, gdy EnabledPasskey jest prawdziwe i nie skonfigurowano sekretu TOTP. Konto korzystające wyłącznie z passkey otrzymuje sesję po weryfikacji hasła, mimo że Enabled2FA wskazuje na posiadanie drugiego czynnika.

W Nginx UI od wersji 2.0.0 do 2.5.0 aplikacja akceptuje główne poświadczenie Node.Secret poprzez parametr zapytania node_secret w ścieżkach uwierzytelniania HTTP i WebSocket, zamiast wymagać nagłówka X-Node-Secret. Poświadczenie może pojawić się w logach dostępu, logach proxy, historii przeglądarki, nagłówkach Referer, adresach URL konfiguracji i danych środowiskowych wdrożenia.

Nginx UI to interfejs webowy dla serwera Nginx. Od wersji 2.3.8 do 2.5.0 uwierzytelniony administrator z aktywną sesją może przesłać kontrolowany przez atakującego materiał klucza kopii zapasowej i pasujący manifest do POST /api/restore. Proces przywracania ufa dostarczonemu kluczowi, odszyfrowuje kontrolowaną treść i zastępuje plik app.ini, w tym chronione ustawienia poleceń nginx, takie jak TestConfigCmd. Wywołanie POST /api/nginx/test wykonuje przywrócone polecenie w kontekście środowiska Nginx UI.

Nginx UI w wersjach od 2.5.0 do 2.6.0 wykonuje tymczasowe zapisywanie treści żądania kontrolowanej przez atakującego i synchronizuje ją na dysk przed weryfikacją skrótu i podpisu kryptograficznego. Nieuwierzytelniony zdalny klient może wyczerpać miejsce na dysku, operacje wejścia/wyjścia oraz zasoby przetwarzania żądań, zanim żądanie zostanie odrzucone. Problem został naprawiony w wersji 2.6.0.

Nginx UI to interfejs webowy dla serwera Nginx. W wersjach 2.3.4 i wcześniejszych, uwierzytelniony użytkownik może przeprowadzić atak typu Server-Side Request Forgery (SSRF) poprzez utworzenie węzła klastra wskazującego na dowolny wewnętrzny adres URL.

Nginx UI w wersjach przed 2.3.8 posiada handler API GetSettings, który serializuje wszystkie struktury ustawień do JSON i zwraca je uwierzytelnionym użytkownikom. Wiele wrażliwych pól oznaczonych protected:"true" jest chronionych tylko przy zapisie, a przy odczycie ignorowanych jest ponad 40 pól, w tym JwtSecret, NodeSecret, OIDC ClientSecret i konfiguracja białej listy IP.

W wersji 2.3.5 interfejsu użytkownika Nginx (nginx-ui) występuje podatność na nieautoryzowane przejęcie podczas początkowej instalacji, która jest eksponowana przez POST /api/install.

Nginx UI to interfejs webowy dla serwera Nginx. W wersjach od 2.0.0 do przed 2.3.8, nieautoryzowany atakujący sieciowy może przejąć początkowe konto administratora na świeżej instancji nginx-ui podczas pierwszej konfiguracji.

Nginx UI w wersjach przed 2.3.8 pozwala uwierzytelnionemu użytkownikowi wywołać GET /api/settings i uzyskać wrażliwe wartości konfiguracji, w tym node.secret. Ten sam node.secret jest akceptowany przez AuthRequired() poprzez nagłówek X-Node-Secret lub parametr zapytania node_secret, co powoduje traktowanie żądania jako uwierzytelnionego ścieżką zaufanego węzła i powiązanie go z użytkownikiem init.