Server Hetzner saya diretas dan mulai menambang Monero

 (blog.jakesaunders.dev)
1 poin oleh GN⁺ 2025-12-19 | 1 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
Iklan

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
    Iklan
  • 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

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-19
Komentar Hacker News

  • Dulu saya memakai UFW, tapi sekarang saya merekomendasikan firewalld
    UFW makin sulit dikelola seiring waktu, sedangkan firewalld lebih stabil karena berbasis konfigurasi XML
    Dengan perintah firewall-cmd, Anda bisa mengatur SSH, HTTPS, port 80, dan sebagainya, dan sebaiknya menggunakan backend nftables
    Dalam kasus Docker, sering kali port dibuka dengan melewati aturan firewall, jadi lebih aman mengatur StrictForwardPorts=yes di /etc/firewalld/firewalld.conf

    • Sebaiknya jangan membuka port seperti 8080:8080, tetapi ikat ke IP privat seperti 192.168.0.1:8080:8080
      Saya menjalankan Docker di VM 10.0.10.11, dan cukup praktis membuatnya hanya bisa diakses lewat WireGuard lalu menaruh Caddy sebagai reverse proxy
    • Disarankan memasang Podman alih-alih Docker. Docker sering bermasalah karena melewati firewall
    • Apa pun frontend netfilter yang dipakai, tanpa pembatasan koneksi keluar, semuanya tidak ada artinya
      Malware akan mencoba terhubung ke mining pool eksternal atau server C2, jadi akses jaringan dari biner yang tidak diizinkan harus diblokir
      Menghapus izin eksekusi dari /tmp, /var/tmp, dan /dev/shm juga berguna
    • Hetzner menyediakan layanan firewall eksternal gratis, jadi bisa dimanfaatkan sebagai garis pertahanan pertama
    • Secara pribadi, saya merasa nftables.conf saja sudah cukup sederhana dan jelas
      iptables sudah ditinggalkan, jadi lapisan tambahan seperti firewalld tidak selalu diperlukan

  • Ini tampaknya terkait isu “React2Shell CVE-2025-55182”
    Aneh rasanya kerentanan yang berdampak lebih dari setahun ini nyaris tidak mendapat perhatian
    Jika Anda menerapkan web app dengan Next.js dalam 12 bulan terakhir, besar kemungkinan Anda sudah menjadi bagian dari botnet
    Menjengkelkan melihat industri hanya memberi saran setingkat “pakai Docker” atau “nyalakan firewall”
    Akhir-akhir ini saya makin skeptis terhadap ekosistem frontend, sampai mempertimbangkan pindah karier ke C++

    • Siklus pergantian teknologi di frontend sekarang jauh lebih tenang dibanding dulu
      Saat ini kombinasi Next.js, React, Tailwind, dan Postgres sudah seperti standar selama 5 tahun
      Dibanding era ledakan framework pada akhir 2000-an hingga awal 2010-an, sekarang jauh lebih stabil
      Jika Anda tidak suka tren dan perubahan, pengembangan AI justru berubah jauh lebih cepat
    • Anda tetap bisa membuat web app tanpa memakai framework JS terbaru
      Untuk backend, pakai saja stack teknologi yang kokoh seperti .NET, Java, atau Go, lalu frontend dipilih bebas
      Dengan begitu jumlah CVE berkurang dan kelelahan teknis juga lebih rendah
    • Instans Pangolin saya juga ditembus oleh kerentanan ini
      Diskusi GitHub terkait
    • Saya juga telah menerapkan sekitar 100 frontend Next.js, tetapi untungnya tidak terdampak karena tidak memakai Server Components

  • Jika penggunaan CPU kontainer Docker dibatasi dengan --cpus="0.5", layanan yang bermasalah atau miner tidak akan memengaruhi seluruh sistem

    • Menjalankan kontainer dalam mode read-only juga bisa lebih mengurangi permukaan serangan
    • Namun jika batas CPU terlalu rendah, intrusi bisa jadi kurang terlihat sehingga deteksi tertunda
    • Anda harus benar-benar memahami profil performa aplikasi. Jika nanti ada lonjakan trafik, throttling bisa terjadi tanpa disengaja
    • Sebaiknya atur juga soft/hard limit untuk memori

  • Menjalankan server tanpa firewall adalah pilihan yang cukup berani
    Jika memakai firewall eksternal Hetzner bersama-sama, ada satu lapisan pertahanan tambahan saat terjadi kesalahan
    Saya hanya mengizinkan SSH dari IP rumah, dan bila perlu dari luar saya membukanya sementara lewat situs Hetzner

    • Dalam banyak kasus, firewall tidak terlalu efektif
      Yang benar-benar penting adalah tidak menjalankan software dengan kerentanan RCE
      Docker terlihat seperti penyelamat, tapi sebenarnya itu lebih karena beruntung saja
    • Jika ini layanan web publik, firewall tidak banyak membantu
      Sebagai gantinya, Anda bisa memakai bastion host dan mengontrol lalu lintas masuk-keluar lewat HTTP proxy, tetapi konfigurasinya rumit
    • Selama 30 tahun mengoperasikan Linux, satu-satunya saat saya diretas adalah ketika membuka port yang sudah terkenal
      Memakai port nonstandar ternyata cukup efektif
    • Mengaktifkan autentikasi kata sandi itu berisiko. Secara pribadi saya merasa fail2ban tidak selalu wajib
    • Saya mencoba menghindari port scanner dengan mengganti port SSH secara acak
      Saya tidak yakin seberapa efektif, tapi rasanya seperti payung psikologis

  • Saya penasaran, kalau kontainer Docker dijalankan sebagai root, apakah host juga bisa diserang

    • Docker bukan batas keamanan. Docker hanya menyediakan isolasi di tingkat proses
      Untuk menjalankan kode yang tidak tepercaya, Anda harus memakai VM (KVM/QEMU) atau teknologi seperti gVisor(https://gvisor.dev/) dan Firecracker(https://firecracker-microvm.github.io/)
      Docker sebaiknya dipahami bukan sebagai sandbox, melainkan lingkungan eksekusi yang terisolasi
    • Penyerang tetap bisa memakai CPU dari dalam kontainer untuk menambang Monero
      Konfigurasi bawaan Docker tidak membatasi penggunaan RAM, CPU, maupun disk, sehingga rentan juga terhadap serangan DoS
      Selain itu, banyak panduan yang merekomendasikan opsi berbahaya seperti --privileged atau CAP_SYS_PTRACE
    • Dalam mode privileged, root filesystem host bisa diakses melalui soket Docker
      Penyerang juga bisa menjalankan kontainer baru dan menaikkan hak akses menjadi root
    • User namespace harus diaktifkan agar benar-benar ada batas keamanan
      Di Docker ini masih bukan default, jadi tanpa konfigurasi tersebut risiko escape cukup besar
      Sebagian besar container escape di masa lalu bisa dicegah dengan user namespace
    • Container escape memang ada, tetapi kebanyakan hanya serangan mining otomatis yang sederhana
      Jika server tidak menangani data sensitif, membersihkan kontainernya saja mungkin sudah cukup

  • Untuk mengurangi permukaan serangan, layanan yang tidak perlu dipublikasikan sebaiknya jangan diekspos ke luar
    Misalnya, alat analitik cukup dibuat hanya bisa diakses lewat WireGuard atau SSH SOCKS proxy

  • Saya juga pernah mengalami infeksi miner Monero di server Hetzner
    Untungnya itu hanya terjadi di dalam kontainer LXC milik Incus, dan karena prioritas CPU-nya rendah saya tidak langsung menyadarinya
    SSH key ditambahkan ke akun root dan agen manajemen jarak jauh dipasang
    Pada akhirnya saya membuang kontainer itu, tetapi saya mendapat beberapa pelajaran

    • Kita harus berasumsi sistem suatu saat akan ditembus, lalu menyiapkan isolasi dan pembatasan sumber daya
    • Jika snapshot ZFS dan backup dipelihara secara berkala, pemulihan jadi mudah
    • Idealnya sistem yang sudah dikompromikan dibuang, tetapi tergantung situasi, rollback lalu hardening juga memungkinkan
    • Miner itu terlihat karena konfigurasinya buruk, tetapi kalau penyusupannya lebih diam-diam, mungkin saya tidak akan sadar
    • Ini terjadi pada kontainer tempat saya memasang Umami

  • Tulisan itu memuat halusinasi AI yang tidak dikoreksi manusia
    Ia berulang kali mengklaim ini kerentanan terkait Puppeteer, padahal bukan

    • Di paragraf pertama teks aslinya sudah disebutkan bahwa itu adalah transkrip sesi Claude

  • Belakangan ini miner Monero yang memanfaatkan kerentanan React 19 dipasang di mana-mana
    Saya juga mengalami masalah yang sama

    • Malware mining semacam ini justru cukup berguna karena sangat mencolok dan dampaknya kecil
      Ia bekerja semacam bug bounty otomatis yang memberi tahu adanya kerentanan
      Jika pemantauan jaringan atau proses berjalan baik, ini mudah dideteksi
    • Server Umami saya di Oracle Cloud terinfeksi dan saya mereset server
      Untungnya ini menjadi kesempatan bagus untuk meningkatkan sistem backup

  • Melihat kasus seperti ini, saya merasa keputusan untuk tidak mengelola VPS sendiri adalah keputusan yang tepat
    Saya pernah mencobanya dulu, tetapi saya hanya admin tingkat biasa dan merasa sulit menjaga keamanannya
    Karena itu sekarang saya lebih tenang membayar dan menyerahkannya kepada para ahli