Podatności Termix

Termix to platforma zarządzania serwerem, która przed wersją 2.3.2 akceptowała hasło konta jako jedyny czynnik uwierzytelniający dla operacji krytycznych związanych z MFA. Atakujący, który zdobędzie hasło użytkownika, może całkowicie wyłączyć TOTP lub wygenerować kody zapasowe, co czyni uwierzytelnianie dwuskładnikowe nieskutecznym.

Termix to platforma zarządzania serwerem oparta na sieci web, która przed wersją 2.3.2 miała 16 punktów końcowych menedżera plików, które nie weryfikowały, czy użytkownik żądający dostępu posiada sesję SSH identyfikowaną przez `sessionId`. Uwierzytelniony atakujący, który zna lub zgaduje aktywne `sessionId` innego użytkownika, może uzyskać dostęp do plików na zdalnym hoście SSH ofiary.

Termix, platforma do zarządzania serwerami oparta na WWW, w wersjach od 1.7.0 do 1.9.0 zawiera podatność na Stored XSS w komponencie File Manager. Aplikacja nie dezynfekuje zawartości plików SVG przed ich renderowaniem, co pozwala atakującemu, który skompromitował zarządzany serwer SSH, na umieszczenie złośliwego pliku. Podczas podglądu przez użytkownika Termix, plik wykonuje dowolny JavaScript w kontekście aplikacji. Podatność została naprawiona w wersji 1.10.0.

W Termix od wersji 2.4.1 do 2.5.1 uwierzytelniony administrator może zapisać kontrolowane przez atakującego wartości domeny i adresu e-mail przez PATCH /users/acme-ssl-settings, a następnie wywołać ich interpolację do polecenia powłoki certbot przez POST /users/acme-ssl-request. W pliku acme-ssl-routes.ts funkcja child_process.execSync wywołuje /bin/sh -c z tymi wartościami jedynie w cudzysłowach, co pozwala na wykonanie dowolnych poleceń systemowych jako proces backendu Termix. Podatność dotyczy trybów HTTP webroot i DNS Cloudflare challenge, a jej wykorzystanie ujawnia bazy danych Termix, sekrety procesu, przechowywane poświadczenia i dostęp sieciowy. Problem naprawiono w wersji 2.5.1.

Termix przed wersją 2.6.1 zawiera podatność w punkcie końcowym GET /host/db/host/:id/password, która nie weryfikuje własności hosta podczas pobierania poświadczeń. Uwierzytelniony użytkownik może wyliczać identyfikatory hostów i uzyskać poświadczenia SSH lub sudo innych użytkowników.

Termix przed wersją 2.3.2 zawiera podatność w terminalu WebSocket, która pozwala uwierzytelnionemu użytkownikowi o niskich uprawnieniach na wykorzystanie poświadczeń innego użytkownika do połączenia z kontrolowanym przez atakującego serwerem SSH. Może to prowadzić do ujawnienia hasła SSH lub klucza prywatnego.

Termix przed wersją 2.3.2 zawiera podatność w ścieżce usuwania tunelu SSH, która interpoluje dane użytkownika do wzorca polecenia pkill. Uwierzytelniony użytkownik może wstrzyknąć polecenie powłoki, które zostanie wykonane podczas rozłączania tunelu.

Termix to platforma zarządzania serwerami oparta na sieci web, która przed wersją 2.3.2 miała lukę w punkcie końcowym `POST /ssh/tunnel/connect`. Luka ta pozwalała na wstrzyknięcie poleceń systemowych poprzez interpolację pól kontrolowanych przez użytkownika w poleceniu powłoki.

Termix to platforma zarządzania serwerem oparta na sieci, która przed wersją 2.3.2 była podatna na wstrzykiwanie poleceń systemowych w punkcie końcowym GET /ssh/file_manager/ssh/resolvePath. Umożliwia to uwierzytelnionym użytkownikom wykonanie dowolnych poleceń na zdalnym hoście.

Termix przed wersją 2.1.0 zawiera podatność na iniekcję poleceń w endpointach zarządzania kontenerami Docker, gdzie parametr containerId jest bezpośrednio interpolowany do poleceń powłoki, co pozwala uwierzytelnionemu atakującemu na zdalne wykonanie kodu na zarządzanym serwerze.

Termix w wersjach od 2.5.0 do 2.5.1 zawiera podatność w punkcie końcowym /homepage/proxy, który przekazuje parametr url do http.get lub https.get bez ograniczeń docelowych. Walidacja URL jest tylko składniowa, co pozwala na żądania do adresów loopback, RFC1918, link-local i metadanych chmury. Uwierzytelniony użytkownik o niskich uprawnieniach może wyeksfiltrować dane wewnętrznych usług i poświadczenia chmury.

Termix od wersji 2.4.0 do 2.5.1 wymagał wyłącznie hasła jako czynnika ponownego uwierzytelnienia w endpointach wyłączania TOTP i generowania kodów zapasowych. Zmiany z refaktoryzacji cofnęły zabezpieczenie dwuskładnikowe, przez co atakujący mający sesję ofiary i znający hasło może wyłączyć 2FA bez dostępu do autentykatora.

Termix od wersji 1.7.0 do 2.5.1 wyprowadzał klucze do owijania DEK użytkowników OIDC i WebAuthn z domyślnych, zakodowanych na stałe ciągów oraz publicznego userId salt. Atakujący posiadający offline'ową kopię bazy SQLite może wyprowadzić klucz i odszyfrować zapisane hasła SSH, klucze prywatne i passphrase.

Termix w wersjach od 1.7.0 do 2.5.1 w procesie wdrażania kluczy SSH tworzy wzorzec grep z danych kontrolowanych przez użytkownika i wstawia go do poleceń powłoki wykonywanych na zdalnym hoście. Uwierzytelniony użytkownik może wstrzyknąć polecenia powłoki i wykonać je z uprawnieniami wybranego konta zdalnego. Problem naprawiono w wersji 2.5.1.

Termix w wersjach od 2.5.0 do 2.5.1 pozwala uwierzytelnionym użytkownikom skonfigurować kanały powiadomień webhook lub ntfy z adresami URL kontrolowanymi przez atakującego i wywołać żądania po stronie serwera przez endpoint testowy. Brak listy dozwolonych adresów i blokowania adresów prywatnych umożliwia żądania do wewnętrznych usług HTTP. Problem naprawiono w wersji 2.5.1.

Termix w wersjach od 1.7.0 do 2.5.1 w endpoincie POST /credentials/:id/deploy-to-host pobiera rekordy poświadczeń i hostów na podstawie wartości credentialId i targetHostId bez sprawdzenia, czy należą one do żądającego użytkownika. Błędy różnicowe ujawniają istnienie rekordów oraz wartość authType, a host uwierzytelniany kluczem może otrzymać próbę połączenia SSH z kluczem publicznym atakującego. Problem naprawiono w wersji 2.5.1.

Termix w wersjach od 1.8.0 do 2.5.1 pozwala uwierzytelnionym użytkownikom na dostęp do API statystyk serwera bez autoryzacji per host. Endpointy GET /status, GET /status/:id oraz POST /clear-connections ujawniają stan hostów i pozwalają zwykłemu użytkownikowi wyczyścić globalną pulę połączeń SSH. Problem naprawiono w wersji 2.5.1.

W Termix przed wersją 2.3.2 endpoint POST /host/db/proxy/test akceptuje pola singleProxy, proxyChain i testTarget bez walidacji adresów docelowych. Ścieżka testProxyConnectivity używa surowych połączeń TCP i SOCKS do wybranych przez atakującego hostów i portów, co pozwala uwierzytelnionemu użytkownikowi na skanowanie localhost, sieci prywatnych, usług link-local metadata i innej infrastruktury. Błędy połączenia ujawniają informacje o dostępności hostów, a dostęp do metadanych może ujawnić poświadczenia chmury.

W Termix przed wersją 2.3.2 endpoint POST /database/export tworzy eksport użytkownika, który zawiera globalną tabelę ustawień, mimo że reszta eksportu jest ograniczona do użytkownika. Tabela ustawień zawiera artefakty resetowania hasła (reset_code_ i temp_reset_token_), co pozwala uwierzytelnionemu użytkownikowi o niskich uprawnieniach odzyskać kod resetowania innego konta i ukończyć proces resetowania hasła. Skuteczna eksploitacja prowadzi do przejęcia konta lokalnego użytkownika, a w przypadku administratora do przejęcia administracyjnego.

W Termix przed wersją 2.3.2 endpoint tworzenia archiwum w src/backend/ssh/file-manager.ts przekazuje wybrane nazwy plików do tar bez znacznika końca opcji i bez uczynienia operandów jednoznacznie względnymi. Użytkownik z dostępem do sesji menedżera plików SSH może wybrać nazwy zaczynające się od opcji GNU tar, takich jak --checkpoint=1 i --checkpoint-action=exec, co powoduje interpretację tych nazw jako opcji. Wynikowe działanie checkpoint wykonuje polecenia na zarządzanym hoście SSH z uprawnieniami połączonego konta SSH, umożliwiając ujawnienie plików, modyfikację i zakłócenie usług.

Termix to platforma zarządzania serwerem oparta na sieci, która przed wersją 2.1.0 miała luki w punktach końcowych extractArchive i compressFiles. Użycie podwójnych cudzysłowów do konstrukcji poleceń powłoki umożliwiało wstrzyknięcie poleceń na zdalnym hoście SSH.

Termix to platforma zarządzania serwerem oparta na sieci web, która przed wersją 2.1.0 wydawała tymczasowy token JWT dla kont z włączonym TOTP. Token ten, który powinien być używany tylko w procesie uwierzytelniania dwuskładnikowego, był akceptowany przez middleware autoryzacji na standardowych punktach końcowych, co obniżało bezpieczeństwo do jednego składnika.