1 poin oleh GN⁺ 2025-12-19 | Belum ada komentar. | Bagikan ke WhatsApp
  • Setelah ditemukan penggunaan CPU yang tidak normal pada server Hetzner yang dikelola secara pribadi, hasil investigasi menunjukkan bahwa program penambang mata uang kripto Monero (xmrig) sedang berjalan
  • Penyebabnya adalah kontainer alat analitik Umami yang diserang, yang mencakup kerentanan eksekusi kode jarak jauh di Next.js (CVE-2025-66478)
  • Untungnya, kontainer tersebut berjalan dengan pengguna non-root dan tanpa host mount maupun eskalasi hak akses, sehingga intrusi terbatas di dalam kontainer
  • Penyerang mengeksploitasi deserialisasi tidak aman pada server component Next.js untuk menjalankan payload berbahaya dan memasang miner
  • Kasus ini menunjukkan pentingnya manajemen dependensi dan pengaturan keamanan kontainer, dan penulis kemudian memperkuat langkah keamanan seperti mengaktifkan firewall, memperkeras SSH, serta melakukan pembaruan rutin

Peretasan terjadi dan respons awal

  • Menerima email peringatan dari Hetzner bahwa server memindai jaringan eksternal
    • Termasuk pemberitahuan bahwa server bisa diblokir jika tidak ditangani dalam 4 jam
  • Setelah memeriksa lewat SSH, ditemukan proses dengan penggunaan CPU 819% di path /tmp/.XIN-unix/javae serta beberapa proses xmrig
  • Dikonfirmasi bahwa penambangan mata uang kripto telah berlangsung sekitar 10 hari

Investigasi jalur intrusi

  • Semua proses berbahaya berjalan sebagai pengguna UID 1001, yang sesuai dengan kontainer Umami
  • Ditemukan file eksekusi miner di direktori /app/node_modules/next/dist/server/lib/xmrig-6.24.0/
  • Perintah eksekusi mencakup alamat pool mining auto.c3pool.org:443 dan kunci pengguna

Kerentanan Next.js dan metode serangan

  • Penyebabnya adalah kerentanan deserialisasi React Server Components di Next.js (CVE-2025-66478)
    • Jika penyerang mengirim permintaan HTTP yang dimanipulasi, kode arbitrer dapat dijalankan di server
    • Akibatnya, miner mata uang kripto bisa dipasang dan dijalankan
  • Penulis sempat mengira “saya tidak memakai Next.js secara langsung”, tetapi belakangan sadar bahwa Umami berbasis Next.js

Verifikasi isolasi kontainer

  • Dikonfirmasi bahwa /tmp/.XIN-unix/javae tidak ada di filesystem host
    • Ini hanya efek tampilan proses kontainer pada output ps Docker, dan secara nyata isolasinya tetap terjaga
  • Hasil docker inspect
    • Pengguna: nextjs
    • Privileged: false
    • Mounts: tidak ada
  • Karena itu, malware tidak dapat mengakses host, mendaftarkan cron, membuat service sistem, atau memasang rootkit

Pemulihan dan penguatan keamanan

  • Menghentikan dan menghapus kontainer Umami yang terinfeksi, lalu penggunaan CPU kembali normal
  • Mengaktifkan firewall UFW sehingga hanya SSH, HTTP, dan HTTPS yang diizinkan
  • Setelah melaporkan hasil investigasi ke Hetzner, tiket ditutup dalam waktu 1 jam

Pelajaran dan perbaikan

  • Pernyataan “saya tidak memakai X” tidak otomatis mencakup dependensi
    • Perlu memeriksa stack teknologi yang membentuk alat yang digunakan
  • Efektivitas isolasi kontainer terbukti
    • Pengguna non-root, mode non-privileged, dan tidak memakai volume yang tidak perlu membantu mencegah meluasnya dampak
  • Perlunya defense in depth dalam keamanan
    • Firewall, fail2ban, monitoring, dan pembaruan rutin adalah hal wajib
  • Ditekankan pentingnya menulis Dockerfile sendiri dan meminimalkan hak akses kontainer

Tindakan setelah insiden

  • Men-deploy ulang Umami ke versi terbaru dan mengaudit semua kontainer pihak ketiga
    • Memeriksa pengguna yang menjalankan, mount, waktu pembaruan, dan kebutuhannya
  • Beralih ke autentikasi berbasis kunci SSH, menonaktifkan login dengan kata sandi, dan mengatur fail2ban
  • Memperkuat monitoring dengan Grafana dan Node Exporter, serta menerapkan pembaruan keamanan segera

Kesimpulan

  • Kerentanan Next.js di Umami menyebabkan sistem disalahgunakan untuk menambang Monero selama 10 hari, tetapi
    berkat isolasi kontainer dan konfigurasi non-root, dampaknya tetap terbatas
  • Dari pengalaman ini, penulis memahami pentingnya memetakan dependensi, pengaturan keamanan, dan manajemen pembaruan
  • Insiden ditangani dalam sekitar 2 jam, dan menjadi contoh nyata yang memverifikasi efektivitas keamanan kontainer

Belum ada komentar.

Belum ada komentar.