4/03/2009

인터넷 뱅킹과 액티브 엑스 논란에 대해서

오픈웹이라는 운동이 있다. 근본적인 취지에 동의한다. 나 자신도 이미 15년전부터 리눅스, BSD(사실 부끄럽지만 프로그래밍 세계라는 잡지에 FreeBSD에 대한 글을 쓰기도 했고, 마이크로소프트웨어라는 잡지에 OpenBSD를 소개하기도 했다), 맥(2008년 이후 사용중이다), 윈도우즈(1998년 이후에 본격적으로 사용하게 되었다)를 골고루 사용하고 있는 유저로서 한국의 웹환경이 IE 일변도로 흐르고 있다라는 현실은 개탄스럽다. 사실 IE에서 조차도 수많은 이미지와 광고들로 인해서 더럽혀진 포탈 사이트들을 볼때면 사실 웹서핑의 짜증도가 확 올라가기 일쑤다. 인터넷 뱅킹도 가끔 잔고 확인등을 위해서 확인하고는 하는데 소리 소문 없이 설치된 액티브 엑스 모듈들 때문에 기분이 상했던 적이 있다. 키보드 보안 모듈이나 백신이 소리 소문 없이 설치 되어 있는 것을 달가워 할 사람은 아무도 없다. 이러한 상황에 변화가 와야 한다라는 것을 인지 못하는 사람은 아마 드물것이다.

하지만 이러한 모든 책임을 단지 은행권에 대한 납품 업체에 불과한 보안 업체들에게 모두 떠넘기고, 마치 보안 업체들이 보안 모듈의 배포 정책(강제 설치)이나 배포 형식(액티브 엑스)에 전적으로 책임이 있다라고 주장하는 것에는 사실 함정이 있다.

배포 정책: 강제 설치
일단 배포 정책에 대해서는 사실 어떻게 실제로 결정이 되었는지는 당사자들 말고는 아무도 확신을 가지고 알 수 없다. 그런데 무조건 보안 업체들이 정부와 은행권을 꼬드겨서 강제 배포를 실시하고 있다라는 사실의 근거는 어디에 있는지 도저히 알 수가 없다. 근거가 없다면 함부로 누구에게 책임을 함부로 묻는 것은 자제하는 것이 낫지 않을까? 그러한 주장이 모욕적인 인신 공격의 형태로 나온다면 그것은 어떠한 논의도 혼란에 빠뜨릴 뿐이다.

배포 형식: 액티브 엑스
먼저 필자의 직업은 액티브 엑스와 많은 관련이 있다. 필자는 미국 캘리포니아에 위치한 보안 회사(http://www.eeye.com)에 근무하는데 업무상 액티브 엑스 모듈들의 활동을 분석하는 모듈을 개발한 적이 있다. 취약한 액티브 엑스 모듈을 공격하는 스크립트들을 차단하는 모듈을 개발했고, 해당 기술은 2008년에 미국에 특허 출원 상태이고, 미국의 유수 업체에 납품하고 있는 우리 회사의 제품에도 탑재되어 고객들의 보안을 지켜 주고 있다(http://www.reuters.com/article/pressRelease/idUS106893+26-Jan-2009+MW20090126 참조).
결론부터 이야기하자면 액티브 엑스라는 형식이 악성 코드에 의해서 악용되는 경우가 많다고 해서 액티브 엑스로 만든 모듈들은 모두다 악성 코드라고 주장하는 것은 어불 성설이다. 마이크로소프트의 정품 인증 모듈을 비롯해서 마이크로소프트 웹페이지에서도 아직도 액티브 엑스로 배포되는 모듈들을 심심치 않게 찾아 볼 수 있고, JRE나 어도비사의 플래쉬 플레이어 조차도 액티브 엑스와 관련된 부분이 있다. 액티브엑스 기술의 가장 큰 수혜자는 사실 어도비 사가 아닌가 한다. 그런데 액티브 엑스 중에서 가장 많이 실행되는 모듈은 말할 것도 없이 플래쉬 플레이어 모듈이다. 하지만 누구도 플래쉬 플레이어를 악성 코드라고 말하지 않는다. 액티브 엑스로 실행되는 코드의 내용이 악성 양성을 가르는 것이지, 액티브 엑스 기술을 사용하면 악성이 되는 것은 아니다. 이는 마치 많은 바이러스들이 Windows API를 사용한다고해서 Windows API를 사용하면 바이러스라고 단정하는 것과 똑같다. 즉, 전혀 설득력이 없는 주장이라는 것이다.
그렇다면 일단 내 주위에서 접할 수 있는 유용한 양성 액티브 엑스 모듈들을 찾아 보자. 업무상으로 많이들 사용하는 블랙베리와 관련된 액티브 엑스 모듈이 있다. 또한 미국에서 엄청난 가입자를 유치하고 있는 웹을 통한 텔레 컨퍼런스 시스템인 GoToMeeting이 있다. 또한 집이나 출장지에서 회사 시스템에 접속하여 사내망에서 일하는 것처럼 해주는 쥬니퍼사에서 판매하는 VPN시스템의 클라이언트도 액티브 엑스 형태의 배포형식을 제공하고 있다. 물론 맥이나 리눅스 시스템을 동시에 서포트하는 경우도 있지만, 시스템에서 실행 되어야 하는 코드가 존재할 경우에는 해당 스크립트를 따로 관리자 권한으로 돌려야 다음 단계로 진행하는 식으로 처리하고 있다. 그 외에 맥아피나 트렌드 마이크로사와 같은 유수의 안티 바이러스 업체들은 모두 라이브 스캔 서비스를 제공하고 있다. 물론 해당 서비스는 액티브 엑스 기술이 아니라면 거의 구현이 불가능 한 것들이다.

액티브 엑스 배포형태라서 악성이라고 하거나 악성 코드를 가지고 있다라고 몰아 부치는 것은 납득하기 어려운 주장이다.

이렇게 미국에서도 일상 업무에 많이 사용되는 액티브 엑스를 마이크로소프트가 쉽게 포기하리라고 보지 않는다. 사실 액티브 엑스 기술의 99.9%는 COM기술에 기반하고 있으며 액티브 엑스의 실행 과정은 단지 해당 COM 모듈을 vbscript나 jscript에 노출 시켜주는 중간 모듈을 통해서 스크립트를 COM 시스템 내에서 해석해 내는 과정에 불과하다. 이론적으로 vbscript나 jscript가 아닌 다른 형태의 언어가 COM모듈을 이용하도록 만드는 것은 기술적으로 어려운 일이 아니다. 실제로 사용되는지는 모르겠지만 기억으로는 파이어팍스 소스 코드 베이스에도 이 COM 시스템을 이용하기 위한 코드들이 존재하였던것으로 기억한다.

결국 마이크로소프트의 입장에서 액티브엑스라는 기술은 COM의 단순한 확장에 불과하고 COM은 사실 윈도우즈의 가장 핵심적인 기술의 하나이다. 필자의 생각은 현재로서는 마이크로소프트에서 그 확장을 제거할 뚜렷한 이유가 없다라는 것이다. 그러기에는 이미 너무 많은 모듈들이 액티브엑스 기술에 의지하고 있다. 한국의 이야기가 아니라 미국의 이야기이다. 한국의 인터넷 뱅킹때문에 마이크로소프트에서 액티브 엑스를 유지하고 있다라는 과대 망상은 금물이다.

결론
이 글은 현재의 한국의 인터넷 뱅킹 시스템이 좋다라고 말하기 위한 목적이 아니다. 어떻게 고쳐야 된다라고 제시하기 위한 글도 아니다. 앞에서 이미 말했듯이 개인적으로도 한국의 인터넷 뱅킹을 좋아하지 않는다. 단지 엔지니어 입장에서 액티브 엑스에 대해서 알고 있는 내용을 간단하게 정리한 글이다. 다만 한국의 인터넷 뱅킹 시스템에 대해 논의하기 전에 미리 알아야 할 내용을 간단하게 적어 본 글이다. 올바른 배경 지식을 가지고 있지 않으면 올바른 결론이 나올 수 없다. 단지 추측이라든지 남이 그렇게 얘기하니까 그렇다라고 해서는 안된다. 어느 주장에나 그 주장을 뒷받침하는 근거가 있어야 한다. 사실 관계를 제대로 모르고 있는데 과연 올바른 해결책이 나올 수 있을까?

Posted via email from bugtruck's posterous

댓글 12개:

  1. 기억이 맞다면 암호화 플러그인과, 인증서를 제외한 액티브엑스가 강제로 깔리기 시작한 것은 2005년이던가 키로거를 이용한 계좌이체 범죄가 발생한 이후입니다. 그 때 문제가 발생했던 진짜 원인은 키로거 말고도 그 은행에서 주민번호만 알면 공인인증서를 재발급했기 때문이기도 했는데.. 어쩄든 범인은 워낙 허술해서 며칠 안 되서 잡혔지만, 덕분에 그 사건 후 패치가 되더니 백신 설치를 안 하면 진행이 안 되고, 보안 프로그램 업데이트도 확인 버튼 안 눌러도 자동으로 하더군요.

    암호화/공인인증서를 제외한 기능들은 그 전에도 많이 있었지만 원래는 보너스 기능이었는데 그 사건 이후 강제로 깔리더니 점점 모든 기관에 확산되고 필수가 되어 버렸고, 이제는 다른 플랫폼에 적용하는데 본래 암호화/공인인증서보다 더 큰 걸림돌이 되어 버렸습니다.

    답글삭제
  2. 예 댓글 감사합니다. 저의 입장은 액티브엑스가 악이 아니다라는 것뿐입니다. 인터넷 뱅킹시에 설치되는 보안 프로그램의 안정성의 문제는 액티브엑스와는 상관이 없는 문제인 것으로 알고 있습니다. 보안 모듈들이 주로 커널쪽을 많이 거드리기 때문에 생기는 불안정성인듯 합니다. 해당 부분은 업체나 은행측에 항의를 하여서 수정 되도록 하는 것이 올바른 해결 방법인 것 같습니다. 그리고 AV의 경우에는 저도 실시간 감지 기능을 여러 OS에서 구현해 보았는데, 사실 퍼포먼스 튜닝 하는 것이 그렇게 쉽지 않습니다. 물론 AV 시그너쳐의 크기를 줄이는 일도 만만치 않구요. 언뜻 보니까 최근 몇년 사이에 시그너쳐 파일의 크기가 몇배가 되어 버렸더군요. 그만큼 악성 코드의 양이 증가했고, 그만큼 일반 사용자의 경우에는 메모리의 압박도 많이 받게 되는 것이죠.
    결국 문제의 근원은 보안 프로그램들의 퀄러티인데, 시장이 왜곡되어 있는 상황 등등도 간접적인 원인일 것 같습니다.
    그렇다고 외부의 힘으로 강제적으로 그러한 상황을 해결할 수 있는 것은 아닌 것 같습니다.
    일단 소비자 운동 차원에서 보안 프로그램 퀄리티 향상에 대한 요구를 지속적으로 행할 필요가 있을듯 하네요.

    답글삭제
  3. 저도 좋다 나쁘다 얘기를 한 게 아니고요. 그 강제 설치의 유래는 이렇게 시작되었다고 말씀드리고 싶었습니다. 보안 업체의 의도도 아니지만, 그렇다고 고객을 위해 시작한 한 것도 아니고, 과거에 발생했거나 발생 가능성이 있는 보안 사고에 대한 대응 과정에서 지금도 흔히 나오는 이야기인 책임 소재를 따지다가 이렇게 흘러온 것이죠.

    답글삭제
  4. 예 하도 입장을 오해하시는 분들이 많다 보니까요. 일종의 은행의 궁여지책이라고 할 수 있겠죠. 보안 사고가 발생하면 법적으로 은행이 불리할 뿐만 아니라(고객 과실 입증의 의무), 언론에서도 좋지 않게 떠들기 때문에 은행의 피해도 적지 않죠. 결국 은행이 취할 수 있는 옵션이 그렇게 많지 않습니다. 차라리 고객들이 불편하더라도 보안 사고가 터지는 것보다는 낫다라고 판단하고 있는 것이구요. 이 부분에 대한 일반인들의 인식 전환이나 언론들의 태도 변화가 사실 더 필요한 것 같은데 그런 부분은 최근 논의에서 쏙 바져 있죠.
    즉, 은행들이 웹을 오픈할 수 있는 환경이 되어야 오픈이 된다라는 것입니다. 어거지로 열라고 해서 과연 열릴까요? 과연 그렇게 열렸다고 해도 과거로 회귀할 사고가 발생하지 않는다고 장담할 수 있을까요?
    제 생각으로는 고객의 책임에 의한 보안 사고는 전적으로 고객책임이라는 사회적인 인식부터 확산되어야 합니다.

    답글삭제
  5. 저도 Activex가 필요 없다고 생각하지 않습니다. 한때 ActiveX 코드사이닝때문에 밥벌어먹었던 사람인걸요. 하지만 결과적으로 보면 국내에서 ActiveX 오용이 심각했고 그에 따른 국가적인 보안 비용은 증가했다고 생각합니다. (보안 전문가나 업계에서 한번쯤은 판단했어야 할 사안이었다고 생각합니다.)

    특히 은행의 경우 금융 서비스는 공인 인증만 쓰고 보안 사고는 은행이 책임지라는 법적 규제와 그에 따라 ActiveX 플러그인 방식만 제공하는 보안 업체들이 장기적 대안을 실행하는데 걸림돌이 됐을 거라고 생각 합니다.

    하지만, 이 때문에 소수지만 금융 서비스 사각지대에 있는 웹 브라우저/OS 사용자들이 있었고 그들은 어떻게든 구제되어야 합니다.

    그래야만 웹 브라우저와 운영체제가 나올 때 고객들이 업그레이드를 통해 보안 비용을 더 줄여나갈 수 있으니까요.

    답글삭제
  6. 예 자꾸 말씀드리지만 액티브 엑스 자체의 문제라기 보다는 보안 모듈의 문제로 보입니다. 엑티브 엑스는 사실 프로그램 런쳐와 업데이터의 역할 이상도 이하도 아닙니다. 제대로 하려면 고객들이 알아서 마음에 드는 보안 소프트웨어 구매해서 설치하고 인터넷 뱅킹하고 그에 맞게 법제 정비 되고 하는 것이죠. 저도 덕지 덕지 깔리는 모듈들은 싫습니다. 물론 대다수의 국민이 몇만원씩 하는 보안소프트웨어를 과연 구매할까 의문입니다만...

    답글삭제
  7. 근데 AV 시장이 참 어려운게 현재 무료 백신 소프트웨어가 굉장히 많습니다. 아시겠지만 네이버도 제공하고 알약이라고 하는 제품도 있구요. 이에 대응하려고 AV업체들이 웹 사이트 기반 ActiveX 배포-활성화는 이미 큰 사업이 되어 버린 형국입니다.

    또 하나의 문제는 갯수가 너무 많아져서 진성/악성 ActiveX를 구분하기 어려워졌다는 건데요. 우리나라에서 코드사이닝 인증서 발급건수는 매년 천 여장 이상입니다.(세계 최고) 업체별로 한개만 만들어도 천개의 ActiveX 콘트롤이 있는 셈입니다. (물론 다 진성이라고 생각합니다만 adware나 spyware도 적지 않습니다.)

    우리 나라 ActiveX 문화는 대개 유저 경험(사용성)하고 연관이 많이 되는데 최근에 리치웹 경향에 따라 이 부분도 많이 좋아졌습니다. 딱 2년전만 해도 국내 모든 지도 서비스에 ActiveX 플러그인이 깔렸습니다만 지금은 정말 거짓말 같이 다 걷어내고 구글맵 처럼 Ajax 방식으로 바뀌었습니다. 걷어낼 수 있다면 걷어내는 게 맞다고 봅니다.

    답글삭제
  8. 예 그러한 악성 액티브 엑스 모듈을 잡기 위해서라도 AV의 필요성이 더 대두되는 것 같습니다. 그 많은 액티브엑스를 만든 곳은 일단 보안 업체가 아닌데 보안 업체도 액티브엑스를 쓰니 책임을 져라라는 식의 오픈웹의 논리 비약이 문제였고요.

    그 부분만 뺀다면 문제 의식은 공유하고 계신 것 같네요.

    맥아피나 트렌드마이크로 등 세계 AV벤더들이 액티브엑스를 이용한 서비스를 제공하는 부분에 대해서는 어떻게 생각하세요?

    답글삭제
  9. 좀 길지만 한번 더 히스토리를 이야기해 보면요...

    저도 모질라 커뮤니티에서 Firefox 사용자가 국내에서 웹 이용이 원활하도록 관심을 가지고 Matt님 처럼 오픈웹에 조언만 하는 입장입니다. (2003년 부터 노력했지만 국내에서는 이슈화도 안됐습니다.) 2006년에 김교수님이 이걸 법적 이슈로 만들면서 비로서 좀 다른 사람들이 관심을 가지게 됐죠.

    문제의 시초는 비 윈도, 비 IE 사용자에게 금융서비스를 제공하려면 어떡해야 하나?였습니다. 그럴려면 우선 공인 인증이 브라우저 자체 기능이 아닌 플러그인(ActiveX)으로 만들어져 있기 때문에 다른 브라우저에도 플러그인 혹은 호환기능(Npplugin 혹은 자바)로 만들어 달라는 요청을 했었습니다. 그때 PKI 업체들이 그런 제품을 만들고 있었기도 했구요. 금결원이 그걸 거부해서 소송이 시작됐구요.

    소송을 하는 과정에서 또 다른 문제가 있음을 알게됐는데 금감원과 국정원에서 단순히 공인 인증 뿐만 아니라 키로그 방지 혹은 AV도 강하게 결합(ActiveX)시켜 금융 서비스를 하도록 했다는 것이죠. (국내 은행 가보시면 다 강제로 설치합니다.)

    즉, 플러그인 방식으로만 해결이 안되고 보안 플러그인까지 강제 설치해야 하니 문제 해결에 대한 대안이 안보이는 상태가 됐습니다.

    공인 인증 플러그처럼 단순한 인증서 관리나 암호화 정도가 아니라 AV 프로그램까지 구동해야 하는 상태다 보니 Firefox Plugin이 activex launcher 같은 역할을 하도록 해야 문제가 풀리는 게 되는 거죠. (실제로 리눅스에서 키보드해킹 방지 프로그램 만들어 브라우저 플러그인으로 론칭 시키는 우체국 프로젝트도 소프트웨어진흥원에서 추진한 적도 있엇습니다.)

    결국 최근에 플러그인 방식으로는 문제 해결은 요원하다는 결론을 얻게됐고 이런 요인이 공인 인증 ActiveX 플러그인에 보안 문제(창)가 생겼을 때 그걸 보안 ActiveX 플러그인(창)으로 문제를 푼 보안 업체들이 문제가 있지 않나라는 의식을 가지시게 된겁니다. 그때 1인 1백신 갖기 운동을 하거나 정품 백신 SW 사용자에게만 인터넷뱅킹을 하게 했다거나 하는 판단을 해야 하지 않았나 하는거죠.

    맥아피나 트렌드마이크로 같은 업체들도 스캐닝 용도로 activex로 제공하는 것도 저는 괜찮다고 생각합니다. 다만 한국의 문제는 이것들이 웹 사이트에 임베딩되어 있고 서비스와 결합성이 너무 강하다는 거죠. 그래서 비 윈도 비 IE 사용자에게 서비스가 안되는 게 문제라고 생각합니다.

    지난 3년 동안 저는 Mozilla 코드에 SEED(한국 암호알고리듬)를 탑재 시키는 것 그리고 KISA RootCA를 Firefox에 넣는 것에 저도 관여되어 설득하고 하는 작업을 했었는데요. web signing이 표준화 될 수 있을 것을 염두해 둔 것이었습니다. 하지만 이 마저도 최근에 w3c html w/g거부된 상태이고 다른 w/g으로 옮겨졌지만 별로 관심이 없습니다.

    그래서 결국 ssl+otp+(부가 보안 방식)를 이용한 방식을 쓰는게 어떤가 하는 문제가 오픈웹에서 이야기가 시작된 것이죠. 김교수님도 이 방식이 현재의 인증+보안 플러그인을 같이 걷어낼 수 있는 방법이라 생각하셨던 거고 그러다 보니 보안업체에 대한 강한 공격이 이루어졌던 것 같습니다.

    솔직히 저도 김교수님과 비슷한 입장입니다. 저는 Firefox 사용자가 어떤 식으로라도 금융 서비스를 받았으면 좋겠고 그게 다른 방식으로라도 해결 되도록 준비 중인게 있기도 합니다.

    오픈 웹의 구글 그룹을 보시면 옛날 이야기(2006년)가 있는데요. 그때는 플러그인 방식이 문제해결 방법으로 이야기됐었습니다. 그 후에 저도 좀 바쁘고 김교수님이 홀로 소송을 진행해 오셨고 저나 몇 명의 그룹이 종종 조언만 하고 있었던 상태입니다.

    어쨌거나 이번 일로 다시 한번 관심이 폭증된 것 같으니 좋은 결론이 나오지 않을까 하는 생각이 듭니다. 비윈도 비IE 사용자에게도 금융 서비스를 제공해야 한다는 명제에는 다들 동의하니까요.

    답글삭제
  10. 주저리 주저리 쓰면 결론만 보이는데 이게 법률가인 김기창 교수님이 민원 보내고 내용증명 보내고 수년 동안 알아오신 사항이십니다. 누구도 이런 정보를 한큐에 안알려 줬구요. 실제로 저도 잘 모르는 내용이 많았습니다. (나중에 오픈웹 블로그가 다시 복구 되면 백개가 넘는 글들이 위의 문제를 트래킹해 온 과정이라고 보시면 됩니다.)

    답글삭제
  11. 예. 저도 이번일을 기회로 서로 이해를 더 할 수 있어서 기쁩니다. 제가 해외에 나와서 해당 이슈를 일찍 알지 못했던 점이 아쉽네요. 조금 더 일찍 알았더라면 이렇게까지 오해의 골이 깊어지지 않도록 저라도 미천하지만 노력을 했을텐데 말이죠. 어쨌든 상호 비방은 자제하도록 암묵적으로 동의가 된것으로 알겠습니다. 메일링에서는 종종 의견 제시를 하겠습니다.

    답글삭제
  12. 최근에 중간(?)에서 많은 도움 주셔서 감사하고 있습니다. 오픈웹이 일종의 사회운동적인 성격으로 진행되어 왔었지만 결국 기술적 이슈를 안건드리고서는 문제 해결이 안될 것 같습니다. 그게 충돌된 사안 같구요. 앞으로 이런 시행착오를 거치면 안되겠지요.

    답글삭제