Kerentanan RCE satu klik ditemukan pada perangkat lunak driver pra-instal ASUS

• Perangkat lunak DriverHub milik ASUS ditemukan memiliki kerentanan eksekusi kode jarak jauh (RCE) satu klik
• Karena validasi origin yang lemah di lingkungan lokal, situs web berbahaya dapat menjalankan eksekusi dengan hak administrator melalui RPC
• Dengan menyalahgunakan endpoint UpdateApp, kode berbahaya dapat dijalankan melalui kombinasi executable bertanda tangan ASUS dan file ini yang dimanipulasi
• Kerentanan ini dipublikasikan sebagai CVE-2025-3462, CVE-2025-3463, dan ASUS dengan cepat merilis patch
• Saat pelaporan kerentanan, tidak ditemukan kasus eksploitasi nyata, dan ASUS memberikan penghargaan berupa pencantuman di hall of fame alih-alih bug bounty

---

Introduction

• Berawal dari cerita tentang pembelian komponen PC baru
• Saat membeli motherboard ASUS, opsi BIOS untuk instalasi perangkat lunak otomatis aktif secara default
• Karena lupa mematikan opsi tersebut, setelah login ke Windows muncul permintaan izin untuk menginstal DriverHub
• Karena membutuhkan driver WiFi, timbul rasa penasaran dan DriverHub pun diinstal

DriverHub

• DriverHub adalah proses latar belakang yang berjalan tanpa GUI
• Ia berkomunikasi dengan driverhub.asus.com untuk memberi tahu daftar driver yang perlu diinstal/diperbarui
• Secara lokal, ia menyediakan HTTP API (port 53000) sebagai RPC
• Situs web dapat mengirim permintaan API ke layanan lokal ini untuk langsung mengelola driver
• Disadari bahwa jika keamanannya lemah, penyerang bisa mengirim permintaan sewenang-wenang

Finding the Vulnerability

• Dilakukan percobaan apakah situs web bisa sembarang mengirim permintaan RPC ke backend DriverHub
• Dirancang agar hanya merespons saat Origin adalah “driverhub.asus.com”
• Diperiksa apakah pengecekan Origin dilakukan dengan pencocokan wildcard seperti origin.includes("driverhub.asus.com")
• Saat Origin diubah menjadi “driverhub.asus.com.mrbruh.com”, ditemukan bahwa permintaan tetap diizinkan
• Dengan metode ini dipastikan ada risiko serius bahwa penyerang dapat melakukan pemanggilan RPC dari situs berbahaya

The Extent of the Damage

• Melalui reverse engineering dan analisis JavaScript, berhasil diidentifikasi daftar endpoint API yang dapat digunakan di latar belakang
• Endpoint utama:
  • Initialize: mengembalikan status dan informasi instalasi
  • DeviceInfo: mengembalikan perangkat lunak/driver/perangkat keras ASUS yang terinstal serta alamat MAC
  • Reboot: langsung melakukan reboot
  • Log: mengembalikan kumpulan file log
  • InstallApp: menginstal aplikasi atau driver dengan ID yang ditentukan
  • UpdateApp: mengunduh lalu menjalankan executable dari URL yang ditentukan (otomatis dijalankan bila ditandatangani ASUS)
• Secara khusus disorot bahwa UpdateApp dapat disalahgunakan

Achieving RCE

• Endpoint UpdateApp dianalisis secara rinci
• Pada parameter “Url” ada syarat harus memuat .asus.com, tetapi ada kemungkinan untuk dilewati; nama file mengikuti bagian akhir URL
• Hanya executable yang ditandatangani ASUS yang dijalankan otomatis, tetapi file tak bertanda tangan juga tetap diunduh dan tidak dihapus
• Ditinjau kemungkinan serangan timing yang mengganti file tepat sebelum dieksekusi setelah lolos verifikasi tanda tangan, namun dianggap tidak praktis
• Saat menganalisis struktur paket driver WiFi ASUS, ditemukan bahwa properti SilentInstallRun pada AsusSetup.ini dapat digunakan untuk menjalankan perintah arbitrer
• Rantai serangan akhirnya:
  1. Penyerang mengarahkan korban untuk mengakses situs subdomain driverhub.asus.com. *
  2. Situs meminta calc.exe berbahaya melalui UpdateApp (hanya diunduh, tidak dijalankan)
  3. Meminta AsusSetup.ini kustom (SilentInstallRun=calc.exe, juga tidak dijalankan)
  4. Meminta AsusSetup.exe yang ditandatangani (otomatis dijalankan dengan hak administrator, membaca ini dengan flag -s lalu menjalankan calc.exe)
• Hasilnya, RCE satu klik yang menjalankan kode arbitrer jarak jauh dengan hak administrator pun terjadi

Reporting Timeline (DD/MM/YYYY)

• 07/04/2025: Kerentanan pertama kali ditemukan
• 08/04/2025: Bukti RCE dibuat dan kerentanan dilaporkan
• 09/04/2025: Menerima balasan otomatis dari ASUS
• 17/04/2025: Patch dirilis dan build patch diterima
• 18/04/2025: Dipastikan patch sudah live
• 09/05/2025: CVE-2025-3462 (skor 8.4), CVE-2025-3463 (skor 9.4) dipublikasikan

Assessing the Damage

• Segera setelah melaporkan kerentanan, dibuat skrip pelacakan certificate transparency
• Riwayat penerbitan sertifikat untuk subdomain driverhub.asus.com.* dipantau
• Hasil pemantauan selama 1 bulan menunjukkan tidak ada situs lain yang lolos filter selain pengujian pribadi
• Dikonfirmasi bahwa tidak ada indikasi eksploitasi sebelumnya

Bug Bounty

• Ditanyakan kepada ASUS mengenai pembayaran bug bounty, namun ditolak
• Sebagai gantinya, penghargaan diberikan dalam bentuk pencantuman di hall of fame
• Ditambahkan penjelasan bahwa meskipun ASUS adalah perusahaan besar, kebijakan bounty-nya masih kurang memadai

Fun Notes

• Saat mengirim formulir Security Advisory ASUS, PoC diblokir oleh Amazon CloudFront sebagai permintaan berbahaya
• Saat menekan “Install All” di DriverHub, perangkat lunak lain (Norton360, WinRAR, dll.) ikut dipasang secara paksa
• Deskripsi CVE ambigu dan tidak sesuai fakta, sehingga bisa menimbulkan kesalahpahaman bahwa 'desktop/laptop tidak terdampak' (padahal sebenarnya semua perangkat yang menginstal DriverHub terdampak)
• WiFi masih tetap tidak berfungsi, sehingga perlu membeli adaptor WiFi USB eksternal
• Untuk pertanyaan, tersedia Signal: paul19.84, email: contact [at] mrbruh.com

[GN⁺]

Komentar Hacker News

• Hasil dari Responsible Disclosure terasa seperti bencana bagi umat manusia; perusahaan perlu merasakan lebih banyak penderitaan dan lebih sering agar mau menganggap serius keamanan pelanggan. Jika Anda menemukan masalah lalu memberi tahu cara memperbaikinya dalam waktu sebulan, bagi perusahaan itu hanya akan jadi satu tiket backlog. Tetapi jika sampai menjadi berita online dan CEO harus turun tangan, mereka akan menemukan cara memperbaikinya hanya dalam hitungan jam. Tentu pada akhirnya pengguna yang paling dirugikan, tetapi membeli ASUS saja sudah berarti mereka memang sedang menderita.
  • Penanganan ASUS kali ini tergolong cepat; mereka tidak menyangkal masalahnya, tidak menuntut orang yang melakukan reverse engineering, dan langsung merilis patch. Dulu isu seperti ini bisa makan waktu berbulan-bulan atau bahkan melibatkan polisi. Orang awam juga tidak terlalu peduli pada kerentanan; ini dunia di mana orang tetap melakukan transaksi keuangan dengan ponsel yang sudah 3 tahun tidak diperbarui. Membanjiri media dengan isu CVE pun hanya akan membuat semua orang mati rasa. Di Eropa, regulasi baru melarang penjualan produk yang memiliki kerentanan yang sudah diketahui. Jadi jika ASUS terus seperti ini, stok motherboard mereka akan menumpuk di gudang dan distributor akan enggan menjualnya. Ini juga berlaku untuk peralatan rumah tangga; misalnya jika ada kerentanan pada mesin pencuci piring, industrinya pun bisa terdampak besar.
  • Nama "Responsible" Disclosure justru ironisnya merupakan tindakan yang sepenuhnya tidak bertanggung jawab. Kebanyakan perusahaan tidak menambal dalam seminggu, tidak memberi pengakuan, tidak memberi tahu pengguna, dan tidak belajar dari kesalahan. Pengungkapan yang lambat dan terbatas malah mendorong perilaku seperti itu. Tindakan yang benar-benar bertanggung jawab adalah mengungkapkannya segera, secara lengkap, dan terbuka. Jika suatu saat ada kepercayaan bahwa perusahaan akan merespons dengan baik, mungkin pemberitahuan awal sekitar 5 hari kerja bisa dipertimbangkan. Menyebut pengungkapan yang lambat dan parsial sebagai "responsible disclosure" hanyalah permainan kata.
  • Akar masalahnya adalah tidak adanya legislasi tentang tanggung jawab produk. Produsen mobil wajib melakukan recall, tetapi perusahaan software/hardware menghadapi tekanan yang terlalu lemah. Saya pikir pelanggan harus bisa mendapat pengembalian dana penuh untuk produk dengan kerentanan (CVE) yang tidak diperbaiki.
  • Meminjam kata-kata CGPGrey, solusi pertama yang terpikir biasanya buruk dan tidak efektif. Budaya keamanan yang baik harus mendorong agar masalah internal tidak disembunyikan. Perusahaan itu rakus sehingga menyembunyikan semua masalah keamanan. Jika langsung diungkap saat ditemukan, masalah yang sebenarnya bisa diperbaiki dalam sebulan akan langsung terekspos ke semua orang dan risiko eksploitasi naik tajam.
  • Ada ide bisnis, mungkin sudah ada: sebuah platform pengungkapan/perantara yang melindungi privasi pelapor, memverifikasi apakah kerentanan benar-benar bisa dieksploitasi, mengumumkannya secara publik pada jadwal yang sudah ditentukan, dan memungkinkan perusahaan membayar untuk berlangganan feed awal yang relevan dengan mereka; uangnya dipakai untuk memberi imbalan pada pelapor, biaya operasional, dan pembagian keuntungan. Ini mirip marketplace bug bounty, tetapi dari sudut pandang perusahaan agak bersifat adversarial. Saya penasaran apakah ini legal, atau akan dianggap pemerasan.
  • Saya terus menekankan bahwa seperti industri lain, harus ada tanggung jawab hukum atas cacat produk. Kebanyakan orang tidak menoleransi barang cacat kecuali karena harganya murah, dan tidak ada alasan software harus menjadi pengecualian.
  • Kalau kerentanannya langsung diumumkan keesokan harinya, itu justru motivasi yang sesungguhnya. Malu di depan umum juga membantu keamanan berikutnya.
  • Hiperbola seperti menyebut ini “bencana bagi umat manusia” adalah contoh khas yang merusak inti argumen.
• Saya bertanya ke ASUS apakah ada bug bounty, dan mereka bilang sebagai gantinya nama saya akan dimasukkan ke Hall of Fame. Rasanya pahit karena terdengar seperti lelucon bahwa ASUS hanyalah startup kecil yang tidak punya modal untuk memberi bounty.
  • Perusahaan kecil seperti Cisco juga melakukan hal serupa: tidak memberi imbalan, hanya mencantumkan nama. Cisco bahkan lupa menaruhnya di halaman advisory keamanan, jadi kesempatan untuk diakui pun hilang.
  • Kalau tidak ada bug bounty, pilihannya tinggal menyerahkan exploit ke black market atau melakukan full disclosure.
  • Situasi seperti ini membuat saya tidak ingin lagi membeli produk ASUS.
• Kualitas software ASUS juga buruk, dan mereka adalah perusahaan yang terus menimbulkan masalah keamanan. Sebelumnya juga pernah ada isu malware UEFI pada motherboard, dan software yang tidak perlu dipasang secara default sehingga repot untuk dihapus. Ada banyak contoh keluhan yang layak dijadikan referensi.
  • Ini juga bukan pertama kalinya; dulu pernah ada kasus serupa, dan saya juga meninggalkan catatannya di blog lama saya sebagai arsip.
• Mereka bilang kerentanan itu tidak pernah dieksploitasi karena hanya domain uji milik mereka sendiri (driverhub.asus.com.*) yang memenuhi syarat, tetapi itu hanya benar jika tidak ada pihak yang mendaftarkan subdomain di bawah driverhub secara terpisah. Dengan wildcard, ini bisa saja tidak terlihat di certificate transparency log dan tetap bisa dieksploitasi.
  • Sertifikat wildcard hanya mencakup subdomain satu tingkat. Misalnya *.example.com hanya berlaku untuk test.example.com, bukan test.test.example.com. Jika seseorang memiliki wildcard *.asus.com.example.com, maka driverhub.asus.com.example.com akan menjadi valid.
  • Ada yang bilang itu ide bagus lalu langsung dicek, dan saat ini tidak ada wildcard certificate yang mencurigakan.
  • Titik buta pada wildcard certificate memang kritik yang valid. Jika penyerang memiliki wildcard certificate untuk .example.com, maka eksploitasi sebenarnya bisa dilakukan dari lokasi yang bukan driverhub.asus.com. Karena itu, pemantauan CT log saja tidak cukup sempurna untuk mendeteksi kerentanan pengambilalihan subdomain seperti ini.
• Bagian saat ASUS ditanya soal bug bounty lalu menjawab "kami startup kecil jadi tidak ada bounty, tapi nama Anda akan kami masukkan ke Hall of Fame" terasa menonjol, padahal kenyataannya mereka adalah perusahaan raksasa dengan kapitalisasi pasar lebih dari 15B.
  • Sebagai sindiran, ada yang merekomendasikan sarcasm.com.
• Wi-Fi onboard saya tidak berfungsi jadi saya memakai Wi-Fi USB eksternal, tetapi berkat DriverHub semua itu tetap tidak ada gunanya. Katanya solusi, tetapi mengecewakan.
  • Tulisan blognya sendiri tetap menarik untuk dibaca.
  • Driver Wi-Fi terbaru tidak berfungsi, jadi saya harus memakai versi lama.
• ASUS adalah perusahaan besar dengan kapitalisasi pasar 15 miliar dolar, tetapi tetap tidak memberi kompensasi yang layak dan mengabaikan jerih payah pelanggan maupun peneliti. Melihat perlakuan seperti ini, mudah memahami betapa frustrasinya para peneliti. Kesimpulannya, pilihan terbaik adalah tidak membeli produk ASUS.
• Saat mengirim bug report, file PoC ditandai Amazon CloudFront sebagai permintaan berbahaya sehingga pengiriman itu sendiri diblokir. WAF (Web Application Firewall) seperti ini justru merupakan pola atau praktik yang buruk.
• Saya juga paham keluhan soal masalah Wi-Fi onboard; sebenarnya cukup cek model chipset lalu unduh sendiri dari tempat seperti station-drivers, cuma butuh beberapa detik. Karena kerepotan seperti ini saya tidak suka ASUS, dan saya terutama benci opsi BIOS yang berinteraksi langsung dengan sistem operasi.
• Saya suka produk ASUS, tetapi aplikasi pendukung yang dipasang otomatis lewat UEFI selalu saya nonaktifkan. Dulu versi penuh ROG Armory Crate sampai terpasang dan sulit dihapus. Setelah ASUS mengambil alih bisnis NUC dari Intel, pembaruan BIOS memang tetap dipertahankan, tetapi aplikasi pemasangan seperti "MyASUS" ikut ditambahkan secara default. Untungnya ada opsi untuk menonaktifkannya, dan jika diperbarui dari Intel NUC BIOS, tampaknya default-nya dalam keadaan nonaktif.