Trzy luki zero-day w Ivanti Connect Secure umożliwiają przejęcie urządzenia z uprawnieniami root - Security Bez Tabu

Trzy luki zero-day w Ivanti Connect Secure umożliwiają przejęcie urządzenia z uprawnieniami root

Cybersecurity news

Wprowadzenie do problemu / definicja

Ivanti Connect Secure to szeroko stosowane rozwiązanie VPN i zdalnego dostępu, często pełniące rolę krytycznego punktu wejścia do sieci organizacji. Ujawniona kampania pokazała, że połączenie trzech luk zero-day może doprowadzić do pełnego przejęcia urządzenia bez konieczności wcześniejszego uwierzytelnienia.

Skala zagrożenia jest szczególnie duża, ponieważ podatności dotyczą urządzenia brzegowego wystawionego na kontakt z Internetem. W praktyce oznacza to, że skuteczny atak może otworzyć drogę nie tylko do samego appliance, ale także do dalszej penetracji środowiska firmowego.

W skrócie

Napastnik wykorzystał sekwencję trzech podatności w Ivanti Connect Secure, aby przejść od obejścia uwierzytelnienia do zdalnego wykonania kodu, a następnie do eskalacji uprawnień do poziomu root. Dwa elementy łańcucha zostały objęte poprawkami producenta, natomiast dla trzeciej luki poprawka pozostawała w przygotowaniu.

Analiza incydentu wykazała również użycie technik utrudniających wykrycie. Modyfikacje realizowane wyłącznie w pamięci oraz przywracanie konfiguracji po wykonaniu działań ograniczały liczbę trwałych artefaktów, co znacząco utrudniało standardową analizę powłamaniową.

Kontekst / historia

Aktywność napastnika została opisana po analizie kompromitacji urządzenia jednego z klientów. Według ustaleń badaczy działania rozpoczęły się 3 października 2026 r., a aktywność przypisano klastrowi oznaczonemu jako UTA0576. Choć skala kampanii miała być ograniczona, eksploatacja była prowadzona aktywnie w środowisku produkcyjnym.

Łańcuch ataku obejmował dwie pierwsze luki powiązane z identyfikatorem CVE-2026-104935. Umożliwiały one obejście uwierzytelnienia i zdalne wykonanie kodu w kontekście użytkownika procesu cgi-server. Trzecia podatność pozwalała następnie podnieść uprawnienia do root, co finalnie dawało pełną kontrolę nad urządzeniem.

Istotne jest również to, że atakowane urządzenie miało być wcześniej w pełni załatane w ramach używanej wersji. To podkreśla, że nawet organizacje utrzymujące podstawową higienę aktualizacji mogły pozostać narażone na zagrożenie wynikające z nieznanych wcześniej luk.

Analiza techniczna

Technicznie był to klasyczny przykład chainingu podatności w urządzeniu brzegowym. W pierwszym etapie napastnik omijał mechanizm logowania, dzięki czemu nie potrzebował ważnych poświadczeń. Następnie uzyskiwał możliwość zdalnego wykonania kodu, ale początkowo jedynie z ograniczonymi uprawnieniami procesu usługowego.

Kluczowe znaczenie miał trzeci etap, czyli eskalacja uprawnień do konta root. Dopiero ten krok umożliwiał pełne wykonywanie poleceń systemowych, manipulację konfiguracją oraz dostęp do wrażliwych danych przechowywanych lub przetwarzanych przez appliance. W przypadku koncentratora VPN oznacza to ryzyko przejęcia informacji o sesjach, poświadczeniach i połączeniach do zasobów wewnętrznych.

Badacze zwrócili uwagę, że sprawca ograniczał obecność trwałych śladów na dysku. Zmiany w bibliotekach miały być wprowadzane wyłącznie w pamięci, a konfiguracja była przywracana po zakończeniu działań. Taki model działania utrudnia wykrycie przez narzędzia bazujące na integralności plików oraz przez rutynowe przeglądy systemu.

Wśród zaobserwowanych wskaźników kompromitacji wskazano nietypowo dużą liczbę żądań kierowanych do ścieżki /dana-na/auth/url_default/welcome.cgi, obecność nagłówka X-DSCGI-PATH o wartości niespójnej z adresem URL oraz katalog /data/.icscap/. W analizowanym przypadku odnotowano także wykorzystanie określonego adresu IP przez operatora ataku.

Po uzyskaniu dostępu sprawca wykradał zapisane poświadczenia, w tym dane LDAP, przeszukiwał Active Directory pod kątem haseł oraz prowadził password spraying wobec kont w środowisku. Co ważne, nie stwierdzono pozostawienia trwałego web shella ani klasycznego backdoora. Zamiast tego napastnik miał ponownie wykonywać cały łańcuch eksploatacji dla kolejnych poleceń, co dodatkowo ograniczało widoczność incydentu.

Konsekwencje / ryzyko

Ryzyko związane z tym przypadkiem należy ocenić jako bardzo wysokie. Po pierwsze, mowa o aktywnie wykorzystywanych lukach zero-day w systemie wystawionym na styku z Internetem. Po drugie, skuteczny atak prowadzi do uzyskania uprawnień root bez logowania, a więc do pełnej kompromitacji urządzenia.

Konsekwencje nie ograniczają się jednak do samego appliance. Przejęcie platformy dostępowej może umożliwić ruch boczny do usług katalogowych, kont uprzywilejowanych i kluczowych zasobów wewnętrznych. Kradzież poświadczeń oraz działania przeciwko Active Directory oznaczają, że organizacja może pozostać zagrożona nawet po wdrożeniu poprawek.

Dodatkowym problemem jest ograniczona widoczność ataku. Operacje wykonywane w pamięci i przywracanie stanu konfiguracji powodują, że brak jednoznacznych śladów na dysku nie może być traktowany jako dowód braku kompromitacji. W praktyce wymaga to głębszej analizy logów, pamięci i tożsamości niż w typowym procesie patch management.

Rekomendacje

Organizacje korzystające z Ivanti Connect Secure powinny potraktować sprawę priorytetowo i natychmiast zweryfikować używaną wersję oprogramowania. Jeżeli środowisko działa na wersji podatnej, należy wdrożyć zalecane poprawki i równolegle rozpocząć działania w trybie incident response.

Równie ważna jest ocena potencjalnej kompromitacji. Sama aktualizacja nie zamyka ryzyka, jeśli napastnik zdążył pozyskać poświadczenia, tokeny sesyjne lub informacje umożliwiające dalszy dostęp do infrastruktury.

  • niezwłocznie zaktualizować urządzenia do wersji zalecanej przez producenta,
  • przeanalizować logi HTTP, ruch sieciowy i aktywność uwierzytelniającą pod kątem anomalii,
  • zweryfikować wskazane wskaźniki kompromitacji oraz nietypowe nagłówki i ścieżki żądań,
  • przeprowadzić rotację poświadczeń przechowywanych lub używanych przez appliance,
  • zresetować hasła kont uprzywilejowanych, usługowych, LDAP i AD,
  • sprawdzić środowisko pod kątem password sprayingu i wtórnego dostępu,
  • izolować podejrzane urządzenia do czasu zakończenia analizy śledczej,
  • rozszerzyć dochodzenie na kontrolery domeny, systemy IAM oraz krytyczne segmenty sieci.

Podsumowanie

Przypadek Ivanti Connect Secure pokazuje, jak niebezpieczne są łańcuchy exploitów wymierzone w urządzenia brzegowe. Połączenie obejścia uwierzytelnienia, zdalnego wykonania kodu i eskalacji uprawnień do root daje napastnikowi niemal pełną kontrolę nad jednym z najważniejszych elementów infrastruktury dostępowej.

Najważniejszy wniosek dla obrońców jest jasny: szybkie wdrożenie poprawek to dopiero pierwszy krok. Równie istotne są analiza możliwej kompromitacji, ocena wpływu na poświadczenia oraz weryfikacja, czy atak nie doprowadził już do głębszego naruszenia środowiska, zwłaszcza w obszarze Active Directory.

Źródła

  1. https://thehackernews.com/2026/10/attacker-chains-three-ivanti-connect.html
  2. https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-Authentication-Bypass-and-Remote-Code-Execution
  3. https://www.volexity.com/blog/2026/10/13/ivanti-connect-secure-zero-day-exploitation/
  4. https://www.cve.org/CVERecord?id=CVE-2026-104935
  5. https://help.ivanti.com/ps/help/en_US/ICS/25.1R3/ag-ics-installation/Installing_a_Software_Package_on_the_Device.htm