Phát hiện lỗ hổng RCE một cú nhấp trong phần mềm driver cài sẵn của ASUS

• Phát hiện lỗ hổng thực thi mã từ xa (RCE) một cú nhấp trong phần mềm DriverHub của ASUS
• Do xác thực origin lỏng lẻo trên máy cục bộ, trang web độc hại có thể dùng RPC để thực thi với quyền quản trị viên
• Khi lạm dụng endpoint UpdateApp, có thể thực thi mã độc bằng cách kết hợp tệp thực thi có chữ ký ASUS với tệp ini đã bị chỉnh sửa
• Lỗ hổng này đã được công bố với mã CVE-2025-3462, CVE-2025-3463, và ASUS đã nhanh chóng phát hành bản vá
• Tại thời điểm báo cáo lỗ hổng, không phát hiện trường hợp bị khai thác thực tế, và ASUS bồi đáp bằng cách ghi danh vào hall of fame thay vì bug bounty

---

Introduction

• Câu chuyện bắt đầu từ việc mua linh kiện PC mới
• Khi mua bo mạch chủ ASUS, tùy chọn BIOS tự động cài phần mềm được bật mặc định
• Do vô tình không tắt tùy chọn này, sau khi đăng nhập Windows tác giả nhận được yêu cầu cấp quyền cài DriverHub
• Vì cần driver WiFi, tác giả tò mò và đã cài DriverHub

DriverHub

• DriverHub là tiến trình nền hoạt động không có GUI
• Nó giao tiếp với driverhub.asus.com để cung cấp danh sách driver cần cài đặt/cập nhật
• Trên máy cục bộ, nó cung cấp HTTP API (cổng 53000) dưới dạng RPC
• Website có thể gửi yêu cầu API tới dịch vụ cục bộ này để trực tiếp quản lý driver
• Tác giả nhận ra rằng nếu bảo mật kém thì kẻ tấn công có thể gửi yêu cầu tùy ý

Finding the Vulnerability

• Tác giả thử nghiệm xem website có thể tùy ý gửi yêu cầu RPC tới backend DriverHub hay không
• Hệ thống được thiết kế để chỉ phản hồi khi Origin là “driverhub.asus.com”
• Tác giả kiểm tra xem việc kiểm tra Origin có dùng khớp wildcard kiểu origin.includes("driverhub.asus.com") hay không
• Khi đổi Origin thành “driverhub.asus.com.mrbruh.com”, tác giả phát hiện yêu cầu vẫn được chấp nhận
• Điều này xác nhận rủi ro nghiêm trọng khi kẻ tấn công có thể gọi RPC từ một website độc hại theo cách này

The Extent of the Damage

• Thông qua reverse engineering và phân tích JavaScript, tác giả xác định được danh sách endpoint API có thể dùng từ tiến trình nền
• Các endpoint chính:
  • Initialize: trả về trạng thái cài đặt và thông tin
  • DeviceInfo: trả về phần mềm/driver/phần cứng ASUS đã cài cùng địa chỉ MAC
  • Reboot: thực hiện khởi động lại ngay lập tức
  • Log: trả về tập hợp tệp log
  • InstallApp: cài ứng dụng hoặc driver với ID chỉ định
  • UpdateApp: tải xuống rồi chạy tệp thực thi từ URL chỉ định (tự động chạy nếu có chữ ký ASUS)
• Tác giả đặc biệt chú ý đến khả năng bị lạm dụng của UpdateApp

Achieving RCE

• Tác giả phân tích chi tiết endpoint UpdateApp
• Tham số “Url” có điều kiện phải chứa .asus.com nhưng có khả năng bị vượt qua, và tên tệp sẽ theo phần cuối của URL
• Chỉ tệp thực thi có chữ ký ASUS mới được tự động chạy, nhưng tệp không có chữ ký vẫn được tải xuống và không bị xóa
• Tác giả xem xét tấn công timing để thay tệp ngay trước lúc chạy sau khi vượt qua kiểm tra chữ ký, nhưng cách này không thực tế
• Trong quá trình phân tích cấu trúc gói driver WiFi của ASUS, tác giả phát hiện thuộc tính SilentInstallRun của AsusSetup.ini có thể được dùng để chạy lệnh tùy ý
• Chuỗi tấn công cuối cùng:
  1. Kẻ tấn công dụ nạn nhân truy cập website dưới tên miền phụ của driverhub.asus.com. *
  2. Website yêu cầu UpdateApp tải calc.exe độc hại xuống (chỉ tải, chưa chạy)
  3. Yêu cầu một AsusSetup.ini tùy biến (đặt SilentInstallRun=calc.exe, cũng chưa chạy)
  4. Yêu cầu AsusSetup.exe có chữ ký (tự động chạy với quyền quản trị viên, đọc ini bằng cờ “-s” và thực thi calc.exe)
• Kết quả là xảy ra RCE thực thi mã tùy ý từ xa với quyền quản trị viên chỉ bằng một cú nhấp

Reporting Timeline (DD/MM/YYYY)

• 07/04/2025: phát hiện lỗ hổng lần đầu
• 08/04/2025: chứng minh được RCE và báo cáo lỗ hổng
• 09/04/2025: nhận phản hồi tự động từ ASUS
• 17/04/2025: bản vá được phát hành và nhận được bản dựng đã vá
• 18/04/2025: xác nhận bản vá đã được triển khai thực tế
• 09/05/2025: công bố CVE-2025-3462 (8.4 điểm), CVE-2025-3463 (9.4 điểm)

Assessing the Damage

• Ngay sau khi báo cáo lỗ hổng, tác giả viết script theo dõi certificate transparency
• Theo dõi lịch sử cấp chứng chỉ cho các tên miền phụ driverhub.asus.com.*
• Sau 1 tháng giám sát, ngoài thử nghiệm của chính tác giả thì không có website nào khác bị bộ lọc phát hiện
• Xác nhận không có dấu hiệu bị khai thác trước đó

Bug Bounty

• Tác giả hỏi ASUS có trả bug bounty hay không nhưng bị từ chối
• Thay vào đó, phần thưởng chủ yếu là được ghi danh vào hall of fame
• Có bổ sung rằng dù ASUS là tập đoàn lớn nhưng chính sách bounty vẫn còn thiếu

Fun Notes

• Khi gửi form Security Advisory của ASUS, PoC đã bị Amazon CloudFront chặn như một yêu cầu độc hại
• Khi bấm “Install All” trong DriverHub, các phần mềm khác (Norton360, WinRAR, v.v.) cũng bị cài ép
• Mô tả CVE mơ hồ và chưa đúng thực tế, dễ khiến người đọc hiểu nhầm rằng 'desktop/laptop không bị ảnh hưởng' (thực tế là mọi thiết bị có cài DriverHub đều bị ảnh hưởng)
• WiFi vẫn không hoạt động, nên cuối cùng phải mua adapter WiFi USB gắn ngoài
• Liên hệ qua Signal: paul19.84, email contact [at] mrbruh.com

[GN⁺]

Ý kiến trên Hacker News

• Kết quả của Responsible Disclosure khiến người ta cảm thấy như một thảm họa đối với nhân loại; để các công ty thực sự nghiêm túc với bảo mật của khách hàng, có lẽ họ cần thường xuyên chịu đau đớn lớn hơn. Nếu bạn phát hiện vấn đề rồi đưa cách khắc phục và bảo họ sửa trong một tháng, từ góc nhìn doanh nghiệp đó chỉ là một vé backlog nữa mà thôi. Nhưng nếu sự việc lên tin tức online đến mức CEO cũng phải ra mặt, họ sẽ tìm ra cách giải quyết chỉ trong vài giờ. Tất nhiên cuối cùng người dùng vẫn là bên chịu thiệt hại lớn nhất, nhưng đằng nào chỉ riêng việc mua ASUS cũng đã là một dạng đau khổ rồi
  • Cách xử lý lần này của ASUS là khá nhanh; họ không phủ nhận vấn đề, cũng không kiện người đã reverse engineering, và vá lỗi ngay lập tức. Trước đây những vụ như thế này có thể kéo dài hàng tháng hoặc thậm chí cảnh sát can thiệp. Người bình thường vốn cũng chẳng quan tâm đến lỗ hổng, vì đây là thế giới nơi người ta vẫn giao dịch tài chính bằng những chiếc điện thoại 3 năm chưa được cập nhật. Dù báo chí có phủ kín bằng các vụ CVE thì mọi người cũng chỉ ngày càng chai lì cảm xúc. Ở châu Âu, quy định mới cấm bán các sản phẩm có lỗ hổng đã được biết đến, nên nếu ASUS cứ tiếp tục như vậy thì tồn kho bo mạch chủ sẽ chất đống trong kho và nhà phân phối sẽ không muốn bán nữa. Điều này cũng áp dụng cho đồ gia dụng; ví dụ nếu máy rửa chén có lỗ hổng thì cả ngành đó cũng có thể chịu thiệt hại lớn
  • Cái tên “Responsible” Disclosure nghe thật mỉa mai vì đó lại là hành vi hoàn toàn vô trách nhiệm. Phần lớn công ty không vá trong vòng một tuần, không ghi nhận công lao, không thông báo cho người dùng và cũng không học được gì từ sai lầm. Việc công bố chậm và hạn chế lại càng khuyến khích kiểu hành xử đó. Hành động thật sự có trách nhiệm là công bố ngay lập tức, đầy đủ và công khai; và nếu đã có đủ niềm tin rằng công ty sẽ phản ứng đúng đắn thì có thể cân nhắc báo trước khoảng 5 ngày làm việc. Gọi việc công bố chậm và từng phần là “responsible disclosure” về cơ bản chỉ là chơi chữ
  • Gốc rễ của vấn đề là thiếu luật về trách nhiệm sản phẩm. Các hãng xe có nghĩa vụ triệu hồi, còn các công ty phần mềm/phần cứng thì chịu áp lực quá yếu. Tôi nghĩ khách hàng phải có quyền được hoàn tiền đầy đủ cho sản phẩm có lỗ hổng (CVE) chưa được khắc phục
  • Mượn lời CGPGrey, giải pháp đầu tiên nảy ra trong đầu thường khá tệ và không hiệu quả. Một văn hóa bảo mật tốt phải khuyến khích việc không che giấu vấn đề nội bộ. Các công ty thì tham lam nên che giấu mọi vấn đề bảo mật. Nếu công bố ngay khi phát hiện, thì cả những vấn đề có thể sửa trong vòng một tháng cũng sẽ bị phơi bày cho tất cả mọi người và khả năng bị khai thác sẽ tăng vọt
  • Có một ý tưởng kinh doanh, có thể đã tồn tại rồi: một nền tảng công bố/trung gian bảo vệ quyền riêng tư của người báo cáo, xác minh khả năng bị khai thác thực tế của lỗ hổng, công bố công khai theo lịch cố định, và cho phép doanh nghiệp trả tiền để đăng ký feed thông báo sớm về những gì ảnh hưởng đến họ; khoản tiền đó sẽ dùng để thưởng cho người báo cáo, trang trải vận hành và chia lợi nhuận. Mô hình này khá giống bug bounty marketplace nhưng từ phía doanh nghiệp thì có phần đối đầu hơn. Tôi tự hỏi liệu nó có hợp pháp không, hay sẽ bị xem là tống tiền
  • Tôi cứ nhấn mạnh mãi rằng phải có trách nhiệm pháp lý đối với lỗi của sản phẩm như các ngành khác. Hầu hết mọi người chỉ chấp nhận hàng lỗi khi nó rẻ, không có lý do gì phần mềm lại là ngoại lệ
  • Cứ công bố lỗ hổng ngay ngày hôm sau thì đó mới là động lực thật sự. Mất mặt cũng giúp ích cho bảo mật lần sau
  • Kiểu cường điệu như “thảm họa đối với nhân loại” là ví dụ điển hình của việc làm hỏng trọng tâm tranh luận
• Tôi hỏi ASUS có bug bounty không, thì họ bảo thay vào đó sẽ đưa tên tôi vào Hall of Fame. Nghe chua chát như một câu đùa rằng ASUS chỉ là startup nhỏ nên không có vốn để trả bounty
  • Những công ty nhỏ như Cisco cũng làm tương tự, chỉ ghi tên mà không có thưởng. Cisco thậm chí còn quên cả trang security advisory nên cơ hội được ghi nhận cũng biến mất
  • Nếu không có bug bounty thì chỉ còn lựa chọn bán exploit cho chợ đen hoặc công bố toàn bộ
  • Chính những chuyện như thế này khiến tôi không muốn mua sản phẩm ASUS nữa
• Chất lượng phần mềm của ASUS cũng kém, và đây là công ty liên tục gây ra vấn đề về bảo mật. Trước đây cũng từng có vụ malware UEFI trên bo mạch chủ, lại còn cài sẵn phần mềm không cần thiết khiến việc gỡ bỏ cũng phiền phức. Có rất nhiều trường hợp phàn nàn nên cũng đáng tham khảo
  • Đây không phải lần đầu xảy ra chuyện như vậy. Trước đây đã có trường hợp tương tự, và tôi cũng đã lưu lại trên blog cũ của mình như một bản ghi
• Họ nói chỉ có domain thử nghiệm của họ (driverhub.asus.com.*) khớp điều kiện nên chưa từng bị khai thác, nhưng điều đó chỉ đúng nếu không ai đăng ký riêng một subdomain của driverhub. Nếu dùng wildcard thì sẽ không hiện trong certificate transparency log và vẫn có thể bị khai thác
  • Wildcard certificate chỉ bao phủ subdomain thấp hơn một cấp. Ví dụ *.example.com chỉ áp dụng cho test.example.com, chứ không áp dụng cho test.test.example.com. Nếu ai đó dùng wildcard *.asus.com.example.com thì driverhub.asus.com.example.com sẽ trở nên hợp lệ
  • Có người nói đây là ý hay nên đã kiểm tra ngay, và hiện chưa thấy wildcard certificate nào đáng ngờ
  • Điểm mù của wildcard certificate đúng là một nhận xét xác đáng. Nếu attacker có wildcard certificate cho .example.com thì thực sự có thể khai thác từ nơi không phải driverhub.asus.com. Chính vì điểm này mà chỉ giám sát CT log thôi sẽ không thể phát hiện hoàn hảo các lỗ hổng chiếm quyền subdomain kiểu này
• Phần ASUS trả lời “chúng tôi là startup nhỏ nên không có bounty, nhưng sẽ đưa tên bạn vào Hall of Fame” khi được hỏi về bug bounty thật sự rất ấn tượng, trong khi thực tế đây là tập đoàn khổng lồ với vốn hóa thị trường hơn 15B
  • Có người mỉa mai đề xuất sarcasm.com
• Wi‑Fi onboard không hoạt động nên tôi dùng Wi‑Fi USB ngoài, vậy mà nhờ DriverHub nên cũng chẳng ích gì, đúng là thất vọng khi gọi đó là giải pháp
  • Bản thân bài blog thì tôi đọc thấy khá thú vị
  • Driver Wi‑Fi mới nhất không hoạt động nên tôi phải dùng bản cũ hơn
• ASUS là một tập đoàn lớn với vốn hóa thị trường 15 tỷ USD mà vẫn không trả thưởng đàng hoàng, lại còn phớt lờ công sức của khách hàng và nhà nghiên cứu. Nhìn cách họ đối xử như vậy thì rất dễ đồng cảm với cảm giác bất công của các nhà nghiên cứu; kết luận là tốt nhất đừng mua sản phẩm ASUS
• Khi gửi bug report thì file PoC bị Amazon CloudFront nhận diện là request độc hại nên chặn luôn việc gửi. Kiểu WAF (Web Application Firewall) như vậy đúng là một mẫu hình hay ví dụ không tốt
• Tôi đồng cảm với lời phàn nàn về vấn đề Wi‑Fi onboard; thật ra chỉ cần xem model chipset rồi tải riêng từ những nơi như station-drivers là xong trong vài giây. Cũng vì những phiền toái như vậy mà tôi không thích ASUS. Tôi đặc biệt ghét các tùy chọn BIOS tương tác trực tiếp với hệ điều hành
• Tôi thích phần cứng ASUS nhưng luôn tắt các ứng dụng hỗ trợ được cài sẵn trong UEFI. Trước đây bản đầy đủ của ROG Armory Crate từng được cài vào và rất phiền để gỡ bỏ. Sau khi ASUS tiếp quản mảng NUC từ Intel thì các bản cập nhật BIOS vẫn được duy trì, nhưng những ứng dụng cài đặt như MyASUS lại được thêm mặc định. May là có tùy chọn vô hiệu hóa, và có vẻ nếu cập nhật từ BIOS Intel NUC thì mặc định nó sẽ ở trạng thái tắt