2 điểm bởi GN⁺ 2025-05-12 | 1 bình luận | Chia sẻ qua WhatsApp
  • 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 Origindriverhub.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

  • Gói driver ASUS WiFi chứa AsusSetup.exe, AsusSetup.ini, SilentInstall.cmd
  • Khi chạy, AsusSetup.exe đọc metadata driver từ AsusSetup.ini
  • Khi chạy AsusSetup.exe với cờ -s, nó thực hiện cài đặt im lặng không có GUI và chạy mục được chỉ định trong SilentInstallRun của AsusSetup.ini
    • DriverHub dùng cờ -s để cài đặt im lặng
    • Tệp INI gốc chỉ định script cmd cho cài đặt tự động không cần giám sát
    • SilentInstallRun cũng có thể chỉ định tệp thực thi khác
  • Trình tự tấn công hoàn chỉnh

    • Người dùng truy cập một website có miền dạng driverhub.asus.com.*
    • Site yêu cầu tệp thực thi PoC calc.exe bằng UpdateApp
    • calc.exe được tải xuống nhưng không chạy vì thất bại khi kiểm tra chữ ký
    • Tệp không bị xóa mà vẫn còn lại
    • Site yêu cầu AsusSetup.ini bị chỉnh sửa bằng UpdateApp
    • Tệp này cũng được tải xuống nhưng không được chạy
    [InstallInfo]
    SilentInstallPath=.\
    SilentInstallRun=calc.exe
    
    • Site yêu cầu binary AsusSetup.exe có chữ ký ASUS bằng UpdateApp
    • AsusSetup.exe được tải xuống rồi chạy với quyền quản trị viên
    • Vì DriverHub chạy nó với -s, nó đọc AsusSetup.ini
    • Theo SilentInstallRun=calc.exe, calc.exe được chạy với quyền quản trị viên

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

 
GN⁺ 2025-05-12
Ý 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

    • Tốc độ phản hồi lần này của ASUS khá ổn, và tôi không thấy vấn đề lớn ở đây. ASUS không phủ nhận lỗi, cũng không đe dọa kiện vì lý do reverse engineering phần mềm, và đã vá nhanh
      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
    • Cái tên “công bố có trách nhiệm” thật nghịch lý. Vì trên thực tế nó gần với một cách làm hoàn toàn vô trách nhiệm
      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
    • Cốt lõi là vấn đề luật hóa trách nhiệm. Các nhà sản xuất ô tô bị ra lệnh thu hồi và sửa chữa, nhưng các công ty phần mềm/phần cứng chịu áp lực quá yếu
      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
    • Dẫn lời CGPGrey, giải pháp đầu tiên nảy ra trong đầu thường rất tệ và không hiệu quả
      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
    • Có thể có một ý tưởng kinh doanh như thế này. Có lẽ đã tồn tại rồi cũng nên: tạo một dịch vụ môi giới và tổng hợp công bố
      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

    • Với một công ty nhỏ như Cisco thì cũng có thể hiểu được. Cisco cũng đã làm tương tự trong nhiều năm với vô số dịch vụ trực tuyến mà họ mua lại
      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
    • Nếu không có bug bounty, exploit sẽ đi ra chợ đen, hoặc là bị công bố toàn diện
    • Nhìn cách phản hồi như vậy, tôi không muốn mua sản phẩm ASUS nữa
    • Tôi không biết cụm “Asus là một startup nhỏ” từ đâu ra. Asus đã làm bo mạch chủ và linh kiện PC ít nhất từ thập niên 90 rồi
  • 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...

  • 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ỉ wildcard
    Nếu ai đó có wildcard thì họ đã có thể khai thác mà không lộ trong minh bạch chứng chỉ

    • Chứng chỉ wildcard chỉ áp dụng cho một cấp nhãn đơn. *.example.com. không dùng được cho test.test.example.com., nhưng dùng được cho test.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ưới driverhub.asus.com.example.com. và khiến nó trông hợp lệ
    • Ý hay nên giờ tôi đã kiểm tra, và xác nhận rằng không có gì đáng ngờ trong bản ghi wildcard
    • Đúng là có vùng mù với chứng chỉ wildcard. Nếu kẻ tấn công có chứng chỉ wildcard cho .example.com thì 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 domain driverhub.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
    • Thêm nữa, tôi cũng tò mò liệu chứng chỉ tự ký có hoạt động không. Những chứng chỉ như vậy không vào nhật ký minh bạch
      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

    • Bài blog thì hay
    • Driver WiFi mới nhất không hoạt động nên phải dùng phiên bản cũ hơn
  • Đ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/

    • Hoặc cũng có thể là sarcasm.com ;)
  • Đâ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”

    • Nhưng có nhà sản xuất mainboard nào “về cơ bản là ổn” không? Hay hãng lớn nào cũng có những câu chuyện tương tự?
      Hỏi giúp một người bạn sắp ráp PC mới
    • Chuyện này làm tôi tức, nhưng tôi tò mò không biết cách biện hộ mạnh mẽ nhất và hợp lý nhất cho lập trường của ASUS sẽ là gì
      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

    • Chắc vì họ là “startup nhỏ”
    • Phần mềm và hỗ trợ khách hàng của Asus thật tệ, và lúc nào cũng vậy