Startup dan Bisnis

Kestra dieksploitasi tanpa login—penambang kripto mengikuti reverse shell

|Penulis: Tim Redaksi QUASA|5 mnt baca| 1
Kestra dieksploitasi tanpa login—penambang kripto mengikuti reverse shell

Pada 2 September 2026, pemberitahuan CISA tentang katalog KEV memasukkan CVE-2026-49869 pada Kestra OSS berdasarkan bukti eksploitasi aktif. Penetapan ini berarti celah tersebut telah digunakan dalam serangan nyata, bukan hanya tersedia sebagai proof of concept.

Jawaban untuk administrator jelas: Kestra OSS yang rentan harus segera diperbarui, tetapi pekerjaan tidak selesai setelah patch. Advisory keamanan Kestra menetapkan versi hingga 1.3.20 sebagai terdampak serta 1.0.45 dan 1.3.21 sebagai rilis perbaikan; bypass autentikasi memungkinkan penyerang tanpa kredensial membuat dan menjalankan workflow dengan perintah yang dieksekusi sebagai root di container worker.

Dampak pascaeksploitasinya sudah terlihat dalam satu insiden. Analisis Microsoft atas kompromi Kestra menilai dengan keyakinan tinggi bahwa akses awal kemungkinan memakai CVE-2026-49869, lalu mencatat reverse shell dari workflow, pengintaian container, pemasangan XMRig, penghindaran pertahanan, dan pengumpulan data.

Versi rentan dan rilis perbaikan Kestra

Inventaris deployment Kestra OSS memisahkan versi rentan hingga 1.3.20 dari versi perbaikan 1.0.45 dan 1.3.21.

Matriks versi perlu dibaca berdasarkan jalur rilis, karena 1.0.45 merupakan pengecualian yang sudah diperbaiki di dalam rentang angka yang lebih luas. Administrator tidak cukup memeriksa versi webserver yang tampak dari antarmuka; seluruh worker yang masih dapat menerima pekerjaan juga harus masuk inventaris.

  • Kestra OSS 1.0.x sebelum 1.0.45: terdampak; gunakan 1.0.45 atau rilis terdukung yang lebih baru.
  • Rilis di atas jalur 1.0.45 hingga 1.3.20: termasuk dalam rentang terdampak; naikkan setidaknya ke 1.3.21.
  • Kestra OSS 1.0.45 dan 1.3.21: tercantum sebagai versi yang telah memuat perbaikan.

Cakupan yang dijelaskan adalah Kestra OSS dengan Basic Auth. Instance tidak harus dapat dijangkau langsung dari internet: pihak yang sudah mempunyai akses jaringan ke layanan tetap dapat menyerang endpoint rentan. Pembatasan jaringan mengurangi permukaan serangan, tetapi bukan pengganti pembaruan.

Suffix configs mengubah bypass login menjadi eksekusi workflow

Akar celah berada pada AuthenticationFilter, yang mengenali endpoint konfigurasi publik dengan memeriksa apakah path berakhir pada /configs. Karena yang digunakan adalah pencocokan suffix, bukan path yang tepat, rute API lain dengan segmen terakhir configs ikut melewati pemeriksaan autentikasi.

Penyerang dapat memanfaatkan kondisi tersebut untuk membuat atau menimpa flow bernama configs, kemudian memicu eksekusinya lewat rute lain yang juga berakhir dengan nama itu. Plugin eksekusi skrip yang tersedia pada instalasi membuat workflow berbahaya dapat memanggil shell atau interpreter tanpa kredensial dan tanpa interaksi pengguna.

Eksekusi root yang dimaksud berada di dalam container worker, bukan otomatis pada host. Pengujian yang dijabarkan dalam advisory tidak membuktikan pelarian langsung dari container karena lingkungan uji tidak memasang Docker socket dan tidak memberikan CAP_SYS_ADMIN. Namun, batas dampaknya berubah jika deployment menyediakan volume sensitif, rahasia melalui environment, akses ke jaringan internal, atau socket runtime container.

Perbedaan itu terlihat pada kompromi yang diamati: worker dapat mengakses Docker socket, membaca metadata, dan memeriksa environment container lain. Dengan konfigurasi semacam ini, celah pada aplikasi orkestrasi dapat membuka akses ke kata sandi basis data, token API, kunci cloud, dan alamat layanan internal yang berada di luar workflow awal.

Reverse shell diikuti XMRig dan pengumpulan data

Workflow Kestra yang tidak sah memicu reverse shell, pengintaian container, dan proses penambangan kripto.

Rangkaian yang terdokumentasi dimulai dari aktivitas shell yang berasal dari workflow Kestra. Dua sesi shell muncul dalam jarak waktu berdekatan; aktivitas lanjutan mengakses Docker socket, menginventarisasi lingkungan container, mengambil penambang kripto, dan melakukan operasi berkas untuk mengurangi kemungkinan deteksi.

XMRig diunduh, diekstrak, diganti namanya, lalu dijalankan di latar belakang untuk menambang Monero. Karena nama berkas dan proses dapat diubah, pencarian yang hanya mengandalkan kata “xmrig” tidak cukup; hubungan proses dengan worker, eksekusi dari direktori sementara, koneksi ke pool penambangan, dan konsumsi CPU yang menyimpang memberi konteks yang lebih kuat.

Insiden tersebut juga mencakup pengumpulan data. Konten jarak jauh diteruskan langsung ke shell dengan pola curl-pipe-shell, sedangkan hasilnya dikodekan dan disimpan melalui fasilitas key-value Kestra. Konsekuensinya, tidak ditemukannya proses miner yang masih berjalan tidak membuktikan lingkungan bersih: reverse shell dapat sudah ditutup sementara data, kredensial, atau artefak workflow tetap tertinggal.

Kunci SSH dan cron perlu diperlakukan secara hati-hati. Penambahan kunci SSH dan pembuatan cron dalam laporan yang sama berkaitan dengan workload lain, bukan indikator yang secara khusus diamati pada kasus Kestra. Keduanya layak diperiksa pada host hanya bila akses container, rahasia yang terekspos, atau bukti lokal menunjukkan penyerang mungkin telah melampaui worker.

Patch harus diikuti pemeriksaan kompromi

Respons insiden Kestra mengisolasi worker sambil memeriksa log, resource configs, proses, kunci SSH, dan kredensial yang terpapar.

Patch menutup jalur bypass autentikasi, tetapi tidak menghapus workflow berbahaya, koneksi reverse shell, kredensial yang sempat terbaca, atau muatan yang sudah dijalankan. Pada sistem yang menunjukkan aktivitas mencurigakan, urutan respons perlu menjaga bukti sekaligus menghentikan akses penyerang.

  1. Inventarisasi versi webserver dan seluruh worker. Isolasi node yang dicurigai agar tidak menerima pekerjaan baru atau membuat koneksi keluar.
  2. Pertahankan log API, riwayat eksekusi workflow, isi key-value yang relevan, metadata container, proses, dan telemetri jaringan sebelum container dibangun ulang.
  3. Terapkan rilis perbaikan pada semua komponen dan pastikan node lama tidak kembali masuk ke kelompok worker aktif.
  4. Cari pembuatan, perubahan, penghapusan, atau eksekusi flow bernama configs serta permintaan tidak dikenal menuju rute yang berakhir dengan /configs.
  5. Korelasikan proses bash, sh, curl, wget, Python, nohup, atau miner dengan proses induk worker. Periksa pula akses Docker socket, enumerasi environment container, direktori sementara, dan koneksi ke infrastruktur penambangan.
  6. Tentukan rahasia apa yang dapat dibaca dari worker atau container lain. Setelah jalur masuk ditutup, rotasi token, kata sandi, kunci cloud, dan kunci SSH yang berpotensi terpapar; bangun ulang node yang terbukti dikompromikan.

Hingga kini, status eksploitasi aktif CVE-2026-49869 dan ketersediaan patch telah terkonfirmasi. Satu rangkaian serangan yang dianalisis bergerak dari reverse shell menuju pengintaian container, XMRig, dan pengumpulan data, tetapi belum ada bukti publik bahwa semua korban menerima muatan yang sama atau seluruh aktivitas berasal dari satu pelaku. Versi menentukan kebutuhan patch; log dan telemetri lokal menentukan apakah respons harus berkembang menjadi investigasi insiden penuh.

Baca juga:

Bagikan:

Berlangganan buletin kami

Dapatkan berita Web3, AI, dan kripto terbaru langsung di kotak masuk Anda.

0