정보보호 관련 잡지에 연재중인 ActiveX 관련 2회 내역. 개인적으로는 중요한 회사일과 원고마감일이 겹쳐서 무척이나 힘들었다.

(참조 이미지도 상당량인데, 이미지 업로드에 대한 귀차니즘 때문에 이미지는 전체 생략. OTL)

-----------------------------

[글 싣는 순서]

1. 비판적 시각에서의 ActiveX 기술

2. ActiveX 취약점에 대한 이해와 보안 <-- 이번회

ActiveX는 1996년 초에 발표되었으며, 잘 알려진 바와 같이 ActiveX는 COM(Component Object Model)의 확장판의 성격을 가지며, DCOM(Distributed COM)을 거쳐서 현재의 .NET 전략으로 통합되는 양상을 띄고 있다. 사실상 ActiveX는 SUN의 JAVA에 대한 대안의 성격으로 발표되었다고 보는 것이 맞다고 보며, 당시 마이크로소프트의 API 혁명이라고 불릴만한 OLE(Object Linking and Embedding) 기술은 OLE로 연결된 개체가 다른 응용프로그램에서도 적용되고, 작동될 수 있도록 하는 것을 의미한다. 물론 이러한 것은 DOS 시절에는 불가능하던 것들 이었다.

위에서도 잠시 언급했지만, ActiveX를 SUN의 JAVA에 대한 아류작 정도로 생각하는 경우도 존재하는데, MS가 SUN의 JAVA에 대한 대안적 의미의 기술을 제시했지만, 그 적용 방식에 있어서는 SUN의 JAVA와 상당한 차이를 보이고 있다. 간단히 몇 가지만을 보면 아래와 같다.

구분	ActiveX	JAVA
플랫폼 의존성	플랫폼 의존	플랫폼 독립적
구현 언어	다양한 언어로 구현 가능	JAVA Applet은 JAVA로만 구현 가능
해석 방식	Compile 방식	Interpreter 방식
속도	빠름	상대적으로 느림
구현	IE에서 동작	거의 모든 브라우저에서 동작

JAVA의 기본 보안 모델은 신뢰할 수 없는 코드를 샌드박스(Sandbox, 아이들이 다치지 않고 놀 수 있는 모래로 만들어진 공간으로써, 안전한 공간 또는 격리된 공간을 의미)에서 실행하지만, ActiveX의 기본 보안 모델은 신뢰할 수 없는 코드는 아예 실행하지 않는 모델이라고 볼 수 있다. 따라서 ActiveX에 Sandbox에서 실행된다는 개념은 없으며, 이미 수없이 많이 본 저작자 서명된 컨트롤을 허용할 지의 여부를 물어보게 되는데, 사실 이 신뢰 모델의 중심에는 전자서명(Digital Sign)이 있다. 이러한 전자서명은 개발자가 배포한 올바른 배포본이 맞는지, 다른 누군가에 의해 배포본이 수정되지는 않았는지의 여부를 효과적으로 검증 가능하게 한다. 문제는 전자서명이 되어 있다고 해서 이것이 악의적인 공격 코드를 포함하고 있는지, 특정 시스템 명령을 악용하는지 등 안전성 여부에서 자유롭다는 것을 의미하지는 않는다.

문제의 중심에는 바로 이러한 신뢰모델이 문제가 되는데, MS는 기본적으로 서명된 ActiveX 컨트롤은 허용하고, 서명되지 않은 ActiveX 컨트롤은 불허하는 방식이다. 설명만 들으면 그럴 듯 해 보일 수도 있으나, 이것은 서명된 ActiveX 컨트롤이 올바른 배포본이고, 악의적인 코드가 포함되어있지 않다는 필요충분조건이 만족해야 가능한 시나리오이다. 또한, 사용자는 특정 서비스를 이용하기 위해 본인이 명확히 모르고, 원하지도 않는 ActiveX 컨트롤의 허가 및 불허 여부를 강요당하는데, ActiveX의 컨트롤 운영 방식은 전부가 아니면 허용하지 않는 방식이기 때문에 무심코 받아들인 ActiveX 컨트롤은 사용자가 할 수 있는 모든 접근권한을 갖게 된다고 볼 수 있다. 이때, 사용자의 시스템에 존재하는 특정 개인정보를 빼가거나, 시스템 명령 수행을 통해 악의적 행위가 이루어지게 되면, 사실상 사용자가 할 수 있는 일은 거의 없다고 보면 된다. 바로 이러한 부분에서 JAVA와 ActiveX는 현격한 구현상의 차이를 보이는 부분이기도 하다.

보안 측면에서 ActiveX가 갖는 의미는 공격 방식의 변화를 의미하며, 기존의 PC<->System, PC<->Network, PC<->PC의 1차원적 공격을 벗어났다는 것을 의미한다. 기존의 공격 방식은 1:1 공격이 주류를 이루고, 이러한 공격 방식은 Layer 4(Transport Layer) 기반의 IP, Port 기반의 접근제어(Access Control)로 방어할 수 있는 성격의 취약점 들 이었다. 하지만, 이러한 공격 방식은 공격자들에게는 하나의 장벽이지만 뛰어넘지 못할 정도의 것은 아니었으며, 새로운 공격방식으로 등장한 어플리케이션 취약점에 주목하기 시작했다.

이는 WWW의 폭발적인 성장으로 인해 인터넷이 업무 그 자체가 되는 시대에 웹 클라이언트에서 이용 가능한 자바스크립트나 VB 스크립트와 같은 프로그래밍 언어 및 자바애플릿과 ActiveX 컨트롤 등의 개념이 지속적으로 생겨나면서 공격자와 사용자 사이에 다양한 커뮤니케이션의 연결고리가 생겼다는 것을 의미하며, 이는 공격 방식이 기존의 1:1에서 1:n으로 변화되었다는 것을 의미한다. 이는 기존의 공격 방식이 Layer 4(Transport Layer)에서 Layer 7(Application Layer) 계층으로 변화되었다는 것을 의미하며, 좀 더 정확히는 기존의 접근제어 체계를 우회하여 효과적으로 공격 가능한 루트 확보에 성공했다는 것을 의미한다. 따라서 공격자가 어플리케이션 공격에 주목했다는 의미는 기존의 IP, Port 기반의 접근제어(Access Control)의 영향을 받지 않는다는 것이라고 볼 수 있으며, 좀 더 정확히는 기존의 방화벽 기술이 이러한 어플리케이션 기반 공격을 전혀 막아내지 못한다는 것을 의미한다. 최근에 시장에서 선보이고 있는 웹 방화벽이나 각종 컨텐츠 필터링 계열 장비들의 존재는 바로 이러한 기존 방화벽과 같은 접근제어 체계의 현실적 한계성에서 비롯된다고 할 수 있다.

대한민국의 경우에는 그야말로 ActiveX의 천국이며, MS가 꿈꾸어왔던 ActiveX가 할 수 있는 모든 것이 대한민국의 거의 모든 사이트마다 구현되어 있다고 보면 정확할 듯싶다. 우리나라의 정보보호기반시설에서 사용되는 보안시스템은 국가의 평가 및 인증제도를 거친 안정성 높은 시스템을 이용하도록 장치가 마련되어 있으나, 어플리케이션 구현 내역에 대해서는 주기적으로 홈페이지 리뉴얼 및 개편과 같이 수시로 변화하는 특성 때문에 이러한 검증제도의 구현이 현실적으로 어려우며, 개발자에 의해 구현된 ActiveX 컨트롤에 대해서 평가 및 인증제도를 거치는 경우 또한 없다. 따라서 ActiveX 컨트롤의 보안성은 개발자의 보안지식에 의존할 뿐 ActiveX 컨트롤에 대한 시스템적인 평가와 인증과 같은 검증절차를 거치는 경우는 없다고 보는 것이 정확할 듯싶다.

ActiveX 컨트롤을 설계하는 개발자는 보안적인 측면에서 악용이 가능한 기능을 제공하지 않거나, ActiveX 컨트롤이 불완전한 Method, Property등을 제공하고 있다면, 이러한 서비스 제공 여부를 판단하여, 검증하고 구현한 후 배포가 이루어져야 하지만, 현실은 그렇지 못하며, 일반적인 어플리케이션 개발과 마찬가지로 RFP(Request for Proposal)에 명시된 기능 목록을 만족하면 검수가 되는 일반적인 절차를 거친다.

불특정 다수에게 서비스가 되는 어플리케이션을 개발할 때는 유의해야 할 사항이 많다는 것을 알 수가 있는데, 오피스 프로그램, 뷰어, ActiveX 등이 그 예가 될 수 있다. 공격자는 이러한 어플리케이션 간의 연결고리를 분석하고 취약점의 존재 여부를 검증하며, 동시에 공격에 이용 가능한 PoC(Proof of Concept) 코드를 작성하게 되는데, 최근에 많은 취약점이 쏟아지고 있는 오피스 계열의 취약점의 경우, 조작된 문서를 읽게 되면 사용자 PC의 권한 획득이 가능한(일반적으로 오피스 계열의 취약점은 Classical Buffer Overflow 또는 Race Condition 취약점이 대부분이다) 경우가 존재하는 등, 다양한 부분에서 역공학(Reverse Engineering) 등의 기법을 통한 취약점이 맹위를 떨치는 이유는 개발자의 개발 산출물에 대한 보안성 검증이 의외로 허술하다는 점에 기인한다.

기존에 발견되었던 ActiveX 컨트롤 취약점을 다시 한번 분석해 보면 그 유형이 아래와 같음을 알 수 있다.

1. 로컬 자원에 접근 가능한 Method를 직접적으로 제공

2. 업데이트 기능을 악용하여, 정상적인 배포본이 아닌 조작된 배포본을 받게 하는 행위

3. 정교하게 조작된 입력값을 통해 정상적 로직을 Bypass 하는 경우

4. Method나 Property 등의 입력 값에 대한 버퍼 오버플로우

위의 내역을 살펴보면 사실 별 것 아닐 수도 있는 취약점이거나 설마 저런 것도 검증이 안될까라고 생각되는 부분도 존재하는 것을 볼 수가 있는데, 현업에서 보안 컨설팅을 하다 보면 이러한 문제점이 10곳 중에서 7곳에서는 나오는 취약점 유형임을 감안해 본다면, 이러한 검증 걸차가 이루어지지 않거나, 보안의 심각성 자체를 인지하지 못하는 경우가 대부분이다.

ActiveX 컨트롤은 자바 애플릿과는 달리 파일이나 레지스트리에 대한 접근이 가능하다. 또한, 일반적인 윈도우 어플리케이션과는 달리 공격자가 웹 인터페이스를 통해 누구나 언제든지 실행할 수 있다는 점이 특징적이다.

[Object Tag 및 Script를 이용한 호출]

그렇다면 ActiveX 컨트롤은 도대체 어느 정도에 쓰여지는지를 알아보면, 윈도우 기본 컨트롤은 물론이며, 메신저 프로그램, 동영상 및 음악 플레이어, 온라인 게임설치 프로그램, 공인인증서, 보안프로그램(키로거, PC 방화벽, 스파이웨어 등) 등에서 사용되고, 이는 거의 모든 국내 사이트에서 ActiveX 컨트롤이 사용되고 있음을 의미한다. 문제는 이러한 ActiveX 컨트롤의 설치 여부를 사용자가 오판하여 문제가 발생하는 경우 외에도 2002년 이후에 나오는 대부분의 애드웨어 등은 ActiveX 또는 IE 취약점을 이용하는 경우가 대부분이며, 이러한 취약점을 이용하기 때문에 “확인” 버튼을 누르는 것과는 관계없이 자동으로 설치되는 경우가 대부분이다.

[이미 악성코드가 설치된 웹 서비스]

[악성코드가 숨겨진 스크립트 내역]

따라서 사용자는 본인의 의지와는 관계없이 특정 악성코드가 설치된 웹 사이트를 방문하는 것 만으로도 악성 ActiveX 컨트롤이 설치된다. 이러한 경우, 최소한의 PC 보안 장치 조차 없는 경우에는 거의 사용자는 무방비 상태로 방치되며, 사용자는 보안에 대한 상당 수준의 지식이 없으면, 이러한 악성 컨트롤이 설치된 여부를 알지 못하는 경우가 일반적이다. 사실 이러한 경우에는 해당 사이트 규모에 따라서 엄청난 규모의 피해가 나타날 수도 있는데, 공공 사이트 또는 포털 사이트 및 SNS(Social Network Service) 사이트 및 게임 사이트의 경우에는 단일 사용자가 1,000만명을 넘는 경우도 존재하는데, 각종 스크립트 인젝션 등의 자체 취약점을 이용하거나, ActiveX 컨트롤 취약점을 이용하게 될 경우, 1,000만명이 사용하는 PC 전체의 권한의 획득은 물론이고, 개인정보의 획득 또한 가능하게 된다.

[업데이트 관련 취약성이 존재하는 ActiveX 컨트롤]

위 스크립트를 보면, 인터넷 익스프롤러(이하 ‘IE’)는 위 스크립트를 실행하고 Server_IP라는 인자에 설정된 주소로 업데이트 요청을 시도하는 것을 확인 할 수 있다. 위 스크립트의 경우 http://100.100.100.100/Vulnerable/Vulnerable.exe를 다운로드 받도록 되어있었다. 그러나 위 스크립트는 사용자 브라우저에서 실행되어지는 것이므로 관련 스크립트에 정의된 Server_IP와 같은 인자값이 조작되는 것이 가능하였다.

[업데이트 위치를 조작한 경우]

만약 공격자가 위 스크립트에서 Server_IP를 자신의 공격용 서버로 변경하고 자신의 서버에 악성코드가 심어진 Vulnerable.exe 업데이트 파일을 올려놓을 경우, 공격자는 해당 사용자 PC의 관리자 권한을 획득하는 것이 가능하게 되었다.

                    [사이트 방문시 자동으로 악성코드가 인스톨된 상태]

이처럼 이미 신뢰상태에 있는 ActiveX 컨트롤의 업데이트와 같은 방법을 통해 “확인”절차 하나 없이도 공격자는 스스로의 악성 코드를 사용자에게 이식시킬 수 있고, 심지어 원격에서 조정도 가능하다.

                                            [악성 코드가 삽입된 메일 발송]

위의 그림에서는 일반적인 메일 서비스를 이용해서 악성코드가 삽입된 메일을 발송한 예가 된다.

[ActiveX 컨트롤 취약점을 이용하여 IRC 채널을 통한 원격 PC 접속]

위 그림에서는 ActiveX 컨트롤 취약점을 이용하여 스크립트가 삽입된 악성 메일을 특정 사용자에게 보내게 되면, 사용자는 의심 없이 해당 메일을 받아들임과 동시에 악성 코드에 감염이 된다. 이러한 경우, 공격자는 방화벽을 우회하여 기업 내에 존재하는 원거리 시스템을 실시간으로 조작할 수 있을 정도의 권한의 획득이 가능해 진다. 이러한 경우 하나의 조직 내에 이러한 취약점이 존재할 경우, 해당 조직에서 사용하는 전체 PC의 권한 획득이 가능함은 물론이며, 특정 기밀 정보의 유출 또한 가능해 진다. 또한, 엄청난 수의 사용자가 방문하는 웹 사이트에 이러한 취약점이 존재할 경우에는 재앙이라고 표현 가능할 정도의 파급도가 예상된다.

이러한 ActiveX 관련 취약점 유형에는 위에서 언급한 업데이트 관련 내역 말고도 상당한 응용이 가능한 취약점 유형이 다수 존재하고 있는데, 대략적인 내역을 살펴보면 다음과 같다.

1. File Read/Write Method 조작

[정상적인 File Read/Write Method]

[조작된 File Read/Write Method]

위의 경우에는 File Operation 기능을 우회하여, 임의의 경로에 존재하는 임의의 파일을 쓰거나 실행시킬 수 있었다. 현재 국내에서 상당히 많은 수의 사이트에서는 Read/Write File과 같이 직접적인 Method를 제공하는 ActiveX 컨트롤도 다수 존재하며, 이러한 경우에는 개발자가 미처 생각지 못했던 Method, Property를 호출해 우회적으로 임의의 파일을 쓰거나 실행시키는 공격방식이 존재한다. 위의 경우에서는 파일 쓰기권한을 획득한 경우 기존 파일을 덮어쓰거나, “c:\documents and settings\All users\시작 메뉴\프로그램\시작프로그램” 폴더에 파일을 생성해 다음 번 로그인 또는 부팅 시에 파일이 악성 파일이 자동으로 실행되게 할 수 있었다.

2. 시스템 자원에 대한 접근 방식

과거 C언어에서 System 함수와 같은 역할을 하는 Method를 과감히 사용하는 경우도 대단히 많이 존재하는데, SetRegistryValue, GetRegistryValue 등 레지스트리에 대한 직접적 조작이 가능한 Method는 잠재적으로 모두 취약할 가능성이 99.99%라고 보면 될 듯 싶다. 따라서 이러한 경우에는 아래와 같은 방식으로 간단히 공격용 도구를 시스템에 설치하고 실행시키는 방식이 존재한다.

3. 보안영역 접근 방식

일반적으로 IE는 현재 페이지의 보안영역에 따라 서로 다른 수준의 보안수준의 설정을 한다는 것을 알 수 있는데, 보안영역은 해당 페이지가 속한 도메인이 무엇인가에 따라 결정된다고 보면 된다. 이러한 영역구분은 인터넷 영역, 인트라넷 영역, 내컴퓨터 영역으로 구분된다.

인터넷 영역은 사실상 로컬자원에 대한 접근은 금지되며, 인트라넷 영역은 인터�