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

 (mrbruh.com)
2 คะแนน โดย GN⁺ 2025-05-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ASUS DriverHub ซึ่งอาจถูกติดตั้งทันทีหลังล็อกอินเข้า Windows มีวิธีเชื่อมเว็บไซต์กับบริการในเครื่องที่ทำให้เพียงผู้ใช้เข้าชมเว็บไซต์บางแห่ง ก็อาจนำไปสู่การรันโค้ดด้วยสิทธิ์ผู้ดูแลระบบได้
  • DriverHub ทำงานอยู่เบื้องหลังโดยไม่มี GUI และมีโครงสร้างที่ให้ driverhub.asus.com ส่งคำขอไปยังบริการ HTTP/WebSocket ในเครื่องที่ 127.0.0.1:53000 โดยการตรวจสอบ Origin อนุญาตโดเมนในรูปแบบ driverhub.asus.com.*
  • เอนด์พอยต์ UpdateApp ดาวน์โหลดไฟล์หาก URL มีสตริง .asus.com อยู่ และจะรันไฟล์ปฏิบัติการที่มีลายเซ็นของ ASUS ด้วยสิทธิ์ผู้ดูแลระบบ ขณะที่ไฟล์ที่ตรวจสอบลายเซ็นไม่ผ่านจะ ไม่ถูกลบ
  • เอ็กซ์พลอยต์สุดท้ายทำให้ดาวน์โหลด calc.exe ที่ไม่มีลายเซ็น, AsusSetup.ini ที่ถูกแก้ไข, และ AsusSetup.exe ที่มีลายเซ็น ตามลำดับ จากนั้นใช้ SilentInstallRun=calc.exe เพื่อทำ RCE ด้วยสิทธิ์ผู้ดูแลระบบ
  • ASUS ยืนยันการแจกจ่ายเวอร์ชันแก้ไขในเดือนเมษายน 2025 และมีการเปิดเผย CVE-2025-3462 กับ CVE-2025-3463 เมื่อวันที่ 9 พฤษภาคม 2025 โดยจากบันทึก certificate transparency ไม่พบร่องรอยการโจมตีอย่างแพร่หลายก่อนการเปิดเผย

DriverHub local RPC ที่เชื่อมกับเว็บไซต์

  • หลังซื้อเมนบอร์ด ASUS และล็อกอินเข้า Windows จะมีการแจ้งเตือนขอสิทธิ์ผู้ดูแลระบบเพื่อให้ติดตั้ง ASUS DriverHub ให้เสร็จสมบูรณ์
  • DriverHub ไม่ได้เป็น GUI แยกต่างหาก แต่ทำงานเป็นโปรเซสเบื้องหลัง และ driverhub.asus.com จะแนะนำไดรเวอร์และรายการอัปเดตที่จำเป็น
  • เว็บไซต์สื่อสารกับโปรเซส DriverHub ที่รันอยู่ในเครื่องผ่าน RPC
    • บริการในเครื่องทำงานบนพอร์ตคงที่ 53000 ของ 127.0.0.1
    • โครงสร้างคือเว็บไซต์หรือบริการส่ง API request ไปยังพอร์ตในเครื่องนี้
  • หากการป้องกัน RPC ในโครงสร้างแบบนี้ไม่เพียงพอ ผู้โจมตีอาจนำไปใช้ติดตั้งแอปพลิเคชันอันตรายได้

การเลี่ยงการตรวจสอบ Origin ที่หลวม

  • DriverHub ไม่ได้รับคำขอจากทุกเว็บไซต์ แต่ถูกออกแบบให้ตอบสนองคำขอที่มีเฮดเดอร์ Origin เป็น driverhub.asus.com
  • ปัญหาคือการตรวจสอบไม่ใช่การเทียบตรง ๆ แต่เป็นลักษณะคล้ายการตรวจว่ามีสตริงอยู่หรือใช้ไวลด์การ์ด
    • ไม่ใช่การเทียบตรงแบบ origin == driverhub.asus.com
    • เมื่อตั้ง Origin เป็น driverhub.asus.com.mrbruh.com คำขอก็ได้รับอนุญาต
  • ผู้โจมตีสามารถใช้พฤติกรรมนี้เข้าถึง DriverHub RPC ในเครื่องจากโดเมนรูปแบบ driverhub.asus.com.* ได้

เอนด์พอยต์ RPC ที่ถูกเปิดเผย

  • จาก JavaScript ของเว็บไซต์และการ decompile ไฟล์ปฏิบัติการ พบ RPC endpoint หลายรายการ
  • เอนด์พอยต์หลักมีดังนี้
    • Initialize: ส่งคืนสถานะการติดตั้งซอฟต์แวร์และข้อมูลการติดตั้งพื้นฐาน
    • DeviceInfo: ส่งคืนซอฟต์แวร์ ASUS ที่ติดตั้งอยู่, ไดรเวอร์ .sys ที่ติดตั้งอยู่, ส่วนประกอบฮาร์ดแวร์, และที่อยู่ MAC
    • Reboot: รีบูตอุปกรณ์เป้าหมายทันทีโดยไม่มีการยืนยัน
    • Log: ส่งคืนไฟล์บีบอัดของ log ทั้งหมดของ DriverHub
    • InstallApp: ติดตั้งโดยใช้ app หรือ driver ID โดย app ID ถูก hardcode ไว้ในไฟล์ XML ที่ตัวติดตั้ง DriverHub ให้มา
    • UpdateApp: ดาวน์โหลดและรัน URL ของไฟล์ที่ให้มาเพื่ออัปเดต DriverHub ด้วยตัวเอง

วิธีที่ UpdateApp สร้างเงื่อนไขให้เกิด RCE

  • คำขอ UpdateApp ทำงานในรูปแบบต่อไปนี้
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • พฤติกรรมที่สังเกตได้ของ UpdateApp ให้เงื่อนไขหลายอย่างที่จำเป็นต่อ RCE chain
    • พารามิเตอร์ Url ต้องมีสตริง .asus.com อยู่ แต่รูปแบบอย่าง example.com/payload.exe?foo=.asus.com ก็ได้รับอนุญาต
    • ไฟล์จะถูกบันทึกด้วยชื่อไฟล์ที่ระบุไว้ท้าย URL
    • สามารถดาวน์โหลดไฟล์ได้ไม่ว่า extension จะเป็นอะไร
    • หากไฟล์เป็นไฟล์ปฏิบัติการที่มีลายเซ็นของ ASUS จะถูกรันโดยอัตโนมัติด้วยสิทธิ์ผู้ดูแลระบบ
    • หากเป็นไฟล์ปฏิบัติการที่ ASUS ลงลายเซ็นไว้ ก็จะถูกรันแม้ไม่ใช่ตัวติดตั้ง DriverHub
    • แม้ไฟล์ที่ดาวน์โหลดมาจะตรวจสอบลายเซ็นไม่ผ่าน ก็จะไม่ถูกลบ
  • ตอนแรก RCE ดูเหมือนทำได้ยากเพราะมีการตรวจสอบลายเซ็น แต่เมื่อรวม พฤติกรรมที่ไฟล์ตรวจลายเซ็นไม่ผ่านยังคงเหลืออยู่ กับพฤติกรรมการติดตั้งของไฟล์ปฏิบัติการที่มีลายเซ็น ASUS จึงเกิดเส้นทางเลี่ยงขึ้น

เอ็กซ์พลอยต์เชนที่ใช้ AsusSetup.ini

  • แพ็กเกจไดรเวอร์ ASUS WiFi มี AsusSetup.exe, AsusSetup.ini, SilentInstall.cmd รวมอยู่ด้วย
  • เมื่อรัน AsusSetup.exe จะอ่าน metadata ของไดรเวอร์จาก AsusSetup.ini
  • หากรัน AsusSetup.exe ด้วยแฟล็ก -s จะทำการติดตั้งแบบเงียบโดยไม่มี GUI และรันรายการที่กำหนดไว้ใน SilentInstallRun ของ AsusSetup.ini
    • DriverHub ใช้แฟล็ก -s เพื่อการติดตั้งแบบเงียบ
    • ไฟล์ INI เดิมระบุสคริปต์ cmd สำหรับการติดตั้งอัตโนมัติแบบ unattended
    • SilentInstallRun สามารถระบุไฟล์ปฏิบัติการอื่นได้ด้วย

  • ลำดับการโจมตีที่สมบูรณ์

    • ผู้ใช้เข้าชมเว็บไซต์ที่มีโดเมนรูปแบบ driverhub.asus.com.*
    • เว็บไซต์เรียก UpdateApp เพื่อขอไฟล์ปฏิบัติการ PoC calc.exe
    • calc.exe ถูกดาวน์โหลด แต่ตรวจสอบลายเซ็นไม่ผ่านจึงไม่ถูกรัน
    • ไฟล์ไม่ถูกลบและยังคงอยู่
    • เว็บไซต์เรียก UpdateApp เพื่อขอ AsusSetup.ini ที่ถูกแก้ไข
    • ไฟล์นี้ก็ถูกดาวน์โหลด แต่ไม่ถูกรัน
    [InstallInfo]
SilentInstallPath=.\
SilentInstallRun=calc.exe
    • เว็บไซต์เรียก UpdateApp เพื่อขอไบนารี AsusSetup.exe ที่มีลายเซ็นของ ASUS
    • AsusSetup.exe ถูกดาวน์โหลดแล้วรันด้วยสิทธิ์ผู้ดูแลระบบ
    • เนื่องจาก DriverHub รันด้วย -s จึงอ่าน AsusSetup.ini
    • ตาม SilentInstallRun=calc.exe ทำให้ calc.exe ถูกรันด้วยสิทธิ์ผู้ดูแลระบบ

ตั้งแต่การรายงานจนถึงการเปิดเผย CVE

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

ความเป็นไปได้ในการถูกโจมตีและร่องรอยที่สังเกตพบ

  • หลังรายงานทันที ได้รันสคริปต์บน VPS เพื่อติดตามการอัปเดต certificate transparency และตรวจสอบว่ามีการจดโดเมน driverhub.asus.com.* หรือไม่
  • อ้างอิงจากเว็บไซต์บันทึก certificate transparency อื่น ๆ โดเมนและซับโดเมนมักปรากฏใน log ภายในหนึ่งเดือน
  • เมื่อตรวจสอบหลังผ่านไปหนึ่งเดือน พบว่าเว็บไซต์ที่ตรงกับ regular expression มีเพียงโดเมนทดสอบเท่านั้น
  • ตามเกณฑ์นี้ โอกาสที่ช่องโหว่จะถูกใช้งานอย่างแพร่หลายก่อนการรายงานจึงต่ำ

การตอบสนองของ ASUS และประเด็นที่ยังเหลือ

  • ASUS ไม่ได้ให้ bug bounty แต่ตอบว่าจะใส่ชื่อไว้ใน hall of fame แทน
  • ภายหลังพบว่านักวิจัยความปลอดภัยอีกคนชื่อ leonjza ได้รายงาน ปัญหาการตรวจสอบ Origin เดียวกันไว้แล้วในเดือนกุมภาพันธ์ 2025 และ ASUS ได้แก้ไขปัญหานี้ภายในช่วงแก้ไขครั้งนี้
    • ASUS ไม่ได้แจ้งเรื่องนี้แยกต่างหาก
    • หน้า cve.org ใส่เครดิตเฉพาะนักวิจัยรายนั้น และตอบว่าจะไม่เพิ่มเครดิตเพิ่มเติม
  • เมื่อต้องส่งรายงานช่องโหว่ผ่าน ASUS Security Advisory form Amazon CloudFront ตรวจพบ PoC ที่แนบมาเป็นคำขออันตรายและบล็อกการส่ง
    • จึงต้องลบโค้ด PoC บางส่วนออกและส่งลิงก์วิดีโอบันทึกหน้าจอแทน
  • ใน DriverHub หากไม่ติดตั้งไดรเวอร์ที่แนะนำทีละรายการ แต่กด “Install All” ระบบจะติดตั้ง ArmouryCrate, CPU-Z เวอร์ชันปรับแต่งของ ASUS, Norton360 และ WinRAR ไปด้วย
  • คำอธิบาย CVE ของ ASUS ระบุขอบเขตและผลกระทบของ RCE ไว้แคบ
    • ในคำอธิบายมีข้อความทำนองว่า “จำกัดอยู่ที่ motherboards และไม่กระทบ laptops, desktop computers”
    • ในความเป็นจริง กระทบคอมพิวเตอร์ทุกเครื่องที่ติดตั้ง DriverHub รวมถึง desktops/laptops
    • แทนที่จะระบุว่าเป็นการรันโค้ดโดยพลการหรือจากระยะไกล กลับใช้ถ้อยคำว่า “untrusted sources อาจส่งผลต่อ system behaviour”

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

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

 
GN⁺ 2025-05-12
ความคิดเห็นจาก Hacker News

  • การเปิดเผยอย่างมีความรับผิดชอบ และผลลัพธ์ของมันแทบเป็นหายนะต่อมนุษยชาติ บริษัทต่าง ๆ ต้องรู้สึกเจ็บปวดให้บ่อยกว่านี้มาก และหนักกว่านี้มาก ถึงจะจริงจังกับความปลอดภัยของลูกค้ามากขึ้น
    ถ้าให้เวลาหนึ่งเดือนพร้อมป้อนวิธีแก้ให้ถึงปาก มันก็จะกลายเป็นแค่ตั๋วหนึ่งใบใน backlog เท่านั้น ถ้าทุกครั้งที่เกิดปัญหาความปลอดภัย มันกลายเป็นข่าวใหญ่มากพอบนออนไลน์จน CEO ต้องเข้ามาเกี่ยวข้อง และต้องหาวิธีแก้ภายในไม่กี่ชั่วโมงแทนที่จะเป็นหลายเดือน พวกเขาก็จะขยับเชิงรุกกว่านี้มาก แน่นอนว่าผู้ใช้ปลายทางจะเสียหายมากที่สุด แต่ตั้งแต่ซื้อ ASUS ก็เจ็บปวดอยู่แล้วด้วย

    • รอบนี้ความเร็วในการตอบสนองของ ASUS ถือว่าใช้ได้ทีเดียว และผมไม่เห็นปัญหาใหญ่ตรงนี้ ASUS ไม่ได้ปฏิเสธบั๊ก ไม่ได้ขู่จะฟ้องเพราะมีการ reverse engineering ซอฟต์แวร์ และแพตช์อย่างรวดเร็ว
      ถ้าเป็นยุคก่อนการเปิดเผยอย่างมีความรับผิดชอบ กระบวนการนี้อาจใช้เวลาหลายเดือนและอาจมีตำรวจเข้ามาเกี่ยวข้องด้วย ผู้ใช้ทั่วไปไม่สนใจช่องโหว่ และทำธุรกรรมการเงินด้วยโทรศัพท์ที่ไม่ได้อัปเดตมา 3 ปีแล้ว ถ้าเอา CVE ไปโปรยในข่าวเรื่อย ๆ ผู้คนจะเบื่อกับเรื่องเล่าว่า “ทุกบริษัทห่วยหมด” จนด้านชาแม้ภัยคุกคามจริงจะมาถึง
      EU กำลังผลักดันทางออกอีกแบบหนึ่ง ใน กฎระเบียบไซเบอร์ซีเคียวริตี้ ฉบับใหม่ จะห้ามขายผลิตภัณฑ์ที่มีช่องโหว่ที่ทราบแล้วในร้านค้า ถ้า ASUS ยังทำพลาดซ้ำ ๆ เมนบอร์ดก็จะกลายเป็นสต็อกค้าง และร้านค้าก็จะไม่อยากขายฮาร์ดแวร์ ASUS อีก ไม่ใช่แค่ฮาร์ดแวร์คอมพิวเตอร์ แต่รวมถึงตู้เย็นและเครื่องซักผ้าอัจฉริยะด้วย ถ้าพบช่องโหว่ในเครื่องล้างจาน และผู้ผลิตไม่ได้ใส่วิธีอัปเดตเฟิร์มแวร์ไว้ ก็อาจทำให้ทั้งอุตสาหกรรมมีสต็อกใช้การไม่ได้มูลค่าหลายล้านดอลลาร์
    • ชื่อ “การเปิดเผยอย่างมีความรับผิดชอบ” นั้นย้อนแย้ง เพราะในความเป็นจริงมันใกล้เคียงกับวิธีที่ไร้ความรับผิดชอบโดยสิ้นเชิง
      บริษัทส่วนใหญ่จัดการการเปิดเผยได้แย่มาก ไม่แก้ให้ทันเวลา เช่น ภายในหนึ่งสัปดาห์ ไม่ให้เครดิตอย่างเหมาะสม ไม่แจ้งผู้ใช้ และไม่เรียนรู้จากความผิดพลาด การเปิดเผยแบบจำกัดที่ล่าช้าอย่างไร้ความรับผิดชอบยิ่งตอกย้ำพฤติกรรมเหล่านั้น
      วิธีที่มีความรับผิดชอบจริง ๆ คือเปิดเผยทันที ครบถ้วน และต่อสาธารณะ หากจำเป็นก็ทำแบบไม่ระบุตัวตนเพื่อปกป้องตัวเองได้ เฉพาะหลังจากบริษัทที่ได้รับผลกระทบพิสูจน์แล้วว่าตอบสนองได้ดีซ้ำ ๆ เท่านั้น จึงค่อยได้รับสิทธิ์แจ้งล่วงหน้าสั้นมาก เช่น ประมาณ 5 วันทำการ
      การที่การเปิดเผยแบบจำกัดที่ล่าช้าอย่างไร้ความรับผิดชอบเช่นนี้ถูกเรียกว่า “การเปิดเผยอย่างมีความรับผิดชอบ” เองก็เป็นตัวอย่างหนึ่งของ Newspeak
    • ประเด็นหลักคือเรื่อง การทำให้ความรับผิดเป็นกฎหมาย ผู้ผลิตรถยนต์ถูกสั่งให้เรียกคืนและซ่อม แต่บริษัทซอฟต์แวร์และฮาร์ดแวร์ถูกกดดันน้อยเกินไปมาก
      ลูกค้าควรสามารถขอคืนเงินเต็มจำนวนได้ เช่น สำหรับอุปกรณ์ที่พังและมี CVE ที่ยังไม่ได้แก้ไข
    • อ้างคำของ CGPGrey วิธีแก้ที่นึกออกเป็นอย่างแรกมักจะแย่มากและไม่ได้ผล
      วัฒนธรรมด้านความปลอดภัยและความมั่นคงที่ดีจะส่งเสริมให้ผู้มีส่วนร่วมไม่ปกปิดปัญหา บริษัทเป็นสิ่งมีชีวิตที่โลภ จึงจะทำทุกอย่างเพื่อซ่อนความผิดพลาดด้านความปลอดภัย
      ถ้าเปิดเผยปัญหาที่ถูกกฎหมายและแก้ไขได้ภายในหนึ่งเดือนให้ทุกคนรู้ โอกาสถูกนำไปใช้โจมตีก็จะเพิ่มขึ้นมากเช่นกัน
    • อาจมีไอเดียธุรกิจแบบนี้อยู่ หรืออาจมีอยู่แล้วก็ได้ คือทำ บริการนายหน้าและรวบรวมการเปิดเผย
      ปกป้องความเป็นส่วนตัวของผู้แจ้งเบาะแส ตรวจสอบช่องโหว่ความปลอดภัย และยืนยันว่าช่องโหว่ทุกตัวที่เปิดเผยสามารถนำไปใช้โจมตีได้จริง เปิดเผยตามรอบเวลาที่กำหนด และเก็บค่าสมัครสมาชิกจากบริษัทสำหรับ “ฟีดล่วงหน้า” ที่ได้รับเนื้อหาการเปิดเผยซึ่งส่งผลกระทบต่อตนเองก่อน เงินนั้นนำไปจ่ายรางวัลให้ผู้แจ้งเบาะแส จ่ายค่าใช้จ่ายในการดำเนินงาน และเหลือกำไรบางส่วน
      พูดง่าย ๆ คือเป็น ตลาดบั๊กบาวน์ตี ที่ค่อนข้างเป็นปฏิปักษ์กับบริษัท สงสัยเหมือนกันว่านี่จะถูกกฎหมายไหม หรือจะถูกมองว่าเป็นการกรรโชก

  • ประเด็นที่ถาม ASUS ว่ามี bug bounty ไหม แล้วเขาตอบว่าไม่มี แต่จะใส่ชื่อใน “Hall of Fame” ให้แทนนั้น ชวนขมขื่น
    เป็นการประชดว่า ASUS คงเป็นสตาร์ทอัพเล็ก ๆ เลยไม่มีทุนจ่าย bounty ซึ่งก็พอเข้าใจได้

    • กรณีบริษัทเล็ก ๆ อย่าง Cisco ก็น่าเข้าใจเช่นกัน Cisco ก็ทำแบบคล้าย ๆ กันกับบริการออนไลน์จำนวนมากที่เข้าซื้อมาเป็นเวลาหลายปี
      Cisco ไปไกลกว่านั้นถึงขั้นลืม หน้าประกาศด้านความปลอดภัย ไปเลย ทำให้การให้เครดิตใด ๆ ตอนนี้หายไปในอากาศแล้ว
    • ถ้าไม่มี bug bounty ตัว exploit ก็จะไปสู่ ตลาดมืด หรือไม่ก็กลายเป็นการเปิดเผยแบบเต็มรูปแบบ
    • เห็นการตอบสนองแบบนี้แล้วทำให้ไม่อยากซื้อผลิตภัณฑ์ ASUS อีกเลย
    • ไม่รู้ว่าสำนวน “Asus เป็นสตาร์ทอัพเล็ก ๆ” มาจากไหน Asus ทำเมนบอร์ดและชิ้นส่วน PC มาตั้งแต่อย่างน้อยยุค 90 แล้ว

  • ไม่น่าแปลกใจ ซอฟต์แวร์ของ ASUS แย่มาก และในแง่ความปลอดภัยก็ใกล้เคียงกับ บริษัทที่มีปัญหาซ้ำซาก ซึ่งขาดการป้องกัน
    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...

  • ประเด็นที่ดูจากบันทึกความโปร่งใสของใบรับรอง (Certificate Transparency logs) แล้วพบว่าโดเมนที่ตรงกับ driverhub.asus.com.* มีเพียงโดเมนทดสอบของตัวเอง จึงตัดสินว่าก่อนการรายงานน่าจะไม่ได้ถูกนำไปใช้โจมตีอย่างจริงจังนั้น จะเป็นจริงได้ก็ต่อเมื่อไม่มี ใบรับรองแบบไวลด์การ์ด เท่านั้น
    หากมีใครสักคนมีไวลด์การ์ด ก็อาจใช้ช่องนี้โจมตีได้โดยไม่ปรากฏในความโปร่งใสของใบรับรอง

    • ใบรับรองแบบไวลด์การ์ดใช้ได้กับระดับเลเบลเดียวเท่านั้น *.example.com. ใช้กับ test.test.example.com. ไม่ได้ แต่ใช้กับ test.example.com. ได้
      หากมีใครออกไวลด์การ์ดสำหรับ *.asus.com.example.com. ได้ ก็สามารถตั้งเว็บเซิร์ฟเวอร์ไว้ใต้ driverhub.asus.com.example.com. และทำให้ดูเหมือนถูกต้องได้
    • เป็นไอเดียที่ดี เลยลองตรวจสอบตอนนี้แล้ว และยืนยันว่าใน เรคคอร์ดไวลด์การ์ด ไม่มีอะไรน่าสงสัย
    • เรื่องมุมอับของใบรับรองไวลด์การ์ดนั้นถูกต้องแล้ว หากผู้โจมตีมีใบรับรองไวลด์การ์ดสำหรับ .example.com ก็อาจใช้ประโยชน์จากโดเมน driverhub.asus.com. ได้โดยไม่ปรากฏแบบเจาะจงในบันทึกความโปร่งใสของใบรับรอง
      ดังนั้นการมอนิเตอร์บันทึกความโปร่งใสของใบรับรองเพียงอย่างเดียวจึงไม่เพียงพอสำหรับตรวจจับช่องโหว่ประเภท การยึดครองซับโดเมน แบบนี้
    • อีกอย่าง สงสัยเหมือนกันว่าใบรับรองที่เซ็นเองจะใช้งานได้ไหม ใบรับรองแบบนั้นจะไม่เข้าไปอยู่ในบันทึกความโปร่งใส
      และยังสงสัยด้วยว่าจำเป็นต้องเป็น HTTPS จริงหรือไม่

  • ตอนจบที่ว่า “WiFi ออนบอร์ดของฉันยังใช้ไม่ได้อยู่ดี และต้องไปซื้ออะแดปเตอร์ USB WiFi แยก ขอบคุณนะ DriverHub” ทำให้กระบวนการทั้งหมดนี้กลายเป็น เสียแรงเปล่า แบบตรงตัว

    • แต่บทความบล็อกเองเขียนดี
    • ไดรเวอร์ WiFi เวอร์ชันล่าสุดใช้ไม่ได้ จึงต้องใช้ เวอร์ชันเก่า

  • ส่วนที่ตอนส่งรายงานช่องโหว่ผ่านแบบฟอร์มแจ้งความปลอดภัยของ ASUS แล้ว Amazon CloudFront ตัดสินว่า PoC ที่แนบเป็นคำขออันตรายและบล็อกไว้ ดูเหมือนเป็นการเตือนว่า Web Application Firewall เป็นแอนติแพตเทิร์น: https://thedailywtf.com/articles/Injection_Rejection

  • ที่บอกว่า “ASUS เป็นสตาร์ทอัพเล็ก ๆ ก็เข้าใจได้” นี่หมายถึงสตาร์ทอัพเล็ก ๆ ที่มีมูลค่าตลาดแค่ 15,000 ล้านดอลลาร์
    สิ่งที่เข้าใจยากจริง ๆ ไม่ใช่แค่ผลิตภัณฑ์ห่วย ๆ แต่ยังรวมถึงการปฏิบัติกับนักวิจัยที่ทำเรื่องใหญ่หลวงให้ลูกค้าของพวกเขาแบบนี้ด้วย
    สงสารนักวิจัยที่ทำเรื่องแบบนี้แล้วกลับถูกเมินหรือถูกกดคุณค่าลง มันไม่ยุติธรรมเอามาก ๆ
    สิ่งเดียวที่ทำได้คือไม่ซื้อผลิตภัณฑ์ของ ASUS

  • มีคนถาม ASUS ว่ามีบั๊กบาวน์ตีไหม และ ASUS ตอบว่าไม่มี แต่จะเอาชื่อขึ้น “Hall of Fame” ให้แทน เป็นการเสียดสีว่าก็เข้าใจได้ เพราะ ASUS เป็นสตาร์ทอัพเล็ก ๆ คงไม่มีทุนพอจะจ่ายบาวน์ตี
    [1]: https://companiesmarketcap.com/asus/marketcap/

    • หรือไม่ก็อาจเป็น sarcasm.com ก็ได้ ;)

  • ลิงก์วิดีโอ Scumbag Asus ที่ต้องแปะตามธรรมเนียม
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    “ASUS ส่งอีเมลหาเราเมื่อสัปดาห์ที่แล้ว บอกว่าอยากมาที่ออฟฟิศสัปดาห์นี้เพื่อ ‘พูดคุยแบบเปิดกว้าง’ เกี่ยวกับปัญหา เราตอบว่าได้ แต่การพูดคุยต้องมีการบันทึกวิดีโอ เพราะอย่างไรเสียพวกเขาก็บอกเองว่าอยากคุยแบบเปิดกว้าง หลังจากนั้น 5 วันก็ไม่มีคำตอบ ดังนั้น ASUS เคยมีโอกาสจะแก้ไขเรื่องนี้ให้ถูกต้องแล้ว เราถึงพักวิดีโอไว้เพื่อให้โอกาสนั้น แต่ทันทีที่เราบอกว่า ‘ได้ แต่เราจะถ่ายไว้เพื่อให้มีบันทึกถึงสิ่งที่รับปากกัน’ ก็เจอความเงียบกลับมา”

    • แล้วมีผู้ผลิตเมนบอร์ดที่ “โดยพื้นฐานแล้วโอเค” อยู่จริงไหม? หรือค่ายใหญ่ ๆ ก็มีเรื่องคล้ายกันหมด?
      ถามเผื่อเพื่อนที่กำลังจะประกอบพีซีเครื่องใหม่เร็ว ๆ นี้
    • เรื่องนี้ทำให้โมโห แต่ก็สงสัยว่า ถ้าจะปกป้องจุดยืนของ ASUS ให้แข็งแรงที่สุด จะพูดอย่างไรได้บ้าง
      ฝั่งที่น่าจะตรงกับความเป็นจริงคงเป็นแบบนี้: พวกเขาไล่ตามกำไร และในเมื่อยังรอดไปได้ ก็ไม่มีเหตุผลให้ทำอะไรที่ถูกบันทึกไว้แล้วดูแย่ สู้เอาเวลาไปทำการตลาดดีกว่า

  • การ ไม่มีบั๊กบาวน์ตี นี่ไร้สาระมาก ต่อไปจะไม่ซื้อผลิตภัณฑ์ ASUS แล้ว

    • คงเพราะเป็น “สตาร์ทอัพเล็ก ๆ” ละมั้ง
    • ซอฟต์แวร์และฝ่ายสนับสนุนลูกค้าของ Asus แย่มาก และก็เป็นแบบนั้นมาตลอด