Strona główna / Blog / IXON VPN: trwały root przez config

Blog · case study

IXON VPN Client: jedna zmiana konfiguracji, trwały root/SYSTEM i brak widocznej awarii. Kiedy „persistent but still working” jest najgorszym rodzajem exploita

CVE-2026-75925 w IXON VPN Client (przed wersją 1.4.7) jest interesujące nie tylko dlatego, że kończy się jako root lub SYSTEM — ale dlatego, jak mało sygnałów widzi użytkownik po udanym ataku. Wartości konfiguracyjne przyjmowane przez lokalny service są zapisywane do pliku konsumowanego później przez uprzywilejowany subprocess, a CRLF nie jest neutralizowane — atakujący może wstrzyknąć dodatkowe directives.

CVE-2026-75925 (CVSS v4 9.4): CRLF injection do pliku konfiguracyjnego → nowy directive → command execution jako root/SYSTEM.
Wzmocnienie: interfejs konfiguracyjny akceptuje zmiany bez właściwego uwierzytelnienia / weryfikacji origin.
Affected: IXON VPN Client < 1.4.7.
untrusted configuration value → privileged local service accepts it → writes config file → line break creates new directive → privileged subprocess consumes file → command execution as root/SYSTEM

Lokalny „helper” staje się privilege boundary

Jeżeli service działa lokalnie z wysokimi uprawnieniami, przyjmuje configuration changes i nie weryfikuje caller'a, to staje się granicą uprawnień. Chain nie potrzebuje admin rights — wystarczy nieuprzywilejowany lokalny caller, a wynikiem jest root/SYSTEM. To wyraźne przejście: local configuration plane → OS privilege plane.

Persistence + brak awarii = niska widoczność

Wstrzyknięta konfiguracja zostaje na dysku i przeżywa restart klienta oraz systemu. To nie jest jednorazowy command injection — to trwała zmiana stanu. A VPN nadal działa normalnie:

compromise + no obvious service failure = low visibility

Wiele zespołów wykrywa problemy przez crash, outage czy skargi użytkowników. Tutaj po ataku użytkownik dalej uruchamia klienta i zestawia VPN. „Program działa” nie znaczy „jest bezpieczny” — silent persistence to dodatkowy czynnik ryzyka.

Config file jako security boundary; CRLF to nie „tylko web bug”

Security teams skupiają się na shell, SQL i templates, ale plik konfiguracyjny bywa równoważny kodowi, jeśli downstream process interpretuje directives (SSH config, systemd units, OpenVPN config, proxy config). CWE-93 kojarzy się z HTTP response splitting i log injection — tu ten sam primitive staje się privileged configuration directive injection. Etykieta CWE nie opisuje pełnego impactu: primitive to CRLF, a efektywny skutek to persistent root/SYSTEM.

Remediation verification — nie kończ na numerze wersji

VPN client to krytyczny asset (dostęp do network configuration, tuneli, tras, zaufanie użytkownika; w OT/industrial remote access szczególnie wrażliwy). Dobre verification sprawdza nie tylko version = 1.4.7, ale też: kontrolę origin/auth konfiguracji, odrzucanie CRLF oraz brak złośliwych directives w istniejącym pliku. Przy mocnym podejrzeniu kompromitacji — rebuild, bo persistent config przeżywa restart.

Wniosek

CVE-2026-75925 pokazuje, dlaczego VM powinien rozróżniać patch complete od compromise remediated. Najgorszy exploit nie zawsze powoduje awarię — czasem najbardziej niebezpieczny jest ten, który zdobywa roota, przeżywa reboot i zostawia normalnie działającą funkcjonalność.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 6 września 2026. CVE-2026-75925 (IXON VPN Client < 1.4.7, CVSS v4 9.4): CRLF injection do pliku konfiguracyjnego konsumowanego przez uprzywilejowany subprocess daje command execution jako root/SYSTEM; interfejs konfiguracyjny bez uwierzytelnienia. Artykuł nie zakłada automatycznego lateral movement do OT — opisuje privilege transition i persistence w konfiguracji.

Zapamiętaj jedno

Jeżeli podatność pozwala zapisać trwałą konfigurację wykorzystywaną przez privileged subprocess, upgrade usuwa wejście — ale nie musi usuwać skutku wcześniejszej eksploatacji. System VM powinien rozróżniać „patch complete” od „compromise remediated”.