|
정보보호 관련 잡지에 연재중인 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)이 있다. 이러한 전자서명은 개발자가 배포한 올바른 배포본이 맞는지, 다른 누군가에 의해 배포본이 수정되지는 않았는지의 여부를 효과적으로 검증 가능하게 한다. 문제는 전자서명이 되어 있다고 해서 이것이 악의적인 공격 코드를 포함하고 있는지, 특정 시스템 명령을 악용하는지 등 안전성 여부에서 자유롭다는 것을 의미하지는 않는다.
“Although code signing can guarantee the identity of the control author and guarantee that the control has not been tampered with, it does not guarantee that the code is free from errors and security vulnerabilities”
Source : 288P, WRITING SECURE CODE, MICROSOFT PRESS.
문제의 중심에는 바로 이러한 신뢰모델이 문제가 되는데, 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가 꿈꾸어 | 
0
2