윈도우 드라이버 서명 우회로 커널 루트킷 설치 가능성

 (bleepingcomputer.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 겉으로는 최신 패치가 적용된 Windows라도 Windows Update 프로세스가 장악되면 오래된 커널 구성요소로 되돌아가 Driver Signature Enforcement 우회와 커널 루트킷 배포로 이어질 수 있음
  • SafeBreach 연구자 Alon Leviev는 BlackHat과 DEFCON에서 다운그레이드/버전 롤백 공격을 시연했으며, Windows Update takeover는 아직 완전히 패치되지 않은 상태로 남아 있음
  • 관리자 권한을 가진 공격자는 최신 Windows 11에서도 ci.dll을 패치되지 않은 버전으로 바꿔 서명되지 않은 커널 드라이버 로딩을 가능하게 만들 수 있음
  • Virtualization-based Security는 UEFI 잠금과 레지스트리 설정에 의존하므로, Mandatory 플래그가 없는 구성에서는 레지스트리 수정이나 핵심 파일 교체가 우회 경로가 될 수 있음
  • Microsoft는 오래된 VBS 시스템 파일을 폐기하는 보안 업데이트를 개발 중이지만, 영향 버전 조사·호환성 테스트·회귀 방지 때문에 공개 시점은 불분명함

최신 패치 상태를 무력화하는 다운그레이드 공격

  • 공격자는 Windows Update 프로세스를 제어해 최신 상태로 보이는 시스템에 오래된 취약 구성요소를 다시 넣을 수 있음
  • 운영체제는 여전히 완전히 패치된 것처럼 보이지만, 실제로는 이미 수정된 취약점에 다시 노출됨
  • 다운그레이드 대상에는 DLL, 드라이버, NT kernel 등이 포함됨
  • Alon Leviev는 Windows Downdate 도구를 공개해 사용자 지정 다운그레이드를 만들 수 있음을 보여줌

Driver Signature Enforcement 우회와 루트킷 위험

  • Leviev는 커널 보안이 강화된 이후에도 Driver Signature Enforcement(DSE) 우회가 가능하다는 점을 시연함
  • DSE 우회에 성공하면 공격자는 서명되지 않은 커널 드라이버를 로드할 수 있음
  • 이런 드라이버는 보안 제어를 비활성화하고 침해 탐지를 어렵게 만드는 루트킷 악성코드 배포에 활용될 수 있음
  • Leviev는 자신의 방식을 "ItsNotASecurityBoundary" DSE bypass라고 부름
    • 이 방식은 ItsNotASecurityBoundary 익스플로잇을 다운그레이드하는 형태임
    • 해당 익스플로잇은 Elastic의 Gabriel Landau가 식별한 Windows의 거짓 파일 불변성(false file immutability) 취약점 부류를 활용해 커널 권한의 임의 코드 실행을 가능하게 함

ci.dll 교체와 재부팅 조건

  • 새 연구에서 Leviev는 관리자 권한을 가진 공격자가 Windows Update 프로세스를 악용해 완전히 업데이트된 Windows 11에서도 DSE 보호를 우회할 수 있음을 보여줌
  • 핵심은 DSE를 강제하는 ci.dll을 드라이버 서명을 무시하는 패치되지 않은 버전으로 교체하는 방식임
  • 구성요소가 취약한 버전으로 다운그레이드된 뒤에는 정상 업데이트 과정처럼 시스템 재시작이 필요함
  • Leviev는 완전히 패치된 Windows 11 23H2 시스템에서 DSE 패치를 다운그레이드로 되돌린 뒤 해당 구성요소를 악용하는 시연을 공개함

VBS 설정이 약할 때 열리는 우회 경로

  • Leviev는 Microsoft의 Virtualization-based Security(VBS) 를 비활성화하거나 우회하는 방법도 다룸
  • VBS는 Windows의 필수 리소스와 보안 자산을 보호하기 위해 격리된 환경을 만듦
    • 보호 대상에는 보안 커널 코드 무결성 메커니즘인 skci.dll과 인증된 사용자 자격 증명이 포함됨
  • VBS는 일반적으로 UEFI 잠금과 레지스트리 구성 같은 보호 장치에 의존함
  • VBS가 최대 보안 설정인 “Mandatory” flag로 구성되지 않았다면, 표적 레지스트리 키 수정으로 비활성화될 수 있음
  • VBS가 부분적으로만 활성화된 경우 SecureKernel.exe 같은 핵심 VBS 파일을 손상된 버전으로 교체해 VBS 동작을 방해할 수 있음
    • 이 상태는 “ItsNotASecurityBoundary” 우회와 ci.dll 교체로 이어지는 경로를 열 수 있음

Microsoft 대응과 남은 공백

  • BlackHat과 DEFCON에서 공개된 다운그레이드 공격에 사용된 CVE-2024-21302와 CVE-2024-38202는 다뤄졌지만, Windows Update takeover 문제는 아직 남아 있음
  • Microsoft는 이 문제가 정의된 보안 경계를 넘지 않는다고 봤고, 관리자 권한으로 커널 코드 실행을 얻는 것은 보안 경계 침해가 아니라고 판단함
  • Leviev는 Microsoft가 문제를 수정하기 전까지 보안 솔루션이 다운그레이드 공격을 모니터링하고 탐지해야 한다고 강조함
  • Microsoft는 해당 위험을 막기 위한 완화책을 적극 개발 중이라고 밝힘
  • 회사는 오래되고 패치되지 않은 VBS 시스템 파일을 폐기하는 보안 업데이트를 개발 중임
    • 이 과정에는 영향받는 모든 버전 조사, 업데이트 개발, 호환성 테스트가 포함됨
    • 고객 보호와 운영 중단 최소화를 위해 통합 실패나 회귀를 피해야 함
    • 문제의 복잡성 때문에 업데이트 제공 시점은 불분명함
  • 10월 27일 업데이트에서 공격에는 관리자 권한이 필요하다는 점이 명확해졌고, Microsoft가 완화 조치를 취하지 않는다는 혼동을 줄이기 위한 정보가 추가됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • MS는 UAC가 보안 경계가 아니라고 말하는데, 이는 일부 사용자가 관리자 권한으로 올라가는 문제임
    그런데 이번 사례처럼 관리자에서 커널로 가는 것도 보안 경계가 아니라고 하면서, 동시에 드라이버 서명 강제는 보안 기능이라고 말함
    여기서는 바로 그 기능이 우회되고 있는데도 보안 경계를 넘은 게 아니라고 하니 앞뒤가 맞게 설명해줬으면 함

    • MS의 논리는 말이 됨. 빠뜨린 핵심이 있음
      UAC는 이미 관리자 그룹에 속한 사용자를 위한 것이지 “일부 사용자가 관리자가 되는” 기능이 아님
      보안 경계는 관리자 사용자가 아니라 표준 사용자 주변에 있음
      마음에 들지 않을 수는 있지만, 보안 경계를 원한다면 사용자를 Administrators 그룹에 넣지 않으면 됨
    • 이건 가치 체계의 불일치로 보임
      의견 충돌에는 대체로 정의의 불일치와 가치 체계의 불일치가 있다고 봄
      이 경우 Microsoft는 이 문제를 축소하는 데 가치를 두고 있고, 그게 우선순위 맨 위에 있다면 그들의 결정은 그 기준에서는 일관적으로 보일 수 있음
      정의의 불일치는 비교적 해결하기 쉬움. 예를 들어 소프트웨어 시스템 설계를 두고 모두가 디자인 패턴 용어로 말하지만, 각자가 A를 A′나 A″로 다르게 이해하면 큰 혼란이 생길 수 있음
    • Windows 버그를 고치게 하려면 유료 전문 지원을 사야 한다는 걸 배움
      기업이 관리하는 오픈소스 소프트웨어도 마찬가지임
      진짜 질문은 왜 사람들이 지적 에너지를 데스크톱 Linux 개선에 쓰지 않고 Microsoft를 위해 무료 보안 연구를 하느냐는 것임
    • 실제로 UAC는 보안 경계로 작동하지 않고, 그렇게 만들면 사용자가 너무 불편해져서 다른 운영체제로 떠날 것임
      UAC와 sudo는 둘 다 운영체제 수준의 쿠키 동의 창에 가깝고, 셋 다 없애는 편이 낫다고 봄
      UAC/sudo 같은 사용자 기반 권한 상승 방식은 포기하고, Android와 iOS처럼 사용자가 아니라 앱을 샌드박스해야 함
    • Microsoft에는 늘 이런 모순이 있었음. 아마도 전부 우회 방법이 많다는 걸 알고 있기 때문으로 봄

  • Windows와 Linux 모두에서 일반 권한 로컬 계정은 실제로는 거의 root 동등 권한처럼 동작한다는 점도 흥미로움
    Linux에서는 시스템 관련 작업 앞에 sudo를 붙이라고 훈련시키고, Windows에서는 UAC 프롬프트를 눌러 넘기라고 훈련시킴
    sudo가 비밀번호 오타 말고 다른 이유로 누군가에게 “안 된다”고 한 게 마지막으로 언제였나 싶음
    UAC는 시스템이 관리하는 UI인 반면 sudo는 그냥 프로그램이라, 공격자가 악성 셸 별칭으로 sudo를 바꿔 비밀번호를 훔칠 수 있다는 점에서 UAC가 약간 낫긴 함
    기본 설정에서는 sudo와 UAC를 없애고, root와 주 사용자의 로컬 계정 사이에 단단한 보안 경계가 있는 척하지 않는 편이 사용자에게도 더 편하고 실제 보안 상태에도 더 맞음

    • Linux에서는 현대적인 사용자용 애플리케이션 대부분이 sudo 대신 polkit을 사용함
      터미널에서도 sudo 대신 pkexec를 쓸 수 있음
      임의 명령을 root로 실행하는 대신 애플리케이션은 org.freedesktop.udisks2.filesystem-mount 같은 미리 정의된 동작을 사용할 수 있고, 사용자에게 앱이 무엇을 하려는지 지역화된 메시지로 보여줘 허용 여부를 결정하게 함
      시스템 관리자는 flatpak 업데이트처럼 특정 동작에 인증을 요구하지 않거나, 반대로 특정 동작을 완전히 차단하도록 설정할 수도 있음
    • 같은 말을 다르게 하면 훨씬 다르게 들림: Windows와 Linux 모두에서 기본 설치 사용자는 실제로 root 동등 권한에 가깝다는 것임
      설치를 수행한 사용자가 시스템을 통제해야 한다는 전제가 깔려 있다고 봄. 애초에 설치를 안 할 수도 있었으니까
      sudo도 UAC처럼 사람에게 “안 된다”고 말하는 장치가 아님. 둘 다 관리자가 예상하지 못한 관리 작업을 하려 할 때 사람이 “안 된다”고 말하도록 만든 것임
      관리자 권한이 없지만 그런 작업이 필요한 사람은 관리자의 승인을 받아야 함
      1인용 시스템이 아니라면, 기계를 설정하는 사람이 일상 사용용 제한 계정을 만들어야 함
    • Linux에서는 sudo를 설치하지 않음
      root가 될 일이 자주 없고, 필요할 때는 보통 여러 작업을 연달아 하기 때문임
      sudo는 회사 소유·관리 컴퓨터처럼 다중 사용자 컴퓨터에서, 관리자가 일부 사용자에게 제한된 특권 작업만 허용하고 싶을 때 유용하다고 봄
      root가 아닌 다른 계정을 항상 쓰는 주된 이유는 보안보다 실수 방지임. 의도하지 않은 파일을 삭제하거나 덮어쓰는 일을 피하려는 것임
      그래서 드물게 역할을 바꾸기 위해 비밀번호를 입력해야 하는 정도는 충분히 정당화된다고 봄
    • 내 경험상 적어도 Gnome에서는 Linux도 Windows식 sudo 보호 쪽으로 가고 있음
      다만 “확인하려면 ctrl+alt+delete를 누르라”는 트릭은 없음
      Windows는 모든 걸 스크립트로 짤 필요가 없다는 장점이 있음
      원하면 모든 도구를 runas/System.Management.Automation.PSCredential로 감쌀 수 있지만, 대부분의 경우 그럴 필요가 없음

  • 커널이 파일 열기 시 모든 열린 파일 핸들을 훑어 충돌하는 강제 잠금을 확인하면서 파일 공유 규칙을 강제하지만, 충돌 권한을 가진 메모리 매핑은 확인하지 않는 구조로 보임
    실수이긴 하지만 수정은 비교적 단순해 보임
    흥미롭게도 Linux는 강제 잠금의 마지막 흔적을 막 제거했음. 이제 로드된 실행 파일에 써도 EBUSY가 나지 않음
    같은 기능이 한 운영체제에서는 보안 인프라의 하중을 받치는 부분이고, 다른 운영체제에서는 지워야 할 레거시 찌꺼기라는 점이 흥미로움

  • 보안 전문가는 아니고 기본적인 것만 이해하지만, 뭔가 개념 모델을 놓치고 있는 듯함
    Windows는 왜 이렇게 해킹하기 쉬운지 궁금함

    • 가장 큰 이유를 아직 아무도 안 짚은 게 믿기 어려움
      Windows는 돈이 되는 표적, 특히 기업 환경에 가장 널리 배포된 데스크톱 운영체제라서 뚫는 데 많은 시간과 투자가 들어감
    • Windows는 보안이 중요해지기 전에 개발된 것이 문제임
      진정으로 안전한 컴퓨팅 플랫폼을 만들기 위한 투자가 충분히 이뤄지지 않았음
      이상적인 보안 플랫폼은 fdroid처럼 공개적으로 검증 가능한 인프라에서 재현 가능한 빌드를 제공하고, 신뢰할 수 없는 모든 애플리케이션을 샌드박스 안에서 가상화하며, 최소 권한 모델을 구현해야 함
      지금은 최악의 보안 상태임. CPU의 ME, UEFI 구성요소, 운영체제의 서드파티 드라이버까지 모든 링에서 정체를 알 수 없고 아마도 충분히 테스트되지 않은 불안전한 코드가 실행됨
      SeL4는 완전히 검증된 커널을 갖고 있지만 아직 가상화는 하지 않음
    • 서드파티 커널 수준 코드가 흔하다는 점도 중요한 요인임
      Windows 악성코드 상당수는 어느 시점에 취약한 서드파티 커널 드라이버에 의존함
      반대로 Linux에서는 서드파티 커널 모듈이 드물고 좋지 않게 여겨지며, macOS에서는 아예 금지됨
    • 내 경험상 문제는 사용자가 기본적으로 관리자라는 데 있음
      그리고 사용자에게 상승된 권한으로 아무거나 실행하게 설득하기가 너무 쉬움
    • 드라이버 서명 차단 목록 파일 DriverSiPolicy.p7b가 수년 동안 업데이트되지 않았음
      2022년에 CERT 분석가 Will Dormann이 왜 그런지 묻고 나서야 다뤄졌음
      지금은 정기적으로 업데이트되지만, 정말 어이가 없음 https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...

  • 이 건은 Microsoft 쪽 입장에 어느 정도 동의함
    관리자는 컴퓨터에 임의의 일을 할 수 있고, 새삼스러운 얘기는 아님
    심각도를 높이는 세부 차이가 있는지 모르겠음
    Raymond Chen이 이런 유형의 공격을 정리한 글도 참고할 만함
    https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

    • 내 생각도 같음
      누군가 이미 시스템의 임의 DLL을 바꿀 수 있다면, 이 “익스플로잇”이 작동하기 위한 전제조건이 이미 충족된 것이고, 그 시점에서는 모든 게 끝난 셈임
      드라이버 서명 우회 능력은 걱정거리 중에서도 아마 가장 작은 축에 들 것임

  • 공격이 수상할 정도로 단순해 보임
    업데이트 프로세스를 속여 알려진 취약점이 있는 오래된 커널 구성요소를 설치하게 만드는 방식임
    전문가가 아니어도 Microsoft가 이미 이런 걸 생각해서 차단 목록이나 폐기 메커니즘 같은 걸 갖고 있어야 할 것 같은데 궁금함
    근본 원인이 운영체제 설계 문제인지, 아니면 깨졌거나 나쁜 해시를 올바른 위치에 기록하지 못한 프로세스 실패인지가 핵심임
    후자라면 고치기 훨씬 쉽지만, 늘 그렇듯 약간 포장된 보안 공지는 전자를 주장하는 듯함

    • 기업 사용자가 업데이트 때문에 뭔가 깨지면 다운그레이드할 수 있어야 한다고 고집해서 허용해야 하는 것일 수도 있음

  • 데모가 있는데 Microsoft가 반박한다는 게 믿기 어려움
    그 Vimeo 계정에는 다른 보안 발견도 많이 있음. 예를 들어 WhatsApp이 Python 스크립트를 실행하는 것도 있던데, 진짜인지 사기인지 궁금함

  • Windows에서 Microsoft가 처음 드라이버 서명을 요구했을 때 [1]에서 모두가 겪었던 고생이 떠오름
    [2]용 심층 패킷 검사 드라이버를 만들고 있었는데, 처음 보기에는 Apple Store 앱 승인보다도 더 까다로운 절차처럼 보였고 문서도 전혀 명확하지 않았음
    회사들이 Microsoft 요구사항을 맞추느라 쏟아부은 자원을 생각하면, 이런 방식으로 악용됐다는 건 큰 후퇴처럼 느껴짐
    취약점은 언제나 있기 마련이지만, 누군가가 더 일찍 이걸 찾아냈다면 안심이 됐을 것임
    발견한 Alon Leviev와 SafeBreach에게는 박수를 보냄
    [1] https://www.nektra.com/
    [2] https://www.verizon.com/business/en-nl/products/security/man...

  • “관리자로서 커널 코드 실행을 얻어 가능”하다는 건, 결국 root 사용자가 rootkit을 설치할 수 있다는 평범한 얘기임
    멋진 이름을 붙이는 걸 잊지 말아야 함. 아, 이미 연구자가 Windows Downdate라는 도구를 공개했음
    0xF분짜리 명성은 확보했으니 잘한 셈임

    • 무엇이든 할 수 있는 root/슈퍼유저 계정이라는 개념은 흔하지만, 그건 운영체제 설계 선택임
      사용자 계정도 운영체제 안의 객체일 뿐이고, 슈퍼유저 계정을 제한하더라도 모든 사용자 계정에 특정 규칙을 강제하는 운영체제를 설계할 수 있음
      예를 들어 관리자 계정이 침해됐을 때도 TPM처럼 특정 비밀을 보호하거나, 관리자가 실수로 시스템을 부팅 불가능한 상태로 망가뜨리는 것을 막는 정당한 이유가 있을 수 있음
      더 논쟁적인 목표로는 DRM 강제도 있음
      Windows에서 Microsoft가 하려는 것도 바로 이것임. 운영체제가 관리자 계정이 커널에 간섭하거나 rootkit을 설치하는 것을 막으려 함
      이 논의에서는 운영체제 안의 관리자 사용자 계정과, 물리적·하드웨어 접근 권한을 가진 “관리자” 사람을 구분하는 것이 항상 중요함
    • 여기서는 15라고 쓰는 게 더 쉬웠을 텐데 0xF라고 쓴 게 궁금함
      잘못은 아니지만 묘한 선택이라 호기심이 생김. 그냥 스타일 때문이었는지 궁금함

  • Windows를 써야 할 때는 항상 그 컴퓨터가 이미 침해됐다고 가정함

답변달기