윤근용 happyme9@nhncorp.com | 필자는 시스템 프로그래머로 시스템에 대한 다양한 분야에 관심이 많다. 특히 보안 문제에 대한 관심이 높아 다년간 보안 업무에 종사하고 있다. 바이러스 보안 업체를 거쳐 현재는 NHN에서 주로 보안 관련 프로젝트를 수행하고 있다.
루트킷은 자신을 감추기 위해서 다양한 기술을 이용한다. 가장 대표적인 것이 후킹을 이용하는 방법이다. 주로 SSDT 후킹과 같은 커널 레벨에서의 후킹이 많이 사용되는데 이를 위해서는 루트킷이 커널 드라이버 형태로 작성돼야 한다. 루트킷은 스스로를 더욱 교묘하고 은밀하게 숨기기 위해 커널 패치와 같은 로우 레벨의 조작을 수행하는 경우가 많으며, 심지어는 BIOS와 같은 펌웨어를 이용하기도 한다. 가상화 기술을 이용하는 루트킷 기술은 이제 더 이상 새로운 것이 아니며, 이미 새로운 위협으로 예상되어 왔다. 하지만 현재 대부분의 보안 제품으로는 탐지하기 힘들다면 것이 문제라고 할 수 있다. 즉 가상화 기술을 이용해서 자신의 VM(Virtual Machine) 안에서 독자적으로 루트킷이 실행된다면 현재의 보안제품으로는 탐지가 불가능하다. 따라서 악성 코드가 가상화 기술을 이용하는 경우에는 문제가 더욱 심각하다.
가상화의 위협
루트킷 탐지가 어려운 이유 중 하나는, 루트킷 탐지 소프트웨어와 동일한 레벨의 권한을 가지고 수행된다는 것이다. 대부분의 루트킷 탐지 소프트웨어는 커널 레벨에서 동작하지만 루트킷 또한 커널 레벨에서 동작하는 커널 드라이버 형태로 많이 작성된다. 따라서 서로 동일한 능력을 가지고 대치되기 때문에 탐지 및 무력화가 쉽지 않은 것이 현실이다. 따라서 어느 한쪽이 더 높은 권한을 가진다면 승패는 한쪽으로 기울 것이다. 커널 레벨보다 한 층 더 높은 권한을 부여 받을 수 있는 방법이 바로 가상화다. 가상화로 커널 레벨보다 높은 권한을 갖는 루트킷은 커널 레벨에서 동작하는 루트킷 탐지 소프트웨어를 무력화 시킬 수 있다(<그림 1> 참조). 이와 반대로 루트킷 탐지 소프트웨어가 커널 레벨보다 더 높은 권한을 갖는다면 커널 레벨에서 동작하는 루트킷은 부처님 손바닥 안의 손오공 신세가 돼 버릴 것이다(<그림 2> 참조).
.jpg)
가상화
가상화(Virtualization)라는 용어는 다양한 분야에서 사용된다. 컴퓨터 시스템에서의 가상화는 시스템의 유효한 리소스(하드웨어, 운영체제, 데이터 등)를 보다 효율적으로 사용하기 위해서 연구되어 왔다. 그 중 하나가 운영체제 가상화인데, 이는 하드웨어 리소스가 부족했던 6~70년대 VMM(Virtual Machine Monitor)이라는 개념으로 출발했다. VMM은 하드웨어와 운영체제 사이에 위치해서 하드웨어에 대한 리소스(CPU, Memory, Physical Disk)를 가상화한다. VMM이 운영체제에게 제공하는 인터페이스는 하드웨어가 운영체제에게 제공하는 인터페이스와 동일하기 때문에 운영체제 입장에서는 VMM의 존재 여부에 영향을 받지 않고(존재 자체를 모르고) 동작할 수 있으며, VMM에 의해서 동시에 여러 운영체제가 동작할 수 있다.
하이퍼바이저
하이퍼바이저(Hypervisor)란 하나의 시스템에서 동시에 여러 개의 운영체제를 사용할 수 있게 해주는 가상화 플랫폼을 말한다. 가장 대표적이고 쉬운 예로 VM웨어를 들 수 있다. 하이퍼바이저는 다음과 같이 크게 두 가지 형태로 구분된다. 물론 아래의 두 형태가 복합된 형태 또한 가능하다. Type 1에서는 VMM (Virtual Machine Monitor)이 Host 운영체제 안에서 동작한다.
.jpg)
Type 2에서는 VMM(Virtual Machine Monitor)이 하드웨어와 게스트 운영체제(Guest OS) 사이에 존재한다.
.jpg)
다음은 Type 1형태로 구현된 VM웨어의 내부 구성요소이다.
- VMApp : 유저 레벨 애플리케이션(Host OS의 App로써 동작)
- VMDriver : 호스트 시스템을 위한 디바이스 드라이버(Host OS의 커널에서 동작, 호스트 운영체제와 게스트 운영체제 간의 실행 context switching을 담당한다.)
- VMM : VMDriver가 로드되면서 생성되는 virtual machine monitor
소프트웨어 가상화
IA-32에서 운영체제는 Ring 0, 애플리케이션은 Ring 3 권한으로 동작한다. 하지만 가상화 환경에서는, 하드웨어와 직접 연결되어 가상화를 수행하는 VMM이 Ring 0 권한으로 실행돼야 한다. 이때, 운영체제도 동일하게 Ring 0 권한으로 실행되면 운영체제가 VMM 코드를 제어할 수 있을 뿐만 아니라 VMM에 의한 가상화 자체가 불가능해 진다. 따라서 운영체제는 VMM보다 낮은 권한을 부여한다. 이러한 작업을 Ring Deprivileging이라고 하는데, Ring Deprivileging은 다음과 같은 두 가지 형태로 수행된다.
♦ VMM : Ring 0
Guest OS : Ring 1
App : Ring 3
♦ VMM : Ring 0
Guest OS : Ring 3
App : Ring 3
이렇게 운영체제의 실행 권한이 하향 조정됨으로써 야기되는 문제점 때문에 VMM의 역할 비중이 커졌다. 즉 운영체제가 하드웨어에 접근하는 작업이나 특정한 시스템 콜과 같이 Ring 0 권한이 요구되는 작업을 모두 모니터링해서 그에 맞는 작업을 수행해야 한다. 동시에 여러 개의 운영체제가 동작 중이라면 이들에 대한 Context Switching을 VMM이 담당해야 한다. 실행권한 변경에 따른 문제점을 극복하기 위해서 Paravirtualization, Binary Translation 등의 방법들이 이용됐다.
하지만 Paravirtualization은 운영체제의 커널을 수정해서 특정한 VMM에서 가상화가 가능하도록 하는 것인데, 이는 리눅스와 같은 오픈소스 운영체제에서나 가능한 일이며 일반적으로 적용할 수 있는 방법이 아니다. 또한 Binary Translation은 상대적인 성능상의 부하가 문제가 된다. 이런 소프트웨어 가상화에 의한 문제점을 해결해 주는 것이 CPU 레벨의 가상화라고 할 수 있다. 즉 가상화를 구현하기 위해서 사용된 Paravirtualization, Binary Translation과 같은 작업을 CPU 레벨에서 지원하는 것이다.
하드웨어 가상화
인텔, AMD의 CPU 레벨에서 제공하는 하이퍼바이저를 하드웨어 가상화라고 할 수 있다. 인텔이나 AMD에서 CPU 레벨의 가상화를 지원하기 전까지는 대부분 소프트웨어 가상화에 의존해왔다. 하지만, IA-32 자체가 가상화에 맞지 않는 구조를 가지기 때문에, (애초에 하나의 운영체제만 동작하도록 설계됨) 소프트웨어 가상화 구현의 어려움 뿐만 아니라 그에 따른 부가적인 문제점을 갖게 된다.
인텔
- VT(Virtual Technology, 코드명: Vanderpool) 간단히 IVT라고 한다.
- IA-32 기반 CPU에서의 IVT를 VT-x라고 하며 IA-64(itanium)기반 CPU에서의 IVT를 VT-i라고 한다.
- 제공 CPU: 일부 펜티엄 4, Xeon, 코어듀오, 코어 2 듀오 프로세서(IVT기능을 지원하는 정확한 인텔 CPU 목록은 http://process orfinder.intel.com에서 조회 할 수 있다.)
AMD
- AMD-V(AMD Virtualization, 코드명: Pacifica)
- 제공 CPU: (64비트 x86 아키텍처) AMD 애슬론 64, 애슬론 64×2, 튜리온 64?2, 옵테론, 페놈
VT-x
이제 인텔 CPU에서 제공하는 VT-x에 대해서 간단히 살펴보자. VT-x에서는 VMX(Virtual Machine Extension)라는 실행 모드를 지원함으로써 가상화를 가능케 한다. VMX는 두 가지 모드로 나뉘는데, VMX root operation(fully privileged Ring 0) 모드와 VMX non-root operation(less privileged Ring 0) 모드이다. 여기서 VMM은 VMX root operation 모드로 동작하고 VM은 VMX non-root operation 모드로 동작한다. VMX root operation 모드는 몇 가지를 제외하고는 일반적인 CPU 동작 모드와 거의 동일하다. VM non-root operation 모드에서의 CPU 작업은 가상화를 지원하기 위해서 제약되거나 변경된다. 더 정확히 말하면 root operation 모드로 동작하는 VMM은 Ring 0 보다 권한이 높고, non-root operation 모드로 동작하는 게스트 운영체제는 Ring 0, App는 Ring 3 권한으로 동작한다. VMX의 동작 모드 변경은 다음 두 가지 경우가 있다.
♦ VM entry: VMM이 VMX non-root operation 모드로 VMX not-root operation 모드로 동작하는 VM의 코드(운영체제, 애플리케이션)가 실행된다.
♦ VM exit: VMM이 VMX root operation 모드로 VMX root operation 모드로 동작하는 VMM으로 CPU 제어권이 반환된다.
VMS operation의 시작과 종료는 VMXON, VMXOFF 명령에 의해서 수행된다. 특정한 명령이나 이벤트(예외 발생, I/O 디바이스 접근, 특정 레지스터 접근 등)가 발생하면 VM exit에 의해서 VMX root operation 모드가 된다. VMCS(Virtual Machine Control Structure)의해서 VMX의 모드 변경과 VMX non-root operation이 관리된다(AMD-V의 경우는 VMCB (Virtual Machine Control Block)).
.jpg)
<그림 5>에서 보는 바와 같이 루트킷 디텍터 등의 보안 프로그램은 어디까지나 루트킷 VM에 의해서 로드되고 컨트롤 되는 하나의 게스트 운영체제 상의 커널 모듈이거나 일반적인 애플리케이션일 뿐이다. 따라서 이런 구조에서의 루트킷 탐지는 거의 불가능하다(100 퍼센트 불가능한 것은 아님).
.jpg)
가상화 기술을 이용하는 루트킷
이제 앞에서 언급한 가상화 기술을 이용하는 루트킷에 대해서 알아보자.
SubVirt
SubVirt는 마이크로소프트와 미시간 대에서 가상화 기술을 이용한 루트킷이 가능한지 여부를 증명하기 위해서 만든 것이며, 기존의 가상화 소프트웨어(VM웨어, 버추얼-PC)를 이용한 것이므로 진정한 의미의 가상화를 이용한 루트킷이라고 보기 힘들다. SubVirt는 호스트 운영체제로 리눅스를 이용하며 시스템의 Boot Sequence를 수정해서 원래의 운영체제를 로드한다.
Vitriol
Dino Dai Zovi에 의해서 개발된 VM 루트킷으로써 MaxOS X 운영체제에서 동작하며 인텔 VT-x(인텔 코어듀오/솔로)기술을 이용했다(2006년 10월 마이크로소프트의 BlueHat 컨퍼런스에서 발표되었다).
BluePill
Vista x64(AMD 64)에서 AMD-V를 이용한 VM 루트킷. BIOS 수정이나 SubVirt처럼 Boot Sequence를 변경시키는 작업을 수행하지 않으므로 재부팅 없이 언제든지 설치가 가능하며 어떤 입출력에 대해서도 가상화를 않기 때문에 성능상의 부하가 거의 없다.
.jpg)
현재 그리고 미래
루트킷과 악성코드를 구분하는 게 모호하긴 하지만 엄밀히 말하면 같지는 않다. 루트킷과 악성코드의 결합, 정확히 말하면 악성 코드가 루트킷 기술을 사용하면(이미 이런 악성코드가 많은 것이 현실이다.) 더욱 강력한 공격력과 전파력을 보유한다. 그러면 탐지나 방어, 치료(제거)와 같은 후속 조치가 더 어려워질 것이다. 사실, MPack과 같은 공격 툴킷이 거래되고 있는 블랙마켓이 존재하는 것이 현실이다. 심지어 악의적인 행위 자체도 거래가 된다. 이를 통한 잠재적인 피해 규모는 산정하기 힘들 정도다. 예전에는 악성 코드를 여러 형태로 분류했지만 이미 오래 전부터 대부분의 악성코드가 복합적인 성격을 띄기 시작했다. 서로간의 사용 기술을 복합적으로 사용하고 있을 뿐만 아니라 목적 자체도 복합적인 것들이 많아졌다.
CPU에서 제공하는 가상화 기능을 이용하는 것은 단지 루트킷의 은닉 기술 중 하나일 뿐이다. 가상화 이외에도 하드디스크의 사용하지 않는 섹터를 이용해서 은닉하는 기술, ATAPI 스펙을 이용한 은닉과 같이 탐지가 불가능한 경우가 상당히 많다. 가장 무서운 것은 알려지지 않은 루트킷, 좀더 정확히 말하면 알려지지 않은 기술을 사용한 루트킷은 존재여부 조차도 모르고 있다. 더 큰 문제는 기존의 보안 프로그램이 교묘한 방법을 사용하지 않고 전통적인 기술을 사용하는 루트킷도 만족스럽게 탐지하지 못한다는 점이다. 탐지해도 안전하게 제거하는 기술은 아직 미흡한 실정이다. 루트킷 탐지를 위한 기술 영역뿐만 아니라 루트킷을 안전하고 완벽하게 제거하는 기술 영역도 지속적인 연구가 필요하다. 현재까지 안정적으로 루트킷을 탐지할 수 있는 증명된 기술은 없다. 루트킷이 사용하는 기술과 보안 소프트웨어가 사용하는 기술이 크게 다르지 않기 때문에 누가 먼저 새로운 기술을 이용하느냐에 따라서 그 승패가 좌우된다. 마이크로소프트에서 얼마 전에 코모쿠(komoku)라고 하는 안티 루트킷 솔루션 업체를 인수했다는 소식은 시사하는 바가 크다고 할 수 있다.