ASUS 사전 설치 드라이버 소프트웨어의 원클릭 RCE 취약점

 (mrbruh.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Windows 로그인 직후 설치될 수 있는 ASUS DriverHub가 웹사이트와 로컬 서비스를 연결하는 방식 때문에, 사용자가 특정 웹사이트를 방문하는 것만으로 관리자 권한 코드 실행까지 이어질 수 있었음
  • DriverHub는 GUI 없이 백그라운드에서 동작하며 driverhub.asus.com이 127.0.0.1:53000의 로컬 HTTP/WebSocket 서비스에 요청을 보내는 구조였고, Origin 검사가 driverhub.asus.com.* 형태의 도메인을 허용했음
  • UpdateApp 엔드포인트는 URL에 .asus.com 문자열만 포함되면 파일을 내려받았고, ASUS 서명 실행 파일은 관리자 권한으로 실행하면서 서명 검증에 실패한 파일은 삭제하지 않았음
  • 최종 익스플로잇은 서명되지 않은 calc.exe, 조작된 AsusSetup.ini, 서명된 AsusSetup.exe를 순서대로 내려받게 한 뒤 SilentInstallRun=calc.exe로 관리자 권한 RCE를 달성함
  • ASUS는 2025년 4월 수정본 배포를 확인했고 2025년 5월 9일 CVE-2025-3462와 CVE-2025-3463이 공개됐으며, 인증서 투명성 로그 기준으로 공개 전 활발한 악용 흔적은 보이지 않았음

웹사이트와 연결된 DriverHub 로컬 RPC

  • ASUS 마더보드 구매 후 Windows 로그인 직후 ASUS DriverHub 설치 완료를 위해 관리자 권한을 요청하는 알림이 표시됨
  • DriverHub는 별도 GUI가 아니라 백그라운드 프로세스로 동작하며, driverhub.asus.com에서 필요한 드라이버와 업데이트 대상을 안내함
  • 웹사이트는 로컬에서 실행 중인 DriverHub 프로세스와 RPC로 통신함
    • 로컬 서비스는 127.0.0.1의 고정 포트 53000에서 동작함
    • 웹사이트나 서비스가 이 로컬 포트로 API 요청을 보내는 구조임
  • 이런 구조에서 RPC 보호가 충분하지 않으면 공격자가 악성 애플리케이션 설치에 악용할 수 있음

느슨한 Origin 검사 우회

  • DriverHub는 아무 웹사이트의 요청을 모두 받지는 않았고, Origin 헤더가 driverhub.asus.com인 요청에 응답하도록 설계돼 있었음
  • 문제는 검사가 정확한 비교가 아니라 문자열 포함 또는 와일드카드에 가까운 방식이었다는 점임
    • origin == driverhub.asus.com 같은 직접 비교가 아니었음
    • driverhub.asus.com.mrbruh.com을 Origin으로 설정하자 요청이 허용됨
  • 공격자는 이 동작을 이용해 driverhub.asus.com.* 형태의 도메인에서 로컬 DriverHub RPC에 접근할 수 있었음

노출된 RPC 엔드포인트

  • 웹사이트 JavaScript와 실행 파일 디컴파일을 통해 여러 RPC 엔드포인트가 확인됨
  • 주요 엔드포인트는 다음과 같음
    • Initialize: 소프트웨어 설치 여부와 기본 설치 정보를 반환함
    • DeviceInfo: 설치된 ASUS 소프트웨어, 설치된 .sys 드라이버, 하드웨어 구성요소, MAC 주소를 반환함
    • Reboot: 확인 없이 대상 장치를 즉시 재부팅함
    • Log: DriverHub 로그 전체의 압축본을 반환함
    • InstallApp: 앱 또는 드라이버 ID로 설치를 수행하며, 앱 ID는 DriverHub 설치 프로그램이 제공하는 XML 파일에 하드코딩돼 있음
    • 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 체인에 필요한 조건을 여러 개 제공함
    • Url 파라미터에는 .asus.com 문자열이 포함돼야 했지만, example.com/payload.exe?foo=.asus.com 같은 형태도 허용됨
    • 파일은 URL 끝에 지정된 파일명으로 저장됨
    • 확장자와 관계없이 파일을 내려받을 수 있음
    • 파일이 ASUS 서명 실행 파일이면 관리자 권한으로 자동 실행됨
    • ASUS가 서명한 실행 파일이면 DriverHub 설치 프로그램이 아니어도 실행됨
    • 내려받은 파일이 서명 검사에 실패해도 삭제되지 않음
  • 처음에는 서명 검증 때문에 RCE가 어려워 보였지만, 서명 실패 파일이 남는 동작과 ASUS 서명 실행 파일의 설치 동작이 결합되면서 우회 경로가 생김

AsusSetup.ini를 이용한 익스플로잇 체인

  • ASUS WiFi 드라이버 패키지에는 AsusSetup.exe, AsusSetup.ini, SilentInstall.cmd가 포함돼 있었음
  • AsusSetup.exe는 실행 시 AsusSetup.ini에서 드라이버 메타데이터를 읽음
  • AsusSetup.exe를 -s 플래그로 실행하면 GUI 없이 조용한 설치를 수행하고, AsusSetup.ini의 SilentInstallRun에 지정된 항목을 실행함
    • DriverHub는 조용한 설치를 위해 -s 플래그를 사용함
    • 원래 INI 파일은 자동 무인 설치용 cmd 스크립트를 지정함
    • SilentInstallRun에는 다른 실행 파일도 지정할 수 있었음

  • 완성된 공격 순서

    • 사용자가 driverhub.asus.com.* 형태의 도메인을 가진 웹사이트를 방문함
    • 사이트가 UpdateApp으로 PoC 실행 파일 calc.exe를 요청함
    • calc.exe는 다운로드되지만 서명 검사에 실패해 실행되지 않음
    • 파일은 삭제되지 않고 남음
    • 사이트가 UpdateApp으로 조작된 AsusSetup.ini를 요청함
    • 이 파일도 다운로드되지만 실행되지는 않음
    [InstallInfo]
SilentInstallPath=.\
SilentInstallRun=calc.exe
    • 사이트가 UpdateApp으로 ASUS 서명 바이너리 AsusSetup.exe를 요청함
    • 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가 패치 완료와 검증용 빌드를 전달
    • 2025-04-18: ASUS가 수정본 배포를 확인
    • 2025-05-09: CVE-2025-3462 점수 8.4와 CVE-2025-3463 점수 9.4가 공개됨

악용 가능성과 관찰된 흔적

  • 신고 직후 VPS에서 certificate transparency 업데이트를 추적하는 스크립트를 실행해 driverhub.asus.com.* 도메인 등록 여부를 확인함
  • 다른 인증서 투명성 로그 웹사이트 기준으로 도메인과 서브도메인은 보통 한 달 안에 로그에 나타났음
  • 한 달 뒤 확인한 결과 정규식에 맞는 웹사이트는 테스트 도메인뿐이었음
  • 이 기준에서는 신고 전 활발히 악용됐을 가능성이 낮았음

ASUS 대응과 남은 이슈

  • ASUS는 버그 바운티를 제공하지 않고, 대신 hall of fame에 이름을 올리겠다고 답함
  • 이후 다른 보안 연구자 leonjza가 같은 Origin 검사 문제를 2025년 2월에 이미 신고했으며, ASUS는 이번 수정 시점까지 이를 고쳤음
    • ASUS는 이 사실을 별도로 알리지 않았음
    • cve.org 페이지에는 해당 연구자만 크레딧에 올라갔고, 추가 크레딧 반영은 하지 않겠다고 답함
  • ASUS Security Advisory form으로 취약점 보고서를 제출할 때 Amazon CloudFront가 첨부된 PoC를 악성 요청으로 탐지해 제출을 차단함
    • 일부 PoC 코드를 제거하고 녹화 영상 링크를 대신 제출해야 했음
  • DriverHub에서 각 추천 드라이버를 개별 설치하지 않고 “Install All”을 누르면 ArmouryCrate, ASUS의 커스텀 CPU-Z, Norton360, WinRAR도 함께 설치됨
  • ASUS의 CVE 설명은 RCE 범위와 영향을 좁게 표현함
    • 설명에는 “motherboards에 한정되며 laptops, desktop computers에는 영향이 없다”는 취지의 문구가 있었음
    • 실제로는 DriverHub가 설치된 desktops/laptops를 포함한 모든 컴퓨터에 영향이 있음
    • 임의 또는 원격 코드 실행 대신 “untrusted sources가 system behaviour에 영향을 줄 수 있다”는 식으로 표현됐음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 책임 있는 공개와 그 결과는 인류에게 재앙에 가까웠음. 회사들이 고객 보안을 더 진지하게 받아들이려면 훨씬 더 자주, 훨씬 더 큰 고통을 느껴야 함
    한 달을 주고 해결책까지 떠먹여 주면 그냥 백로그 티켓 하나가 될 뿐임. 보안 문제가 터질 때마다 온라인에서 충분히 큰 뉴스가 되어 CEO까지 관여하고 몇 달이 아니라 몇 시간 안에 해결책을 찾아야 한다면 훨씬 더 선제적으로 움직일 것임. 물론 최종 사용자가 가장 크게 피해를 보겠지만, ASUS를 산 시점에서 이미 고통받고 있기도 함

    • 이번 ASUS의 대응 속도는 꽤 괜찮았고, 여기서 큰 문제는 안 보임. ASUS는 버그를 부인하지 않았고, 소프트웨어 역공학을 이유로 고소하겠다고 협박하지도 않았으며, 빠르게 패치했음
      책임 있는 공개 이전 시대였다면 이 과정은 몇 달이 걸리고 경찰까지 끼어들었을 가능성이 큼. 일반 사용자는 취약점에 관심이 없고, 3년째 업데이트가 끊긴 휴대폰으로 금융 업무를 봄. 뉴스에 CVE를 계속 뿌리면 “모든 회사가 형편없다”는 얘기에 질려 실제 위협이 와도 무감각해질 것임
      EU는 다른 해법을 추진 중임. 새 사이버보안 규정에서는 알려진 취약점이 있는 제품을 매장에서 팔 수 없게 함. ASUS가 계속 망치면 메인보드는 재고가 되어버리고, 매장도 ASUS 하드웨어를 팔고 싶어 하지 않게 됨. 컴퓨터 하드웨어뿐 아니라 스마트 냉장고와 세탁기도 해당됨. 식기세척기 취약점을 발견하면 제조사가 펌웨어 업데이트 수단을 넣지 않았을 경우 업계에 수백만 달러 규모의 못 쓰는 재고를 만들 수도 있음
    • “책임 있는 공개”라는 이름은 역설적임. 실제로는 완전히 무책임한 방식에 가깝기 때문임
      대다수 기업은 공개를 형편없이 처리함. 제때, 예컨대 일주일 안에 고치지 않고, 공로 표기도 제대로 하지 않으며, 사용자에게 알리지도 않고, 실수에서 배우지도 않음. 무책임하게 지연된 제한 공개는 그런 행동을 강화함
      정말 책임 있는 방식은 즉시, 완전하게, 공개적으로 밝히는 것임. 필요하면 자신을 보호하려고 익명으로 할 수는 있음. 영향을 받는 회사가 반복적으로 제대로 대응한다는 걸 입증한 뒤에야, 예컨대 영업일 5일 정도의 아주 짧은 사전 통보 권리를 얻을 수 있음
      이런 무책임한 지연 제한 공개가 “책임 있는 공개”라고 불리는 것 자체가 뉴스피크의 한 사례임
    • 핵심은 책임 법제화의 문제임. 자동차 제조사는 리콜과 수리를 명령받지만, 소프트웨어·하드웨어 회사는 받는 압박이 너무 약함
      고객은 예를 들어 수정되지 않은 CVE가 있는 고장 난 기기에 대해 전액 환불을 받을 수 있어야 함
    • CGPGrey를 인용하면, 처음 떠오르는 해법은 대체로 끔찍하고 효과가 없음
      좋은 안전·보안 문화는 참여자들이 문제를 숨기지 않도록 장려함. 기업은 탐욕스러운 존재라 보안 실수를 숨기기 위해 무엇이든 할 것임
      한 달 안에 고칠 수 있는 합법적이고 수정 가능한 문제를 모두에게 공개하면, 악용될 가능성도 크게 올라감
    • 이런 사업 아이디어가 있을 수 있음. 이미 있을지도 모르겠지만, 공개 중개·집계 서비스를 만드는 것임
      제보자의 프라이버시를 보호하고, 보안 취약점을 검증하며, 공개하는 모든 취약점이 실제 악용 가능한지 확인함. 정해진 주기로 공개하고, 기업에는 자신에게 영향을 주는 공개 내용을 미리 받는 “조기 피드” 구독료를 받음. 그 돈으로 제보자에게 보상하고, 운영비를 내고, 일부 이익을 남김
      말하자면 기업에 약간 적대적인 버그 바운티 장터임. 이게 합법일지, 아니면 갈취로 볼지 궁금함

  • ASUS에 버그 바운티가 있냐고 물었더니 없다고 답하면서 대신 “명예의 전당”에 이름을 올려주겠다고 했다는 대목이 씁쓸함
    ASUS는 작은 스타트업이라 바운티를 줄 자본이 없을 테니 이해할 수 있다는 비꼼임

    • Cisco 같은 작은 회사에도 이해할 만한 일임. Cisco도 수년간 인수한 수많은 온라인 서비스에 대해 비슷하게 해왔음
      Cisco는 더 나아가 보안 공지 페이지까지 잊어버려서, 어떤 인정도 이제 허공으로 사라졌음
    • 버그 바운티가 없다면 익스플로잇은 암시장으로 가거나, 아니면 전면 공개로 가게 됨
    • 이런 대응을 보면 다시는 ASUS 제품을 사고 싶지 않아짐
    • “Asus는 작은 스타트업”이라는 표현이 어디서 나왔는지 모르겠음. Asus는 적어도 90년대부터 메인보드와 PC 부품을 만들어왔음

  • 놀랍지 않음. 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...

  • 인증서 투명성 로그를 보고 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를 악성 요청으로 판단해 막았다는 부분은, 웹 애플리케이션 방화벽이 안티패턴이라는 알림 같음: https://thedailywtf.com/articles/Injection_Rejection

  • “ASUS는 작은 스타트업이라 이해된다”니, 시가총액이 겨우 150억 달러인 작은 스타트업이라는 얘기임
    정말 이해하기 어려운 건 형편없는 제품뿐 아니라 고객을 위해 엄청난 일을 한 연구자까지 이렇게 대한다는 점임
    이런 일을 하고도 무시당하거나 깎아내려지는 연구자들이 안타까움. 너무 불공정함
    할 수 있는 일은 ASUS 제품을 사지 않는 것뿐임

  • ASUS에 버그 바운티가 있냐고 물었고, ASUS는 없지만 대신 “명예의 전당”에 이름을 올려주겠다고 답함. 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는 이를 바로잡을 기회가 있었다. 우리는 그 기회를 주려고 영상을 보류하고 있었다. 하지만 ‘좋다, 다만 약속한 내용을 기록으로 남기기 위해 촬영하겠다’고 하자마자 침묵이 돌아왔다”

    • 그래도 “기본적으로 괜찮은” 메인보드 제조사가 있긴 한가? 아니면 주요 업체마다 비슷한 이야기가 있는 건가?
      곧 새 PC를 조립하려는 친구를 위해 묻는 것임
    • 이건 화가 나는데, ASUS 입장을 가장 그럴듯하게 강하게 변호하면 뭐가 있을지 궁금함
      현실과 일치하는 쪽은 아마 이쪽일 것임. 이익을 쫓고 있고 그래도 넘어가니, 기록에 남아 나빠 보일 이유가 없고 그 시간에 마케팅이나 하는 편이 낫다고 보는 것임

  • 버그 바운티 없음은 말도 안 됨. 앞으로 ASUS 제품은 안 살 것임

    • “작은 스타트업”이라서 그런가 봄
    • Asus 소프트웨어와 고객 지원은 끔찍하고, 늘 그래왔음
답변달기