포스트

[프로세스와 잡] 보호 프로세스

[프로세스와 잡] 보호 프로세스
  • 윈도우 보안 모델에서 디버그 특권(관리자 계정 등)을 가진 토큰으로 실행하는 프로세스는 해당 머신에서 실행 중인 다른 프로세스에게 자신이 원하는 어떤 접근 권한이든 요청할 수 있다.
    • 다른 프로세스의 메모리에 접근해 읽기/쓰기
    • 코드 인젝션
    • 스레드 일시 중지/재실행
    • 프로세스 정보 얻기
  • 이런 동작은 디지털 권한 관리 요구사항(블루레이 미디어 등)에 대한 시스템 동작과 상충한다. 이러한 콘텐츠에 대해 신뢰할 수 있고 보호되는 재생을 지원하기 위해 보호 프로세스를 도입했다.
    • 보호 프로세스는 여타 프로세스가 요청할 수 있는 접근 권한에 상당한 제약을 둘 수 있다.
  • 보호 프로세스는 어떤 애플리케이션에 의해서든 생성될 수 있으나, 운영체제는 이미지 파일이 특수한 윈도우 미디어 인증서로 디지털 서명이 이뤄진 경우에만 프로세스가 보호되게 한다.
    • 오디오 디바이스 그래프 프로세스(audiodg.exe)는 보호된 음악 콘텐츠를 복호화하는 보호 프로세스이다.
    • 미디어 파운데이션 보호 파이프라인(mfpmp.exe) 역시 비슷한 이유로 보호 프로세스이다.
    • 윈도우 오류 보고 클라이언트 프로세스(werfaultsecure.exe)는 보호 프로세스 중 하나가 크래시될 때 해당 프로세스에 접근해야 할 필요가 있으므로 보호 프로세스로 실행될 수 있다.
    • 시스템 프로세스 자체도 보호 프로세스로 시작되는데, ksecdd.sys 드라이버에 의해 생성되는 복호화 관련 정보가 유저 모드 메모리상에 저장되기 때문이기도 하고, 시스템 프로세스가 갖는 핸들 테이블은 시스템의 모든 커널 핸들을 갖고 있기 때문에 무결성을 보장하기 위해서이기도 하다.
  • 커널 레벨에서 보호 프로세스를 지원하기 위해 두 가지 일이 행해진다.
    • 인젝션 공격을 피하기 위해 대부분의 프로세스 생성이 커널 모드 내에서 일어난다.
    • 보호 프로세스의 EPROCESS 구조체에 특수 비트가 설정되는데, 이로 인해 프로세스 관리자가 보안 관련 루틴을 수행할 때 일반적인 상황에서는 관리자 권한에 대해 허용되는 접근 권한이라도 거부하게 동작을 변경한다.
    • 보호 프로세스에 대해 허용되는 접근 권한은 PROCESS_QUERY/SET_LIMITED_INFORMATIONPROCESS_TERMINATE, PROCESS_SUSPEND_RESUME 뿐이다.
  • Process Explorer는 표준 모드 윈도우 API를 사용해 프로세스 내부의 정보를 질의하므로 보호 프로세스에 대해서는 특정 동작을 수행할 수 없다.
  • 커널 디버깅의 경우에는 커널 내부의 구조를 이용해서 이 정보를 얻으므로 완벽한 정보를 표시할 수 있다.
  • 보호 프로세스는 EPROCESS 구조체 내에 플래그를 통해 구별되므로, 관리자 계정에서 커널 모드 드라이버를 로드해 해당 플래그를 무력화할 수 있다.
    • 이런 행위는 PMP 모델을 어기는 것이므로 악성 행위로 간주된다.
    • 코드 서명 정책에서는 악성 행위를 하는 코드에 대한 디지털 서명을 금지하므로 64비트 시스템에서 차단된다.
    • 패치가드(PatchGuard)로 알려진 커널 모드 패치 보호 및 보호 환경과 인증 드라이버(peauth.sys) 또한 이런 악성 행위를 인지한다.

보호 프로세스 라이트(PPL)

  • 보호 프로세스의 최초 모델은 DRM 기반의 콘텐츠에 집중했으며, 이후 보호 프로세스 라이트(Protected Process Lite)라는 보호 프로세스 모델의 확장이 도입됐다.
  • 이는 전통적인 보호 프로세스와 의미적으로 동일하게 보호된다. 즉, 유저 모드 코드는 스레드를 인젝션하거나 로드된 DLL에 관한 상세한 정보를 구함으로써 보호 프로세스를 뚫을 수 없다. 하지만 PPL 모드는 추가적인 보호의 단계(속성값)을 가진다. 서명자 간의 신뢰 수준이 달라 특정 PPL은 다른 PPL보다 더 많거나 더 작은 보호가 이뤄지게 한다.
  • 표준 보호 프로세스는 현재 서명자 값에 기반을 두고 구분된다. 예를 들어, PROCESS_TERMINATE는 특정 PPL 서명자에게는 허용되지 않는다.
    • WinSystem은 가장 높은 우선순위의 서명자로서 메모리 압축 프로세스와 같은 시스템 프로세스와 최소 프로세스에 사용된다.
    • 유저 모드 프로세스의 경우 WinTCB가 가장 높은 우선순위를 가진 서명자이며, 임계 프로세스 보호에 이용된다.
  • 프로세스의 보호 수준은 로드가 허용되는 DLL에 영향을 준다.
    • 이러한 동작이 없으면 논리적 버그나 단순한 파일 교체 및 변조를 통해 적법한 보호 프로세스가 서드파티나 악의적 라이브러리를 로딩하는 것에 함께 강제적으로 딸려갈 수 있다. 이렇게 되면 이들은 보호 프로세스와 동일한 보호 수준으로 실행한다.
    • 이 검사는 EPROCESSSignatureLevel 필드에 저장된 서명 레벨로 각 프로세스를 승인한 다음 EPROCESSSectionSignatureLevel 필드에 저장된 해당 DLL 서명 레벨을 내부 룩업 테이블을 이용해 찾아봄으로써 구현한다.
    • 프로세스에서 어떤 DLL 로딩이든 코드 무결성 컴포넌트에 의해 주요 실행 파일을 검증하는 것과 동일한 방식으로 이뤄진다.
    • 실행 파일 서명자가 WinTCB인 프로세스는 Windows나 그 이상으로 서명된 DLL만을 로드한다.
  • 윈도우 10에서 smss.execsrss.exe, services.exe, wininit.exe 프로세스는 WinTCB-Lite로 서명된 PPL이다. lsass.exe는 ARM 윈도우에서 PPL로 실행하며, 정책에 의해 PPL로 구성된다면 x86/x64에서도 PPL로 실행할 수 있다.
  • AppX 사용 서비스와 WSL 같은 다수의 서비스 또한 보호 모드로 실행하므로 이런 보호 레벨을 갖고 실행하는 특정 svchost.exe도 볼 수 있다.
  • 이런 핵심 시스템 바이너리가 TCB로서 실행한다는 것은 사실 시스템 보안에 치명적이다.
    • 예를 들어 csrss.exe는 윈도우 관리자(win32k.sys)에 의해 구현된 특정 비공개 API에 접근할 수 있다. 이는 공격자들이 관리자 권한으로 커널의 민감한 부분에 접근할 수 있게 한다.
    • 비슷하게 smss.exewininit.exe는 시스템 시작 부분과 관리자의 개입 없이 수행하기에는 너무나 중요한 관리 부분을 구현한다.
  • 윈도우는 이들 바이너리를 항상 WinTCB-Lite로 실행하게 보장한다. 예를 들어 CreateProcess를 호출할 때 프로세스 속성에 정확한 프로세스 보호 레벨을 지정하지 않고는 프로세스를 시작할 수 없다. 이런 보장 방식은 최소 TCB 목록(minimum TCB List)이라 하며, 호출자의 입력 값에 관계없이 최소 보호 레벨과 서명 레벨을 갖게 강제한다.
Process Explorer에서 보호 프로세스 살펴보기
  • Process Explorer를 실행하고 Process Image 탭에서 Protection 체크박스를 선택하면 Protection 열을 볼 수 있다.
  • DLL을 보도록 구성한 상태에서 보호 프로세스를 선택하고 하단을 살펴봐도 아무것도 보이지 않는다. Process Explorer는 로드된 모듈을 질의할 때 유저 모드 API를 사용하고, 보호 프로세스를 접근하는 데 승인이 되지 않는 접근을 필요로 하기 때문이다.
  • 시스템 프로세스지만 시스템 프로세스에는 DLL이 존재하지 않아서 Process Explorer는 대신 로드된 커널 모듈의 목록을 보여준다. 이는 프로세스 핸들을 필요로 하지 않는 시스템 API인 EnumDeviceDrivers를 이용해 이뤄진다.
  • Handle 뷰를 보면 완전한 핸들 정보를 볼 수 있다. Process Explorer는 시스템의 모든 핸들을 반환하는 문서화되지 않은 API를 이용하며, 이 API는 특정 프로세스 핸들을 요구하지 않는다. 이들 API는 각 핸들과 관련된 PID를 반환하기 때문에 Process Explorer는 해당 프로세스를 식별할 수 있다.

서드파티 PPL 지원

  • PPL은 마이크로소프트가 만든 실행 파일의 범주를 벗어난 프로세스에 대해서도 보호하도록 그 가능성을 확장할 수 있다. 일반적인 예로는 안티멀웨어 소프트웨어가 있다.
  • 통상적인 안티멀웨어 소프트웨어는 다음과 같은 컴포넌트로 구성된다.
    • 파일 시스템과 네트워크에 대한 I/O 요청을 가로채서 객체와 프로세스, 스레드 콜백 사용 기능의 차단을 구현하는 커널 드라이버
    • 드라이버의 정책을 구성하는 유저 모드 서비스(일반적으로 특권 계정에서 실행). 이런 서비스는 관심 이벤트에 대해 드라이버로부터 통지를 받고 로컬 서버나 인터넷과 통신할 수 있다.
    • 사용자와 정보를 주고받으며 사용자로 하여금 해당하는 경우에 대해 선택적으로 결정을 하게 허용하는 유저 모드 GUI 프로세스
  • 멀웨어가 시스템을 공격할 수 있는 한 가지 방법은, 상승된 권한으로 실행하는 프로세스에 코드를 인젝션하거나 더 뛰어난 기법으로 안티멀웨어 서비스에 특수하게 코드를 인젝션해 안티멀웨어를 조작하거나 동작을 무력화시키는 것이다.
    • 하지만 안티멀웨어 서비스가 PPL로 동작한다고 해도 코드 인젝션은 불가능하고 프로세스 종료도 허용되지 않는다.
    • 이는 소프트웨어가 커널 수준의 취약점 공격을 이용하지 않는 멀웨어로부터 좀 더 안전하게 보호된다는 것을 의미한다.
  • 이렇게 사용하려면 안티멀웨어 커널 드라이버는 초기에 시작하는 안티멀웨어 드라이버(ELAM; Early-Launch Anti Malware)를 가져야 한다.
    • 이런 드라이버는 마이크로소프트가 제공하는 특수한 안티멀웨어 인증서를 가져야 한다.
    • 일단 설치되면 자신의 주요 실행 파일(PE) 내에 ELAMCERTIFICATEINFO로 불리는 맞춤형 자원 섹션을 포함할 수 있다.
    • 이 섹션은 세 가지 추가적인 서명자를 기술할 수 있으며, 각각 세 개까지의 추가적인 EKU를 가질 수 있다.
    • 코드 무결성 시스템이 이들 세 서명자 중 하나에 의해 서명된 파일을 식별하면 프로세스가 PS_PROTECTED_ANTIMALWARE_LIGHT PPL 요청을 하도록 허용한다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.