Kerentanan RCE sekali klik pada perangkat lunak driver pra-instal ASUS

 (mrbruh.com)
2 poin oleh GN⁺ 2025-05-12 | 1 komentar | Bagikan ke WhatsApp
  • ASUS DriverHub yang dapat terpasang sesaat setelah login Windows ternyata, karena cara menghubungkan situs web dan layanan lokal, dapat berujung pada eksekusi kode dengan hak administrator hanya dengan pengguna mengunjungi situs web tertentu
  • DriverHub berjalan di latar belakang tanpa GUI, dengan struktur di mana driverhub.asus.com mengirim permintaan ke layanan HTTP/WebSocket lokal di 127.0.0.1:53000, dan pemeriksaan Origin mengizinkan domain berbentuk driverhub.asus.com.*
  • Endpoint UpdateApp akan mengunduh file jika URL hanya mengandung string .asus.com, dan saat file executable bertanda tangan ASUS dijalankan dengan hak administrator, file yang gagal verifikasi tanda tangan tidak dihapus
  • Eksploit akhir mengunduh calc.exe yang tidak ditandatangani, AsusSetup.ini yang dimanipulasi, lalu AsusSetup.exe yang ditandatangani secara berurutan, kemudian mencapai RCE dengan hak administrator lewat SilentInstallRun=calc.exe
  • ASUS mengonfirmasi distribusi perbaikan pada April 2025, lalu CVE-2025-3462 dan CVE-2025-3463 dipublikasikan pada 9 Mei 2025, dan berdasarkan log certificate transparency tidak terlihat jejak penyalahgunaan aktif yang signifikan sebelum pengungkapan

DriverHub local RPC yang terhubung dengan situs web

  • Setelah membeli motherboard ASUS dan sesaat setelah login Windows, muncul notifikasi yang meminta hak administrator untuk menyelesaikan instalasi ASUS DriverHub
  • DriverHub bukan GUI terpisah, melainkan proses latar belakang, dan driverhub.asus.com menampilkan driver yang diperlukan serta target pembaruan
  • Situs web berkomunikasi dengan proses DriverHub yang berjalan secara lokal melalui RPC
    • Layanan lokal berjalan pada port tetap 53000 di 127.0.0.1
    • Struktur ini membuat situs web atau layanan mengirim permintaan API ke port lokal tersebut
  • Dalam struktur seperti ini, jika perlindungan RPC tidak memadai, penyerang dapat menyalahgunakannya untuk memasang aplikasi berbahaya

Bypass pemeriksaan Origin yang longgar

  • DriverHub tidak menerima semua permintaan dari sembarang situs web; ia dirancang untuk merespons permintaan dengan header Origin bernilai driverhub.asus.com
  • Masalahnya, pemeriksaan bukan perbandingan yang tepat, melainkan metode yang mendekati pencocokan substring atau wildcard
    • Bukan perbandingan langsung seperti origin == driverhub.asus.com
    • Saat driverhub.asus.com.mrbruh.com dijadikan Origin, permintaan tetap diizinkan
  • Penyerang dapat memanfaatkan perilaku ini untuk mengakses RPC DriverHub lokal dari domain berbentuk driverhub.asus.com.*

Endpoint RPC yang terekspos

  • Melalui JavaScript situs web dan dekompilasi file executable, teridentifikasi beberapa endpoint RPC
  • Endpoint utamanya adalah sebagai berikut
    • Initialize: mengembalikan status apakah perangkat lunak terpasang dan informasi instalasi dasar
    • DeviceInfo: mengembalikan perangkat lunak ASUS yang terpasang, driver .sys yang terpasang, komponen perangkat keras, dan alamat MAC
    • Reboot: langsung me-reboot perangkat target tanpa konfirmasi
    • Log: mengembalikan arsip terkompresi dari seluruh log DriverHub
    • InstallApp: melakukan instalasi berdasarkan ID aplikasi atau driver, dan ID aplikasi di-hardcode dalam file XML yang disediakan installer DriverHub
    • UpdateApp: mengunduh dan menjalankan URL file yang diberikan untuk memperbarui DriverHub sendiri

Cara UpdateApp menciptakan kondisi untuk RCE

  • Permintaan UpdateApp bekerja dalam bentuk berikut
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • Perilaku UpdateApp yang diamati menyediakan beberapa syarat yang diperlukan untuk rantai RCE
    • Parameter Url harus mengandung string .asus.com, tetapi bentuk seperti example.com/payload.exe?foo=.asus.com juga diizinkan
    • File disimpan dengan nama file yang ditentukan di akhir URL
    • File dapat diunduh tanpa memedulikan ekstensi
    • Jika file adalah executable bertanda tangan ASUS, file itu otomatis dijalankan dengan hak administrator
    • Jika executable ditandatangani ASUS, file itu akan dijalankan meski bukan installer DriverHub
    • Meski file yang diunduh gagal pemeriksaan tanda tangan, file tersebut tidak dihapus
  • Awalnya RCE tampak sulit karena verifikasi tanda tangan, tetapi gabungan antara perilaku file yang tetap tersisa saat verifikasi gagal dan perilaku instalasi executable bertanda tangan ASUS menciptakan jalur bypass

Rantai eksploit menggunakan AsusSetup.ini

  • Paket driver WiFi ASUS berisi AsusSetup.exe, AsusSetup.ini, dan SilentInstall.cmd
  • Saat dijalankan, AsusSetup.exe membaca metadata driver dari AsusSetup.ini
  • Jika AsusSetup.exe dijalankan dengan flag -s, ia melakukan instalasi senyap tanpa GUI dan menjalankan item yang ditentukan pada SilentInstallRun di AsusSetup.ini
    • DriverHub menggunakan flag -s untuk instalasi senyap
    • File INI asli menunjuk ke skrip cmd untuk instalasi otomatis tanpa interaksi
    • SilentInstallRun juga dapat diarahkan ke executable lain

  • Urutan serangan yang lengkap

    • Pengguna mengunjungi situs web dengan domain berbentuk driverhub.asus.com.*
    • Situs meminta executable PoC calc.exe melalui UpdateApp
    • calc.exe diunduh tetapi tidak dijalankan karena gagal pemeriksaan tanda tangan
    • File tetap tersisa dan tidak dihapus
    • Situs meminta AsusSetup.ini yang dimanipulasi melalui UpdateApp
    • File ini juga diunduh tetapi tidak dijalankan
    [InstallInfo]
SilentInstallPath=.\\
SilentInstallRun=calc.exe
    • Situs meminta biner bertanda tangan ASUS AsusSetup.exe melalui UpdateApp
    • AsusSetup.exe dijalankan dengan hak administrator setelah diunduh
    • Karena DriverHub menjalankannya dengan -s, file itu membaca AsusSetup.ini
    • Sesuai SilentInstallRun=calc.exe, calc.exe dijalankan dengan hak administrator

Dari pelaporan hingga publikasi CVE

  • Jadwal penanganan kerentanan adalah sebagai berikut
    • 2025-04-07: penemuan awal kerentanan
    • 2025-04-08: konfirmasi eskalasi menjadi RCE
    • 2025-04-08: pelaporan kerentanan ke ASUS
    • 2025-04-09: menerima respons otomatis dari ASUS
    • 2025-04-17: setelah tindak lanjut, ASUS mengirim build untuk verifikasi dan menyatakan patch selesai
    • 2025-04-18: ASUS mengonfirmasi distribusi perbaikan
    • 2025-05-09: CVE-2025-3462 dengan skor 8.4 dan CVE-2025-3463 dengan skor 9.4 dipublikasikan

Kemungkinan eksploitasi dan jejak yang teramati

  • Segera setelah pelaporan, dijalankan skrip di VPS yang melacak pembaruan certificate transparency untuk memeriksa apakah domain driverhub.asus.com.* telah didaftarkan
  • Berdasarkan situs web log certificate transparency lain, domain dan subdomain biasanya muncul di log dalam waktu satu bulan
  • Hasil pemeriksaan sebulan kemudian menunjukkan bahwa situs web yang cocok dengan regex itu hanya domain uji
  • Berdasarkan patokan ini, kemungkinan penyalahgunaan aktif secara luas sebelum pelaporan dinilai rendah

Respons ASUS dan isu yang tersisa

  • ASUS tidak menyediakan bug bounty, dan sebagai gantinya menjawab bahwa nama pelapor akan dicantumkan di hall of fame
  • Belakangan diketahui peneliti keamanan lain, leonjza, sudah melaporkan masalah pemeriksaan Origin yang sama pada Februari 2025, dan ASUS memperbaikinya pada saat perbaikan kali ini
    • ASUS tidak secara terpisah memberi tahu fakta ini
    • Di halaman cve.org hanya peneliti tersebut yang dicantumkan dalam kredit, dan ASUS menjawab bahwa kredit tambahan tidak akan ditambahkan
  • Saat mengirim laporan kerentanan melalui formulir Security Advisory ASUS, Amazon CloudFront mendeteksi PoC terlampir sebagai permintaan berbahaya dan memblokir pengiriman
    • Sebagian kode PoC harus dihapus dan sebagai gantinya dikirim tautan video rekaman
  • Jika di DriverHub menekan “Install All” alih-alih memasang tiap driver yang direkomendasikan secara terpisah, ArmouryCrate, CPU-Z kustom ASUS, Norton360, dan WinRAR juga ikut terpasang
  • Penjelasan CVE dari ASUS menggambarkan cakupan dan dampak RCE secara terlalu sempit
    • Penjelasan itu memuat kalimat yang pada intinya menyatakan “terbatas pada motherboards dan tidak memengaruhi laptops atau desktop computers”
    • Kenyataannya, semua komputer termasuk desktop/laptop yang memasang DriverHub terdampak
    • Alih-alih menyebut eksekusi kode arbitrer atau jarak jauh, penjelasan itu menggunakan ungkapan seperti “untrusted sources dapat memengaruhi system behaviour”

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-12
Komentar Hacker News

  • Pengungkapan yang bertanggung jawab dan dampaknya nyaris menjadi bencana bagi umat manusia. Agar perusahaan menganggap keamanan pelanggan jauh lebih serius, mereka harus jauh lebih sering merasakan rasa sakit yang jauh lebih besar
    Kalau diberi waktu sebulan dan bahkan disuapi solusinya, itu hanya akan menjadi satu tiket backlog. Jika setiap kali masalah keamanan meledak, kabarnya cukup besar di internet sampai CEO ikut terlibat dan mereka harus mencari solusi dalam hitungan jam, bukan bulan, mereka akan bergerak jauh lebih proaktif. Tentu pengguna akhir yang akan paling dirugikan, tetapi sejak membeli ASUS pun mereka sudah menderita

    • Kecepatan respons ASUS kali ini cukup baik, dan saya tidak melihat masalah besar di sini. ASUS tidak menyangkal bug tersebut, tidak mengancam akan menuntut dengan alasan rekayasa balik software, dan menambalnya dengan cepat
      Pada era sebelum pengungkapan yang bertanggung jawab, proses ini mungkin memakan waktu berbulan-bulan dan bahkan melibatkan polisi. Pengguna umum tidak peduli pada kerentanan, dan tetap melakukan urusan finansial dengan ponsel yang sudah tiga tahun tidak mendapat update. Jika CVE terus disebar di berita, orang akan jenuh dengan narasi “semua perusahaan buruk” dan menjadi kebal bahkan saat ancaman nyata datang
      UE sedang mendorong solusi lain. Dalam regulasi keamanan siber baru, produk dengan kerentanan yang diketahui tidak boleh dijual di toko. Jika ASUS terus gagal, motherboard mereka akan menjadi stok mati, dan toko pun tidak akan ingin menjual hardware ASUS. Ini berlaku bukan hanya untuk hardware komputer, tetapi juga kulkas pintar dan mesin cuci. Jika menemukan kerentanan pada mesin pencuci piring, dan produsen tidak menyertakan cara untuk memperbarui firmware, Anda bisa menciptakan stok tak terpakai bernilai jutaan dolar di industri
    • Nama “pengungkapan yang bertanggung jawab” itu ironis. Sebab dalam praktiknya, ini lebih dekat dengan cara yang sepenuhnya tidak bertanggung jawab
      Sebagian besar perusahaan menangani pengungkapan dengan buruk. Mereka tidak memperbaikinya tepat waktu, misalnya dalam seminggu, tidak memberi kredit dengan benar, tidak memberi tahu pengguna, dan tidak belajar dari kesalahan. Pengungkapan terbatas yang ditunda secara tidak bertanggung jawab justru memperkuat perilaku seperti itu
      Cara yang benar-benar bertanggung jawab adalah mengungkapkannya segera, secara lengkap, dan terbuka. Jika perlu, bisa dilakukan secara anonim untuk melindungi diri. Barulah setelah perusahaan yang terdampak membuktikan berulang kali bahwa mereka merespons dengan benar, mereka bisa memperoleh hak pemberitahuan dini yang sangat singkat, misalnya sekitar 5 hari kerja
      Fakta bahwa pengungkapan terbatas yang ditunda secara tidak bertanggung jawab seperti ini disebut “pengungkapan yang bertanggung jawab” adalah salah satu contoh newspeak
    • Intinya adalah soal membuat tanggung jawab menjadi hukum. Produsen mobil bisa diperintahkan melakukan recall dan perbaikan, tetapi tekanan terhadap perusahaan software dan hardware terlalu lemah
      Pelanggan seharusnya bisa mendapatkan refund penuh, misalnya untuk perangkat rusak yang memiliki CVE yang belum diperbaiki
    • Mengutip CGPGrey, solusi pertama yang terlintas biasanya buruk dan tidak efektif
      Budaya keselamatan dan keamanan yang baik mendorong para pelaku agar tidak menyembunyikan masalah. Perusahaan adalah entitas serakah, jadi mereka akan melakukan apa saja untuk menyembunyikan kesalahan keamanan
      Jika masalah yang legal dan bisa diperbaiki dalam sebulan diumumkan ke semua orang, kemungkinan untuk dieksploitasi juga meningkat tajam
    • Mungkin ada ide bisnis seperti ini. Mungkin sudah ada, tetapi idenya adalah membuat layanan perantara dan agregasi pengungkapan
      Layanan ini melindungi privasi pelapor, memverifikasi kerentanan keamanan, dan memastikan setiap kerentanan yang dipublikasikan benar-benar bisa dieksploitasi. Publikasi dilakukan secara berkala, dan perusahaan dikenai biaya langganan untuk “feed awal” agar menerima terlebih dahulu pengungkapan yang berdampak pada mereka. Uang itu digunakan untuk memberi imbalan kepada pelapor, membayar biaya operasional, dan menyisakan sebagian laba
      Dengan kata lain, ini semacam pasar bug bounty yang agak antagonis terhadap perusahaan. Saya penasaran apakah ini legal, atau akan dianggap pemerasan

  • Bagian yang pahit adalah ketika mereka bertanya apakah ASUS punya bug bounty, jawabannya tidak, tetapi sebagai gantinya mereka menawarkan untuk memasukkan nama ke “Hall of Fame”
    Ini sindiran bahwa ASUS pasti startup kecil yang tidak punya modal untuk memberi bounty, jadi bisa dimaklumi

    • Hal yang bisa dimaklumi juga untuk perusahaan kecil seperti Cisco. Cisco juga selama bertahun-tahun melakukan hal serupa untuk banyak layanan online yang mereka akuisisi
      Cisco bahkan melangkah lebih jauh dengan melupakan halaman advisori keamanan mereka, sehingga pengakuan apa pun kini lenyap ke kehampaan
    • Jika tidak ada bug bounty, exploit akan masuk ke pasar gelap, atau dipublikasikan penuh
    • Respons seperti ini membuat saya tidak ingin membeli produk ASUS lagi
    • Saya tidak tahu dari mana ungkapan “Asus adalah startup kecil” berasal. Asus sudah membuat motherboard dan komponen PC setidaknya sejak era 90-an

  • Tidak mengejutkan. Software ASUS buruk, dan dari sisi keamanan mereka hampir seperti perusahaan bermasalah berulang yang kurang melakukan pencegahan
    https://www.techspot.com/news/95425-years-gigabyte-asus-moth...
    https://www.reddit.com/r/ASUS/comments/tg3u2n/removing_bloat...
    https://www.reddit.com/r/ASUS/comments/ojsq80/nahimic_servic...

  • Bagian yang menilai bahwa, setelah melihat log Certificate Transparency, domain yang cocok dengan driverhub.asus.com.* hanya domain pengujian mereka sendiri sehingga kemungkinan besar belum dieksploitasi secara aktif sebelum dilaporkan, hanya berlaku jika tidak ada sertifikat wildcard
    Jika ada pihak yang memiliki wildcard, mereka bisa saja mengeksploitasinya tanpa muncul di Certificate Transparency

    • Sertifikat wildcard hanya berlaku pada satu tingkat label. *.example.com. tidak berlaku untuk test.test.example.com., tetapi berlaku untuk test.example.com.
      Jika seseorang menerbitkan wildcard untuk *.asus.com.example.com., mereka bisa menjalankan server web di bawah driverhub.asus.com.example.com. dan membuatnya terlihat valid
    • Itu ide yang bagus, jadi saya baru saja mengeceknya, dan memastikan tidak ada hal mencurigakan pada record wildcard
    • Benar, ada blind spot pada sertifikat wildcard. Jika penyerang memiliki sertifikat wildcard untuk .example.com, mereka bisa mengeksploitasinya tanpa muncul secara spesifik di log Certificate Transparency sebagai domain driverhub.asus.com.
      Jadi pemantauan log Certificate Transparency saja tidak cukup untuk mendeteksi kerentanan pengambilalihan subdomain semacam ini
    • Selain itu, saya juga penasaran apakah sertifikat self-signed akan berfungsi. Sertifikat seperti itu tidak masuk ke log transparency
      Dan saya juga bertanya-tanya apakah memang harus HTTPS

  • Akhirnya malah, “WiFi onboard saya masih tidak berfungsi, dan saya harus membeli adaptor WiFi USB eksternal. Terima kasih, DriverHub”; seluruh proses ini benar-benar sia-sia

    • Tulisan blognya sendiri bagus
    • Driver WiFi terbaru tidak berfungsi, jadi harus memakai versi lama

  • Bagian ketika mengirim laporan kerentanan melalui formulir pelaporan keamanan ASUS, Amazon CloudFront menganggap PoC yang dilampirkan sebagai request berbahaya lalu memblokirnya, terasa seperti pengingat bahwa web application firewall adalah antipola: https://thedailywtf.com/articles/Injection_Rejection

  • “ASUS bisa dimaklumi karena startup kecil”, maksudnya startup kecil dengan kapitalisasi pasar cuma 15 miliar dolar AS
    Yang benar-benar sulit dipahami adalah mereka memperlakukan seperti ini bukan hanya produk yang buruk, tetapi juga peneliti yang sudah melakukan pekerjaan luar biasa demi pelanggan mereka
    Kasihan para peneliti yang melakukan pekerjaan seperti ini tetapi kemudian diabaikan atau diremehkan. Sangat tidak adil
    Satu-satunya hal yang bisa dilakukan hanyalah tidak membeli produk ASUS

  • Ada yang bertanya apakah ASUS punya bug bounty, dan ASUS menjawab tidak, tetapi sebagai gantinya akan mencantumkan nama di “Hall of Fame”. Ini sindiran bahwa ASUS adalah startup kecil, jadi bisa dimaklumi kalau tidak punya modal untuk memberi bounty
    [1]: https://companiesmarketcap.com/asus/marketcap/

    • Atau mungkin ini sarcasm.com ;)

  • Tautan video Scumbag Asus yang wajib diposting
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    “ASUS mengirim email kepada kami minggu lalu dan mengatakan ingin datang ke kantor minggu ini untuk melakukan ‘dialog terbuka’ tentang masalah ini. Kami bilang oke, tetapi menjawab bahwa percakapannya harus direkam. Toh mereka bilang ingin dialog terbuka. Setelah itu, selama 5 hari tidak ada jawaban. Jadi ASUS punya kesempatan untuk memperbaikinya. Kami menahan video ini karena ingin memberi mereka kesempatan itu. Namun begitu kami berkata, ‘baik, tetapi kami akan merekamnya agar janji yang dibuat terdokumentasi’, yang kembali adalah keheningan”

    • Tapi apakah memang ada produsen motherboard yang “pada dasarnya baik”? Atau apakah semua pemain besar punya cerita serupa?
      Saya bertanya untuk teman yang sebentar lagi akan merakit PC baru
    • Ini membuat marah, tetapi saya penasaran apa pembelaan terkuat yang paling masuk akal dari sudut pandang ASUS
      Yang mungkin paling sesuai dengan kenyataan adalah ini: mereka mengejar keuntungan, tetap bisa lolos begitu saja, tidak ada alasan untuk tercatat dan terlihat buruk, dan lebih baik memakai waktu itu untuk marketing

  • Tidak ada bug bounty itu tidak masuk akal. Ke depannya saya tidak akan membeli produk ASUS

    • Mungkin karena mereka “startup kecil”
    • Software dan dukungan pelanggan Asus mengerikan, dan memang selalu begitu