พบช่องโหว่ RCE แบบคลิกเดียวในซอฟต์แวร์ไดรเวอร์ที่ติดตั้งมากับเครื่องของ ASUS

 (mrbruh.com)
2 คะแนน โดย GN⁺ 2025-05-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พบ ช่องโหว่การรันโค้ดจากระยะไกล (RCE) แบบคลิกเดียว ในซอฟต์แวร์ DriverHub ของ ASUS
  • จากการ ตรวจสอบ origin ที่หละหลวม บนเครื่องโลคัล ทำให้เว็บไซต์อันตรายสามารถสั่ง รันด้วยสิทธิ์ผู้ดูแลระบบ ผ่าน RPC ได้
  • หากนำ เอ็นด์พอยต์ UpdateApp ไปใช้ในทางที่ผิด ก็สามารถรันโค้ดอันตรายได้ด้วยการจับคู่ไฟล์ปฏิบัติการที่มีลายเซ็นของ ASUS กับไฟล์ ini ที่ถูกดัดแปลง
  • ช่องโหว่นี้ถูกเปิดเผยในชื่อ CVE-2025-3462, CVE-2025-3463 และ ASUS ก็ปล่อยแพตช์ออกมาอย่างรวดเร็ว
  • ณ เวลาที่รายงานช่องโหว่ ยังไม่พบการนำไปใช้โจมตีจริง และ ASUS ตอบแทนด้วยการบันทึกชื่อในหอเกียรติยศแทน bug bounty

Introduction

  • เรื่องเริ่มจากการพูดคุยเกี่ยวกับการซื้อชิ้นส่วนพีซีใหม่
  • เมื่อซื้อเมนบอร์ด ASUS มา พบว่า ตัวเลือกติดตั้งซอฟต์แวร์อัตโนมัติจาก BIOS ถูกเปิดใช้งานเป็นค่าเริ่มต้น
  • เพราะเผลอไม่ได้ปิดตัวเลือกนี้ จึงเจอ คำขอสิทธิ์ติดตั้ง DriverHub หลังล็อกอินเข้า Windows
  • ด้วยความที่ต้องใช้ไดรเวอร์ WiFi และเกิดความสงสัย จึงลองติดตั้ง DriverHub

DriverHub

  • DriverHub เป็น โปรเซสเบื้องหลังที่ทำงานโดยไม่มี GUI
  • มันสื่อสารกับ driverhub.asus.com เพื่อบอกว่ามีไดรเวอร์ใดที่ต้องติดตั้งหรืออัปเดต
  • บนเครื่องโลคัล มันเปิดให้ใช้งาน HTTP API (พอร์ต 53000) เป็น RPC
  • เว็บไซต์สามารถส่งคำขอ API ไปยังบริการโลคัลนี้เพื่อจัดการไดรเวอร์ได้โดยตรง
  • จึงตระหนักว่า หากระบบความปลอดภัยไม่รัดกุม ผู้โจมตีก็อาจส่งคำขอใด ๆ ได้ตามใจ

Finding the Vulnerability

  • ได้ทดลองว่าเว็บไซต์สามารถส่งคำขอ RPC ตามอำเภอใจไปยังแบ็กเอนด์ของ DriverHub ได้หรือไม่
  • ระบบถูกออกแบบให้ตอบสนองเฉพาะเมื่อ Origin เป็น “driverhub.asus.com” เท่านั้น
  • จากนั้นตรวจสอบว่าการเช็ก Origin ใช้การ จับคู่แบบ wildcard ลักษณะ origin.includes("driverhub.asus.com") หรือไม่
  • เมื่อเปลี่ยน Origin เป็น “driverhub.asus.com.mrbruh.com” ก็พบว่า คำขอยังถูกอนุญาต
  • จึงยืนยันได้ว่านี่เป็น ความเสี่ยงร้ายแรง ที่ผู้โจมตีสามารถเรียก RPC จากเว็บไซต์อันตรายได้

The Extent of the Damage

  • จากการรีเวิร์สและวิเคราะห์ JavaScript ทำให้ทราบ รายการเอ็นด์พอยต์ API ที่ใช้ได้ในเบื้องหลัง
  • เอ็นด์พอยต์สำคัญได้แก่:
    • Initialize: คืนค่าสถานะการติดตั้งและข้อมูลต่าง ๆ
    • DeviceInfo: คืนค่าซอฟต์แวร์ ASUS, ไดรเวอร์, ฮาร์ดแวร์ และ MAC address ที่ติดตั้งอยู่
    • Reboot: สั่ง Reboot ทันที
    • Log: คืนค่าชุดไฟล์ล็อก
    • InstallApp: ติดตั้งแอปหรือไดรเวอร์ตาม ID ที่ระบุ
    • UpdateApp: ดาวน์โหลดแล้วรันไฟล์ปฏิบัติการจาก URL ที่ระบุ (หากมีลายเซ็น ASUS จะรันอัตโนมัติ)
  • โดยเฉพาะ UpdateApp ที่ถูกมองว่าน่าจะนำไปใช้โจมตีได้

Achieving RCE

  • มีการวิเคราะห์เอ็นด์พอยต์ UpdateApp อย่างละเอียด
  • พารามิเตอร์ “Url” มีเงื่อนไขว่าต้องมี .asus.com อยู่ แต่ก็มีช่องให้หลบเลี่ยงได้ และชื่อไฟล์จะอิงจากท้าย URL
  • แม้จะ รันอัตโนมัติเฉพาะไฟล์ปฏิบัติการที่มีลายเซ็นของ ASUS แต่ไฟล์ที่ไม่มีลายเซ็นก็ยังถูกดาวน์โหลดและไม่ถูกลบ
  • จึงพิจารณาความเป็นไปได้ของ การโจมตีเชิงจังหวะเวลา ที่สลับไฟล์ก่อนรันหลังผ่านการตรวจสอบลายเซ็น แต่พบว่าไม่ค่อยใช้งานได้จริง
  • ระหว่างวิเคราะห์โครงสร้างแพ็กเกจไดรเวอร์ WiFi ของ ASUS ก็พบว่าคุณสมบัติ SilentInstallRun ใน AsusSetup.ini สามารถใช้รันคำสั่งใดก็ได้
  • ห่วงโซ่การโจมตีสุดท้ายคือ:
    1. ผู้โจมตีล่อให้เป้าหมายเข้าเว็บซับโดเมนของ driverhub.asus.com. *
    2. เว็บไซต์ส่งคำขอ UpdateApp เพื่อให้ดาวน์โหลด calc.exe อันตราย (ดาวน์โหลดอย่างเดียว ยังไม่รัน)
    3. ส่งคำขอไฟล์ AsusSetup.ini แบบปรับแต่งเอง (SilentInstallRun=calc.exe เช่นกัน และยังไม่รัน)
    4. ส่งคำขอ AsusSetup.exe ที่มีลายเซ็น ซึ่งจะถูกรันอัตโนมัติด้วยสิทธิ์ผู้ดูแลระบบ และอ่านไฟล์ ini ด้วยแฟล็ก -s ก่อนสั่งรัน calc.exe
  • ผลลัพธ์คือเกิด การรันโค้ดตามอำเภอใจจากระยะไกลด้วยสิทธิ์ผู้ดูแลระบบ (RCE) แบบคลิกเดียว

Reporting Timeline (DD/MM/YYYY)

  • 07/04/2025: ค้นพบช่องโหว่ครั้งแรก
  • 08/04/2025: พิสูจน์ RCE และรายงานช่องโหว่
  • 09/04/2025: ได้รับการตอบกลับอัตโนมัติจาก ASUS
  • 17/04/2025: แพตช์ถูกปล่อยและได้รับบิลด์ที่แก้ไขแล้ว
  • 18/04/2025: ยืนยันว่าแพตช์ขึ้นใช้งานจริงแล้ว
  • 09/05/2025: เปิดเผย CVE-2025-3462 (8.4 คะแนน), CVE-2025-3463 (9.4 คะแนน)

Assessing the Damage

  • หลังรายงานช่องโหว่ทันที ได้เขียนสคริปต์ติดตาม certificate transparency
  • ใช้มันเฝ้าดูประวัติการออกใบรับรองของซับโดเมน driverhub.asus.com.*
  • จากการติดตามเป็นเวลา 1 เดือน เว็บไซต์ที่เข้าข่ายตามตัวกรองมีเพียงของผู้วิจัยเองที่ใช้ทดสอบ
  • จึงยืนยันได้ว่า ยังไม่มีร่องรอยว่าถูกนำไปใช้โจมตีก่อนหน้า

Bug Bounty

  • มีการสอบถาม ASUS ว่า มีการจ่าย bug bounty หรือไม่ แต่ถูกปฏิเสธ
  • สุดท้ายจึงได้รับการตอบแทนในรูปแบบ การบันทึกชื่อในหอเกียรติยศ (hall of fame)
  • มีการอธิบายเพิ่มเติมว่าแม้ ASUS จะเป็นบริษัทใหญ่ แต่ก็ยังไม่มีนโยบาย bounty ที่ดีพอ

Fun Notes

  • ตอน ส่งฟอร์ม Security Advisory ของ ASUS นั้น PoC ถูก Amazon CloudFront บล็อกในฐานะคำขออันตราย
  • เมื่อกด “Install All” ใน DriverHub จะมีการติดตั้งซอฟต์แวร์อื่นเพิ่มเติมแบบบังคับด้วย (เช่น Norton360, WinRAR)
  • คำอธิบาย CVE คลุมเครือและไม่ตรงกับข้อเท็จจริง จนอาจทำให้เข้าใจผิดว่า 'ไม่กระทบเดสก์ท็อป/โน้ตบุ๊ก' (แต่ความจริงคือกระทบทุกอุปกรณ์ที่ติดตั้ง DriverHub)
  • WiFi ก็ยังใช้ไม่ได้อยู่ดี จนต้องซื้ออะแดปเตอร์ USB WiFi ภายนอก
  • ช่องทางติดต่อคือ Signal: paul19.84, อีเมล contact [at] mrbruh.com

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-12
ความคิดเห็นจาก Hacker News
  • ผลลัพธ์ของ Responsible Disclosure ให้ความรู้สึกเหมือนหายนะต่อมวลมนุษยชาติ บริษัทต่าง ๆ จำเป็นต้องเจ็บตัวให้บ่อยขึ้นและหนักขึ้นกว่านี้ถึงจะเริ่มจริงจังกับความปลอดภัยของลูกค้า ถ้าคุณพบปัญหาแล้วบอกวิธีแก้ให้เวลาแก้หนึ่งเดือน สำหรับบริษัทมันก็เป็นแค่ตั๋วงานใน backlog ใบหนึ่ง แต่ถ้ากลายเป็นข่าวออนไลน์จนถึงขั้น CEO ต้องออกหน้า พวกเขาก็จะหาทางแก้ได้ภายในไม่กี่ชั่วโมง แน่นอนว่าคนที่เสียหายที่สุดสุดท้ายก็คือผู้ใช้ แต่เอาจริง ๆ แค่ซื้อ ASUS พวกเขาก็ทุกข์พออยู่แล้ว
    • การรับมือของ ASUS ครั้งนี้ถือว่าค่อนข้างเร็ว ไม่ได้ปฏิเสธปัญหา ไม่ได้ฟ้องคนที่ทำ reverse engineering และก็ออกแพตช์ทันที ในอดีตเรื่องแบบนี้อาจกินเวลาหลายเดือนหรือถึงขั้นมีตำรวจเข้ามาเกี่ยวข้อง คนทั่วไปก็ไม่ได้สนใจช่องโหว่อะไรอยู่แล้ว ในโลกที่ผู้คนยังทำธุรกรรมการเงินบนมือถือที่ไม่ได้อัปเดตมา 3 ปี ต่อให้สื่อพูดถึงประเด็น CVE จนเต็มหน้าข่าว คนส่วนใหญ่ก็แค่ชินชาไปเท่านั้น ในยุโรปมีกฎใหม่ที่ห้ามขายสินค้าที่มีช่องโหว่ที่ทราบอยู่แล้ว เพราะงั้นถ้า ASUS ยังเป็นแบบนี้ต่อไป เมนบอร์ดก็คงกองค้างสต็อกจนตัวแทนจำหน่ายไม่อยากขาย เรื่องนี้ใช้กับเครื่องใช้ไฟฟ้าด้วย เช่น ถ้าเครื่องล้างจานมีช่องโหว่ อุตสาหกรรมนั้นก็อาจเสียหายหนักได้
    • ชื่อว่า "Responsible" Disclosure แต่กลับเป็นพฤติกรรมที่ไร้ความรับผิดชอบอย่างยิ่ง บริษัทส่วนใหญ่ไม่แพตช์ภายในหนึ่งสัปดาห์ ไม่ให้เครดิตผู้รายงาน ไม่แจ้งผู้ใช้ และไม่เรียนรู้จากความผิดพลาด การเปิดเผยแบบช้า ๆ และจำกัดกลับยิ่งส่งเสริมพฤติกรรมแบบนี้ สิ่งที่รับผิดชอบจริง ๆ คือเปิดเผยทันที อย่างครบถ้วน และต่อสาธารณะ และถ้ามีความเชื่อมั่นสะสมว่าบริษัทตอบสนองอย่างเหมาะสม ก็ค่อยพิจารณาแจ้งล่วงหน้าราว 5 วันทำการ การเรียกการเปิดเผยแบบช้าและไม่ครบว่า "responsible disclosure" ก็เป็นแค่การเล่นคำเท่านั้น
    • ต้นตอของปัญหาคือการไม่มีบทกฎหมายเรื่องความรับผิดชอบต่อผลิตภัณฑ์ ผู้ผลิตรถยนต์มีภาระต้องเรียกคืนสินค้า แต่บริษัทซอฟต์แวร์/ฮาร์ดแวร์แทบไม่ถูกกดดันเลย ผมคิดว่าลูกค้าควรมีสิทธิ์ขอคืนเงินเต็มจำนวนสำหรับสินค้าที่มีช่องโหว่ (CVE) ที่ยังไม่ได้รับการแก้ไข
    • ขออ้างคำพูดของ CGPGrey ว่าวิธีแก้ที่ผุดขึ้นมาเป็นอย่างแรกมักจะแย่และไม่ได้ผล วัฒนธรรมด้านความปลอดภัยที่ดีควรส่งเสริมไม่ให้ซ่อนปัญหาภายใน บริษัทต่าง ๆ โลภจนปกปิดปัญหาด้านความปลอดภัยหมด หากเปิดเผยทันทีตั้งแต่พบ ปัญหาที่จริง ๆ แล้วแก้ได้ภายในเดือนเดียวก็จะถูกเปิดให้ทุกคนเห็นและเพิ่มโอกาสถูกนำไปใช้โจมตีอย่างมาก
    • มีไอเดียธุรกิจหนึ่ง ซึ่งอาจมีอยู่แล้วก็ได้ เป็นแพลตฟอร์มเปิดเผย/ตัวกลางที่คุ้มครองความเป็นส่วนตัวของผู้รายงาน ตรวจสอบว่าช่องโหว่สามารถนำไปใช้ได้จริงหรือไม่ ประกาศต่อสาธารณะตามกำหนดเวลาแน่นอน และให้บริษัทสมัครรับฟีดล่วงหน้าสำหรับสิ่งที่กระทบตนเองโดยจ่ายเงิน เงินนั้นก็นำไปใช้เป็นรางวัลให้ผู้รายงาน ค่าใช้จ่ายในการดำเนินงาน และการแบ่งกำไร โมเดลนี้คล้าย bug bounty marketplace แต่จากมุมมองบริษัทจะออกแนวเป็นปฏิปักษ์อยู่หน่อย สงสัยว่าแบบนี้ถูกกฎหมายไหม หรือจะถูกมองว่าเป็นการขู่กรรโชก
    • ขอย้ำอีกครั้งว่าควรมีความรับผิดทางกฎหมายต่อข้อบกพร่องของสินค้าเหมือนอุตสาหกรรมอื่น คนส่วนใหญ่ไม่ยอมรับของเสียหายนอกจากเพราะมันราคาถูก และไม่มีเหตุผลที่ซอฟต์แวร์ควรเป็นข้อยกเว้น
    • ถ้าเปิดเผยช่องโหว่ตั้งแต่วันถัดไปเลย นั่นแหละคือแรงจูงใจที่แท้จริง ความอับอายขายหน้าก็ช่วยให้ความปลอดภัยครั้งต่อไปดีขึ้นได้เช่นกัน
    • การพูดโอเวอร์แบบ "หายนะต่อมวลมนุษยชาติ" เป็นตัวอย่างชัดเจนของการทำให้ประเด็นเสีย
  • พอถาม ASUS ว่ามี bug bounty ไหม คำตอบคือแทนที่จะให้รางวัล จะเอาชื่อผมไปขึ้น Hall of Fame ให้ ฟังแล้วขม ๆ เหมือนกำลังล้อว่า ASUS เป็นแค่สตาร์ตอัปเล็ก ๆ เลยไม่มีทุนพอจ่าย bounty
    • บริษัทเล็ก ๆ อย่าง Cisco ก็ทำคล้ายกัน คือไม่ให้รางวัลอะไร แค่เอาชื่อไปขึ้นไว้เท่านั้น แถม Cisco ยังลืมหน้า security advisory ของตัวเองอีก เลยหมดโอกาสได้รับการยอมรับไปด้วย
    • ถ้าไม่มี bug bounty ก็เหลือแค่ทางเลือกว่าจะขาย exploit ให้ตลาดมืด หรือไม่ก็เปิดเผยทั้งหมดไปเลย
    • สถานการณ์แบบนี้ทำให้ไม่อยากซื้อสินค้า ASUS อีกเลย
  • คุณภาพซอฟต์แวร์ของ ASUS ก็ไม่ดี และยังเป็นบริษัทที่มีปัญหาด้านความปลอดภัยอยู่เรื่อย ๆ ก่อนหน้านี้ก็เคยมีประเด็นมัลแวร์ UEFI บนเมนบอร์ด และยังชอบติดตั้งซอฟต์แวร์ไม่จำเป็นมาให้ตั้งแต่แรกจนลบออกก็ยังน่ารำคาญ มีกรณีร้องเรียนเยอะพอควรให้อ้างอิงได้
    • นี่ไม่ใช่ครั้งแรก ก่อนหน้านี้ก็เคยมีกรณีคล้ายกัน และผมก็เก็บบันทึกไว้ในบล็อกเก่าของตัวเองด้วย
  • เขาบอกว่าไม่มีการนำไปใช้โจมตีเพราะมีแค่โดเมนทดสอบของตัวเองเท่านั้นที่ตรงตามเงื่อนไข (driverhub.asus.com.*) แต่จะเป็นจริงก็ต่อเมื่อไม่มีใครจดทะเบียนเฉพาะซับโดเมนของ driverhub ไว้ต่างหาก ถ้าใช้ wildcard ก็อาจไม่แสดงใน certificate transparency log และยังถูกนำไปใช้โจมตีได้
    • wildcard certificate ครอบคลุมแค่ซับโดเมนชั้นเดียว เช่น *.example.com ใช้ได้กับ test.example.com เท่านั้น แต่ใช้กับ test.test.example.com ไม่ได้ ถ้ามีใครใช้ wildcard *.asus.com.example.com ก็จะทำให้ driverhub.asus.com.example.com กลายเป็นชื่อที่ใช้ได้
    • บอกว่าเป็นไอเดียที่ดีเลยไปเช็กทันที และตอนนี้ยังไม่พบอะไรน่าสงสัยใน wildcard certificate
    • ประเด็น blind spot ของ wildcard certificate เป็นข้อสังเกตที่ถูกต้อง ถ้าผู้โจมตีมี wildcard certificate สำหรับ .example.com จริง ก็อาจใช้โจมตีผ่านที่อื่นที่ไม่ใช่ driverhub.asus.com ได้จริง เพราะเหตุนี้การเฝ้าดู CT log อย่างเดียวจึงจับช่องโหว่ประเภท subdomain takeover แบบนี้ได้ไม่สมบูรณ์
  • ส่วนที่ ASUS ตอบเรื่อง bug bounty ว่า "เราเป็นสตาร์ตอัปเล็ก ๆ เลยไม่มี bounty แต่จะเอาชื่อคุณขึ้น Hall of Fame ให้" นั้นชวนสะดุดใจ เพราะความจริงเป็นบริษัทยักษ์ใหญ่ที่มีมูลค่าตลาดเกิน 15B
    • มีคนแนะนำ sarcasm.com แบบประชดประชัน
  • พอ Wi‑Fi บนบอร์ดใช้ไม่ได้เลยไปใช้ USB Wi‑Fi ภายนอก แต่สุดท้ายก็ไม่มีประโยชน์เพราะ DriverHub อยู่ดี บอกว่าเป็นโซลูชันแต่กลับน่าผิดหวัง
    • ตัวบทความบล็อกอ่านสนุกดี
    • ไดรเวอร์ Wi‑Fi เวอร์ชันล่าสุดใช้งานไม่ได้ เลยต้องกลับไปใช้เวอร์ชันเก่า
  • ASUS เป็นบริษัทใหญ่ที่มีมูลค่าตลาดถึง 15 พันล้านดอลลาร์ แต่กลับไม่ให้ค่าตอบแทนอย่างเหมาะสม และยังมองข้ามความพยายามของทั้งลูกค้าและนักวิจัย เห็นการปฏิบัติแบบนี้แล้วก็เข้าใจได้ว่านักวิจัยจะรู้สึกคับข้องใจแค่ไหน สรุปคือทางเลือกที่ดีที่สุดคืออย่าซื้อสินค้า ASUS
  • ตอนส่ง bug report ไฟล์ PoC กลับถูก Amazon CloudFront มองว่าเป็นคำขออันตรายจนบล็อกการส่งไปเลย WAF (Web Application Firewall) แบบนี้กลับกลายเป็นรูปแบบหรือกรณีศึกษาที่ไม่ดีเสียมากกว่า
  • เห็นด้วยกับคำบ่นเรื่อง Wi‑Fi บนบอร์ด จริง ๆ แค่ดูรุ่นชิปเซ็ตแล้วไปดาวน์โหลดแยกจากที่อย่าง station-drivers ก็ใช้เวลาไม่กี่วินาที ความยุ่งยากแบบนี้นี่แหละที่ทำให้ไม่ชอบ ASUS โดยเฉพาะตัวเลือกใน BIOS ที่ไปโต้ตอบกับระบบปฏิบัติการโดยตรง
  • ผมชอบสินค้าของ ASUS แต่จะปิดแอปซัพพอร์ตที่ติดตั้งมากับ UEFI เสมอ แต่ก่อนมันถึงขั้นติดตั้ง ROG Armory Crate เวอร์ชันเต็ม ทำให้การลบออกยุ่งยาก หลัง ASUS รับช่วงธุรกิจ NUC จาก Intel ก็ยังคงอัปเดต BIOS ต่อ แต่มีแอปติดตั้งอย่าง MyASUS ถูกเพิ่มมาเป็นค่าเริ่มต้น โชคดีที่มีตัวเลือกให้ปิด และถ้าอัปเดตจาก BIOS ของ Intel NUC ดูเหมือนว่าจะปิดไว้เป็นค่าเริ่มต้นอยู่แล้ว