ASUS ön yüklü sürücü yazılımında tek tıkla RCE açığı

 (mrbruh.com)
2 puan yazan GN⁺ 2025-05-12 | 1 yorum | WhatsApp'ta paylaş
  • Windows oturum açıldıktan hemen sonra kurulabilen ASUS DriverHub, web sitesi ile yerel hizmeti bağlama şekli nedeniyle, kullanıcının yalnızca belirli bir web sitesini ziyaret etmesiyle yönetici yetkileriyle kod çalıştırmaya kadar gidebiliyordu
  • DriverHub, GUI olmadan arka planda çalışıyor ve driverhub.asus.com adresi 127.0.0.1:53000 üzerindeki yerel HTTP/WebSocket hizmetine istek gönderiyordu; ayrıca Origin kontrolü driverhub.asus.com.* biçimindeki alan adlarını kabul ediyordu
  • UpdateApp uç noktası, URL içinde yalnızca .asus.com dizesi geçiyorsa dosya indiriyordu; ASUS imzalı yürütülebilir dosyaları yönetici yetkileriyle çalıştırırken imza doğrulamasında başarısız olan dosyaları silmiyordu
  • Nihai exploit, imzasız calc.exe, manipüle edilmiş AsusSetup.ini ve imzalı AsusSetup.exe dosyalarını sırayla indirtip ardından SilentInstallRun=calc.exe ile yönetici yetkili RCE elde ediyordu
  • ASUS, Nisan 2025'te düzeltmeyi dağıttığını doğruladı; 9 Mayıs 2025'te CVE-2025-3462 ve CVE-2025-3463 yayımlandı; sertifika şeffaflığı günlüklerine göre kamuya açıklanmadan önce aktif kötüye kullanım izine rastlanmadı

Web sitesine bağlı DriverHub yerel RPC

  • ASUS anakart satın alındıktan sonra, Windows'ta oturum açılır açılmaz ASUS DriverHub kurulumunu tamamlamak için yönetici yetkisi isteyen bir bildirim gösteriliyor
  • DriverHub, ayrı bir GUI yerine arka plan süreci olarak çalışıyor ve driverhub.asus.com gerekli sürücüleri ve güncellenecek bileşenleri gösteriyor
  • Web sitesi, yerelde çalışan DriverHub süreciyle RPC üzerinden iletişim kuruyor
    • Yerel hizmet, 127.0.0.1 üzerindeki sabit 53000 portunda çalışıyor
    • Web sitesi veya hizmet bu yerel porta API istekleri gönderiyor
  • Bu yapıda RPC koruması yeterli değilse, saldırganlar bunu kötü amaçlı uygulama kurulumunda kötüye kullanabiliyor

Gevşek Origin kontrolünün aşılması

  • DriverHub, her web sitesinden gelen isteği kabul etmiyor; Origin başlığı driverhub.asus.com olan isteklere yanıt verecek şekilde tasarlanmıştı
  • Sorun, kontrolün tam eşleşme yerine dize içerme ya da wildcard'a yakın bir yöntemle yapılmasıydı
    • origin == driverhub.asus.com gibi doğrudan bir karşılaştırma yapılmıyordu
    • driverhub.asus.com.mrbruh.com değerini Origin olarak ayarlayınca istek kabul edildi
  • Saldırganlar bu davranışı kullanarak driverhub.asus.com.* biçimindeki alan adlarından yerel DriverHub RPC'sine erişebiliyordu

Açığa çıkan RPC uç noktaları

  • Web sitesi JavaScript'i ve yürütülebilir dosya decompilation'ı üzerinden birden fazla RPC uç noktası tespit edildi
  • Başlıca uç noktalar şunlardı
    • Initialize: Yazılımın kurulu olup olmadığını ve temel kurulum bilgilerini döndürüyor
    • DeviceInfo: Kurulu ASUS yazılımlarını, kurulu .sys sürücülerini, donanım bileşenlerini ve MAC adresini döndürüyor
    • Reboot: Onay almadan hedef cihazı anında yeniden başlatıyor
    • Log: DriverHub günlüklerinin tamamının sıkıştırılmış kopyasını döndürüyor
    • InstallApp: Uygulama veya sürücü ID'siyle kurulum yapıyor; uygulama ID'leri DriverHub yükleyicisinin sağladığı XML dosyasına hardcode edilmiş durumda
    • UpdateApp: Verilen dosya URL'sini indirip çalıştırarak DriverHub'ı kendi kendine güncelliyor

UpdateApp'in RCE koşullarını oluşturma biçimi

  • UpdateApp isteği şu şekilde çalışıyor
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • UpdateApp için gözlenen davranışlar, RCE zinciri için gereken birkaç koşulu bir arada sağlıyordu
    • Url parametresinde .asus.com dizesi bulunmalıydı, ancak example.com/payload.exe?foo=.asus.com gibi biçimler de kabul ediliyordu
    • Dosya, URL'nin sonunda belirtilen dosya adıyla kaydediliyordu
    • Uzantıdan bağımsız olarak dosya indirilebiliyordu
    • Dosya ASUS imzalı bir yürütülebilir dosyaysa yönetici yetkileriyle otomatik çalıştırılıyordu
    • ASUS tarafından imzalanmışsa, DriverHub yükleyicisi olmasa bile yürütülebiliyordu
    • İndirilen dosya imza kontrolünden geçmese bile silinmiyordu
  • Başta imza doğrulaması nedeniyle RCE zor görünse de, imza doğrulamasında başarısız olan dosyanın yerinde kalması ile ASUS imzalı yürütülebilir dosyaların kurulum davranışı birleşince bir bypass yolu ortaya çıktı

AsusSetup.ini kullanılan exploit zinciri

  • ASUS WiFi sürücü paketinde AsusSetup.exe, AsusSetup.ini ve SilentInstall.cmd bulunuyordu
  • AsusSetup.exe, çalışırken AsusSetup.ini içinden sürücü metadata'sını okuyordu
  • AsusSetup.exe, -s bayrağıyla çalıştırıldığında GUI olmadan sessiz kurulum yapıyor ve AsusSetup.ini içindeki SilentInstallRun alanında belirtilen öğeyi çalıştırıyordu
    • DriverHub, sessiz kurulum için -s bayrağını kullanıyordu
    • Orijinal INI dosyası, otomatik katılımsız kurulum için bir cmd betiği belirtiyordu
    • SilentInstallRun içinde başka bir yürütülebilir dosya da belirtilebiliyordu

  • Tam saldırı sırası

    • Kullanıcı, alan adı driverhub.asus.com.* biçiminde olan bir web sitesini ziyaret ediyor
    • Site, UpdateApp ile PoC yürütülebilir dosyası calc.exeyi istiyor
    • calc.exe indiriliyor ancak imza kontrolünde başarısız olduğu için çalıştırılmıyor
    • Dosya silinmeden yerinde kalıyor
    • Site, UpdateApp ile manipüle edilmiş AsusSetup.ini dosyasını istiyor
    • Bu dosya da indiriliyor ancak çalıştırılmıyor
    [InstallInfo]
SilentInstallPath=.\\
SilentInstallRun=calc.exe
    • Site, UpdateApp ile ASUS imzalı ikili AsusSetup.exeyi istiyor
    • AsusSetup.exe, indirildikten sonra yönetici yetkileriyle çalıştırılıyor
    • DriverHub bunu -s ile çalıştırdığı için AsusSetup.ini dosyasını okuyor
    • SilentInstallRun=calc.exe nedeniyle calc.exe yönetici yetkileriyle çalışıyor

Bildirimden CVE yayımlanmasına kadar

  • Açığın ele alınma takvimi şöyleydi
    • 2025-04-07: İlk açık keşfedildi
    • 2025-04-08: RCE'ye genişlediği doğrulandı
    • 2025-04-08: Açık ASUS'a bildirildi
    • 2025-04-09: ASUS'tan otomatik yanıt alındı
    • 2025-04-17: Takip iletişiminin ardından ASUS, yamanın tamamlandığını ve doğrulama için build'i iletti
    • 2025-04-18: ASUS, düzeltmenin dağıtıldığını doğruladı
    • 2025-05-09: CVE-2025-3462 için 8.4 ve CVE-2025-3463 için 9.4 puanı yayımlandı

Kötüye kullanım olasılığı ve gözlenen izler

  • Bildirimin hemen ardından VPS üzerinde certificate transparency güncellemelerini izleyen bir betik çalıştırılarak driverhub.asus.com.* alan adı kaydı olup olmadığı kontrol edildi
  • Diğer sertifika şeffaflığı günlük sitelerine göre alan adları ve alt alan adları genelde bir ay içinde kayıtlarda görünüyordu
  • Bir ay sonra yapılan kontrolde, regex ile eşleşen tek sitenin test alan adı olduğu görüldü
  • Bu ölçüte göre, bildirim öncesinde aktif kötüye kullanım olasılığı düşük görünüyordu

ASUS'un yanıtı ve kalan sorunlar

  • ASUS, bug bounty sunmuyor; bunun yerine hall of fame sayfasına isim eklemeyi teklif etti
  • Daha sonra başka bir güvenlik araştırmacısı olan leonjza'nın aynı Origin kontrolü sorununu Şubat 2025'te zaten bildirdiği ve ASUS'un bunu bu düzeltme sırasında giderdiği ortaya çıktı
    • ASUS bu durumu ayrıca bildirmedi
    • cve.org sayfasında kredide yalnızca ilgili araştırmacının adı yer aldı ve ek kredi verilmeyeceği belirtildi
  • ASUS Security Advisory form üzerinden açık raporu gönderilirken, Amazon CloudFront ekli PoC'yi kötü amaçlı istek olarak algılayıp gönderimi engelledi
    • Bazı PoC kodları çıkarılmak ve bunun yerine kayıt videosu bağlantısı gönderilmek zorunda kalındı
  • DriverHub'da önerilen sürücüler tek tek kurulmak yerine “Install All” seçildiğinde ArmouryCrate, ASUS'un özelleştirilmiş CPU-Z sürümü, Norton360 ve WinRAR da birlikte kuruluyor
  • ASUS'un CVE açıklaması, RCE kapsamını ve etkisini olduğundan daha dar ifade ediyor
    • Açıklamada, “yalnızca motherboards etkilenir, laptops ve desktop computers etkilenmez” anlamına gelen bir ifade yer alıyordu
    • Gerçekte, DriverHub kurulu masaüstü ve dizüstü bilgisayarlar dahil tüm sistemler etkileniyor
    • İfade, keyfi veya uzaktan kod çalıştırma yerine “untrusted sources sistem davranışını etkileyebilir” tarzında kurulmuştu

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-12
Hacker News görüşleri

  • Sorumlu açıklama ve sonuçları insanlık için neredeyse felaket oldu. Şirketlerin müşteri güvenliğini daha ciddiye alması için çok daha sık ve çok daha büyük acı hissetmeleri gerekiyor
    Bir ay verip çözümü de ağızlarına kaşıkla verirseniz bu sadece backlog’da bir ticket’a dönüşür. Her güvenlik sorunu patladığında internette yeterince büyük haber olup CEO’nun bile devreye girmesini ve aylar değil saatler içinde çözüm bulmalarını gerektirse, çok daha proaktif davranırlar. Elbette en büyük zararı son kullanıcı görür, ama ASUS satın aldığı noktada zaten acı çekmeye başlamış da olur

    • Bu kez ASUS’un yanıt hızı gayet iyiydi ve burada büyük bir sorun görmüyorum. ASUS hatayı inkâr etmedi, yazılım tersine mühendisliği nedeniyle dava açmakla tehdit etmedi ve hızlıca yama yayımladı
      Sorumlu açıklama öncesi dönemde olsaydık bu süreç aylar sürer, polis bile işin içine girebilirdi. Sıradan kullanıcılar zafiyetlerle ilgilenmez; üç yıldır güncelleme almayan telefonlarıyla bankacılık işlemleri yapar. Haberlerde sürekli CVE yağdırırsanız, “tüm şirketler berbat” söyleminden bıkıp gerçek bir tehdit geldiğinde bile duyarsızlaşırlar
      AB başka bir çözüm üzerinde ilerliyor. Yeni siber güvenlik düzenlemesi kapsamında, bilinen zafiyetleri olan ürünler mağazalarda satılamayacak. ASUS sürekli çuvallarsa anakartları elde kalmış stok hâline gelir ve mağazalar da ASUS donanımı satmak istemez. Bu yalnızca bilgisayar donanımı için değil, akıllı buzdolapları ve çamaşır makineleri için de geçerli. Bir bulaşık makinesi zafiyeti bulursanız ve üretici firmware güncelleme yolu koymamışsa, sektörde milyonlarca dolarlık kullanılamaz stok yaratabilirsiniz
    • “Sorumlu açıklama” adı ironik. Çünkü gerçekte tamamen sorumsuz bir yönteme yakın
      Şirketlerin büyük çoğunluğu açıklama süreçlerini berbat yönetiyor. Zamanında, örneğin bir hafta içinde düzeltmiyorlar; emeği doğru düzgün belirtmiyorlar; kullanıcılara haber vermiyorlar; hatalarından ders çıkarmıyorlar. Sorumsuzca geciktirilmiş sınırlı açıklama bu davranışı pekiştiriyor
      Gerçekten sorumlu yöntem, derhâl, eksiksiz ve kamuya açık biçimde açıklamaktır. Gerekirse kendinizi korumak için anonim yapılabilir. Etkilenen şirket, tekrar tekrar doğru şekilde yanıt verdiğini kanıtladıktan sonra ancak örneğin 5 iş günü gibi çok kısa bir ön bildirim hakkı kazanabilir
      Bu tür sorumsuz gecikmeli sınırlı açıklamanın “sorumlu açıklama” diye adlandırılması başlı başına bir Newspeak örneği
    • Meselenin özü sorumluluğun yasalaştırılması. Otomobil üreticilerine geri çağırma ve onarım emri veriliyor, ama yazılım/donanım şirketlerinin üzerindeki baskı çok zayıf
      Müşteriler, örneğin düzeltilmemiş bir CVE’si olan arızalı cihaz için tam para iadesi alabilmeli
    • CGPGrey’den alıntılarsak, akla ilk gelen çözümler genelde korkunçtur ve işe yaramaz
      İyi bir güvenlik ve emniyet kültürü, katılımcıları sorunları saklamamaya teşvik eder. Şirketler açgözlü yapılardır; güvenlik hatalarını gizlemek için ellerinden geleni yaparlar
      Bir ay içinde düzeltilebilecek meşru ve düzeltilebilir bir sorunu herkese açıklarsanız, istismar edilme olasılığı da ciddi biçimde artar
    • Böyle bir iş fikri olabilir. Belki zaten vardır: Bir açıklama aracılığı ve toplama servisi kurmak
      Bildiren kişinin gizliliğini korur, güvenlik zafiyetlerini doğrular ve yayımladığı tüm zafiyetlerin gerçekten istismar edilebilir olduğundan emin olur. Belirli aralıklarla yayımlar; şirketlerden ise kendilerini etkileyen açıklamaları önceden aldıkları bir “erken feed” için abonelik ücreti alır. Bu parayla bildirenlere ödül verilir, operasyon giderleri karşılanır ve bir miktar kâr bırakılır
      Yani şirketlere biraz düşmanca yaklaşan bir bug bounty pazarı. Bunun yasal olup olmayacağını, yoksa şantaj sayılıp sayılmayacağını merak ediyorum

  • ASUS’a bug bounty programı olup olmadığı sorulduğunda olmadığını söyleyip bunun yerine “şeref listesine” adını ekleyebileceklerini belirtmeleri acı bir ayrıntı
    ASUS küçük bir startup olduğu için bounty verecek sermayesi olmamasını anlayabiliriz, diye yapılan bir iğneleme bu

    • Cisco gibi küçük bir şirket için de anlaşılır bir şey. Cisco da yıllar boyunca satın aldığı sayısız çevrimiçi hizmet için benzerini yaptı
      Cisco daha da ileri gidip güvenlik duyuruları sayfasını bile unuttu; böylece verilen tüm takdirler artık boşluğa karıştı
    • Bug bounty yoksa exploit ya karaborsaya gider ya da tam açıklamaya
    • Bu tür bir yanıtı görünce bir daha ASUS ürünü almak istemiyorum
    • “Asus küçük bir startup” ifadesinin nereden çıktığını bilmiyorum. Asus en azından 90’lardan beri anakart ve PC bileşenleri üretiyor

  • Şaşırtıcı değil. ASUS yazılımları berbat ve güvenlik açısından da önlem almada yetersiz, neredeyse müzmin sorunlu bir şirket
    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...

  • Sertifika Şeffaflığı günlüklerine bakıp driverhub.asus.com.* ile eşleşen tek alan adının kendi test alan adları olduğu için, bildirimden önce aktif olarak istismar edilmemiş olma ihtimalinin yüksek olduğu sonucuna varılan kısım yalnızca wildcard sertifika yoksa geçerli
    Wildcard'a sahip biri, Sertifika Şeffaflığı'nda görünmeden de bunu istismar edebilirdi

    • Wildcard sertifikalar yalnızca tek bir etiket seviyesine uygulanır. *.example.com. test.test.example.com. için geçerli olmaz, test.example.com. için geçerli olur
      Biri *.asus.com.example.com. için wildcard sertifika almış olsaydı, driverhub.asus.com.example.com. altında bir web sunucusu çalıştırıp geçerli gibi gösterebilirdi
    • İyi fikir, şimdi kontrol ettim ve wildcard kayıtlarında şüpheli bir şey olmadığını doğruladım
    • Wildcard sertifika kör noktası gerçekten var. Saldırganın .example.com için wildcard sertifikası olsaydı, Sertifika Şeffaflığı günlüklerinde driverhub.asus.com. alan adı özel olarak görünmeden bunu istismar edebilirdi
      Bu yüzden yalnızca Sertifika Şeffaflığı günlüklerini izlemek, bu tür alt alan adı ele geçirme zafiyetlerini tespit etmek için yeterli değil
    • Ek olarak, kendinden imzalı sertifikaların da çalışıp çalışmayacağını merak ediyorum. Bu tür sertifikalar şeffaflık günlüklerine girmez
      Ayrıca illa HTTPS gerekip gerekmediği de soru işareti

  • Sonucun “yerleşik WiFi'ım hâlâ çalışmıyor ve harici USB WiFi adaptörü almak zorunda kaldım. Teşekkürler DriverHub” olması, tüm bu sürecin kelimenin tam anlamıyla boşa kürek çekmek olduğunu gösteriyor

    • Blog yazısının kendisi iyiydi
    • En yeni WiFi sürücüsü çalışmadığı için önceki sürümü kullanmak gerekiyor

  • ASUS güvenlik bildirim formuna zafiyet raporu gönderirken Amazon CloudFront'un ekli PoC'yi kötü amaçlı istek sayıp engellediği kısım, web uygulaması güvenlik duvarının bir antipattern olduğuna dair bir bildirim gibi: https://thedailywtf.com/articles/Injection_Rejection

  • “ASUS küçük bir startup, anlaşılır” deniyor; sonuçta piyasa değeri yalnızca 15 milyar dolar olan küçük bir startup
    Asıl anlaşılması zor olan, sadece berbat ürünler değil, müşterileri için inanılmaz bir iş yapan araştırmacıya da böyle davranmaları
    Böyle işler yapıp da yok sayılan ya da küçümsenen araştırmacılar için üzülüyorum. Çok adaletsiz
    Yapılabilecek tek şey ASUS ürünleri satın almamak

  • ASUS'a bug bounty programı olup olmadığı sorulmuş; ASUS olmadığını, ama bunun yerine adını “Onur Listesi”ne ekleyeceklerini söylemiş. ASUS küçük bir startup olduğu için bounty verecek sermayesi yoktur herhâlde, anlaşılır, şeklinde bir iğneleme
    [1]: https://companiesmarketcap.com/asus/marketcap/

    • Ya da sarcasm.com da olabilir ;)

  • Zorunlu Scumbag Asus video bağlantısı
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    “ASUS geçen hafta bize e-posta gönderip bu hafta ofise gelerek sorun hakkında ‘açık bir diyalog’ yapmak istediklerini söyledi. Biz de olur dedik, ama görüşmenin kayda alınması gerektiğini belirttik. Sonuçta açık bir diyalog istediklerini söylemişlerdi. Sonraki 5 gün boyunca yanıt gelmedi. Yani ASUS'un bunu düzeltme fırsatı vardı. Biz de onlara bu fırsatı vermek için videoyu bekletiyorduk. Ama ‘tamam, ancak taahhüt ettiğiniz şeylerin kayıtlara geçmesi için bunu çekeceğim’ dediğimiz anda sessizlik oldu”

    • Yine de “temelde düzgün” bir anakart üreticisi var mı? Yoksa büyük üreticilerin hepsi için benzer hikâyeler mi var?
      Yakında yeni bir PC toplayacak bir arkadaşım için soruyorum
    • Bu insanı öfkelendiriyor; ASUS'un tarafını en makul ve güçlü şekilde savunmak gerekse bunun ne olacağını merak ediyorum
      Gerçeğe daha yakın olan muhtemelen şu: Kâr peşindeler ve yine de bunun yanlarına kalacağını düşünüyorlar; kayda geçip kötü görünmek için bir nedenleri yok, o zamanı pazarlamaya ayırmak daha iyi

  • Bug bounty olmaması saçmalık. Bundan sonra ASUS ürünü almayacağım

    • “Küçük startup” oldukları içindir herhâlde
    • Asus yazılımı ve müşteri desteği korkunç, her zaman da öyleydi