Rantai Zero-Day Ivanti Connect Secure: Root Tanpa Login, Tambal ke Build Ini

Oleh , Tim Engineering APIPedia · Terbit · 7 menit baca

Tiga celah Ivanti Connect Secure dirantai untuk akses root tanpa login dan sudah masuk CISA KEV. Ini versi aman, cara cek, dan deteksinya.

Sampul APIPedia: rantai zero-day Ivanti VPN, kartu fakta 3 CVE berantai, CVSS tertinggi 8.6, hasil root tanpa login, build aman 25.1.1.3, 25.1.3.1, 22.8R2.6

Ivanti Connect Secure sedang diserang lewat rantai tiga celah (CVE-2026-104935, CVE-2026-118527, CVE-2026-111357) yang memungkinkan penyerang menjalankan perintah sebagai root tanpa login. Ketiganya sudah masuk katalog CISA KEV, dan tenggat tambal untuk instansi federal AS jatuh kemarin, 2 November 2026. Kalau kantor Anda memakai VPN Ivanti, ini prioritas hari ini.

Apa yang sebenarnya terjadi?

Pada 13 Oktober 2026 Ivanti merilis advisory untuk CVE-2026-104935, sebuah celah authentication bypass by spoofing (CWE-290) dengan skor CVSS v3 8.6. Hari yang sama, CISA memasukkannya ke katalog Known Exploited Vulnerabilities (KEV) dan Volexity menerbitkan laporan serangan yang mereka temukan sejak awal Oktober.

Masalahnya, celah pertama itu hanya pintu masuk. Volexity melihat penyerang, yang mereka beri label UTA0576, menggabungkan tiga celah sekaligus untuk mendapatkan akses root di perangkat yang saat itu dianggap sudah ditambal (versi 22.8R2.4). Dua celah sisanya baru mendapat pembaruan darurat dari Ivanti pada 29 Oktober, lalu CISA menambahkan CVE-2026-111357 dan CVE-2026-118527 ke KEV pada 30 Oktober dengan tenggat 2 November.

Ivanti Connect Secure (dulu Pulse Secure) banyak dipakai sebagai gerbang VPN di instansi pemerintah, BUMN, bank, dan perusahaan besar, termasuk di Indonesia. Menurut data pemindaian yang dikutip SecurityOnline, ada lebih dari 10.000 perangkat yang terlihat di internet publik. ITdaily mencatat angka yang lebih konservatif, minimal 5.500 instans.

Bagaimana rantai serangannya bekerja?

Diagram alur rantai serangan Ivanti Connect Secure: 1) bypass autentikasi CVE-2026-104935 CVSS 8.6, 2) eksekusi perintah sebagai user cgi-server dengan CVE-2026-118527 CVSS 4.3, 3) eskalasi ke root lewat broker dsinvoked CVE-2026-111357 CVSS 7.0, 4) dampak pencurian kredensial LDAP dan password spraying

Urutannya kira-kira seperti ini:

  1. Masuk tanpa akun. CVE-2026-104935 memungkinkan penyerang memalsukan data yang dipakai sistem untuk memverifikasi identitas. Hasilnya, perintah bisa dijalankan dari jarak jauh tanpa autentikasi, dengan hak user cgi-server.
  2. Menaruh file di lokasi yang bisa ditebak. CVE-2026-118527 (CVSS 4.3) adalah masalah nama file yang mudah diprediksi, sehingga file berbahaya bisa diletakkan di lokasi yang diketahui.
  3. Naik ke root. CVE-2026-111357 (CWE-829) muncul karena broker dsinvoked terlalu percaya pada data konfigurasi DSCache. Penyerang lokal bisa memakainya untuk naik ke root.

Setelah menjadi root, menurut laporan Volexity yang dirangkum The Hacker News, penyerang mencuri kredensial yang tersimpan di perangkat, termasuk kredensial domain LDAP, menelusuri Active Directory untuk mencari kata sandi, lalu melakukan password spraying ke jaringan internal.

Yang membuat kasus ini licin: eksploit hanya mengubah kode pustaka di memori, lalu mengembalikan konfigurasi yang diubah ke kondisi semula. Tidak ada webshell atau backdoor yang ditinggalkan. Penyerang bahkan menjalankan ulang seluruh rantai untuk setiap perintah.

Ringkasan tiga CVE

CVEJenisCVSSMasuk KEVPeran dalam rantai
CVE-2026-104935Authentication bypass by spoofing (CWE-290)8.613 Okt 2026Akses awal tanpa login, eksekusi perintah
CVE-2026-118527Nama file mudah ditebak4.330 Okt 2026Menaruh file di lokasi yang diketahui
CVE-2026-111357Inclusion of functionality from untrusted control sphere (CWE-829)7.0 (NVD/CNA)30 Okt 2026Eskalasi hak akses ke root

Catatan: SecurityOnline menulis skor CVE-2026-111357 sebagai 8.8 di badan artikel, tetapi 7.0 di tabelnya. Record CVE di OpenCVE/NVD memakai 7.0 dengan vektor lokal (AV:L/AC:H/PR:L). Skor satuan tidak terlalu penting di sini, karena yang berbahaya adalah gabungannya: dari tanpa akses menjadi root.

Siapa yang terdampak dan versi mana yang aman?

Yang terdampak adalah Ivanti Connect Secure (ICS). Rinciannya agak berbelit karena tambalan keluar dalam dua gelombang:

  • CVE-2026-104935 memengaruhi 25.1.1.1 dan sebelumnya, 25.1.2.2 dan sebelumnya, serta 22.8R2.4 dan sebelumnya. Perbaikan gelombang pertama ada di 25.1.1.2, 25.1.3.0/25.1.3.1, dan 22.8R2.5.
  • CVE-2026-111357 dan CVE-2026-118527 menurut SecurityOnline memengaruhi 25.1.1.2 dan sebelumnya, serta 22.8R2.5 dan sebelumnya. Artinya build gelombang pertama belum cukup.
  • Versi aman untuk seluruh rantai, berdasarkan pembaruan advisory Canadian Centre for Cyber Security (AV26-1035, update 30 Oktober): 25.1.1.3, 25.1.3.1, atau 22.8R2.6.
  • Seri 22.7.x ke bawah disebut tidak terdampak CVE-2026-104935. Tapi 22.7 dan 22.8 akan habis masa dukungan pada 31 Januari 2027, jadi rencanakan migrasi ke 25.1.

Sumber-sumber tidak sepenuhnya sepakat soal daftar build tetap (SecurityOnline sendiri menampilkan tiga daftar berbeda). Sebelum rollout, cocokkan nomor build dengan advisory resmi Ivanti di portal Ivanti Hub.

Kapan semuanya terjadi?

Kronologi zero-day Ivanti Connect Secure: 3 Oktober 2026 serangan dimulai, 13 Oktober advisory Ivanti dan masuk KEV, 15 Oktober CVE-2026-111357 terbit, 29 Oktober update darurat Ivanti, 30 Oktober dua CVE tambahan masuk KEV, 2 November tenggat CISA

Perhatikan jaraknya: sekitar 10 hari antara serangan pertama dan advisory, lalu lebih dari dua minggu sampai rantai lengkap tertambal. Selama jeda itu, perangkat yang "sudah update" masih bisa dibobol sampai root.

Bagaimana cara mengecek apakah perangkat saya rentan?

ICS adalah appliance, jadi tidak ada shell biasa untuk menjalankan perintah. Cara paling pasti:

  1. Masuk ke konsol admin, lihat versi di Maintenance → Platform atau di header halaman admin.
  2. Bandingkan dengan tabel di atas. Kalau di bawah 25.1.1.3, 25.1.3.1, atau 22.8R2.6, anggap rentan.
  3. Kalau perangkat pernah berjalan di versi rentan sejak awal Oktober, anggap mungkin sudah disusupi dan lanjutkan ke bagian deteksi.

Bagaimana mendeteksi tanda serangan?

Ivanti sendiri menyatakan indikator kompromi yang andal belum tersedia. Volexity mempublikasikan beberapa indikator, dan inilah yang bisa Anda buru di log yang diteruskan ke syslog/SIEM:

  • Permintaan dalam jumlah besar ke /dana-na/auth/url_default/welcome.cgi.
  • Header HTTP X-DSCGI-PATH yang nilainya tidak cocok dengan path URL.
  • Direktori /data/.icscap/ (terlihat lewat forensik).
  • Alamat IP 108.165.147[.]64.

Contoh pencarian di log yang sudah diekspor ke server Linux:

# Hitung permintaan ke welcome.cgi per alamat IP (ganti path log sesuai SIEM/syslog Anda)
grep -h "/dana-na/auth/url_default/welcome.cgi" /var/log/ivanti/*.log \
  | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -rn | head -20

# Cari IP penyerang yang dilaporkan Volexity
grep -rn "108.165.147.64" /var/log/ivanti/ /var/log/nginx/ 2>/dev/null

# Bila ada reverse proxy/WAF yang mencatat header, cari header mencurigakan
grep -rni "x-dscgi-path" /var/log/ 2>/dev/null | head

Untuk IDS, aturan Suricata sederhana ini menandai header yang tidak lazim datang dari luar. Sesuaikan $HOME_NET dan sid dengan lingkungan Anda:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Kemungkinan eksploitasi Ivanti ICS - header X-DSCGI-PATH"; flow:to_server,established; http.header_names; content:"X-DSCGI-PATH"; nocase; classtype:attempted-admin; sid:9100001; rev:1;)

Karena penyerang mencuri kredensial LDAP lalu melakukan password spraying, periksa juga domain controller. Banyak login gagal (Event ID 4625 atau 4771) dari alamat IP appliance VPN adalah sinyal merah:

# Jalankan di domain controller: login gagal 7 hari terakhir, dikelompokkan per IP sumber
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625,4771; StartTime=(Get-Date).AddDays(-7)} |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'IpAddress' } |
  Group-Object '#text' | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

Satu peringatan penting dari Volexity: hasil bersih dari Integrity Checker Tool (ICT) bukan bukti perangkat aman, karena modifikasi terjadi di memori. Konfirmasi kompromi butuh forensik jaringan dan memori.

Apa langkah mitigasinya?

  1. Tambal sekarang ke 25.1.1.3, 25.1.3.1, atau 22.8R2.6, di luar jadwal patch rutin.
  2. Buru indikator di atas mundur sampai minimal awal Oktober 2026.
  3. Rotasi kredensial yang tersimpan di appliance: akun bind LDAP/AD, akun admin lokal, dan sertifikat bila ada indikasi kompromi.
  4. Batasi antarmuka admin agar hanya bisa diakses dari jaringan manajemen, bukan internet.
  5. Bila ada tanda kompromi, isolasi perangkat dan ikuti langkah pemulihan Ivanti (reset pabrik lalu pasang build bersih), bukan sekadar upgrade di atas sistem yang sudah dibobol.
  6. Pantau AD untuk password spraying dan login tidak wajar dari akun layanan.

Pola "celah perangkat tepi lalu curi kredensial" ini juga muncul di kasus lain bulan ini, seperti RCE GitLab CVE-2026-97229 dan PHP2Shell. Kalau tim Anda mengelola server Linux, cek juga celah TCP kernel Linux CVE-2026-98432.

FAQ

Apakah 22.8R2.5 sudah aman?

Belum untuk seluruh rantai. 22.8R2.5 menutup CVE-2026-104935, tetapi CVE-2026-111357 dan CVE-2026-118527 masih memengaruhi 22.8R2.5 ke bawah. Naik ke 22.8R2.6.

Saya sudah menjalankan Integrity Checker Tool dan hasilnya bersih. Cukup?

Tidak. Volexity melaporkan ICT tidak menangkap rantai ini karena eksploit bekerja di memori dan memulihkan konfigurasi. Gabungkan dengan analisis log, forensik jaringan, dan memori.

Tenggat CISA hanya untuk lembaga AS. Apa relevansinya untuk Indonesia?

Tenggat itu memang mengikat instansi federal AS, tetapi status KEV berarti eksploitasi sudah terkonfirmasi. Penyerang tidak memilih negara; perangkat Ivanti yang terbuka ke internet di Indonesia sama rentannya.

Apakah ada solusi sementara kalau belum bisa upgrade?

Sumber yang kami baca tidak menyebut workaround resmi. Langkah terbaik sementara adalah membatasi akses ke portal VPN (misalnya hanya dari rentang IP tertentu), memperketat pemantauan, dan menjadwalkan upgrade secepat mungkin.

Siapa pelakunya?

Volexity melacaknya sebagai UTA0576 dan menilai, dengan keyakinan rendah, motifnya kriminal alih-alih spionase. Ivanti menyebut eksploitasi terbatas pada sejumlah kecil pelanggan.

Sumber

Topik:

Tentang penulis

Tim APIPedia — Tim Engineering APIPedia

Tim engineering di balik APIPedia yang membangun dan memelihara API data Indonesia - ongkir, OCR KTP, data wilayah, BMKG, hingga server MCP - dan menulis panduan integrasinya dari pengalaman langsung.