"ActiveX에 대한 취약점"에 대한 정리

2,168 views
Skip to first unread message

Gilbert Lee

unread,
Apr 11, 2009, 3:35:43 PM4/11/09
to open web
안녕하세요, 이경문입니다.

제 홈페이지에 와 오신 분은 아시겠지만,
제가 아직 오픈웹에 대한 감정적인 증오심이 사라 졌다거나 한 상태는 아닙니다.
솔직히 성인군자가 아닌 이상 그러한 감정이 쉽게 가라 앉을 것 같지는 않군요.

다만 이렇게 글을 쓰는 것은 처음에도 말씀드렸듯이
건설적인 의견 수렴의 차원에서 글을 쓰는 것을 우선 밝힙니다.

현재 ActiveX에 대해 많은 이런 저런 오해가 있는 상태입니다.
누구보다도 ActiveX에 문제점이 많다고 주장하던 주의의 사람들마저
오픈웹과의 논쟁으로 인해서
지금은 오히려 반대로 ActiveX를 옹호하는 모습으로 비춰 짐이 안타까울 뿐입니다.

결국, 비록 제가 ActiveX 전문가는 아니나
도움이 될 만한 몇몇 글을 포스팅하도록 하겠습니다.

ActiveX Launcher를 이용한 해킹
ActiveX가 악용되어 질 수 있는 간단한 예를 들었습니다.
초보적인 내용이고, 간단한 웹 스크립트 정도만 알고 있으면 누구나 이해가 되실 겁니다.

유명 메신저를 이용하여 백도어 설치하기
MITM Attack의 개념이 이상한 방향으로 흘러 가는 것 같아서 올려 봅니다.

BankTown ActiveX 보안 취약점
Fuzzing에 대한 어느 보안 전문가의 글입니다.
ActiveX도 COM이고, COM이기 때문에 거기에 다양한 인자를 넣다 보면
COM 모듈이 맛탱이(crash)가는 것을 찾아 내는 기법을 말합니다.
쉽게 말해서 소 뒷걸음 치다가 쥐잡는 격이라고 보시면 됩니다.
실제로 이러한 Fuzzing 테스트를 통하여
국내 많은 ActiveX의 보안상의 결함을 발견하고 패치된 사례들이 많습니다.
이제 국내에서도 Fuzzing Tool에 대한 연구와 툴 제작이 본격화되고 있는 상태입니다.

ActiveX 취약점 공격 및 방어 기법
ActiveX의 취약점에 대해 가장 잘 일반적으로 설명해 주는 문서가 아닐까 싶습니다.

How to Implement COM Monitor
제가 알고 있던 취약점들중에 국내에서 가장 위협적이었던 내용을 담고 있는 문서입니다.
RE(Reverse Engineering)쪽 전문가가 아니면 잘 이해하지 못하는 부분이기는 하지만
참고해 두시면 좋을 듯 합니다.

위에서 열거한 내용들은 전부
ActiveX 제작자(혹은 회사)가 고의적으로 악성코드를 만드는 것이 아니고
개발자가 개발 과정에서 쉽게 간과할 수 있는 설계 & 코드작성 과정의 결함(hole)에 대한
문제점에 의해 생기는 취약점들을 얘기하고 있습니다.

아울러 당부의 말씀을 드리자면, 기분 나쁘게 들리실 수 있지만
김기창 교수님의 "예" 이론은
틀린 말은 아니어도
보안쪽에서 생각하는 ActiveX 취약점과는
입장 차이가 너무 많이 나고 있는 상황입니다.

최소한 제가 위에서 열거한 부분들에 대해
어느 정도 익숙해 지신 이 후에
그때 가서 ActiveX의 취약점에 대해서 얘기를 한다면
보안 전문가, 보안 업체들과도 많은 공감대를 형성할 수 있을 것이라고 봅니다.

본 글이 김기창 교수님을 비롯한 많은 분들께
조금이나마 도움이 되었으면 하는 바램입니다.

dasony

unread,
Apr 12, 2009, 12:11:53 AM4/12/09
to open web
정리된 정보 감사합니다. 특히 감정이 많이 상해 있으시고 오픈웹때문에 바쁜 시간도 많이 낭비하셨다는 것을 잘 알고 있는지라, 더
더욱 감사드립니다.

오픈웹에서 논의되었던 각종 ActiveX로 인해 발생할 수 있는 공격 방법이 모두 정리되어있네요. 제가 굳이 언급하지 않은
Universal Wrapper 방식 등도 다 나와있어서 반갑습니다. 유명 ActiveX 컨트럴의 보안 문제를 공격하는
attack이 상당히 많이 나와있군요. ActiveX 개발 시에 가장 기본적으로 고려해야하는 부분인데, 아쉬운 일입니다. 사실
몇 년 전에 ActiveX 프로그램도 제작하는 회사에서 일했던 적이 있는데, ActiveX를 설치해야 한다는 단점을 피해가기 위
해 당시 유명하던 모 ActiveX을 이용해서 설치해버리자는 의견을 낸 적도 있었습니다. 물론 반쯤 농담이었고, 실행하지는 않았
습니다 ^^;

그런데 사실 보여주신 문서에서 생소한 이야기는 없는 것 같습니다. 오픈웹과 보안 쪽에서 이야기하는 ActiveX에 대한 입장이
어떻게 다른건가요? 오픈웹에서는 악성코드를 ActiveX로 직접 배포하는 위험을 주로 말하고 있고, 보안에서는 IE나 기존에 설
치된 ActiveX의 취약점을 통해 악성코드를 배포하는 위험을 주로 말하고 있기 때문인가요? 솔직히 말씀드려서 오픈웹에서
ActiveX에 대해 어떤 오해를 가지고 있다는 것인지 잘 모르겠습니다.

그래도 반가운 부분은 되는 부분은, 당연하지만 제가 생각만 해봤던 공격 방식 대부분을 이미 인지하고 있다는 사실입니다. 그렇다
면 어떻게든 막아두고 있겠지요. (개인적으로 Universal Wrapper는 어떤식으로 막고 있을지 궁금합니다. 몇가지 조악
한 방법은 떠오릅니다만...) 그렇게 공격 하나하나 막아가면서 운영을 하려니 타 플랫폼 지원은 꿈도 못 꾸고, 로우레벨 접근이
가능한 ActiveX를 사용하지 않고서는 못 배기는 것 같습니다. 하지만 좀 더 근본적인 대안 없이 언제까지 이렇게 갈 수 있을
지 모르겠습니다. 인내심이 부족해서 보안을 계속 팔 수 없는 저같은 사람은, 생각을 바꾸면 더 간단한 방법을 찾을 수 있지 않을
까 궁금할 수 밖에 없네요. =)

swlee

unread,
Apr 12, 2009, 9:09:04 AM4/12/09
to open web
인터넷 뱅킹의 보안 모듈이 ActiveX 라고 해서 문제라고 한정하는 부분에서 납득이 안가기 때문입니다.
현재 게임, 음악, 정부기관, 뱅킹. 쇼핑, 증권, 교육등 거의 모든 분야에서 ActiveX는 반드시 필수로, 강제로 사용되고
있으며
ActiveX 설치 없이는 윈도우 보안 업데이트 조차 되지 안는 현재 상황에서 공공성이라는 오픈웹만의 잣대로
보안 ActiveX 모듈만을 문제삼는것이 이해가 안될 뿐입니다.

두번째로 현재 적용되어 있는 보안 접속 모델인 E2E(end- to- end )는 기술적인 측면만 보면
SSL의 암호화 접속의 단점을 보완하는 Application 레벨의 암호화를 지원하는 기술로서
모바일등의 플래폼서 SSL의 단점을 보완하기위해 채택되는 표준 보안 기술임에도 불구하고
ActiveX를 이용하여 구현했다는 이유 만으로 황당한 무용론을 주장하며 SSL로 회귀해야 한다는 주장입니다.
(기술적인 측면에서 분명히 SSL보안 접속보다 진보된 기술임에도 불구하고요..)

문제가 있으면 문제점을 보완하는것이 당연함에도 불구하고
ActiveX 로 구현했다는 이유만으로 SSL과 차이점이 없으며 걷어내야 한다는 주장은
보안업계 입장에서는 황당하죠 ..

차라리 ActiveX 가 아닌 다른 방법으로 구현이 가능하다등의 주장이면 그건 납득이 가고 이해가 가는데..
기술적으로 동작 방법에 별반 차이가 없고 오히려 SSL보다 더 취약하다는 이유로
ActiveX 를 걷어내야 한다는 주장이 어이가 없는 것이죠..

현재 ActiveX 의 문제는 MS 종속적인 기술이기 때문에 MS의 정책이 변경될때마다 한국 IT가 흔들릴 수 있으며
ActiveX 중심으로 구현된 사이트는 타 브라우저를 지원하지 못해 점점더 MS 종속화 되어 가고 있는것이 문제라 할 수 있는

이에대한 책임을 보안업체로 돌리는 것이 안타깝네요..
대표적인 예가 "보안 ActiveX 때문에 사용자들에게 ActiveX 가 뜰때 무조건 예를 누르는 것을 학습 시킨다."

인터넷 뱅킹이야 말로 그 무엇보다도 가장 최선의 보안대책이 구현되어야 하는 보안이 가장 중요한 사회적 행위임이 분명한데..
그러한 보안의 중요성 보다는 당장 웹 표준화, ActiveX 제거만을 외치는 부분이 안타깝습니다.

소송같은 방법을 통해 당장 무언가를 하려는 급한 모습보다는
모든 브라우저에서 잘 동작하는 사이트 TOP 100, ActiveX 를 사용하지 않고 표준화 기술을 성공적으로 적용한 CASE
소개
개발자들이 쉽게 웹 표준 기술을 적용할 수 있도록 할 수 있는 기술적 안내, 지침등
쉽게 할 수 있는 부분부터 차근차근 캠페인해 나갔으면 하는 바램입니다.

Mountie Lee

unread,
Apr 12, 2009, 9:47:44 AM4/12/09
to open...@googlegroups.com
일부 내용에 이견이 있어서 의견드립니다.

ActiveX E2E 구현 취지는 Application 레벨의 암호화를 지원하는것이지만
현실은 SSL Layer와 다를바 없이 동작합니다.

유저가 입력하는 모든 Form value를 통째로 묶어서 암호화하고
서버에서는 무슨 내용인지는 상관없이 통째로 복호화합니다.

서버에서 내용을 Return할때도 역시 내용은 상관없이 응답할 페이지의 일부분(말그대로 전체 페이지의 일부분이죠)을 통째로 암호화해서
클라이언트로 보내면 ActiveX에서는 무슨 내용인지 상관없이 통째로 복호화해서 페이지이 끼워넣습니다.

Application 레벨의 암호화 지원을 이야기하려면
중요한 비밀번호등을 개별 암호화하고 이것을 서버를 거쳐 application 까지 그대로 가져가서 필요할때만 복호화해서 사용하는등의 처리가 되어야하는데
현실은 그렇지 않습니다.

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

보안 서버의 종류중에서 ActiveX 방식이 방통위고시에서 지정된것은
제가 보기에는 완전히 황당 그자체입니다.

그 조항을 빼야하고 더이상 보안서버로 ActiveX 방식을 팔면 안됩니다.


2009/4/12 swlee <Ban...@gmail.com>

dasony

unread,
Apr 12, 2009, 10:08:15 AM4/12/09
to open web
swlee님/
mountie님께서 직접 글을 써주셨으니 기술적인 부분을 제외하고 다시 씁니다. 일단 ActiveX라서 문제는 아니고요, 타플랫
폼에서 사용할 수 없어서 문제입니다. 오픈웹은 가장 적은 비용으로 많은 플랫폼을 지원할 수 있는 방법을 찾고 있는 것입니다.
즉 말씀하신 "ActiveX 가 아닌 다른 방법으로 구현이 가능"한 방법을 찾고 있는 것이 현재 토론의 주 내용입니다. 각 운영
체제 및 브라우져 별로 플러그인을 개발하는 제2안을 주장하기 앞서, 웹표준을 최대한 사용하는 제1안이 현재 방식보다 보안이 취약
한지에 대한 내용이지요.

책임 문제는 동의합니다. 책임 추궁보다는 대안을 찾고 있는 것이니까요. 그런데 ActiveX 전체의 문제를 보안 업계에 책임을
돌리려고 한다거나, 사용자가 yes 누르는 것까지 보안 업계만의 책임이라고 주장하는 상식적인 사람은 없으리라고 생각합니다. 실제
로 오픈웹은 가장 먼저 정부와 은행을 겨누지 않았습니까^^; 한국 웹환경에서 ActiveX 만연 현상은 우리 모두의 책임이라고
봅니다. (실제로 저 역시 ActiveX 컨트럴을 개발하던 회사에 몸담은 적이 있습니다.) 그런데 책임 추궁의 대표적인 예로 드
신 부분은, 책임 추궁보다 문제 제기로 보시면 안될까요? ^^; 혹시 제가 쓴 글을 누군가에 대한 책임 추궁으로 받아들이신 분
이 계시다면 죄송합니다.

마지막으로 말씀하신 웹표준 기술에 대한 홍보는, 오픈웹 활동과는 별개로 수년동안 끊임없이 이루어지고 있습니다. 가이드도 많이 있
고요. 그리고 실제로 몇년간 정말 엄청난 개선이 이루어져 있습니다. 웹과 관련된 일을 하시는 대부분의 분들이 표준 사용과 크로스
브라우저에 신경을 쓰고 있습니다. 개인뿐만 아니라 대형 사이트들(특히 네이버와 다음)도 크로스브라우저를 중요시 하고 있습니다.
웹 개발자 중에 현실에 치여 웹 표준 기술을 적용하지 못하고 있는 분들은 아직 있어도, 할 줄 모르는 분들은 없을겁니다. 심지
어 정부기관도 이제는 웹표준 문제에 동의하고 해결책을 모색하고 있습니다. 실제로 제가 굳이 IE를 실행하는 경우는 인터넷 뱅킹
과 쇼핑몰 및 관련 사이트를 사용할 때를 제외하고는 없습니다.

youknowit

unread,
Apr 12, 2009, 10:34:18 AM4/12/09
to open web
swlee/

> > ActiveX를 이용하여 구현했다는 이유 만으로 황당한 무용론을 주장하며 SSL로 회귀해야 한다는 주장입니다.
> > (기술적인 측면에서 분명히 SSL보안 접속보다 진보된 기술임에도 불구하고요..)

선뜻 납득이 가지는 않는 부분이네요... 모두가 아시는 내용이지만, ActiveX 는 프로그래밍 플랫폼의 일종일 뿐, 그 자체
가 무슨 프로그램인 것은 아닙니다. 액티브X는 프로그램을 담는 일종의 틀(framework)에 해당하는데, 막상 그 틀에 담기
는 프로그램 자체는 보안과 관련이 있을 수도 있고, 없을 수도 있습니다. 보안접속 프로그램을 담은 ActiveX의 경우, 실제
로 그 보안접속 프로그램이 수행하는 역할은 SSL 과 대동소이 하지 않나요? 심지어 소프트포럼의 보안접속 플러그인은 아예
"SSL 접속을 하기 위한 것"이라고 적혀 있던 것으로 기억합니다. -이니텍은 조금 다른 것도 같습니다만, 어쨋건,
shared key 를 비대칭 암호화 방식으로 전달하고, 상대방이 이것을 복호화하고 나면, 그 순간부터 세션이 끝날때 까지 이
shared key 를 가지고 대칭 암호화한 정보가 네트웍을 오가는 원리는 SSL 과 같다고 저는 이해합니다.

다만, SSL/TLS 보안접속과의 차이점은 shared key 가 서버-클라이언트 간에 공유되는 구체적 절차에 대한
documentation 이 (국내에서 사용되는 보안접속 프로그램의 경우에는) 전혀 없으므로, 그 위험여부를 객관적으로 검증해
볼 수 없다는 것 정도로 저는 생각하고 있습니다.

> > 인터넷 뱅킹이야 말로 그 무엇보다도 가장 최선의 보안대책이 구현되어야 하는 보안이 가장 중요한 사회적 행위임이 분명한데..
> > 그러한 보안의 중요성 보다는 당장 웹 표준화, ActiveX 제거만을 외치는 부분이 안타깝습니다.

선생님께서 적으신 이 부분은 실은, 두개의 논점이 포함되어 있습니다.

1. 오픈웹은 그동안 “ActiveX 만을 사용하고, 다른 어떤 대안도 제공하지 않는 서비스 제공 행태”에 대하여는 단호하고 분
명하게 반대 입장을 취해 왔습니다. 그런 행태는 다양한 소프트웨어들 간의 자유로운 경쟁과 소비자의 선택권을 원천적, 일방적으로
말살하기 때문입니다. 웹브라우저 소프트웨어 선택권은 user 에게 있어야 하는 것이지, 서비스 제공자가 user 의 선택권을 일
방적으로 말살하는 것은 옳지 않다고 생각합니다.

2. 그러나, “보안 기술적 측면”에만 국한 할 경우, 오픈웹의 입장은 ActiveX 라는 ‘틀’에 담긴 어떤 프로그램이 보안
에 도움이 되는 부가프로그램일 수는 있지만, 보안을 위한 그런 부가 프로그램을 무작정 ActiveX 라는 틀에 담아서 배포하는
것은 모순적일 수 있다는 것입니다. 선생님께서도 지적하셨듯이, 대부분의 경우, 액티브X는 오히려 보안과는 무관한 맥락에서 사용됩
니다(웹서버가 제공하는 pdf 문서를 '읽기'위해서, 웹서버가 주는 동영상 파일을 그저 '재생'하기 위하여 등, 로컬 리소스에
대한 액세스와는 전혀 상관없는 맥락). 액티브X는 그런 맥락에서 이용자의 사용 경험을 풍부하게 하는 용도로 사용하는 것이 바람직
하다는 것이 제 생각입니다.

액티브X가 "일반적으로" 보안 위험을 초래할 "잠재성"이 큰 기술이라는 사실은 MS사 스스로도 인정하고, 그 배포과정을 점진적으
로 더 까다롭게(user intervention을 더 많이 요구하는 방식으로) 변경시키고 있지 않습니까?

액티브X가 "보안"을 위하여 반드시 필요하다는 견해는 저는 잘 이해가 어렵습니다. 그 속에 담기는 어떤 프로그램이 보안에 유용
한 것이라는 점을 알겠는데, 그와 대등한 기능이 이미 웹브라우저에 built-in 되어 있다거나(보안접속의 경우), NPAPI
형태로 그 프로그램을 구현해도 되는데(전자서명의 경우), 굳이 ActiveX 라는 '틀'을 고집하는 것이 잘 이해가 안되어 자
꾸 물어보는 것입니다. 그 '틀'이 보안을 제공하는 것은 아니지 않습니다. (틀 속에 담긴 프로그램이 보안을 제공하고, 그 프
로그램은 덜 위험한 틀에 담아서 사용할 수도 있는데...)

youknowit

unread,
Apr 12, 2009, 10:38:59 AM4/12/09
to open web
오타... (아래는 수정된 것입니다)

> 액티브X가 "보안"을 위하여 반드시 필요하다는 견해는 저는 잘 이해가 어렵습니다. 그 속에 담기는 어떤 프로그램이 보안에 유용

> 한 것이라는 점은 알겠는데, 그와 대등한 기능이 이미 웹브라우저에 built-in 되어 있다거나(보안접속의 경우), NPAPI


> 형태로 그 프로그램을 구현해도 되는데(전자서명의 경우), 굳이 ActiveX 라는 '틀'을 고집하는 것이 잘 이해가 안되어 자

> 꾸 물어보는 것입니다. 그 '틀'이 보안을 제공하는 것은 아니지 않습니까? (틀 속에 담긴 어떤 '프로그램'이 보안을 제공하고, 그 '프
> 로그램'은 덜 위험한 '틀'에 담아서 배포, 사용할 수도 있는데...)

youknowit

unread,
Apr 12, 2009, 11:02:29 AM4/12/09
to open web
소프트포럼이 사용하는 액티브액스 콘트롤은 보안접속을 SSL 프로토콜로 구현합니다.

로그인 직전 단계에서는 익명사용자 SSL 접속세션(anonymous SSL session) 이 이루어집니다. 스크린 샷 참조.
http://groups.google.com/group/open-web/web/softforum_SSL_plugin.png

로그인이 이루어지면, 클라이언트가 확인된 세션(client authenticated SSL session) 이 형성됩니다. 스크
린 샷 참조. http://open-web.googlegroups.com/web/softforum_SSL_client_authenticated_session.png

저는 도무지 어째서 "SSL 이 더 안전하냐, ActiveX가 더 안전하냐"는 식의 논란이 이토록 소모적으로 벌어지는지를 이해
할 수 없습니다. 보안전문가 분들께서는 이미 아시고 계실 것이 아닙니까, ActiveX 플러그인 중에는 "실은 SSL 을 구현
할 목적으로 사용되는 것"들도 있다는 사실을... 이런 ActiveX 플러그인이 어째서 필요하다는 말씀이신지요?

(그리고, 소포가 사용하는 SSL 이 SSL2인지, SSL3 인지도 어느 분이 좀 말씀해 주시면 좋겠습니다. 저같이 업계 관련자
가 아닌 일반인들은 도저히 알 방법이 없네요. Documentation 이라도 좀 속 시원히 있었으면 좋으련만...)

정 태영

unread,
Apr 12, 2009, 11:08:45 AM4/12/09
to open...@googlegroups.com
아래 인용한 내용은 약간 다르게 표현되어야 할 것 같습니다.

인터넷 익스플로러용 확장기능을 구현하기 위한 방법이 ActiveX(DCOM
Component)이고, 모질라 계열 브라우져(+Konqueror)의 확장기능을 구현하기
위한 방법이 NPAPI 인 걸로 알고 있습니다.

둘다 내재되어 있는 위험성은 동일하므로 NPAPI로 배포되느냐 혹은 ActiveX
로 배포되느냐로
위험성 여부를 판단할 수는 없을 것 같습니다.

실제 Flash plugin만 보더라도 Internet explorer를 위한 ActiveX와 Firefox
를 위한 NSPlugin을 따로 배포하고 있고, 둘 중 하나만 설치할 경우 다른 브
라우져에서는 플래쉬를 볼 수 없죠.


그리고 계속 되풀이되는 얘기지만 SSL Sniff, strip과 관련된 내용은 ActiveX
를 사용한다고 막을 수 있는 문제들이 아니라고 판단됩니다. 비슷한 문제를
가지고 있다면 크로스 브라우징을 지원할 수 없는 방법보다는 크로스 브라우
징을 지원할 수 있는 있는 방식을 체택하는 것이 더 좋을거란 얘기죠.

대신 보안 채널 만으로는 원하는 정도의 보안 레벨을 제공할 수 없을테니 보
안카드, 공인인증서 등의 2차적 보안 장치를 사용하고, 키보드 해킹, 바이러
스 등에 취약한 운영체제에 대해선 사용자가 선택적으로 보안 툴을 적용할
수 있음 좋을 것 같습니다. (Ex: 다음 로그인 화면의 보안접속, 해킹방지 옵
션 네이버 로그인 화면의 1, 2, 3단계 보안 레벨) - 참고로 공인인증서를 이
용하여 값들을 서명하게 될 경우 중간에서 내가 보낸 값을 변조하는게 불가능
해집니다. 단 공인인증서가 ssl 채널 하에 전송될 수 있다는 점(처음 발급받
을 경우) 때문에 문제가 될 수 있겠네요.

게다가 지금 윈도우 실정에 맞게 구성되어 있는 보안 툴들을 그대로 타 플랫
폼에까지 적용하려고 하니까 심사를 통과할 수가 없는 실정인데...

http://news.zdnet.com/2100-9595_22-251586.html

위 링크는 작년 말에 zdnet에 실렸던 기사입니다. 제 기억으로는 torrent로
배포된 iLife에 해킹 툴이 심어져있었던 사건으로 기억되는데, 윈도우 세계에
서 저정도 일이라면 뭐 대수롭지 않게 넘겼겠죠. 워낙 흔한 일이니. 하지만
Mac OS X 에서는 저런 일이 절대 흔하지 않은 일이었던 겁니다. 리눅스도 거
의 마찬가지 상황이죠.

이런 OS 환경과 (일반적으로 초심자들에 많이 노출되어서 이런 결과가 나오
고 있겠지만) 윈도우 환경을 동일한 선상에 놓고 동일한 것들을 막아야한다는
건 조금 어폐가 있다고 생각합니다. 백신, 키보드 보안 툴들을 맥, 리눅스 환
경에 까지 강요하는 것은 피해줬음 좋겠다는 얘기죠.



2009. 04. 12, 오후 11:34, youknowit 작성:

youknowit

unread,
Apr 12, 2009, 11:44:36 AM4/12/09
to open web
On 4월13일, 오전12시08분, 정 태영 <mas...@mytears.org> wrote:
> 인터넷 익스플로러용 확장기능을 구현하기 위한 방법이 ActiveX(DCOM
> Component)이고, 모질라 계열 브라우져(+Konqueror)의 확장기능을 구현하기
> 위한 방법이 NPAPI 인 걸로 알고 있습니다.
>
> 둘다 내재되어 있는 위험성은 동일하므로 NPAPI로 배포되느냐 혹은 ActiveX
> 로 배포되느냐로
> 위험성 여부를 판단할 수는 없을 것 같습니다.

네, 둘 다가 플러그인 이라는 점에서는 비슷한 위험 요인이 있지만, 윤석찬님께서 지적하신 것 처럼, npPlugin 의 경우 웹
브라우저가 Sandbox 역할을 합니다. 그래서 위험성이 ActiveX 플러그인과 "동일하다"고 하기는 어렵지 않나요?
http://groups.google.com/group/open-web/browse_thread/thread/cefbaf8e595c116d/8cab669b56e7fc1b

물론, 제가 적은 것 처럼, npPlugin 형태로만 전자서명 플러그인을 배포, 사용할 경우, MS IE로는 인터넷 뱅킹을 못하
게 되는 반면, 파이어폭스, 크롬, 오페라 등 npapi 프러그인을 지원하는 다양한 웹브라우저는 모두 사용이 가능하게 됩니다.

전국민의 99%에 설치되어 있는 MS IE 를 뱅킹에 사용하지 못하게 한다는 것이 말이되냐? 라고 반문하실 것입니다. 그러나,
100%의 국민이 파이폭스나 크롬 등을 설치할 수는 있습니다. 그 설치가 과연 현재 은행들이 설치를 강요하는 ActiveX 플러
그인 설치 보다 "비현실적으로 어렵거나 번거로운가"는 논의해 볼 만한 이슈라고 생각합니다. 설치에 필요한 "클릭 수"는 비슷합니
다. (은행들이 아예 "파이어폭스 설치 ActiveX"를 배포할 수도 있긴 하지요)

물론, 지난 10년간 다른 웹브라우저를 못쓰게 막는 것은 당연히 여기면서도, MS IE 를 못쓰게 하는 것은 결코 용납 못하는
분들이 대부분일 것입니다. 그분들의 논거는 실은 "보안"이 아닙니다. "뱅킹에서는 보안이야말로 지상의 가치"라고 말씀은 하시지
만, 실은 보안이 아니라, 다수의 이용자들이 그저 MS IE 를 사용한다는 "현실"을 더 중요한 가치로 두고, "비록 보안에는
상당한 양보를 해야 하지만" 그냥 ActiveX 를 쓰는 것입니다.

"보안이 지상가치이므로 ActiveX 를 써야만 한다"는 반복되는 담론은 적지 않은 "허구"를 담고 있다는 점을 부각시키기 위하
여, NPAPI 이야기를 꺼냈습니다. 진정으로 보안이 지상 가치라면, 그리고, 플러그인을 어쩔 수 없이 써야 하는 상황이라면(전
자서명은 플러그인 없이 안되니), npPlugin 을 선택하는 것이 논리적으로는 옳지 않겠습니까? ActiveX 보다는
npPlugin 이 "보안상으로는" 덜 위험하니까...
파폭 설치는 2-3분이면 끝나지 않나요?

Channy Yun

unread,
Apr 12, 2009, 12:32:37 PM4/12/09
to open web
여기서 고려해야 할 점은 기존의 npplugin 방식도 윈도우에서는 activex launcher로
사용될 수도 있기 때문에 잠재적인 문제는 여전히 가지고 있습니다.
http://www.iol.ie/~locka/mozilla/plugin.htm

위의 프로젝트가 아주 오래 오픈 소스로 진행되고 있음에도 모질라 커뮤니티에서
인정하지 않는 것도 이런 요인 때문에 그렇습니다.

Channy

On 4월13일, 오전12시44분, youknowit <keechang....@googlemail.com> wrote:
> On 4월13일, 오전12시08분, 정 태영 <mas...@mytears.org> wrote:
>
> > 인터넷 익스플로러용 확장기능을 구현하기 위한 방법이 ActiveX(DCOM
> > Component)이고, 모질라 계열 브라우져(+Konqueror)의 확장기능을 구현하기
> > 위한 방법이 NPAPI 인 걸로 알고 있습니다.
>
> > 둘다 내재되어 있는 위험성은 동일하므로 NPAPI로 배포되느냐 혹은 ActiveX
> > 로 배포되느냐로
> > 위험성 여부를 판단할 수는 없을 것 같습니다.
>
> 네, 둘 다가 플러그인 이라는 점에서는 비슷한 위험 요인이 있지만, 윤석찬님께서 지적하신 것 처럼, npPlugin 의 경우 웹

> 브라우저가 Sandbox 역할을 합니다. 그래서 위험성이 ActiveX 플러그인과 "동일하다"고 하기는 어렵지 않나요?http://groups.google.com/group/open-web/browse_thread/thread/cefbaf8e...

youknowit

unread,
Apr 12, 2009, 12:46:37 PM4/12/09
to open web
제가 언제나 궁금히 여기던 점이 한가지 있는데요...

서명 플러그인을 ActiveX로 배포할 경우에는 반드시 관리자 권한이 있어야 설치가 가능한 것 같은데, 이것이 맞는지?

그리고, 통상의 npPlugin 의 경우, 일반 사용자 권한으로도 설치가 가능한 것 같은데, 전자서명 기능을 가진
npPlugin 도 일반 사용자 권한으로 설치 가능한지? (서명된 자바 애플렛 형태의 signer plugin 은 당연히 일반
사용자 권한으로 실행이 가능하다는 점은 알고 있습니다만, npPlugin 도 그런지는 잘 모르겠습니다)

On Apr 13, 1:32 am, Channy Yun <cha...@gmail.com> wrote:
> 여기서 고려해야 할 점은 기존의 npplugin 방식도 윈도우에서는 activex launcher로

> 사용될 수도 있기 때문에 잠재적인 문제는 여전히 가지고 있습니다.http://www.iol.ie/~locka/mozilla/plugin.htm

skon

unread,
Apr 12, 2009, 4:02:03 PM4/12/09
to open web
참 힘든 일인게..
이 운동의 핵심은 정치적인 접근입니다. 정치적으로 좀 공정해지자는 뜻입니다.
그런데 주위에서는 자꾸만 경제적인 면을 보라고 합니다. 구축 비용의 문제이며, 해킹됐을 때 손해보게되는 비용, 대외 신용(이것
도 결국은 경제적인 관점이랄 수 있겠죠.)의 문제라는 뜻입니다.
하지만, 이런 주장은 결국 정치적인 공정함을 무시하게 됩니다.

정치적 공정함을 생각할 때, 흔히 생각나는 것으로 장애우들이 있습니다.
장애우들이 보통 경제적으로 도움이 되기보다는 보통 손해를 끼치고 불편을 줍니다. 하지만, 인간의 존엄성을 기초로 정치적인 공정함
을 적용해, 어찌보면 낭비에 해당할 수 있는 그들에 대해서 특별히 배려하고 그들을 위해 불편을 감수합니다. 왜 그럴까요.. 장애
우도 우리 나라의 한 구성원이며 (구성비율이 낮음에도 불구하고) 인간으로서 누려야할 혜택이 필요한 존재이고, 그 혜택은 다른 사
람에 대해 좀더 특별해야하기 때문입니다.

이러한 상황은 우리나라의 인터넷 사용환경과 비슷한 면이 많습니다. 1% 정도일지 모르겠지만, 윈도우 환경이 싫어 다른 방법을 찾
아본 사람들입니다. 저 또한 주력 컴퓨터로 FreeBSD를 7년 정도 쓰다가, 3년 정도는 맥을 써온 사람입니다. 그런데, 정
부 홈페이지, 은행에 들어갈려면 윈도우밖에 방법이 없습니다.
(개발자분들 중에 1%에 불과한 이용자를 위해 별도의 비용과 시간을 들이는 것은 불합리하다는 생각을 가지신 분들이 너무 많습니
다. 또한 가끔 비윈도우 사용자도 어떤 방법으로든 은행을 이용해왔으니 문제될 것 없다는 주장을 하시는 분도 계십니다. 블로그나
게시판에 당당히 이런 불만을 얘기하시던 분들을 많이 봐왔습니다. 그런데 그런 발언들은 정말 비윈도우 사용자에게 무례한 것입니
다. 사람이란 자기 의결권을 가지고 있습니다. 그걸 강제할 때 사람들은 심한 모멸감을 느낄 수밖에 없습니다. 정말 어쩔 수 없
이 무기력하게 쓰는 것이지, 쓰고 싶은 것이 아닙니다.)

이런 제반의 환경에서 오픈웹의 운동방향은 단순히 캠패인 수준에서 진행될 수 없었다고 봐야할 것입니다. 그렇다고 해서 캠페인을 안
한것도 아닙니다. XP SP2에서의 ActiveX 정책 변경, 비스타의 ActiveX 정책 변경, IE8에서의 ActiveX 정
책변경과 같은 굴직굴직한 이슈에서 끊임없이, "봐라 너무 종속된 환경에 의존하는 경우 문제가 많이 발생할 수 있다. 좀더 표준적
인 환경으로 가자"라고 주장해왔습니다. 그러면 뭐합니까? 3년간의 중요이슈에서 현재까지 온 길은 오직, 윈도우, IE에서의 보안
강화였습니다.

이 굴직굴직한 사안들이 터졌을 때, 전문가 집단 어느 누구도 다른 길도 있으니 그 길을 마련해보자는 얘기나 그 시도는 없었습니
다. ActiveX는 여전히 사용가능하다라는 식으로는 접근했습니다. ActiveX가 꼬졌다가 우선이 아니라 한 회사의 정책에 더
이상 그만 휘둘리자는 겁니다.
전문가라면 전문가라는 자부심과 전세계 시장의 흐름을 얘기하고 싶다면 시장성이 없다라도 앞으로 무엇을 어떤 식으로 개선해나갈 수
있는가라는 제안이라도 좀 제시했어야하는 거 아닐까요? 왜 전문가 집단도 아닌 오픈웹에서 우리 주장에 기술적으로 완비된 해결책을
제시해야할까요. 이건 오히려 전문가집단에서 이런 식으로 하면 가능할 수 있다라는 시안을 주고 이 시안으로 오픈웹이 정부와, 은행
과 협상해야했던 것이 아닐까요?

지금도 지속되고 있습니다만, 과거 과학과 정치, 경제 등과의 연관성에 대한 많은 고민들이 있었습니다. 그리고 많은 과학자들이 반
성하기도 했습니다. 과학의 발전은 결코 정치, 경제와 독립적이지 않았고 거기에 피해를 받은 많은 사람들이 있었습니다. 작금의
ActiveX 사태또한 이런 문제가 있다고 생각합니다. 너무나도 경제 논리에 휘둘려 이에 소외되는 사람들이 많다는 점을 무시하
고 있습니다... 전문가 여러분... 조금은 더 정치적인 공정함으로 이 기술을 바라봐주셨으면 합니다.


사족.
"예" 이론은 많은 부분에서 지적될 수 있는 부분이기는 하지만, 역설적으로 "아니오"를 누룰 필요가 있음을, "아니오"를 누루
는 훈련을 의도적으로 시켜야함을 얘기하고 있다고 생각합니다. 인간은 어쩔 수 없이 "예"를 누루기 싶습니다. 다른 사람의 질문
에 부정적으로 시작하는 사람이 얼마나 될까요?

하지만, ActiveX의 역사는 MS에게 영광이기도 했지만, 질곡의 역사이기도 했습니다. XP SP2에서 왜 굳이 "예", "아
니오"를 넣었겠습니까.. 생각좀 하고 설치해라라는 거 아니었던가요? 서비스가 완비되지 않더라도 아니라고 생각하면 내가 원하지 않
는다면, "아니오"를 눌러라는 뜻 아닌가요?

보안 프로그램 설치시에 이런 선택권이 있나요? 키보드 보안 프로그램, 백신 프로그램... 거절하면 큰일난다는 소리는 있어
도... 안깔아도 쓸 수는 있지만, 너 위험해라는 선택권은 있던가요?
인간은 선택할 수 있는 권리가 있고, 그 권리를 행사했을 때, 책임을 질 의지도 있습니다. 이용자를 바보취급하기 이전에 이용자에
게 충실한 정보와 선택권을 주고 있는지도 생각해주셨으면 좋겠습니다.

어떤 분께서 일본에서도 ActiveX를 이용한 기술을 쓰려고 한다면서, 얘기하신 것이 일본사람들은 잘 안쓰려는 경향이 있다라고
언급하셨습니다. 우리나라는 당장 이런 학습과정이 필요로 합니다. 우리나라는 "아니오"를 누르게하는 일체의 학습과정이 없었습니
다. 무조건 "예"만 누르라고 합니다.
다시한번 말하지만, 오픈웹에서 주장하는 "예"이론은 그게 맞다, 틀리다를 떠나서 "아니오"를 누르게하는 학습이 필요함을 역설한다
고 생각합니다.


사족 2.
ActiveX를 자꾸 지적하는 것은 좀 다른 길을 알아볼 사람은 없냐라는 질문이기도 합니다.
자꾸만 ActiveX가 좋다는데.. 이런 문제가 있으니까 다른 길좀 알아보자라고 한 겁니다.. 그거에 ActiveX 꼬진 게 아
니다라고 얘기하는 것은 별 의미가 없습니다. 압니다.. ActiveX 좋은 거.. 그렇지만, 문제가 있다는 겁니다.

검은 그냥 도구일 뿐입니다. 그걸 사과껍질 깔 때 쓸 수도 있고, 사람 죽이는데 쓸 수도 있습니다.
다만, 사람들이 이러한 도구가 어떻게 쓰여왔는지의 역사를 알고 있습니다. ActiveX 또한 좋은 기술인 거 압니다. 다만,
그 역사가 안좋은데 쓰인 적이 너무나 많음을 알고 있는 것입니다.
그러면 그러한 역사를 가진 놈을 어떻게 관리하냐고요? 아무렇게나 쓰게 나두지 않습니다. 칼집에서 검을 꺼내는 순간을 생각해보세
요.. 상당히 제한된 상황에서 쓰게 하는 거죠.. ActiveX도 그러했습니다. MS의 일련의 조치를 생각해보십시오.
우리나라의 ActiveX는 이런 조치에 정면으로 반발했습니다. 하다못해 Vista에서의 작동을 생각해보면 MS의 기본 정책조차
무시하라고 합니다.


사족 3.
말 주변머리가 없어서.. 정리가 안되는 점 죄송합니다.

skon

unread,
Apr 12, 2009, 4:06:02 PM4/12/09
to open web
정태영님이 말씀하신 Mac OS X에서의 사실관계에 대해서 언급드립니다.
정확히 말해서 iWork '09 버전입니다.
정품에는 없었고, 인터넷에 불법으로 올려진 버전에 trojan이 심어져있었습니다.

http://www.macworld.com/article/138412/2009/01/trojan.html

swlee

unread,
Apr 12, 2009, 8:21:15 PM4/12/09
to open web
아마 오픈웹의 가장큰 오해는 E2E 보안접속 기술이 통채로 암호화 하여 다를바가 없다라고 말씀하시는 것 같습니다. 일부를 암호화
하던, 통채로 암호화 하던 기술적으로 가능하며 통채로 암호화하는 것이 FORM DATA 의 악의적인 위변조를 막는데 효과적입니
다.

예를들어 계좌번호가 12345678 이라면 SSL 만 적용되어 있다면 간단한 SSL 터널링 기법을 이용하여 손쉽게 위변조를 시도
해야 겠지만 E2E 보안 기술이 적용되어 있다면 우선 암호하 로직 부터 뚫어야 겠죠...

또 기술적으로 서버에서 E2E 자체적으로 클라이언트 DATA의
무결성 검증등이 가능하기 때문에
얼마든지 앞으로도 추가 개발을 통해 보안을 향상시켜나갈 여지가 많지만

SSL은 웹서버에 SSL 인증서 설치, 웹소스에서
링크를 https 수정 이외에는 할 수 있는것이 없습니다.

지속적으로 증가하는 보안 위협에는 택도 없는 노릇이죠..
했던말 또하고,,또하고.. 이젠 힘드네요..

여기있는 분들이 단순 이론적인 논리로만 말씀하시는데..
실제 구현된 로직을 분석해 보시고 OWASP 웹 10대 취약점을 기반으로
비교해 보시면 어느방법이 실제로 나은지 알 수 있을 것입니다.

교수님이 말씀하신 인터넷 뱅킹 취약점 역시
논리와 간단한 문서, 나머지는 말을 통해 이러이러한 식으로가능할 것이다 가 아니라
실질적으로 샘플 환경을 구현해 보시고 취약점을 시뮬레이션 한 다음에
XXX 한 논리는 이래서 가능하고 ZZZ 한 점은 불가능 하다 하시면
누구나 충분히 공감하고 이해할 수 있을 것이며
더이상 억지라고 말하지 않을 것입니다.

최소한 그 정도는 되어야 남을 설득하고,
자신의 주장이 옳다고 예기할 수 있는 수준의
근거가 될 수 있을 것입니다.

> > > 로그램은 덜 위험한 틀에 담아서 사용할 수도 있는데...)- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -

swlee

unread,
Apr 12, 2009, 8:54:06 PM4/12/09
to open web
음..
현재 적용되어 있는 SSL은 서버를 인증하는 것입니다.
상호 인증이 있기는 하지만 일반적인 웹 서비스에서 상호인증을 구현하는 경우는 없습니다.

그래서 얼마든지 로컬에서 SSL 프록시 프로그램을 가동하여
SSL 터널링을 하더라도 서버는 전혀 알아 차릴 수가 없는 것이죠..
키교환및 암호화는 SSL 프록시 서버에서 알아서 다 하니까요..
클라이언트가 DATA를 위변조 했다는 사실을 전혀 알 수 없습니다.

반면 E2E는 이러한 프록시의 개념을 적용할 수 없습니다.
따라서 많이 언급된 MITM 같은 네트워크 공격도 불가능 하고요..

눈에 보이는 것이 비슷하다고 같은것이 아닙니다.
보고싶은 것만 보려고 하지 마십시요..

> > - 따온 텍스트 보기 -- 따온 텍스트 숨기기 -

정 태영

unread,
Apr 12, 2009, 8:54:49 PM4/12/09
to open...@googlegroups.com
말하시는 E2E 보안 접속 기술에 대해 찾아봤습니다.

http://demo.initech.com/?module=file&act=procFileDownload&file_srl=2183&sid=5c5c303c7a32e863ee9403ae49ad4da2

하단에 표시되는 페이지 기준으로 37, pdf 에서의 페이지 기준으로 39 페이지
에 해당 내용이 정리되어 있네요.

보니 키보드 보안 모듈에서 키값->암호화 ... 서버단에서 복호화->키값 식의
방식을 사용하여 E2E 보안을 이뤄낼 수 있다. 라고 얘기하는 것으로 보이는데
요. ('E2E Xecureweb' 으로 구글링 했을 때의 결과가 이해가 가네요.)

그렇다면 이는 암호화 모듈 즉 SSL과 대치 해줬음 하는 부분과는 관계가 없어
보입니다.



2009. 04. 13, 오전 9:21, swlee 작성:

youknowit

unread,
Apr 12, 2009, 9:23:55 PM4/12/09
to open web
swlee/

아마 글타래가 달라서 못보신 것 같습니다. 제가 제시한 취약점 공략방법에 대하여 dasony 님께서도 선생님과 유사한 지적을 하
셨는데, 저는 조금 달리 생각하고 있습니다. 제 생각은 여기에 적어보았습니다.

http://groups.google.co.kr/group/open-web/msg/34fc05eef7a986f0?hl=en

e2e 보안은 고객-서버 간 교신 구간에서 이루어지고, 말씀하신대로 서버가 무결성을 점검할 수 있다는 점에서 단순 키보드보안과
는 크게 다르다고 저도 이해하고 있습니다. 하지만, 제가 제시한 방법에서 공격자는 "진짜고객"으로서 은행과 교신하므로, e2e
보안은 문제가 되지 않는다고 생각합니다. 공격자--서버 간의 교신 integrity 는 전혀 공격하거나 건드릴 필요가 없습니
다. 고객과 공격자 간에 plaintext 로 이루어지는 http pipeline 만을 하나 추가하는 것이기 때문입니다. 링크
해 드린 글을 한번 보시고 오류를 지적해 주시면 즉시 수정하겠습니다.

swlee

unread,
Apr 12, 2009, 9:26:03 PM4/12/09
to open web
어플리 케이션 레벨의 암호화(http 소스 레벨) 와 네트워크 레벨에서 패킷을 모두 암호화 하는것의 차이가 별반 없다고 예기했
던 것과 다를바가 없네요..

아래는 www 프록시를 통한 ssl 터널링을 예기하고 있습니다.
http://muffin.doit.org/docs/rfc/tunneling_ssl.html
이러한 개념이 ete 모델 에도 적용이 가능한지 알려주세요..

즉 중간의 프록시에더 평문 데이터의 스니핑이 가능하고 위변조가 가능한지
말씀해 주시면 저역시 두 보안 기술 모델에 차이가 없음을 인정 하겠습니다.


On 4월13일, 오전9시54분, 정 태영 <mas...@mytears.org> wrote:
> 말하시는 E2E 보안 접속 기술에 대해 찾아봤습니다.
>

> http://demo.initech.com/?module=file&act=procFileDownload&file_srl=21...


>
> 하단에 표시되는 페이지 기준으로 37, pdf 에서의 페이지 기준으로 39 페이지
> 에 해당 내용이 정리되어 있네요.
>
> 보니 키보드 보안 모듈에서 키값->암호화 ... 서버단에서 복호화->키값 식의
> 방식을 사용하여 E2E 보안을 이뤄낼 수 있다. 라고 얘기하는 것으로 보이는데
> 요. ('E2E Xecureweb' 으로 구글링 했을 때의 결과가 이해가 가네요.)
>
> 그렇다면 이는 암호화 모듈 즉 SSL과 대치 해줬음 하는 부분과는 관계가 없어
> 보입니다.
>
> 2009. 04. 13, 오전 9:21, swlee 작성:
>
>
>
> > 아마 오픈웹의 가장큰 오해는 E2E 보안접속 기술이 통채로 암호화 하여 다
> > 를바가 없다라고 말씀하시는 것 같습니다. 일부를 암호화
> > 하던, 통채로 암호화 하던 기술적으로 가능하며 통채로 암호화하는 것이
> > FORM DATA 의 악의적인 위변조를 막는데 효과적입니

> > 다.- 따온 텍스트 숨기기 -

dasony

unread,
Apr 12, 2009, 9:28:46 PM4/12/09
to open web
swlee님/ 말씀하신 부분은 E2E에 대한 내용은 아닌 것 같은데요. 양방향 인증을 하기때문에 통상적인 SSL보다 안전하다는
부분은 이미 나온 이야기고, 잘 사용하지는 않지만 이미 모든 브라우저에 탑재되어있는 SSL의 Client Certificate
이용시 동일한 효과를 볼 수 있다는 이야기도 나온 이야기입니다. 인터넷 뱅킹은 일반적인 웹서비스가 아니라 상호인증 구현해서 해야
한다고 생각합니다. =)

다른 쓰레드에서 나온 MITM 공격은 ActiveX 자체를 변경하는 방식이기 때문에, SSL터널링과 거의 흡사한 방식으로 공격
이 가능할 것으로 보고 있습니다. 말로만 하지 말고 실제 시뮬레이션을 해보는 것이 좋다는 부분은 동의하지만, 다들 생업이 있으
신 분들이라 말로밖에 못하는 상황을 좀 이해해주셨으면 합니다. ^^;

다만 ActiveX는 웹브라우저 기능을 사용하는 것에 비해, 자체적인 지속적인 대응이 가능하다는 부분은 확실한 장점입니다. 꼭
그렇게 해야 하나 싶긴 하지만요.

swlee

unread,
Apr 12, 2009, 9:41:05 PM4/12/09
to open web
잘못알고 계시네요...
상호인증을 하면 좋긴 좋지만..
상호인증을 하더라고 공격자는 정상적인 클라이언트 인증서 하나만 받으면 됩니다. 별로 어려운 일이 아닐 듯 하네요.. 즉 상호 인
증 역시 프록시 서버를 이용하여 MITM 하는것이 가능하며 기본적인 SSL의 문제점을 극복할 수는 없습니다.

그리고 ActiveX 는 http form data의 암복호화만을 담당할뿐 HTTP Request 를 전송하거나 하는 행위는 없
습니다. 프록시의 개념은 아닙니다. 클라이언트 측에서 전송과 수신은 모두 브라우저가 처리합니다.

그리고 교수님의 이론은 제가 짧아서 그런지 잘 이해조차 되지 않습니다.
머라고 드릴 말씀이 없습니다.

swlee

unread,
Apr 12, 2009, 9:56:56 PM4/12/09
to open web
단 교수님의 이론에 한가지만 의견을 하지면
공격자는 악의적인 ActiveX 를 Victim 클라이언트 PC 에 설치를 한다는 전제가 필요합니다.

여기계신 보안 전문가들이나 제가 예기하는 문제점에는
클라이언트 PC 에 악성 프로그램을 설치한다는 전제로는 예기하지 않습니다.

사실상 클라이언트 PC 에 공격자가 의도하는 악성코드가 설치되었다고 전제를 하면
못할것은 이미 아무것도 없으며 어떠한 방법을 적용해도
모두 가능하다고 말씀 드리고 싶습니다.
이미 해킹 완료라고 보셔도 무방할 수준입니다.

> > 그렇게 해야 하나 싶긴 하지만요.- 따온 텍스트 숨기기 -

youknowit

unread,
Apr 12, 2009, 9:57:15 PM4/12/09
to open web
죄송합니다. 원래 쓰래드 시작글에 적은 내용이 너무 간략해서, 조금더 보충하는 글을 포스트가 아니라 페이지로 적어두었습니다.
http://groups.google.co.kr/group/open-web/web/%ED%95%9C%EA%B5%AD+%EC%9D%B8%ED%84%B0%EB%84%B7+%EB%B1%85%ED%82%B9+%EB%B3%B4%EC%95%88%EC%9D%98+%EC%B7%A8%EC%95%BD%EC%A0%90?hl=en

그리고, 언급하신 ssl 터널링은 HTTPS transparent proxy 를 어떻게 구현하는지에 대한 개요 설명인 것으로 저
는 이해하고 있습니다. https proxy 의 경우, 프록시는 오가는 데이터를 복호화할 수도 없고, 내용을 변조할 수도 없는
것으로 이해합니다. "When tunneling SSL, the proxy must not have access to the
data being transferred in either direction, for sake of security." 당연
한 내용이라고 생각합니다. 만일 그렇지 않다면 "https" proxy 는 불가능할 것입니다.

"SSH 터널링"과 정 반대의 개념이라고 저는 이해하는데. 즉, SSH 터널링은 암호화된 파이프라인을 만들고 , 그 속으로 평
문 교신이 통과하도록 하는 것이고, HTTPS 터널링은 평문 파이프라인을 만들고, 그 속으로 암호화된 메시지들이 통과하도록 하
는 것 아닌가요?

제시하신 글은, 프록시 공격이 가능하다는 내용은 아니고, 그런 식으로 프록시를 설계하면 HTTPS 교신도 프록시 서버를 통하여
안전하게 이루어질 수 있다는 점을 설명하는 것이라고 저는 이해하고 있습니다만...

Jung Tae-young

unread,
Apr 12, 2009, 10:14:11 PM4/12/09
to open...@googlegroups.com
보안 채널이 TCP 위에 구성되느냐 HTTP 채널 위에 구성되느냐의 차이 정도 아
닌가요? 앞에서 얘기가 많이 나왔던 SSL Strip, SSL sniff 가 대입되지 못할
이유가 없어보입니다.

프로토콜이 공개되어 있진 않지만 비트 단위 출력이 나오는 alz 도(zip 과 유
사하다는 정보만으로) 리버스 엔지니어링 해서 디코더를 만드는 판에 이 프로
토콜을 리버스 엔지니어링 못한다는건 말이 안된다고 봅니다.

단 *정말 상호 인증을 사용하고*, *유효하지 않은 인증서를 자동으로 거부한
다*면 MITM 식으로 중간에서 고객으로 가장하고 서버와 통신하는 문제는 피해
갈 수 있을 것이라 보입니다. [1]

하지만 SSL strip 의 변형 공격이 불가능할 것으론 생각되질 않습니다.
https:// 식의 링크를 http:// 로 변경해서 보내주는게 가능하다면 activeX
를 이용하는 javascript를 변조해서 보내는 것 또한 어렵지 않겠죠.


[1] 질문: MITM 에서 유효하지 않은 인증서 오류를 피하는 방법이 CA 값이
FALSE인 인증서(다른 인증서를 서명할 권한이 없는 인증서)를 사용해서 사인
하는 방법 외에 또 다른게 있나요?

아래 문서에 따르면 관련된 문제는 IE6 이하 버젼에 한정된 것으로 보이니 만
약 저 문제 외에 다른 방법이 없다면 IE6 이하 버젼으로는 인터넷 뱅킹을 하
지 못하도록 하는 것으로 피해갈 수 있을 것으로 보이는데요.

http://www.thoughtcrime.org/ie-ssl-chain.txt


swlee 쓴 글:


> 어플리 케이션 레벨의 암호화(http 소스 레벨) 와 네트워크 레벨에서 패킷을 모두 암호화 하는것의 차이가 별반 없다고 예기했
> 던 것과 다를바가 없네요..
>
> 아래는 www 프록시를 통한 ssl 터널링을 예기하고 있습니다.
> http://muffin.doit.org/docs/rfc/tunneling_ssl.html
> 이러한 개념이 ete 모델 에도 적용이 가능한지 알려주세요..
>
> 즉 중간의 프록시에더 평문 데이터의 스니핑이 가능하고 위변조가 가능한지
> 말씀해 주시면 저역시 두 보안 기술 모델에 차이가 없음을 인정 하겠습니다.
>
>


--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다.

http://mytears.org/

youknowit

unread,
Apr 12, 2009, 10:36:04 PM4/12/09
to open web
네, 그러나 문제는 공격이 성공할 "비율"이 어느 정도 높으냐가 아닐까요? 세심한 주의를 기울이는 이용자마저도 detect 하
기 어려운 공격이라면, 그것은 이미 심각한 보안위협이라고 보아야 하지 않을까 생각합니다.

클라이언트 PC에 악성프로그램이 설치되지 않았다고 전제하고 이야기 한다면, 실은 키보드보안 프로그램 자체가 필요가 없겠지요.

키보드 보안(e2e가 되었건, 단순 안티 키로거가 되었건) 프로그램의 유일한 존재이유가 바로 사람들의 컴퓨터에 악성프로그램이 설
치되어 있고, client workstation 의 integrity 가 깨져있는 경우가 많다는 사실 아닌가요?

지금 이순간에도 사람들이 자꾸 악성프로그램 설치를 "수락"한다는 전제 자체를 부인하면, 아예 우리가 이런 논의를 할 필요도 없
을 것입니다.

사람들이 악성프로그램을 설치하더라도, e2e 보안은 높은 수준의 방어를 제공한다는 것인데, 제가 제시한 방법은 사람들이 "은행
사이트"와 외관과 URL이 완벽하게 동일한 상황에서 그 "은행"이 주는것으로 보이는 프러그인 하나를 "예"하면, e2e 보안이
되었거나, 보안카드 번호가 되었건 모두 무용지물이 된다는 것입니다.

http 접속으로 이루어지는 국내 금융거래의 "특성"을 고려하면, 이런 공격은 어쩔 수 없다고 체념하실 수는 없지 않겠습니까?

swlee

unread,
Apr 12, 2009, 10:43:05 PM4/12/09
to open web
아래 링크는 stunnel 을 이용하여 raw http data 를 ssl 암호화 하여 서버로 통신하는 주제를 다루고 있습니
다.
raw http data야 평문이니 위변조를 못할 이유가 없습니다.

http://sandsprite.com/Sleuth/stunnel_sslRawreq.html
제 말이 이해가 되지 않는다면 참고 바랍니다.

지구인

unread,
Apr 12, 2009, 10:43:29 PM4/12/09
to open web
youknowit 님의 링크내용을 보면 사용자 PC에서는 ActiveX plugin이
구동되지 않는(최소한 가짜가 구동되는)것으로 보여 집니다.
그러니까 E2E는 서버와 공격자PC간에서만 있는것이고 사용자PC에는 공격자PC에 나타난 내용을
수정, 포워딩한 내용만 보여지는것 같습니다. 맞는가요?
사용자는 익숙한 페이지니 그냥 ID/PW를 입력 할것같고
그것을 그대로 받은 공격자는 자신 이 받은 페이지에 그 내용을 그대로 넣는 방식으로 보여 집니다.
E2E프로그램까지 가짜로 만들어서 공격자와 사용자간 가짜E2E를 구성 할 수도 있을것이구요.

이런 식이라면 MITM 과 별로 달라 보이진 않습니다.

E2E는 이런 방법을 막을수 있는가요?
역시 MITM과 E2E에 대한 정확한 이해를 제가 못하고 있을수도 있겠습니다.
지적 부탁 드립니다.

swlee

unread,
Apr 12, 2009, 10:46:05 PM4/12/09
to open web
아래 링크는 공개 유틸리티인 stunnel 을 이용하여
http raw data 를 ssl 암호화 하여 서버와 통신하는 기법을 다루고 있습니다.
http raw data는 평문이기 때문에 얼마든지 위변조가 가능하죠..

http://sandsprite.com/Sleuth/stunnel_sslRawreq.html

이것은 ssl 이 네트웍 구간에서 암호화 만을 보장하는 근본적인 한계를 반증합니다.
제 말을 이해 하시는데 참고 바랍니다.

> > > - 따온 텍스트 보기 -- 따온 텍스트 숨기기 -

swlee

unread,
Apr 12, 2009, 10:48:17 PM4/12/09
to open web
게시글이 올라가지 않네요.,,

http://sandsprite.com/Sleuth/stunnel_sslRawreq.html

위 링크는 raw http data 를 openssl 로 암호화 하여 서버와 정상적인 통신을 한다는 예기입니다.
raw http data 는 평문이기 때문에 위변조 하는것은 일도 아닙니다.

이것은 ssl 이 네트웍 구간에서 암호화 만을 보장하는 한계를 반증합니다.

dasony

unread,
Apr 12, 2009, 10:49:51 PM4/12/09
to open web
> 잘못알고 계시네요...
> 상호인증을 하면 좋긴 좋지만..
> 상호인증을 하더라고 공격자는 정상적인 클라이언트 인증서 하나만 받으면 됩니다. 별로 어려운 일이 아닐 듯 하네요.. 즉 상호 인
> 증 역시 프록시 서버를 이용하여 MITM 하는것이 가능하며 기본적인 SSL의 문제점을 극복할 수는 없습니다.

현재 인터넷 뱅킹에서 사용하나느 공인인증서와 SSL의 Client Certificate를 동일한 것으로 봐야하지 않나요? 공격자
는 정상적인 클라이언트 인증서를 받을 수 없습니다. Client Certificate를 보고 어느 고객인지 확인하는 것인데요.

swlee

unread,
Apr 12, 2009, 10:57:30 PM4/12/09
to open web
SSL 상호 인증을 하게 된다면..
은행은 클라이언트 PC에서 사용해야할 인증서 파일을 지금의 공인 인증서 형태처럼 배포해야 할 것입니다.
그냥 인터넷 뱅킹 신청하면 공인인증서 받듯이 받을 수 있을 것 같은데요..

youknowit

unread,
Apr 12, 2009, 10:59:47 PM4/12/09
to open web
On Apr 13, 11:49 am, dasony <das...@gmail.com> wrote:
> 현재 인터넷 뱅킹에서 사용하나느 공인인증서와 SSL의 Client Certificate를 동일한 것으로 봐야하지 않나요? 공격자
> 는 정상적인 클라이언트 인증서를 받을 수 없습니다. Client Certificate를 보고 어느 고객인지 확인하는 것인데요.

예, 저도 그렇게 알고 있습니다. 소프트포럼이 판매하는 보안접속 ActiveX 는 SSL 접속을 하기 위한 것에 불과합니다. 고
객이 공인인증서로 은행페이지에서 로그인 하면, 그때 부터는 "클라이언트 인증 SSL 세션"이 이루어집니다.

http://groups.google.co.kr/group/open-web/msg/383b949e821302f6?hl=en
링크된 스크린 샷 참조하시기 바랍니다.

여기 토론 하시는 분들은 이미 다 아시는 내용이겠지만...

dasony

unread,
Apr 12, 2009, 11:00:46 PM4/12/09
to open web
네. 하지만 저는 swlee님의 Client Certificate를 받을 수 없기 때문에, 서버를 제가 swlee님이라고 속일
방법은 없습니다. 즉 MITM 공격자가 은행에게 자신이 공격 대상이라고 속일 방법이 없습니다. Client Certificate
를 이용하여 로그인하는 서비스를 사용해보신 적이 없으신 것 같습니다. 많은 서비스들이 아이디/패스워드 없이 Client
Certificate만으로 로그인을 하여 사용합니다.

youknowit

unread,
Apr 12, 2009, 11:07:28 PM4/12/09
to open web
swlee/

국내에서 1000만장 넘게 발급된 공인인증서가 바로 client certificate 입니다.

"SSL 이 안전하냐, 별도 프로그램을 사용한 보안접속이 안전하냐"는 논의는 의미가 없습니다. 소프트포럼 등이 국내 은행에 납품
하여 지금까지 사용해 온 "보안 접속 별도프로그램"이 바로 SSL 교신(익명SSL 세션과 클라이언트 인증 SSL 세션)을 하기
위한 것입니다.

도대체 이런 플러그인이 왜 필요한지요?

Jung Tae-young

unread,
Apr 12, 2009, 11:12:52 PM4/12/09
to open...@googlegroups.com
아래쪽에서 얘기하신 거랑 방금 링크건 내용이랑 같지 않은걸로 보입니다.

1. 아래쪽에서 얘기하신것: HTTP채널 - 데이터는 HTTP로 보내기 전에 암호화
2. 제가 얘기하는 것: 주고받는 내용이 SSL로 암호화된 HTTP (HTTP overl SSL)
3. 방금 얘기하신 것: SSL 을 지원하지 않는 클라이언트를 위한 wrapper

1번의 경우엔 현 ActiveX 체제의 암호화 통신을 들 수 있겠습니다. 데이터는
XecureWeb, INISafeWeb 등을 통해 암호화 되고 HTTP(over tcp) 혹은 TCP 등을
통해 전송됩니다.

2번의 경우엔 암호화를 ActiveX 등이 아닌 브라우져 자체에서 처리합니다. 브
라우져에서 기본으로 SSL을 처리하니까요.

1, 2 번에 대해서는 암호화의 주체(브라우져? ActiveX?), 그리고 프로토콜의
문서화/정형화 여부 밖에는 모르겠습니다.


3번의 경우엔 보내주신 문서보다 다음 문서에 더 잘 나와 있습니다.

http://www.stunnel.org/examples/generic_tunnel.html

간단히 얘기해서 HTTPS를 쓰고 싶은데, 클라이언트 브라우져가 HTTPS를 지원
하지 않는다면 stunnel 데몬을 띄우고 stunnel 을 통해서 https 서버로 접속
을 하게 되는 겁니다. imaps를 쓰고 싶은데, 내 메일 클라이언트가 imaps를
지원하지 않는 경우도 마찬가지


앞에서 간단해게 써놨는데...

1. 서버 - 공격자(고객으로 가장) 사이에 보안 채널이 형성되고,

2. 악의적인 ActiveX 혹은 ActiveX를 사용해서 보안 통신을 하는 것으로 가장
된 javascript 를 사용자에게 보내줄 경우 (SSL Strip과 비슷한 개념으로)

위/변조가 가능할 것으로 보인다는 얘기입니다..

제가 잘못말한 점이 있으면 지적 부탁드리겠습니다.

swlee 쓴 글:

swlee

unread,
Apr 12, 2009, 11:19:28 PM4/12/09