Przejdź do treści

Szukaj w Security Magazine

Szukaj w Security Magazine

NewsletterNewsletter
Menu

Ivanti Connect Secure: łańcuch trzech zero-dayów daje roota na w pełni załatanej bramie VPN

Nieznany aktor połączył trzy podatności zero-day w Ivanti Connect Secure i przejął w pełni załataną bramę VPN z uprawnieniami roota. Atak nie zostawił na dysku żadnego malware ani web shella, a narzędzie do sprawdzania integralności, które Ivanti każe stosować klientom, zostało celowo oślepione. Dla organizacji polegających na tym produkcie oznacza to, że status „aktualny firmware” przestał być dowodem bezpieczeństwa.

cve104935
W tym tekście (6)

Analiza zagrożenia: jak łańcuch zero-dayów przejmuje Ivanti Connect Secure

Firma Volexity śledzi atakującego pod oznaczeniem UTA0576. Celem był system Ivanti Connect Secure w wersji 22.8R2.4 - w chwili ataku najnowszej dostępnej. Trzy luki połączone w jeden łańcuch pozwalały wykonywać polecenia jako root bez uwierzytelnienia.

Łańcuch składał się z:

  • obejścia uwierzytelnienia - pozwalało dostać się do funkcji urządzenia bez logowania,
  • zdalnego wykonania kodu (RCE) - śledzonego pod identyfikatorem CVE-2026-104935,
  • eskalacji uprawnień - przejścia z ograniczonego kontekstu do roota.

Ivanti wydało poprawki dla dwóch pierwszych podatności. Łatka na eskalację uprawnień ma pojawić się dopiero za kilka tygodni, co oznacza, że część łańcucha pozostaje otwarta nawet po aktualizacji.

Dlaczego „załatane” nie znaczy „bezpieczne”

Najistotniejszą cechą tego ataku nie jest sam łańcuch, lecz sposób jego użycia. Według Volexity eksploatacja trwała od 3 października, a atakujący:

  • nie wgrał malware ani web shella - na dysku nie powstały żadne trwałe artefakty,
  • odpalał cały łańcuch od nowa przy każdym poleceniu, zamiast zostawiać sobie stały punkt dostępu,
  • modyfikował kod Ivanti wyłącznie w pamięci, więc pliki na dysku pozostawały nienaruszone,
  • czyścił logi na urządzeniu.

Taki model działania bezpośrednio uderza w Integrity Checker Tool (ICT) - narzędzie, którym Ivanti każe klientom weryfikować stan urządzenia. ICT porównuje zawartość dysku z wzorcem. Skoro na dysku nic się nie zmieniło, skan wraca czysty, mimo że urządzenie było kontrolowane przez atakującego. Każdy, kto traktuje pozytywny wynik ICT jako dowód braku kompromitacji, buduje ocenę ryzyka na fałszywej przesłance.

Jak realnie potwierdzić kompromitację

Brak artefaktów na dysku przesuwa ciężar wykrywania poza samo urządzenie. Potwierdzenie ataku wymaga analizy śledczej, w szczególności:

  1. forensyki pamięci - jedynego miejsca, w którym ślady modyfikacji kodu Ivanti w ogóle istniały,
  2. forensyki sieciowej - analizy ruchu do i z bramy VPN, ponieważ każde polecenie atakującego oznaczało ponowne odpalenie łańcucha,
  3. korelacji logów poza urządzeniem - logi lokalne zostały wyczyszczone, więc wiarygodne są wyłącznie kopie przesłane wcześniej do SIEM.

Ani raport Volexity, ani komunikat Ivanti nie podają tymczasowego obejścia dla klientów, którzy nie mogą od razu zaktualizować urządzeń. Organizacje w takiej sytuacji nie mają dziś żadnego wspieranego przez producenta sposobu na zamknięcie luki poza odcięciem dostępu.

Wpływ na biznes

Skala ekspozycji jest znacząca. Shadowserver liczy ponad 5500 urządzeń Connect Secure dostępnych z internetu, choć nie wiadomo, ile z nich to honeypoty lub systemy już zabezpieczone. CISA dodała CVE-2026-104935 do katalogu Known Exploited Vulnerabilities 13 października, wyznaczając agencjom federalnym termin na reakcję do 16 października - trzy dni. Taki termin sygnalizuje ocenę ryzyka jako pilnego.

Konsekwencje operacyjne i finansowe dla organizacji:

  • Brama VPN to punkt koncentracji ruchu - jej przejęcie daje wgląd w poświadczenia i sesje wszystkich użytkowników zdalnych, nie tylko administratorów urządzenia.
  • Koszt weryfikacji rośnie - zamiast uruchomić skaner producenta, trzeba przeprowadzić analizę pamięci i ruchu sieciowego, często z udziałem zewnętrznego zespołu IR.
  • Niepełna łatka wydłuża okno ryzyka - do czasu publikacji poprawki na eskalację uprawnień zarządzanie incydentem nie może zostać formalnie zamknięte.
  • Historia produktu obciąża decyzję - Connect Secure był celem zero-dayów w 2024, 2025 i 2026 roku. To już nie incydent, lecz wzorzec, który powinien trafić na agendę rozmowy o ryzyku koncentracji na jednym dostawcy bram dostępu zdalnego.

Rekomendacje

Kroki techniczne wynikające bezpośrednio z advisory i raportu Volexity:

  1. Aktualizacja do wersji wskazanych w advisory Ivanti - zamyka obejście uwierzytelnienia i RCE; należy przy tym odnotować, że eskalacja uprawnień pozostaje niezałatana.
  2. Odcięcie panelu zarządzania od internetu - ograniczenie dostępu do interfejsu administracyjnego do sieci wewnętrznej lub dedykowanego kanału.
  3. Przegląd logów po stronie SIEM, nie na urządzeniu - lokalne logi zostały wyczyszczone przez atakującego; wartość dowodową mają wyłącznie kopie przesłane wcześniej na zewnątrz.
  4. Rotacja poświadczeń przechodzących przez VPN - haseł, certyfikatów i tokenów użytkowników oraz kont serwisowych, których sesje mogły przejść przez przejętą bramę.
  5. Analiza pamięci i ruchu sieciowego w przypadku podejrzenia kompromitacji - pozytywny wynik ICT nie wyklucza ataku.

Podsumowanie

Atak UTA0576 na Ivanti Connect Secure pokazuje granice dwóch założeń, na których opiera się rutynowa obrona: że aktualny firmware chroni przed znanymi atakami i że narzędzie producenta wykryje kompromitację. Łańcuch trzech zero-dayów obalił pierwsze, a technika działania wyłącznie w pamięci - drugie. Dopóki trzecia poprawka nie zostanie wydana, odpowiedzialność za zamknięcie ryzyka spoczywa na administratorach: przez ograniczenie ekspozycji, weryfikację poza urządzeniem i rotację poświadczeń.

Źródła: