- ASUS DriverHub, có thể được cài đặt ngay sau khi đăng nhập Windows, do cách kết nối website với dịch vụ cục bộ nên chỉ cần người dùng truy cập một website cụ thể là có thể dẫn đến thực thi mã với quyền quản trị viên
- DriverHub chạy nền không có GUI, với cấu trúc trong đó
driverhub.asus.com gửi yêu cầu tới dịch vụ HTTP/WebSocket cục bộ tại 127.0.0.1:53000, và kiểm tra Origin cho phép các miền dạng driverhub.asus.com.*
- Endpoint
UpdateApp tải tệp xuống nếu URL chỉ cần chứa chuỗi .asus.com; các tệp thực thi có chữ ký ASUS sẽ được chạy với quyền quản trị viên, còn các tệp thất bại khi xác minh chữ ký thì không bị xóa
- Khai thác cuối cùng đạt được RCE quyền quản trị viên bằng cách lần lượt cho tải xuống
calc.exe chưa ký, AsusSetup.ini bị chỉnh sửa và AsusSetup.exe đã ký, rồi dùng SilentInstallRun=calc.exe
- ASUS xác nhận đã phát hành bản sửa lỗi vào tháng 4/2025; CVE-2025-3462 và CVE-2025-3463 được công bố ngày 09/05/2025, và theo log minh bạch chứng chỉ thì không thấy dấu hiệu bị khai thác tích cực trước khi công bố
DriverHub RPC cục bộ được kết nối với website
- Sau khi mua bo mạch chủ ASUS và đăng nhập Windows, một thông báo yêu cầu quyền quản trị viên được hiển thị để hoàn tất cài đặt ASUS DriverHub
- DriverHub không phải là GUI riêng mà chạy như một tiến trình nền, còn driverhub.asus.com hướng dẫn các driver cần thiết và mục cần cập nhật
- Website giao tiếp với tiến trình DriverHub đang chạy cục bộ qua RPC
- Dịch vụ cục bộ chạy trên cổng cố định
53000 của 127.0.0.1
- Website hoặc dịch vụ gửi yêu cầu API tới cổng cục bộ này
- Trong cấu trúc như vậy, nếu cơ chế bảo vệ RPC không đủ chặt chẽ, kẻ tấn công có thể lợi dụng để cài đặt ứng dụng độc hại
Vượt qua kiểm tra Origin lỏng lẻo
- DriverHub không nhận mọi yêu cầu từ bất kỳ website nào, mà được thiết kế để phản hồi các yêu cầu có header
Origin là driverhub.asus.com
- Vấn đề là việc kiểm tra không phải so sánh chính xác, mà gần với kiểu chứa chuỗi hoặc wildcard
- Không phải so sánh trực tiếp kiểu
origin == driverhub.asus.com
- Khi đặt Origin là
driverhub.asus.com.mrbruh.com, yêu cầu được chấp nhận
- Kẻ tấn công có thể lợi dụng hành vi này để truy cập DriverHub RPC cục bộ từ các miền dạng
driverhub.asus.com.*
Các endpoint RPC bị lộ
- Qua JavaScript của website và dịch ngược tệp thực thi, nhiều endpoint RPC đã được xác nhận
- Các endpoint chính như sau
- Initialize: trả về việc phần mềm đã được cài đặt hay chưa và thông tin cài đặt cơ bản
- DeviceInfo: trả về phần mềm ASUS đã cài, driver
.sys đã cài, thành phần phần cứng và địa chỉ MAC
- Reboot: khởi động lại ngay thiết bị mục tiêu mà không cần xác nhận
- Log: trả về bản nén của toàn bộ log DriverHub
- InstallApp: cài đặt theo ID ứng dụng hoặc driver; ID ứng dụng được hard-code trong tệp XML do trình cài đặt DriverHub cung cấp
- UpdateApp: tải xuống và chạy URL tệp được cung cấp để DriverHub tự cập nhật
Cách UpdateApp tạo điều kiện cho RCE
- Yêu cầu
UpdateApp hoạt động theo dạng sau
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp" -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
- Hành vi quan sát được của
UpdateApp cung cấp nhiều điều kiện cần thiết cho chuỗi RCE
- Tham số
Url phải chứa chuỗi .asus.com, nhưng các dạng như example.com/payload.exe?foo=.asus.com cũng được chấp nhận
- Tệp được lưu bằng tên tệp chỉ định ở cuối URL
- Có thể tải xuống tệp bất kể phần mở rộng
- Nếu tệp là tệp thực thi có chữ ký ASUS, nó sẽ tự động chạy với quyền quản trị viên
- Nếu là tệp thực thi do ASUS ký, nó vẫn được chạy ngay cả khi không phải trình cài đặt DriverHub
- Tệp đã tải xuống không bị xóa ngay cả khi thất bại khi kiểm tra chữ ký
- Ban đầu RCE có vẻ khó vì xác minh chữ ký, nhưng khi kết hợp hành vi giữ lại tệp thất bại khi ký với hành vi cài đặt của tệp thực thi có chữ ký ASUS, một đường vòng đã xuất hiện
Chuỗi khai thác dùng AsusSetup.ini
Từ báo cáo đến công bố CVE
- Lịch xử lý lỗ hổng như sau
- 2025-04-07: Phát hiện lỗ hổng ban đầu
- 2025-04-08: Xác nhận mở rộng thành RCE
- 2025-04-08: Báo cáo lỗ hổng cho ASUS
- 2025-04-09: Nhận phản hồi tự động từ ASUS
- 2025-04-17: Sau liên hệ tiếp theo, ASUS thông báo đã hoàn tất bản vá và gửi build để xác minh
- 2025-04-18: ASUS xác nhận phát hành bản sửa lỗi
- 2025-05-09: CVE-2025-3462 điểm 8.4 và CVE-2025-3463 điểm 9.4 được công bố
Khả năng bị khai thác và dấu vết quan sát được
- Ngay sau khi báo cáo, một script theo dõi cập nhật certificate transparency được chạy trên VPS để kiểm tra việc đăng ký các miền
driverhub.asus.com.*
- Theo các website log minh bạch chứng chỉ khác, miền và subdomain thường xuất hiện trong log trong vòng một tháng
- Khi kiểm tra sau một tháng, các website khớp với biểu thức chính quy chỉ có miền thử nghiệm
- Theo tiêu chí này, khả năng lỗ hổng bị khai thác tích cực trước khi báo cáo là thấp
Phản hồi của ASUS và các vấn đề còn lại
- ASUS không cung cấp bug bounty, thay vào đó trả lời rằng sẽ đưa tên lên hall of fame
- Sau đó, một nhà nghiên cứu bảo mật khác là leonjza đã báo cáo cùng vấn đề kiểm tra Origin từ tháng 2/2025, và ASUS đã sửa nó trước thời điểm bản sửa lần này
- ASUS không thông báo riêng về việc này
- Trên trang cve.org, chỉ nhà nghiên cứu đó được ghi công, và ASUS trả lời rằng sẽ không bổ sung ghi công thêm
- Khi gửi báo cáo lỗ hổng qua Security Advisory form của ASUS, Amazon CloudFront phát hiện PoC đính kèm là yêu cầu độc hại và chặn việc gửi
- Phải gỡ một phần mã PoC và thay vào đó gửi liên kết video ghi lại
- Nếu trong DriverHub không cài riêng từng driver được đề xuất mà nhấn “Install All”, ArmouryCrate, CPU-Z tùy biến của ASUS, Norton360 và WinRAR cũng được cài kèm
- Mô tả CVE của ASUS diễn đạt phạm vi và tác động RCE theo hướng thu hẹp
- Mô tả có câu mang ý rằng “chỉ giới hạn ở motherboards và không ảnh hưởng đến laptops, desktop computers”
- Trên thực tế, mọi máy tính có cài DriverHub đều bị ảnh hưởng, bao gồm cả desktops/laptops
- Thay vì thực thi mã tùy ý hoặc từ xa, mô tả dùng cách diễn đạt kiểu “untrusted sources có thể ảnh hưởng đến system behaviour”
1 bình luận
Ý kiến trên Hacker News
Công bố có trách nhiệm và các hệ quả của nó gần như là thảm họa đối với nhân loại. Các công ty cần phải cảm thấy đau đớn thường xuyên hơn nhiều, và lớn hơn nhiều, thì mới coi bảo mật của khách hàng nghiêm túc hơn
Nếu cho họ một tháng và còn dọn sẵn giải pháp đến tận miệng, nó chỉ trở thành một ticket trong backlog. Nếu mỗi lần có sự cố bảo mật, nó trở thành tin tức đủ lớn trên mạng để CEO cũng phải can dự và họ phải tìm ra giải pháp trong vài giờ thay vì vài tháng, thì họ sẽ chủ động hơn nhiều. Tất nhiên người dùng cuối sẽ chịu thiệt hại lớn nhất, nhưng ngay từ lúc mua ASUS thì họ cũng đã chịu khổ rồi
Nếu là thời trước khi có công bố có trách nhiệm, quá trình này có thể đã mất vài tháng và thậm chí có cả cảnh sát can dự. Người dùng phổ thông không quan tâm đến lỗ hổng, và vẫn làm giao dịch tài chính trên điện thoại đã ngừng cập nhật 3 năm. Nếu cứ liên tục rải CVE lên tin tức, họ sẽ chán ngấy câu chuyện “công ty nào cũng tệ” và trở nên vô cảm ngay cả khi có mối đe dọa thật sự
EU đang thúc đẩy một cách giải khác. Theo quy định an ninh mạng mới, các sản phẩm có lỗ hổng đã biết sẽ không được bán trong cửa hàng. Nếu ASUS tiếp tục làm hỏng việc, bo mạch chủ sẽ biến thành hàng tồn kho, và cửa hàng cũng sẽ không muốn bán phần cứng ASUS nữa. Không chỉ phần cứng máy tính, mà cả tủ lạnh và máy giặt thông minh cũng thuộc diện này. Nếu phát hiện lỗ hổng trong máy rửa bát, trong trường hợp nhà sản xuất không đưa vào phương tiện cập nhật firmware, bạn có thể khiến ngành này có lượng hàng tồn kho không dùng được trị giá hàng triệu đô la
Phần lớn doanh nghiệp xử lý việc công bố rất tệ. Họ không sửa kịp thời, chẳng hạn trong vòng một tuần; không ghi nhận công lao đúng mức; không thông báo cho người dùng; và cũng không học từ sai lầm. Việc công bố hạn chế bị trì hoãn một cách vô trách nhiệm chỉ củng cố hành vi đó
Cách thật sự có trách nhiệm là công bố ngay lập tức, đầy đủ và công khai. Nếu cần, có thể làm ẩn danh để tự bảo vệ. Chỉ sau khi công ty bị ảnh hưởng chứng minh được rằng họ nhiều lần phản hồi đúng cách, họ mới có thể nhận được quyền được báo trước rất ngắn, chẳng hạn khoảng 5 ngày làm việc
Việc kiểu công bố hạn chế bị trì hoãn vô trách nhiệm này lại được gọi là “công bố có trách nhiệm” chính là một ví dụ của Newspeak
Khách hàng nên có quyền được hoàn tiền đầy đủ, chẳng hạn đối với một thiết bị lỗi có CVE chưa được sửa
Một văn hóa an toàn/bảo mật tốt khuyến khích những người tham gia không che giấu vấn đề. Doanh nghiệp là những thực thể tham lam, nên sẽ làm mọi thứ để che giấu sai sót bảo mật
Nếu công bố cho tất cả mọi người một vấn đề hợp pháp, có thể sửa và có thể được sửa trong vòng một tháng, khả năng nó bị khai thác cũng tăng mạnh
Bảo vệ quyền riêng tư của người báo cáo, xác minh lỗ hổng bảo mật, và đảm bảo mọi lỗ hổng được công bố đều thực sự có thể bị khai thác. Công bố theo chu kỳ định sẵn, và thu phí đăng ký “feed sớm” từ các công ty để họ nhận trước những công bố ảnh hưởng đến mình. Dùng số tiền đó để thưởng cho người báo cáo, chi trả chi phí vận hành và giữ lại một phần lợi nhuận
Nói cách khác, đó là một chợ bug bounty hơi đối nghịch với doanh nghiệp. Tôi tò mò không biết nó có hợp pháp không, hay sẽ bị xem là tống tiền
Đoạn hỏi ASUS có bug bounty không, họ trả lời là không và thay vào đó đề nghị đưa tên lên “Hall of Fame” nghe thật chua chát
Đây là lời mỉa mai rằng ASUS là một startup nhỏ nên chắc không có vốn để trả bounty, cũng có thể thông cảm
Cisco còn đi xa hơn khi quên luôn cả trang thông báo bảo mật, nên mọi ghi nhận giờ đã biến mất vào hư không
Không ngạc nhiên. Phần mềm của ASUS rất tệ, và về mặt bảo mật thì gần như là công ty có vấn đề tái diễn do thiếu phòng ngừa
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...
https://cve.mitre.org/data/board/archives/2016-06/msg00006.h...
Blog cũ đã biến mất khỏi tumblr, nhưng tôi đã lưu trữ lại
https://gist.github.com/indrora/2ae05811a2625a6c5e69c677db6e...
Phần đánh giá rằng, sau khi xem nhật ký minh bạch chứng chỉ và thấy các domain khớp với
driverhub.asus.com.*chỉ là domain tự kiểm thử, nên khả năng chưa bị khai thác tích cực trước khi báo cáo là cao, chỉ đúng khi không có chứng chỉ wildcardNếu ai đó có wildcard thì họ đã có thể khai thác mà không lộ trong minh bạch chứng chỉ
*.example.com.không dùng được chotest.test.example.com., nhưng dùng được chotest.example.com.Nếu ai đó phát hành wildcard cho
*.asus.com.example.com.thì họ có thể chạy máy chủ web dướidriverhub.asus.com.example.com.và khiến nó trông hợp lệ.example.comthì họ đã có thể khai thác mà không cần xuất hiện cụ thể trong nhật ký minh bạch chứng chỉ với domaindriverhub.asus.com.Vì vậy chỉ giám sát nhật ký minh bạch chứng chỉ là chưa đủ để phát hiện kiểu lỗ hổng chiếm quyền subdomain này
Và cũng không rõ có nhất thiết phải là HTTPS hay không
Kết cục là “WiFi onboard của tôi vẫn không hoạt động, và tôi đã phải mua adapter WiFi USB rời. Cảm ơn DriverHub” — toàn bộ quá trình này đúng nghĩa là công cốc
Đoạn khi gửi báo cáo lỗ hổng qua biểu mẫu báo cáo bảo mật của ASUS, Amazon CloudFront coi PoC đính kèm là yêu cầu độc hại và chặn lại, giống như một lời nhắc rằng tường lửa ứng dụng web là một anti-pattern: https://thedailywtf.com/articles/Injection_Rejection
“ASUS là một startup nhỏ nên có thể thông cảm” — ý là một startup nhỏ với vốn hóa thị trường chỉ 15 tỷ USD
Điều thực sự khó hiểu không chỉ là sản phẩm tệ, mà còn là cách họ đối xử với cả nhà nghiên cứu đã làm một việc rất lớn cho khách hàng của họ như vậy
Thật đáng buồn cho các nhà nghiên cứu làm những việc như thế này rồi vẫn bị phớt lờ hoặc hạ thấp. Quá bất công
Việc duy nhất có thể làm là không mua sản phẩm ASUS
Tôi đã hỏi ASUS có bug bounty không, và ASUS trả lời là không, nhưng thay vào đó sẽ đưa tên tôi lên “Hall of Fame”. Đây là lời châm biếm rằng ASUS là một startup nhỏ nên hẳn không có vốn để trả bounty
[1]: https://companiesmarketcap.com/asus/marketcap/
Đây là link video Scumbag Asus đăng cho đủ lệ bộ
Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
YouTube https://youtube.com/watch?v=cbGfc-JBxlY
“ASUS đã gửi email cho chúng tôi tuần trước, nói rằng họ muốn đến văn phòng trong tuần này để có một ‘cuộc đối thoại cởi mở’ về vấn đề. Chúng tôi nói được thôi, nhưng cuộc trao đổi phải được ghi hình. Dù sao thì họ cũng nói muốn đối thoại cởi mở mà. Sau đó 5 ngày không có phản hồi. Vậy nên ASUS đã có cơ hội để sửa sai. Chúng tôi đã giữ lại video để trao cho họ cơ hội đó. Nhưng ngay khi chúng tôi nói ‘được, nhưng tôi sẽ quay lại để có hồ sơ về những gì các anh đã hứa’, thì họ im lặng”
Hỏi giúp một người bạn sắp ráp PC mới
Phần có lẽ khớp với thực tế là thế này: họ đang chạy theo lợi nhuận, và vì vẫn thoát được nên chẳng có lý do gì để bị ghi hình rồi trông xấu đi; tốt hơn là dành thời gian đó cho marketing
Không có bug bounty là không thể chấp nhận được. Từ nay tôi sẽ không mua sản phẩm ASUS nữa