국내 인터넷 뱅킹 보안의 취약점
youknowit
다.
SSL3/TLS1 이 제공하는 안전한 교신 그 자체는 공격을 못하지만, 고객이 서버와 https 교신채널을 확립하기 전에 공격자
가 끼어들어, 고객과 공격자 간에 HTTP 교신을 하고, 공격자는 고객이 입력하는 모든 값을 그대로 받은 다음, 필요한 부분(액
수, 입금 계좌번호 라든지...)만 변조하여 서비스 제공자와 교신하는 공격방법은 물론 가능합니다. (swlee 님께서 환기해주
신 SSLstrip)
이 공격은 물론, 고객이 자신의 웹브라우저 주소창을 꼼꼼히 살펴보지 않는다는 사정을 exploit 하는 것입니다. 고객과 서버간
에 제대로 된 접속은 https 로 되어야 하지만, 공격자가 중간에 끼어 들면, 고객과 공격자는 http 로 접속됩니다(고객은
자기가 서버와 접속하고 있다고 믿는 상태가 유지되어야 합니다).
한국의 인터넷 뱅킹은 이러한 복잡한 sslstrip 도 필요 없이, 단순 무식한 http sniffing 만으로 공략이 가능할
것으로 저는 생각합니다. 그 개요는 첨부 파일 참조.
http://groups.google.com/group/open-web/web/vulnerability_Korean_internet_banking.pdf
이런 공격은 단 하나의 관문만 통과하면 가능하게 됩니다. 고객이 은행(이라고 생각하고) 접속했을 때, "이 소프트웨어를 설치하시
겠습니까?"라는 보안경고창에서 "예"를 클릭하기만 하면 됩니다. 그동안 언제나 "반드시 예"하라고 교육받은 한국의 이용자들이
이 경고창에서 "아니오"를 선택할 가능성은 없다고 생각합니다(페이지 자체가 은행페이지와 완벽히 동일하고, 웹 주소까지 동일하므
로)
공격에 필요한 플러그인은 중급 기술자가 약 2-3일만에 만들 수준이라고 생각합니다. NamX 님은 마치 암호화/보안접속 등 모
든 기능을 구비한 플러그인을 공격자가 만들어야 하는 것처럼 생각하시지만, 그런 제대로된 플러그인은 은행이 줍니다. 공격자는 고객
의 인증서+개인키+비밀번호를 단순 무식하게 공격자에게 POST 하는 기능을 가진 플러그인을 만들어 고객에게 내려주면 됩니다.
http sniffing, 고객으로부터 전달받은 입력값 중 일부(입금계좌, 금액 등) 만을 실시간으로 바꿔치는 text
change script 정도만 쓸 줄 알면, 별 어려움 없이 공략이 가능할 것입니다.
dasony
해당 프로그램을 완벽히 신뢰할지 여부를 결정해야 합니다. 그런데 현재 인터넷 뱅킹을 사용하면 여러 업체에서 제공하는 여러 개의
프로그램을 설치해야합니다. 그리고 일반 사용자들이 국내 보안 업체의 이름을 명확히 알고 있을리가 없지요. 그러니 영어로 된 적당
히 진짜 회사 같아보이는 이름으로 signing한 악성 코드의 설치에 쉽게 동의할 수 있습니다. 이를 위해 단기적으로라도, 다양
한 보안 프로그램을 각 은행 이름으로 sign한 하나의 ActiveX 형태로 일괄 배포하는 것이 필요하다고 생각합니다.
Mountie Lee
그것을 호출하는 서버와 실제 제공하는 서버(codebase)가 다르더라도
유저가 차이점을 전혀 인지할 수 없습니다.
이것은 구조적인 문제이기 때문에 브라우저자체를 손대지 않고는 해결이 불가능하고
이것을 장점(*)으로 인식하여 codebase URL은 보안업체 자사서버로 지정해두는 경우가 태반입니다.(이게 업데이트에도 아주 신속하게 대응이 되죠)
피싱사이트가 있다고 가정하고
그 피싱사이트에서 은행에서 사용하는 ActiveX Control을 그대로 불러와서 이용하는것이 가능합니다.
더이상의 진행도 가능(*)하다는 짐작을 충분히 해볼 수 있습니다.
최소한 지금보다 보안을 개선하려면
ActiveX를 그대로 쓴다고 하더라도 Server SSL은 필요하다는 생각입니다.
Server SSL에서는 최소한 유저가 다른 도메인에 접근하게 되면 인지가능한 경고메세지가 나옵니다.
dasony
도 쉽게 생각할 수 있는 방법이니 분명히 보안 프로그램에 이에 대한 대응이 있을 법도 한데, 아직 알려주시는 분이 없네요. 그
런 것이 없다면, 이 공격의 핵심은 social engineering입니다. 인터넷 뱅킹 사이트에서 issuer를 확인하지 않
고 ActiveX를 무조건 설치하는 버릇으로 인해서, MITM을 통해 ActiveX를 악성코드로 바꿔치기 했을 때 대다수의 사용
자가 실제로 설치할 것이라는 전제를 갖고 있지요.
기술적 헛점이 없다면, 이 전제가 사실인지 실제 실험을 해보면 재밌을 것 같습니다. 게임방이나 카페 등 사용자가 인터넷 뱅킹을
사용할 법한 공개된 PC가 있는 곳의 네트워크를 조작하여, 인터넷 뱅킹에서 사용하는 보안 프로그램을 중간에서 바꿔치기 하는 것입
니다. 피실험자에게 피해를 주면 안되니 실제 프로그램을 바꾸는 것은 아니고요, 서명만 변경한 cab파일로 바꾸면 됩니다. (재미
를 위해 간단한 프로그램을 추가할 수는 있겠습니다. =)
이렇게 바꿔치기한 ActiveX를 사용자가 설치하는 비율이 얼마나 되는지 확인하는 것입니다. 보안 업체와 흡사한 이름으로 서명
된 코드, 전혀 다른 이름으로 서명된 코드, 아예 Self-signed된 코드 등으로 나누어 각각에 대한 비율을 확인해보면 더
좋겠습니다. Code Sign 인증서는 받을 수도 있겠고, 아니면 실험 대상이 될 PC에서만 미리 가짜 Root CA를 하나 추
가할 수도 있겠습니다.
실제 XecureWeb 등을 흉내내거나 wrapping한 가짜 프로그램을 만들고, 사용자의 이체 계좌를 변경하거나 공인인증서와
passphrase를 빼내는 공격을 시도한다면 조금 더 드라마틱한 시연을 할 수 있겠지만, 그건 비용이 좀 들겠지요.
어떤가요
Matt Oh
--
-matt
Matt Oh
--
-matt
Matt Oh
--
-matt
youknowit
제가 제시한 공격방법은 안티 키로거를 아무리 설치해도 막을 수 없습니다. 안티 키로거(E2E 안티키로거가 되었건, 단순 안티키로
거가 되었건)는 "고객--공격자--서버" 교신 구간 중, "공격자--서버" 간에서만 작동합니다(플러그인 방식으로 안티키로거를 구
동할 경우).
플러그인 방식으로 구동되는 안티바이러스 역시, 이런 공격에는 속수무책일 것입니다. "고객--공격자" 간의 교신 구간에서 공격자
는 은행 홈페이지를 받아서, 그 중에 안티바이러스 플러그인 구동에 필요한 object tag 을 삭제한 html 페이지를 고객에
게 던져주면 그만 입니다.
보안카드 역시 무용지물 입니다. 고객이 꼬박, 꼬박 열심히 입력한 값을 공격자는 그냥 받아서, 그대로 은행에게 전달하면 됩니
다.
고객이 은행에 접속하는 순간 (http로 접속하지요), 공격자가 개입하는데 성공하기만 하면(그리 어렵지 않지요), 고객화면에는
url 도 완벽하게 동일하고, 페이지 외관도 완벽하게 동일한 "은행 페이지"가 나타나고, "이 소프트웨어를 설치하시겠습니까?"라
는 보안경고창이 하나 뜨는 것이 전부 입니다.
여기서 고객이 "예"를 누르면, 공격은 이루어집니다.
다른 공격 방법을 한가지 더 올리겠습니다.
On 4월11일, 오전5시03분, Hodong Kim <cogn...@gmail.com> wrote:
> "콜럼버스의 달걀"
>
> hardware keyboard emulator
> keyboard with ps/2 via rs-232c
> controllable keyboard via another computer
>
> 이게 왜 필요할까... 생각해봅시다.
> 그것을 이해하는 순간,
> 세상엔 뚫리지 않는 방패가 없다는 것을 깨닫게 되실 것입니다.
>
> 제가 "정교한 해킹 기법들에 대한 대응책 모색"에서
> 주장한 내용이 이해가 되실 것입니다.
> 우리사회가 어떻게 종합적으로 대처해야 할 것인가에 대한 답이 나올 것입니다.
> 어느 한 쪽만 노력해서는 안 됩니다. 동시에 여러 분야에서 노력해야 합니다.
>
> 융합 학문, 융합 기술 측면에서 바라보면,
> 정보보호 부분은 전세계가 블루오션입니다. 국제적 논문 거리, 특허 거리 무척 많습니다.
> 먼저 나는 새가 먹이를 잡습니다.
>
> On 4월11일, 오전2시36분, Matt Oh <oh.jeongw...@gmail.com> wrote:
>
> > 예 새로운 관점에서의 교수님의 지적이 신선하게 느껴집니다. MITM으로 설치되는 액티브엑스 컨트롤은 일종의 악성 코드로 분류할 수
> > 있습니다. 일단 시스템의 정합성(integrity)가 깨지면 그 이후의 조치들은 어차피 사후약방문일 수 밖에 없지요. 그래서 더더욱 안티
> > 바이러스와 키로거의 중요성이 부각되는 것 같습니다. 물론 지금처럼 은행 사이트에 들어 갈때만 돌아 가야 하는 것이 아니라 이미 사용자
> > 시스템에 설치 되어서 돌고 있어야 할 필요성이 더 절실한 것 같습니다.
>
> > 그런면에서 오픈웹을 추진하기 이전에 전국민에 대해서 "1 PC 1 백신" 운동이라도 벌이는 것이 낫지 않을까 합니다. 그 이후에
> > 사용자들의 보안성이 어느 정도 확보한 후에 이러한 인터넷 뱅킹에 대한 운동도 조금 설득력을 얻을 것 같네요. 그리고 전국에 존재하는
> > 수많은 취약한 Access Point들도 사실은 여러번 언론에서도 다뤄졌지만 보안성을 해치는 큰 요인중의 하나입니다. 이러한 부분에
> > 대해서 사용자 교육과 계몽, 그리고 보안성 점검 툴의 배포등을 통해서 어느 정도의 보안성을 확보할 필요가 절실한 것이지요.
>
> > 계속 얘기하지만 오픈웹이 점점 보안 개발자와 전문가들의 고충을 이해하시는 것 같아서 기쁩니다(진심입니다).
> > 2009/4/10 Mountie Lee <mountie....@gmail.com>
youknowit
은행이 아무리 ActiveX 를 덕지 덕지 추가해도, 그것은 모두 "공격자--은행" 간에서만 작동하므로 아무 소용이 없다는 점
이 조금더 드러날 것입니다.
Matt Oh
--
-matt
Matt Oh
--
-matt
youknowit
시스템에 설치 되어서 돌고 있어야 할 필요성이 더 절실"하다는 부분을 깜빡했네요... 제대로 된 Antivirus 프로그램(플러
그인 방식이 아니라) 사용을 적극 권장해야 한다는 점은 전적으로 공감합니다.
선생님과 저는 거의 생각이 비슷한 것 같습니다. 보안은 프로그램만 설치한다고 되는 것이 아니라, "사용자 교육"이 병행되어야 한
다는 점 말입니다.
제가 이 논의를 하는 이유는 다음 두 가지 Approach 를 비교하기 위함입니다.
1. 이용자에게 설명하기 보다는, 무조건 우리(은행, 보안업체)를 믿고, 우리가 주는 프로그램을 "반드시 예"하라고 주입하는
approach
2. 플러그인을 아예 주지 않는 대신, EV SSL 인증서와 OTP 를 채용한 다음, 사용자에게 "보안경고창이 나타나면 아니오
하라", 로그인 할때는 반드시 "EV ssl 인증서 씰(seal) 이 주소창에 나타나는지를 확인하라"고 *안내*하는
approach.
Matt 님께서는 이 두 approach 중 어느 것이 보안에 더 나은 선택이라고 생각하시는지요?
은행이 주는 보안프로그램을 "정면돌파"해서 깨는 것이나, 그 프로그램과 외관이 거의 같은(오직 게시자 명칭만 달라서, 99% 이
용자들이 속아넘어가는) 프로그램으로 "속이는" 것이나, 결과는 매 한가지 라고 저는 생각합니다. "속일 수는 있지만, 깰 수는
없으니", 괜찮다는 입장은 왠지 설득력이 떨어지는 것 같다는 생각이 드는 군요.
On 4월11일, 오전9시52분, Matt Oh <oh.jeongw...@gmail.com> wrote:
> 그리고 설명하신 fake 프로그램을 인터넷 뱅킹의 취약점이라고 한다면, 다른 모든 종류의 가짜 프로그램이 있는 프로그램들도 다들 취약점을
> 가지고 있다라고 주장하는 것과 같은 결론이 됩니다.
>
> 누가 가짜로 V3랑 똑같은 UI로 프로그램을 만들어서 배포하는 악성 코드를 보고서, 안랩 V3가 취약해라고 하는 사람은 없습니다.
> 그 부분은 그냥 악성 코드가 나돌고 있다라고 표현하는 것이죠.
>
> 교수님의 아이디어는 악성코드를 만들어서 사용자를 속이겠다라는 것이지, 프로토콜 자체를 해킹하는 것은 아니니까요. SSL MITM과는
> 근본적으로 다르다고 봅니다.
>
> 제발 논의의 방향을 자꾸 엉뚱한 곳으로 이끌지 마시기 바랍니다.
> 2009/4/10 Matt Oh <oh.jeongw...@gmail.com>
>
>
>
> > 예 제글을 잘 안 읽으셨군요.
>
> > 선행적으로 이미 AV나 안티 키로거가 있어야 한다고 말씀드린 것 같습니다만?
>
> > 이런류는 MITM이라고 하기도 그렇고 그냥 Fake 프로그램이라고 불러야 할지 모르겠군요.
> > 이미 가짜 AV도 여러종류 나와 있는데, 그것과 비슷한 형태의 공격으로 볼 수 있겠습니다.
>
> > SSL도 그렇지만 이 부분은 결국 사용자의 주의에 기대는 수밖에 없습니다. 어차피 가짜 정보를 사용자에게 주입할 수 있다면 SSL이나
> > 액티브엑스 방식이나 모두 무력화 되는 것이니까요. 이부분은 이미 수차례 언급된 부분인데 계속 새로 설명해야 하는군요. 결국은 지금
> > 상황에서도 사용자 교육이 더 필요한 내용이구요. 사용자가 부주의하다면 어떠한 공격이든 일어 날 수 있을 것입니다. 이 경우에는 명백히
> > 은행측에서 사용자 과실임을 증명할 수 있으니까요.
>
> > 자꾸 논의가 뱅뱅 도는 것 같습니다. 누구도 현재의 인터넷 뱅킹은 취약점이 없다라고 자신할 수 있는 사람은 없습니다. 다만 그 공격을
> > 행하기 위한 비용과 얼마나 사용자들이 공격을 인지할 수 있는 가능성이 있느냐, 그리고 외국(특히 중국)의 공격자들이 손쉽게 해당 공격을
> > 행할 수 있느냐도 중요한 팩터입니다.
> > 2009/4/10 youknowit <keechang....@googlemail.com>
Matt Oh
일부 사람들은 FF에서 플러그인 지원을 주장하다가 갑자기 플러그인 무용론으로 나오다가 참으로 헷갈립니다. 일단 그 입장을 통일하셔야 할 것 같구요.
youknowit
요? 그래서, ssl strip 이라는 공격방법이 거론되는데, ssl strip 은 SSL3/TLS1 을 직접 공격하는 것이
아니라, 이용자를 속이는 것입니다(주소창을 제대로 확인하지 않는 이용자 행태를 exploit 하는 것이지요). 제가 제시한 공격
방법 역시 이용자를 속이는 것이라는 점에서는 동일합니다.
그러나, ssl strip 은 EV SSL 인증서를 채택하고, 이용자에게 주소창에 나타나는 인증서 씰을 확인하도록 안내하면, 어
느 정도 "예방"이 가능합니다. 제가 제시하는 공격방법을 예방하려면, 이용자들에게, 보안경고창에 나타나는 게시자 명칭을 반드시
확인하라고 안내해야 겠지요. 그러나 이 안내가 실효성이 없어질 만큼 지난 10년간 "반드시 예"하라고 안내해 왔지요. 10년간
축적, 학습된 컴퓨터 이용행태를 고치지 않는 이상, 제가 제시한 공격방법을 예방하기는 쉽지 않을 것으로 생각합니다만...
SSL2 (지금은 deprecated 된 프로토콜)에 대한 MITM 공격은 프로토콜 취약점을 공격하는 요소와 이용자의 부주의
를 exploit 하는 요소를 모두 포함합니다(인증서 경고창이 뜰때 이용자가 그것을 무시해야 가능한 공격입니다). 최신 버전 웹
브라우저에서는 이 공격은 사실상 불가능하다고 봐야 합니다.(오페라, 파폭3 등에서는 SSL2가 아예 제거되었고, MS IE7 이
후 에서는 이용자가 굳이 SSL2를 일부러 활성화해야 하고, 종전 버전 웹브라우저에서는 인증서 경고창 하나 달랑 떴지만, 지금
은 아예 화면 전체가 warning 으로 바뀌고, 위험하다는 안내가 훨씬 크게 나타나도록 웹브라우저가 설계 되어 있지요)
> ...
>
> 추가 정보 >>
Matt Oh
사실은 모든 것이 설득의 문제인데 대다수의 보안 전문가들에게 별로 설득력이 없는 "예" 이론을 자꾸 들고 나오시는 것도 그렇구요.
SSL의 장점은 알지만 SSL과 현재의 시스템을 맞바꾸는 것이 그렇게 쉬운 일이 아니고 그렇다고 SSL이 현재 시스템이 제공하는 모든 기능을 완벽히 지원하지도 않지 않습니까? 그리고 SSL MITM/strip은 오래 연구된 분야이고 이미 해킹툴이 나온 것이나 다름이 없기 때문에 더더욱 문제가 되고 있는 것이지요. 물론 경고창이 뜬다고는 하지만 대부분이 무시한다는 사실은 이미 여러 차례의 사례로 확인이 된 바이고요.
그리고 교수님이 제시하신 ActiveX MITM이라는 방법 또한 클라이언트 보안의 중요성만을 더 실감하게 해주는 예에 불과하구요. 이미 많은 PC들이 감염된 상태에서 현 시스템이 최고는 아니지만 그럭 저럭 운영 되고 있고 현 시스템을 최대한 유지하면서 수정해 나가고 추가하는 방식이 당연히 맞다고 봅니다. 다른 웹브라우저나 운영체제 지원을 위해서 해당 플러그인만 추가하면 되는 일로 알고 있고 이미 보안 업체들이 많은 제품을 개발해 놓은 것은 오픈웹측도 이미 알고 있지 않습니까? 다만 해당 제품들이 시장에서 안 먹혀 들고 있는 것을 억지로 강제할 수는 없지 않을까요? 그 부분을 소송을 통해서 시장에서 FF를 지원해라라고 요청한다면 그 부분도 사실은 별로 설득력이 없는 부분입니다. 자본 주의 사회에서 자본주의 원리로 돌아 가는 시스템에 법적인 잣대를 들이 대어서 해결하려 하는 모양새로 보이는 것이죠.
결국 이 큰 시스템을 변화 시키려면 그 시스템을 설계하고 정책을 결정하시는 분들을 설득하셔야지 자꾸 내말이 맞아 이렇게만 하면 돼라고 주장만 하시면 안됩니다. 누구나가 납득하고 그럴만한 가치가 있다고 판단하게 할 수 있으셔야죠. 그런면에서 지난번의 보안 업계와 전문가들에 대한 인신 공격성 포스트들도 조금 서투른 행보였다라고 보여집니다.
물론 오픈웹 내부에도 내부의 방침이 있겠지만, 오픈웹이 한국의 인터넷과 웹을 재편하는 독재 권력을 가진 것도 아니고, 현실에 이미 구축 되어서 그나마 사고 안 일으키고(물론 사용자들의 불편을 야기하지만) 돌아 가는 시스템이 있는데 무조건 이건 아니다라고 단지 몇가지 fake 말웨어를 만들 수 있다라는 예를 들어서 공격하시면 도대체 누가 설득 당하겠습니까.
오픈웹의 목표를 이루시려면 그 분야를 담당하는 사람을 설득하셔야 합니다. 강요하고 이게 맞아 이렇게만 하면 돼라고 주장하신다고 해결되는 문제는 아니라는 것이지요. 누가 SSL의 기능을 모르고 장점을 모릅니까. 과연 SSL+OTP의 조합이 현재의 시스템과 동등하거나 우수한 보안성과 함께 납득할만한 구축 비용을 비루할 만한가가 모두 결정 되어서 은행 내부에서 결정되는 문제인데 문제를 너무 단순하게 생각하고 계시는 것 같습니다.
일단 오픈웹의 입장이 FF 플러그인 추가인지 아니면 모두 걷어 내고 SSL+OTP면 된다인지 부터 정하시는 것이 좋은 것 같습니다. Channy님은 다른 블로그에서 FF 플러그인도 대안으로 생각한다라는 발언을 하시는데 교수님은 또 아닌 것 같네요. 이런 형태의 논의는 정말 머리 아픕니다.
무엇인가 결론을 내려고 토론을 하는 것이지. 여기서 싸워서 이겨 봐야 무엇이 남습니까?
SSL MITM 은 SSL2 의 취약점을 공략하는 것이고, SSL3/TLS1 에서는 이런 공격이 현실적으로 불가능하지 않나
요? 그래서, ssl strip 이라는 공격방법이 거론되는데, ssl strip 은 SSL3/TLS1 을 직접 공격하는 것이
아니라, 이용자를 속이는 것입니다(주소창을 제대로 확인하지 않는 이용자 행태를 exploit 하는 것이지요). 제가 제시한 공격
방법 역시 이용자를 속이는 것이라는 점에서는 동일합니다.
그러나, ssl strip 은 EV SSL 인증서를 채택하고, 이용자에게 주소창에 나타나는 인증서 씰을 확인하도록 안내하면, 어
느 정도 "예방"이 가능합니다. 제가 제시하는 공격방법을 예방하려면, 이용자들에게, 보안경고창에 나타나는 게시자 명칭을 반드시
확인하라고 안내해야 겠지요. 그러나 이 안내가 실효성이 없어질 만큼 지난 10년간 "반드시 예"하라고 안내해 왔지요. 10년간
축적, 학습된 컴퓨터 이용행태를 고치지 않는 이상, 제가 제시한 공격방법을 예방하기는 쉽지 않을 것으로 생각합니다만...
SSL2 (지금은 deprecated 된 프로토콜)에 대한 MITM 공격은 프로토콜 취약점을 공격하는 요소와 이용자의 부주의
를 exploit 하는 요소를 모두 포함합니다(인증서 경고창이 뜰때 이용자가 그것을 무시해야 가능한 공격입니다). 최신 버전 웹
브라우저에서는 이 공격은 사실상 불가능하다고 봐야 합니다.(오페라, 파폭3 등에서는 SSL2가 아예 제거되었고, MS IE7 이
후 에서는 이용자가 굳이 SSL2를 일부러 활성화해야 하고, 종전 버전 웹브라우저에서는 인증서 경고창 하나 달랑 떴지만, 지금
은 아예 화면 전체가 warning 으로 바뀌고, 위험하다는 안내가 훨씬 크게 나타나도록 웹브라우저가 설계 되어 있지요)
On 4월11일, 오전10시10분, youknowit <keechang....@googlemail.com> wrote:
> ...
>
> 추가 정보 >>
--
-matt
youknowit
오픈웹이 한국의 인터넷을 재편하는 독점적 권력을 누리는 것이 아니라는 점은 당연하고, 저는 그저 제 수준에서 옳다고 생각하는 견
해를 웹블로그를 통해서 지속적으로 개진했을 뿐입니다. 은행이나, 금감원은 user 들을 강제하고 권력을 가지는 주체이지만, 오픈
웹이 그런 권한도 없지요. 그냥 아이디어를 개진할 뿐입니다.
최근 며칠 간의 격렬한 논의가 있기 전의 상황을 한번 생각해 보신다면, 그동안 국내 업계에서는 마치 SSL2 시절의 취약점이 아
직도 보완되지 않고 있는 듯한 전제에 서서, "https는 믿을 수 없다"는 식의 견해만이 난무했었지 않았나요? 해커 출신의 몇
몇 분들께서도, 그저 IE6/SSL2 에서의 MITM 공격 데모만을 계속 재방송 하면서, 담론을 이끌어 왔었지 않나요?
저는 이러한 부정확한 견해가 업계를 지배하는 상황이 오히려 사태 개선을 가로막고 있다는 생각이 들어서, 좀 격렬한 방법을 사용했
습니다. 다른 방법으로 아무리 이야기를 해도, 워낙 강고하게 형성된 그동안의 담론을 깨기가 어려웠습니다. 저야 욕을 먹어도 상관
은 없고, 이제야 비로소, SSL3/TLS1 에 대한 비교적 정확한 평가가 우리 업계에서도 "논의되기 시작한" 단계 까지는 만들
어 냈다고 자평하고 있습니다.
Matt님께서도 지적하셨듯이, 해법은 다양하게 존재할 수 있는데, 지금껏 한가지 방향에서만(plugin over HTTP를 당연
한 것으로 전제한 위에서 출발하여) 해법을 모색하려는 외통수 형국이 답답해서 그렇습니다.
해법 모색을 위해서는 지금의 방식에 대한 냉정한 평가가 선행되어야 하는데, 제가 느끼기에는 모두들 지금 방식의 "약점"에 대해서
는 외면하고, SSL2 의 약점만을 거론하는 것 같았고, 이런 스탠스가 결코 공평하지도, 유용하지도 않다는 것이 제 생각입니
다. Dispassionate 하게 여러 구현방법의 장단점을 평가해야, 개선책이 보일 것이라고 생각합니다.
제가 현재 방식의 약점을 지적하고, SSL3/TLS1의 안전성을 언급하는 것을 두고, "공격적"이라고 받아들이는 국내 업계관계
자 분들이 많습니다. 저는 그냥 있는 것을 있는 그대로 말했을 뿐이라고 여기고 있습니다.
플러그인에 대하여는 다음과 같은 입장입니다.
전자금융거래에는 "공인인증서를 반드시 사용하라"는 금감원 고시가 있습니다. 이 고시를 준수하려면 어쩔 수 없이 플러그인을 사용해
야 합니다. 그럴 경우, 파폭에서도 확장이 배포되어야 공평하다는 입장입니다. (form-signing에 한하여)
그러나, 그외의 경우에는 파폭이건, IE 건 플러그인은 사용을 최소화하거나(키보드 보안프로그램의 경우, 배포는 download
링크방식, 구동은 플러그인 방식), 제거하는 것(세션 암호화용 플러그인은 제거)이 옳다는 생각입니다.
궁극적으로는 "공인인증서를 반드시 사용하라"는 고시가 개정되어야 한다고 생각합니다. 거래 주체가 자율적으로 form-
signing 을 요구할지를 선택할 수 있도록 하는 것이 현명하다고 생각합니다.
웹브라우저의 다양성은 플러그인 사용을 최소화함으로써 구현되어야 하는 것이지, 더 많은 플러그인을 웹브라우저 별로 배포하려는 것
은 옳지 않습니다.
> 2009/4/10 youknowit <keechang....@googlemail.com>
> ...
>
> 추가 정보 >>
youknowit
공인인증기관을 독점적으로 지정해 두고 있는 상황 자체가 시장 논리와는 어긋나지요.
공인인증서 사용이 "강제"되지 않거나, "공인"이 아니라, 사설인증기관도 자유롭게 국내의 인증서비스 시장에 진입하여 영업할 수
있는 상황이었다면, 오픈웹 소송이 아예 제기되지도 않았겠지요.
> ...
>
> 추가 정보 >>
Matt Oh
그것도 격한 언어를 사용한 전술인지요. 제가 말하는 것은 오픈웹의 기술적인 옳고 그름을 떠나서 항상 그러한 태도로 접근하는 방식을 문제 삼고 있는 것입니다.
항상 어떤 단체나 기관을 비난해서 일을 해결해 보려는 방식이요. 그 분들과 협력을 해도 이룩할 수 있을지 없을지 모르는 사안에 대해서 항상 누가 잘했고 누가 못했고, 누가 영혼을 팔아 먹었다라는 식으로 접근해 놓으면 그 기억들은 이미 보안 업체나 기관 관계자들 머리 속에 박혀 있는데 과연 협력과 논의가 이루어질까요?
주장하시는 바를 이루시려는 것인지 주장하는 바에 대한 반론을 듣고 싶은 신 것인지 알수가 없습니다.
그리고 SSL의 취약점이나 약점에 대한 내용은 당연히 현존하는 브라우저를 대상으로 하고 있는 사항입니다. v2니 v3니 구별할 필요가 애초에 없는 사안이구요. 그리고 EV Cert에 대해서도 과연 액티브 엑스 컨트롤의 사이너도 확인 못하는 사용자가 그 부분을 제대로 확인하겠습니까. 결국 돌고 도는 논의입니다. 결국 적절한 보안성에 대한 선택과 비용의 문제인데 자꾸 적을 만드시면 원래 주장하시는 바를 점점 더 이루기 어렵게 만드신다라는 것입니다. SSL MITM이 무척이나 비현실적으로 들리겠지만 실제로 보안 컨퍼런스에서도 실질적으로 가짜 AP를 통해서 해당 공격을 실시간으로 수행해서 보안 전문가들 조차도 대량으로 속인 케이스도 있었습니다.
그리고 어디에도 완벽한 보안 체제는 없습니다. 다만 얼마나 시간을 지연 시키느냐 얼마나 공격자를 힘들게 만드느냐의 문제이죠. SSL이든 한국의 현존하는 인터넷 뱅킹이든 우리가 알지 못하는 잠재적인 위험이 분명히 있습니다. 다만 SSL쪽은 이미 세계적으로 많은 공격법이 연구되어 있고 툴들이 제공 되고 있으므로 그 만큼 공격자의 범위가 엄청나게 넓어진다는 것이구요. 한국의 현존하는 인터넷 뱅킹을 분석해서 공격할 수 있는 사람은 그에 비해서는 100분의 1이나 만분의 일도 안된다고 보아야겠지요. 위험 관리의 측면에서 이렇게 차이가 나는 것이구요. 오픈소스니 클로스드 소스이니 하는 논쟁도 이와 연관이 있는 사항이구요. 보안쪽에서도 분석을 힘들게 만드는 방식으로 공격자의 공격의도를 꺾거나 분석 시간을 엄청나게 소요하게 하는식의 방어 방법은 실제로도 많이 사용되고 있습니다. 소스코드를 보는 것과 바이너리를 분석하는 것은 공격자의 입장에서는 천지 차이의 문제입니다.
그리고 자꾸 제시하시는 외국 사례도 실제로 얼마나 분석을 하신 것인지부터 의문이 가구요. 외국에서 https방식을 많이 쓴다고 해도 그네들은 실시간 이체의 필요성이 없는 경우가 많고 이체시에 별도의 오프라인에서의 서류를 요구한다든지 이체가 적어도 3-4일 이상이 걸린다든지 하는 방식의 장치가 되어 있습니다. 하지만 한국에서는 그런 방식을 강요할 수 있습니까? 어느 나라이든지 그 나라의 금융과 관련된 문화와 사람들의 요구사항이 다른 법인데 그냥 외국은 이렇다니까 우리도 똑같이 하자라는 주장은 수긍이 힘듭니다.
그리고 플러그인 방식이라면 일단 플러그인 방식을 줄기차게 밀고 나가도 이룩 될까 말까인데 여기서는 플러그인 방식을 주장하시다가 또 저 포스트에서는 플러그인 다 들어 내라 라는 식으로 발언 하시고 그러면 정말 논의 자체가 힘든 것이죠. 일단 실현 가능한 부분으로 생각되는 FF의 플러그인 방식을 전략적으로 미는 쪽으로 힘을 쏟으시든지 아니면 플러그인은 아예 부정하고 오로지 SSL+OTP이다 라는 식으로 접근하시는 것이 나을 것 같습니다. 액티브 엑스만 아니면 된다라는 식의 접근 방법은 좀 아니라고 봅니다.
제가 금방 언급한 내용들은 사실 이미 다른 사람들이 줄기차게 건의하고 얘기했던 부분인데 기존의 입장에서 한치도 물러서지 않으시니 어쩔 수 없는 것 같습니다.
--
-matt
Matt Oh
물론 사설 인증 기관들이 늘어 나면 좋겠지만 인증 기관은 극도의 보안과 안정성을 요구로 하는 기관입니다.
만약 관리 잘못으로 룻트 인증서가 도난 당하든지 유출 된다든지 할 경우의 피해를 생각해 보셨나요?
그 부분에 있어서는 안정적으로 서비스할 수 있는 곳은 한국 사정에는 그렇게 많아 보이지 않습니다.
그 부분이 일반 국민들의 편의성 부분과 연결 되는 부분도 아니구요.
지금은 일단 오픈웹이 자유로운 웹환경을 만든다는 취지에서 갑자기 공인 인증의 분야까지 간섭하려고 하는 이상한 형국이라는 생각밖에 들지 않습니다.
--
-matt
Mountie Lee
OpenWeb에 대한 DDoS 공격으로 인해서
불가피하게 홈페이지를 GoogleGroups로 대체하고 난 이후
유저들의 접근성이 좋아지면서
토론이 엄청나게 활성화된듯한 느낌입니다.
DDoS공격을 고맙다고 해야할 상황이군요.
저는 우리가 더 낳은 환경에 대하여 활발한 논의를 하면서 정리해가는 경우
언젠가는 달성될 수 있다는 믿음이 있습니다.
--
Mountie Lee
Tel : +82 2 2140 2700
E-Mail : mou...@paygate.net
======================================= PayGate Inc. * WEB STANDARD PAYMENT * PCI DSS 100% COMPLIANT * www.paygate.net * pay...@paygate.net
dasony
아직 특정 안을 하나로 정해서 밀고나가야할 필요는 없다고 생각합니다. 지금은 기술적으로 최대 보안으로 최대한 많은 플랫폼을 최소
한의 비용으로 지원하는 방안을 찾는 과정이라고 생각합니다. 최적안을 한 두개로 압축한 후에야, 이를 은행 또는 정부 등에 설득하
는 작업으로 넘어가야 겠지요. 플러그인이야 안쓰면 좋지만 정 안되면 써야하지 않겠습니까. 이로 인해 생기는 소외되는 플랫폼 문제
는 또 해결방안이 있으리라고 생각합니다.
이와 별개로 기술적인 질문입니다.
>그리고 EV Cert에 대해서도 과연 액티브 엑스 컨트롤의 사이너도 확인 못하는 사용자가 그 부분을 제대로 확인하겠습니까. 결국 돌고 도는 논의입니다
순수하게 궁금해서 여쭤보는건데, 이렇게 말씀하시면서 왜 "예"이론은 설득력이 없다고 하시는지 궁금합니다.
그리고 김교수님/
>저야 욕을 먹어도 상관 은 없고, 이제야 비로소, SSL3/TLS1 에 대한 비교적 정확한 평가가 우리 업계에서도 "논의되기 시작한" 단계 까지는 만들어 냈다고 자평하고 있습니다.
저도 이번 사태가 몇몇 보안 전문가 분들을 논의의 장으로 끌어들이는 긍정적인 효과도 가져왔다고 생각합니다. 하지만 훨씬 더 많
은 수의 보안 전문가 분들이 김교수님 개인뿐만 아니라 오픈웹 전체에 대해 감정적 이성적으로 나쁘게 생각하게 한 역효과가 더 컸
던 것 같습니다. 특정 개인이나 특정 기업을 비판/비난하고, 보안 전문가 분들이 실력이 없다거나 밥그릇 챙기려고 현 상황을 유지
한다는 식의 인상을 줄 수 있었던 글들에 대한 문제는, 괜찮으시다면 한번 털고 지나가야 할 것 같습니다. 어찌됐든 오픈웹의 목표
를 위해 꼭 동의를 이끌어야할 분들 아니겠습니까.
youknowit
월 초에 이미 게시한 내용입니다만... 구글 cache 에 있는 페이지를 보시기 바랍니다.
소스나 설계 구조를 숨기는 방법이 안전한지, 공개하는 것이 안전한지에 대하여는 저와는 생각 차가 있네요.
http://groups.google.com/group/open-web/browse_thread/thread/f970859859d23e78?hl=ko
에 게시된 글...
"외국"을 거론할 때 미국만을 염두에 두는 것은 적절하지 않습니다. 유럽의 뱅킹은 우리와 비슷하게 실시간 계좌이체, 공과금 납부
가 이루어집니다. 플러그인 없고, https (+ OTP) 사용합니다.
EV SSL certificate 가 주소창에 띄워주는 Seal 은 액티브X 보안경고창에서 게시자 명칭을 확인하는 작업보다는 다
수의 이용자에게 더 분명한 방법이라고 저는 생각합니다. 그리고, 브라우저 다양성 면에서나, 서비스 프로바이더의 고객지원 비용면
에서 훨씬 유리한 점이 있다는 사정도 무시할 수는 없지 않을까요.
> 2009/4/10 youknowit <keechang....@googlemail.com>
> ...
>
> 추가 정보 >>
Matt Oh
수많은 일반 사용자들의 행동 패턴을 연구하는 보안 전문가는 이렇게 생각하는데 난 아니라고 생각한다면 어쩔 수 없구요.
액티브엑스를 안쓴다는 미국에서도 사인안된 액티브 엑스를 보내어서 모의 해킹을 하는 식의 시나리오는 성공률이 꽤 높습니다.
이는 일반적인 인간의 행동 양식에 관한 것이지 한국인들이 액티브 엑스에 단련 되어서 그런 것은 아닙니다.
여기에서도 사인안된 액티브 엑스 던져 줘도 자세히 읽어보지도 않고 다 예를 누릅니다.
미국인들이라고 다르지 않다는 말씀입니다.
그리고 이미 바로 앞 부분에도 말씀드렸지만 보안 전문가들 조차도 그냥 아무 생각 없이 잘못된 보안 인증서에 대해서 "예"를 누르고 넘어 가 버리는 경우가 많다라고 이미 보안 컨퍼런스의 예를 들어서 설명 드렸습니다.
이렇게까지 설명했는데 그래도 "예"이론이 맞아라고 하신다면 제가 설명이 부족한 것이구요.
--
-matt
Matt Oh
사람은 특히 인터넷 상에서는 그 글로 보여 집니다. 그 글이 곧 그 사람의 마음을 표현하고 있는 것이죠.
그런데 표현은 비방의 표현을 해 놓고 난 비방한 것이 아니다라고 하신다면 어떻게 해석해야 하는지 정말 어렵습니다.
EV Cert가 무용지물이라는 소리가 아닙니다 결코. 인간들의 행동 패턴이 그러한 안전 장치를 만들어 놓아도 그냥 넘어가 버린다는 것입니다. 그건 뭐 보안쪽에서는 기초적인 내용이니 넘어 가구요. 그래서 SSL이 나쁘다가 아닙니다. 인간이 그렇다는 것이죠.
단 자꾸 반복되는 내용이지만 이미 시스템이 구축되어 있고 은행들이 비용과 시간에도 불구하고 SSL로 가고 기존 시스템을 폐기해야 하겠다라는 큰 결정을 내릴만큼 그렇게 막강한 차이가 있느냐가 문제이겠죠. 제가 보기에는 전문가들이 팀을 짜서 해당 문제를 분석한다고 해도 뭐 이렇게 몇일만에 답이 나올 것이라고 생각하지는 않습니다. 그냥 단순히 이것이나 저것이나 똑같으니까 이걸로 가면 되지 않느냐라는 식으로 쉽게 결정되는 문제는 아니겠죠.
--
-matt
Channy Yun
6년간의 역사 전체를 트래킹 하시기 힘드시겠지만 기본적으로 제 생각은 보안을 위해서는 단순히 한 가지 방법으로만 해결 할 수 있
는 것이 아니라 복합적 노력을 통해 보안에 드는 비용을 줄여야 한다는 것입니다. 제가 2년전 (2007년)에 쓴 글입니다.
http://channy.tistory.com/136
제 정확한 입장은 우선 ActiveX 혹은 플러그인 방식은 국내에서 오용이 심각하고 금융서비스에 대한 보안은 어느 정도 가능할
지 몰라도 국민 전체 사용자 관점에서 실제로 보안 비용을 높히는 결과를 초래했다고 생각합니다. 실제 키로거방지, AV 소프트웨어
가 ActiveX 방식으로 배포할 수 밖에 없을 지경에 이른 게 그 결과입니다. 게다가 보안에 신경을 쓰는 운영체제나 웹 브라우
저가 나와도 사람들이 업그레이드를 안합니다. (국내에서 많은 사람들이 정품 비스타나 IE8에서 XP/IE6으로 다운그레이드하는
것도 다 같은 이유입니다.)
어쨌든 플러그인 방식으로 SW를 배포하는 것은 점점 줄여야 할 필요는 있구요. 그만큼 사람들의 PC보안 의식도 높아져야겠지요.
지금은 웹 보안 환경이 변했는데 xp/ie6으로 고착화 되는 악순환이 거듭되고 있어요. 특히 activex에서 공인 인증이 가
장 큰 범위를 차지하고 있어서 장기적 대안으로 ssl+otp+(더 높은 수준의 보안 제안)을 이야기합니다. 실제로 올해 부터 정
부 사이트에서 공인 인증을 제외하고 쓸데없이 만든 activex들은 모두 걷어 낸다는 실행안을 만들고 있다고 합니다.
하지만, 제가 앞글에도 썼지만 단기적으로 많은 사람들이 어려움을 겪고 있기 때문에 주요 브라우저에 대한 XP환경 플러그인도 고려
해야 한다고 생각합니다. 같은 플러그인 방식이지만 java는 vm이 있어야 하고 npplugin은 브라우저가 sandbox
역할을 해주고 있어 악용의 소지가 약간 준다고 볼 수 있죠.
실제로 금결원 소송이 시작되기 전에 합의를 할 수 있는 때가 있었고 Firefox용 플러그인만이라도 만들어 배포해 달라고 조정안
을 내기도 했습니다. (금결원은 합의해 주면 사파리, 오페라 사용자도 소송걸거라고 거부했었습니다.)
오픈웹이 activex 다 걷어내고 ssl+otp만 쓰자고 단순하게 주장하는 게 아닙니다. 세부 토론이 특정 분들께서
activex 방식이 ssl+otp 보다 더 안전하다 이런식으로 흘렀기 때문에 와전된것 같습니다.
저는 회사일을 하면서 시간을 쪼개서 틈틈히 모질라쪽 서포트도 하고 파이어폭스 확산을 위해 웹 환경 개선하는 일에 관심을 가지
고 이쪽을 계속 트래킹 해 온 사람으로서 오픈웹에 가끔 조언만 드리고 블로그에 글 몇 개 쓰는 정도입니다. 교수님 조차도 영국에
서 귀국하시면서 느낀 문제점을 해결하시느라 틈틈히 시간을 쪼개서 하는 일입니다.
당연히 중간 중간 빈틈도 보이고 팔로우업도 잘 못하고 공백 기간도 있고 그렇습니다. 제가 알기로 뭐 특별히 입장이 있거나 그렇지
도 않습니다. 어떤 방식이든 보안 비용을 높히지 않으면서도 비 윈도 비 IE 사용자에게 지금 안되는 서비스를 지원 해준다면 그걸
로 바랄게 없지요.
제가 아무리 노력해도 유럽에서 40%가 넘는 파이어폭스 점유율이 한국에서 고작 under 1% 입니다. 안타까워요.
Channy
youknowit
form-signing 은 현재 어쩔 수 없이 플러그인을 사용해야 합니다. 그러나 공인인증서를 발급받을 때 그 플러그인을 설치하
게 됩니다. 이 때에는 단순히 보안경고창만이 뜨는 것이 아니라, 최상위 인증기관 인증서를 신뢰할지 여부를 고객이 판단하도록 하
기 위하여 해쉬값을 육안으로 확인하도록 하는 과정도 있고(모두 법령에 규정된 과정입니다; 현재 은행들이 내려주는 인증용 플러그인
은 이런 과정을 모두 생략해 버리고 있지만), 통상의 플러그인 "OK" 과정에 비하면 대단히 "거창"합니다.
그러나 일단 이렇게 이렇게 공인인증기관이 주는 플러그인이 고객 컴퓨터에 설치되고 나면, 모든 서비스 프로바이더들이 이렇게 이미
설치된 플러그인을 호출, 구동하는 상황(즉, 인증 클라이언트와 인증 서버솔루션이 decoupling 되면)이 바람직합니다. 그러
면, 고객이 이 은행, 저 카드사에 최초 접속할 때 마다, 거듭해서 인증 클라이언트 플러그인을 중복 설치해야 하는 상황은 오지
않았겠지요. (스웨덴, 아이슬랜드, 덴마크, 말레이지아 등은 이렇게 하나의 인증 클라이언트 플러그인을 모든 서비스 제공자들이 공
통으로 사용합니다. 서버측 인증 솔루션은 물론 제각각 만들고요. 인증 클라이언트 플러그인 호출, 구동 방법이 투명하게 공개되
어 있으므로, 서버측 솔루션 구축 사업자들이 아무 문제 없이 작업할 수 있습니다)
제 주장은 form-signing 외에는 플러그인을 사용할 이유가 없다는 것이므로, 이렇게 되면 안전한 이용환경(고객이 더 이상
의 플러그인을 설치하지 않아도 되므로, 악성/진성 플러그인을 아예 구분할 필요 없이 NO 를 선택해도 되지 않겠습니까)이 구축
될 것이라는 것이지요.
Matt Oh
youknowit
게 되면, 전반적으로 보안에 도움이 된다는 것이 제 주장입니다.
영국에서는 적어도 그렇습니다. 미국은 제가 1985-1986 에만 있어봐서 잘 모르겠고요(그때 학교에 있던 Unix 사용하던 경
험이 어렴풋히 나기는 합니다만...ㅎㅎ 그 사이 많이 바뀌었지요?).
On 4월11일, 오후1시12분, Matt Oh <oh.jeongw...@gmail.com> wrote:
> 하지만 교수님이 지금 제시하는 부분이 "예"이론이 맞다는 증거는 아니지 않습니까.
>
> 2009/4/10 youknowit <keechang....@googlemail.com>
Matt Oh
저를 비롯해서 많은 보안쪽 엔지니어분들은 오픈웹의 사소한 기술적인 잘잘못이 아니라 그 사소한 잘못된 주장을 너무나도 자신있게 제시하고, 강경하고도 모욕적인 어조를 유지하던 것에 대해서 말한 것입니다. 일단 그 부분은 이제 해결 된 것 같으니 넘어 가는 것이 좋기는 한 것 같습니다만 앞으로 비슷한 형태로 운동을 전개하는 것이 오픈웹에 그렇게 실익은 없을 것 같다라는 생각은 듭니다.
사람은 감정의 동물이라서 아무 이유 없이 그렇게 비난 당한 사람들의 마음속은 아직도 수습하기 힘들 정도인 사람들도 꽤 될 것으로 보입니다. 그 부분은 전에도 얘기했지만 시간이 필요한 부분이고요. 오픈웹에서도 좀더 부드럽게 다가갈 필요는 있는 것 같습니다.
일단 제가 그냥 생각하는 내용은 순차적인 해결법인데, 일단 제 블로그에도 게시를 하였지만, 현존하는 액티브 엑스로 인해서 시스템에 문제가 발생하고 있는 부분에 대해서 일단 해결을 보자라는 것입니다. 사실 여러분들께서 생각하듯이 시스템을 불안하게 만드는 것은 액티브엑스 자체는 아닌 것으로 판단됩니다. 시스템이 불안정해지거나 느려지거나 하는 부분은 보안 프로그램이 가져다 주는 특유의 불안정성 때문입니다. 물론 QA 가 제대로 안된 탓도 있고, 일정에 쫓겨서 배포된 문제도 있을 것입니다. 이 부분은 보안 업체나 은행의 노력으로 당장에라도 개선을 촉구 할 수 있는 부분으로 보입니다. 그 부분에 대해서 은행이나 보안 업체에 피드백을 계속 주는 방식으로 개선을 요구하는 것은 어떻게 생각하십니까? 비슷한 내용은 이미 김휘강님의 블로그에도 게시가 된었구요.
일단 현실적으로 정말 실현이 가능한 부분부터 밟아 나가는 것이 낫지 않을까 개인적으로 생각합니다.
--
-matt
Matt Oh
그거은 이미 예이론이 맞다라고 가정을 해버리는 것으로 보입니다.
이 부분도 의견이 다르니 넘어 갈 수밖에 없을 것 같네요. 그러나 저에게는 크게 중요한 부분은 아닌 것으로 보입니다.
일단 저는 조언자의 역할을 해 주려는 의도가 있을 뿐이지 논쟁하고 싶지는 않습니다.
--
-matt
skon
기서 어느정도 통일된 의견으로 응집된 힘으로 밀고 나가야 그제서야 사람들이 관심도 가져주고 할 거 같습니다. 지금의 상황을 보
면 그냥 후~ 불면 다 날아갈 것 같은.. 사상누각위에 있는 것처럼 위태위태해 보입니다.
지금의 오픈웹은 문제의식과 해결책의 스펙트럼이 너무나 넓어서, 전문가라고 할지라도 그 모든 이슈에 대응할 수 없으며, 무시되고
있다고 생각됩니다. 이런 경우는 동의를 얻어내기가 너무 어렵습니다. 교수님의 의견을 중심으로 해서 검증을 받을 필요가 있다고 생
각합니다.
물론 이 페이지를 고정된 페이지나 결론으로 내세우기 보다는 그 안에서 일정한 조건하에서 자유롭게 수정될 수 있고 어떤 논의의 결
과물인지가 제시되면 훨씬 좋겠습니다. 작금에 상황에 문제가 있다는 것은 누구나 알고 있지만, 그 해결의 방향이 꼭 한 방향일 수
는 없기 때문입니다.
> ...
>
> 추가 정보 >>
youknowit
서버계정만 제공해 주시면, 씨디네트웍스에서 전방위 서버로 DDoS 공격에 대한 방어를 제공하고, 제게 계정을 열어 주시는 분의
실제 서버는 그 후방에 있으므로, 그리 위험하지는 않은 상황입니다만...
Matt Oh
그동안 알게 모르게 오픈웹으로 인해서 시간을 쓰면서 감사했습니다. 나름대로 이러한 고민을 할 수 있게 되어서 말이죠.
뭐 어느 분이 비난하셨듯이 보안쪽은 자기네들끼리 뭉치는 경향이 있기는 합니다. 굉장히 전문적이고 남들이 관심을
갖지 않는 분야라서 사실 누구와 기술적으로 대화가 힘든 분야이기도 합니다.
제 전문 분야는 클라이언트(특히 윈도우즈) 보안 분야입니다. 미국 캘리포니아 위치한 eeye라는 보안 업체에 근무중이구요.
거기에서 클라이언트 보안 제품(AV와 HIPS,NIPS 등이 결합된)을 개발중이구요. 많은 고객들을 이제 확보해 가는 중입니다.
물론 저는 이제 국내 보안 업계를 떠난지 5년이 넘어 가는 입장이지만 오픈웹 활동에 기술적인 조언은 언제든지 해드릴 수
있습니다. 물론 제 의견을 받아 들여라 이것은 전문가 말이니까 믿어달라고는 하지 않겠습니다. 하지만 제가 이미 보안 업종에
몸담은지 12년이 넘고 있고 국내에서 보안 제품 개발과 컨설팅도 한 경험도 있으니 제 말이 정말 믿지 못할 헛소리는 아닐 것
이라고 생각합니다. 뭐 김휘강씨도 저와 거의 비슷한 시기부터 보안 업계에 투신하신 분이고 컨설팅쪽으로는 대가이시니
그 분 말씀에 엄청난 거짓말이라든지 헛소리는 없을 것으로 판단됩니다. 그리고, 그 분도 보안 업체 소속이 아닌 일반 기업체
소속이시니 보안 업체에 종속된 의견이라고 몰아 부칠 필요도 없구요.
그리고 여기 들르시는 보안 커뮤니티 분들은 저희 메일링에서도 오픈웹을 옹호하시던 분들도 많습니다. 그러니까 조금만
마음을 여시면 그러한 분들이 많이 조언을 드릴 수 있을 것입니다.
일단 주말 동안 저는 좀 쉬겠습니다. 그러면 나중에 다시 뵙겠습니다.
--
-matt
dasony
다.
김휘강님과 Matt님께서 "예" 이론이 근거가 없다고 말씀하시는건, 사용자가 "예"라고 누르는 것이 국내 ActiveX 환경으
로 인한 것이 아니다라는 말씀이신 것 같습니다. 해외 역시 예를 누르는 비율이 크게 다르지 않다니까요. 사실 그래서 제가 다른
쓰레드에서 실제 실험을 제안해봤는데 정말 진행이 될 것 같지는 않군요. 저도 그렇고 다들 생업이 있으시니까 ^^;
저도 동의합니다. 한국 인터넷 환경이 원인이라는 "예" 이론에는 분명히 아직 조사된 근거가 없습니다. 하지만 "예" 현상만은 분
명한 사실입니다. "예" 현상이 누구의 잘못인지를 떠나서, 중요한 것은 사용자들이 예를 누르는 것에 익숙해져 것입니다. 이를 이
용하면 보안전문가들조차도 ActiveX를 통해 악성코드를 설치하기 쉽다는 것은 Matt님께서도 쓰신 Fact입니다. 그러므로 사
용자들에게 ActiveX 설치에 주의하도록 하는 것이 중요한 과제입니다.
그래도 요즘 컴퓨터 조금 한다는 분들은 ActiveX 설치 나오면 최대한 거부하려고 합니다. 그런데 국내에서는 이런 분들마저도
은행 사이트나 결제 페이지에서는 큰 주의 없이 설치를 하기 마련이죠. 즉 네트워크를 장악하면, ActiveX의 위험성을 알고 있
는 분들까지도 악성코드를 설치할 확률이 높아집니다. 그러므로 ActiveX 설치는 최대한 지양해야 한다고 생각합니다. 반드시 사
용해야 한다면, 설치 이전에 안내 메시지를 통해서 '어떤' 프로그램을 설치하려고 하며, '왜' 이런 프로그램을 설치해야 하고,
'어떻게 삭제'하는지에 대한 설명이 필요합니다. 또한 반드시 서비스 사이트와 ActiveX의 서명자가 동일해야 합니다.
이것도 결국 오픈웹의 일부 글에서 "예" 현상의 원인을 보안업계에서 찾았다는 것때문에 일어나는 논쟁 같군요. 오버헤드가 참 큽니
다. ^^; 이제는 그런 분이 거의 없어 보이지만, 오픈웹에서도 책임 소재를 찾기보다는 앞으로의 계획에 더 집중했으면 하는 바람
입니다.
덧. Matt님께서 eEye에 다니신다니 반갑습니다. 제가 처음 사용해본 패킷 스니퍼가 eEye의 제품이었거든요. 지금은 제품
이 많이 변해서, 다른 무료 스니퍼를 사용하지만요.
Won-Kyu Park
> 가족들과 시간을 보내고 왔더니 Matt님은 가족과 시간을 보내러 가셨군요. ^^ 예 이론에 대해서 제가 몇마디 덧붙일까 합니
> 다.
>
> 김휘강님과 Matt님께서 "예" 이론이 근거가 없다고 말씀하시는건, 사용자가 "예"라고 누르는 것이 국내 ActiveX 환경으
> 로 인한 것이 아니다라는 말씀이신 것 같습니다. 해외 역시 예를 누르는 비율이 크게 다르지 않다니까요. 사실 그래서 제가 다른
> 쓰레드에서 실제 실험을 제안해봤는데 정말 진행이 될 것 같지는 않군요. 저도 그렇고 다들 생업이 있으시니까 ^^;
>
> 저도 동의합니다. 한국 인터넷 환경이 원인이라는 "예" 이론에는 분명히 아직 조사된 근거가 없습니다. 하지만 "예" 현상만은 분
> 명한 사실입니다. "예" 현상이 누구의 잘못인지를 떠나서, 중요한 것은 사용자들이 예를 누르는 것에 익숙해져 것입니다. 이를 이
> 용하면 보안전문가들조차도 ActiveX를 통해 악성코드를 설치하기 쉽다는 것은 Matt님께서도 쓰신 Fact입니다. 그러므로 사
> 용자들에게 ActiveX 설치에 주의하도록 하는 것이 중요한 과제입니다.
>
저같은 경우는 윈도우즈 설치한 이후로 바이러스나 다른 이유로 시스템을 재설치 하는 일이 거의 없습니다.
바이러스 체크해도 거의 깨끗하고, 가끔 USB가 바이러스를 옮겨오는 수준입니다.
엑티브엑스도 필요한 것만 설치하고 나머지는 제거합니다. 혹시 익스플로 브라우져가 느려졌다 싶으면 엑티브엑스를
점검해서 의심되는 것은 비활성화 시킵니다. 브라우징은 인터넷익플로러는 인터넷뱅킹때나 쓰고,
나머지는 거의 크롬/파이어폭스를 씁니다.
그런데 매일 게임을 즐겨하는 제 조카의 컴은 엄청난 개수의 애드웨어가 깔려있었습니다. 지워놓아도 다시 설치되어있죠.
한번은 절대로 "예"라는 것을 누르지 말라고 했더니, 방화벽 설정 창이 뜰때도 아니요라고 눌러버려서
컴퓨터 안된다며 난리를 친 적이 있었지요. 아무튼 *예*를 누르지 말라고 했더니만 요새는 왠만해서 고쳐주러
갈 일이 없어졌네요. (조카는 그 무서운 초등학생 입니다 ㅋㅋ)
초등학생한테도 *예*를 누르지 말라고 했더니 컴환경이 훨씬 나아진 편인데 아예 근거가 없다고 말 할 수는 없겠지요.
예를 누르고 말고를 떠나서 *예*를 누르게 되면 어떠한 효과가 있는지, 설치전에 점검해야 할 사항은 무엇인지
그런 것들을 보안 관련 회사에서 보다 적극적으로 설명했어야 합니다. 그것의 위험성이라던지 대책을
논의해야 하는 곳에서 뒷짐지고 있는 형국이 되니, 비전문가 그룹에서 그렇게 지적해도 이상하지 않아보입니다.
오히려 이번 논의는 국내 보안관련 그룹에서 오히려 더 감사해야 하지 않을까요?ㅋ
오픈웹은 말 그대로 *오픈*웹을 지향합니다.
웹이 이렇게 대중적이 된 이유는 그 태생이 익명성과 접근성이 보장되었기 때문입니다.
그것을 가장 가로막는 것이 플랫폼 의존적인 ActiveX 기술이고 이것을 해체하려고 하는 것이 오픈웹의
한가지 목표가 될 수 밖에 없는 이유입니다. 이해 관계가 다를 수 있다는 것이지요.
아무튼 *예* 이론(?)이 아무 근거가 없는 것도 아니고, ActiveX 기술 자체에 대해서도 비판하는 것도 아니고,
거의 가망 없어 보였던 국내에서 웹 표준에 대한 의미가 요즘처럼 활발하게 논의되고 받아들여지고 있는것도,
이러한 하나하나의 비전문가 그룹의 물밑작업이 크게 기여했다는 것이 신기하게 보일 정도입니다.
노스모크에 *바보들의토론*이라는 페이지가 있지요. 아무리 바보들이라도 열린 마음으로 토론을 하면
올바른 결론을 내게 된다는 내용입니다. 똑똑한 사람들이 열린마음으로 참여하는 토론이라면 더욱 더 올바른
결론이 나오겠지요.
그런데 일부 블로거들은 이곳 구글그룹스를 링크까지 걸며 계속 트집잡고 있으니 이것 뭐 애들도 아니고 ㅋㄷ
*우리는 비전문가들이니 부디 몸소 와서 가르쳐주세요* 라고 오픈웹에 써붙여 놓아야 직성이 풀리실 듯ㅋ
제가 기술자적인 측면으로 봤을때는 몇몇 블로거들의 그런 행동은 그저 기술자의 고집과 자존심으로밖에 안보입니다.
그러나 이곳에 오셔서 이렇게 토론을 같이 하시는 보안전문가 여러분들께는 정말 심심한 감사의 말씀을 올립니다.
계속 좋은 토론으로 이어지기를 기대하고 기대합니다 :)
우리 비 보안 전문가들이 주장하는 바가 틀렸으면 가만히 와서 지적해주시고 토론에 참여해주시기를 바랍니다.
우리는 비전문가이기때문에 딱히 내세울 자존심이라는게 없습니다.
단지 오픈웹의 목표는 웹 개방성의 획득이라는 중요한 과제를 푸는 일이라 생각합니다.
> 그래도 요즘 컴퓨터 조금 한다는 분들은 ActiveX 설치 나오면 최대한 거부하려고 합니다. 그런데 국내에서는 이런 분들마저도
> 은행 사이트나 결제 페이지에서는 큰 주의 없이 설치를 하기 마련이죠. 즉 네트워크를 장악하면, ActiveX의 위험성을 알고 있
> 는 분들까지도 악성코드를 설치할 확률이 높아집니다. 그러므로 ActiveX 설치는 최대한 지양해야 한다고 생각합니다. 반드시 사
> 용해야 한다면, 설치 이전에 안내 메시지를 통해서 '어떤' 프로그램을 설치하려고 하며, '왜' 이런 프로그램을 설치해야 하고,
> '어떻게 삭제'하는지에 대한 설명이 필요합니다. 또한 반드시 서비스 사이트와 ActiveX의 서명자가 동일해야 합니다.
>
> 이것도 결국 오픈웹의 일부 글에서 "예" 현상의 원인을 보안업계에서 찾았다는 것때문에 일어나는 논쟁 같군요. 오버헤드가 참 큽니
> 다. ^^; 이제는 그런 분이 거의 없어 보이지만, 오픈웹에서도 책임 소재를 찾기보다는 앞으로의 계획에 더 집중했으면 하는 바람
> 입니다.
>
그렇게 오해할 소지는 충분히 있었겠지만, 그 논의를 책임추궁 수준으로만 받아들였다면 그것도 문제가 아닐까요?
아무튼 저도 그랬으면 좋겠습니다. 그런 일로 에너지 쏟지 말고,
더이상 작은것에 연연하지 말고 앞의 것을 생각하고 결론 도출하는데 힘을 쏟았으면 좋겠습니다~
>
> 덧. Matt님께서 eEye에 다니신다니 반갑습니다. 제가 처음 사용해본 패킷 스니퍼가 eEye의 제품이었거든요. 지금은 제품
> 이 많이 변해서, 다른 무료 스니퍼를 사용하지만요.
> >
>
--
온갖 참된 삶은 만남이다 -- 마르틴 부버
youknowit
http://groups.google.com/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
제가 제시한 국내 인터넷 뱅킹의 취약점은 그저 "고객의 입장"에서 가지게 되는 "걱정" 수준입니다만, 보안 전문가 분들께서 고객
의 이런 걱정에 대하여 좀 더 의미 있는 설명(결론은 어느쪽 이건 간에)을 해주시면 좋겠습니다.
dasony
현재 인터넷뱅킹에서 http 채널이라 문제가 되는 것은, 주의를 기울이는 고객도 현재 자신의 정보가 암호화되는지 명시적으로 알
방법이 없다는 것입니다. 그래서 사실 어차피 신경안쓰는 일반인에게는 그다지 큰 차이가 없을 수도 있습니다. https나 http
나 MITM에 노출되었을 때 할 수 있는 일은 똑같으니까요. 교수님이 말씀하신 공격의 기본은 ActiveX를 대체하여 사용자가
별 생각 없이 설치를 하게 만드는 것에 있습니다. 그런데 https를 사용했다고 하면, 따로 가짜 ActiveX를 만들 필요도
없이 모든 정보를 빼낼 수 있습니다.
결국 보안에 관한 의식이 제로인 사용자에게는 SSL이 플러그인 방식보다 조금 더 쉽게 데이터 스니핑이 가능하니까요. 하지만 보
안 의식이 조금이라도 있는 사용자에게는 브라우저 주소창을 이용하여 현재 사이트가 암호화 되고 있는지 확인할 수 있기에 ssl-
strip도 통하지 않습니다. (인증서 경고는 말할 것도 없겠지요. 대부분의 사용자가 인증서 경고를 무시한다지만, 뱅킹 사이트에
서도 무시할까요? 그건 잘 모르겠습니다.) 그런데 보안 의식이 어느 정도 있는 사용자라도 현재 다운받고 있는 ActiveX가 악
성코드인지 (백신 등에서 잡아주지 않는 한) 확인할 방법이 없다는 것이 문제겠네요.
Fake ActiveX를 통해서 사용자의 정보를 빼는 것이 과연 쉬울 것인가는 별개의 문제입니다. 가장 쉬운 방법은 키로거 및
백신을 대체한 후에 키로거를 돌리는 것이겠네요. 원래는 암호화 플러그인을 wrapping하여 가운데서 데이터를 빼는 것을 생각했
는데, 이경문님께서 해당 문제가 이미 몇년 전에 제기된 적이 있다고 하니 (어떠한 형태로든) 패치되었을 것으로 봅니다. 그러니
조금 더 어렵겠죠. 아니면 기존 보안 플러그인을 리버스 엔지니어링해서 암호화 구조를 모두 이해하여 재구현하는 방법도 있겠습니
다.
교수님의 제안에서는 아예 보안 플러그인을 Fake ActiveX로 대체한 후, 공격자 사이트로 들어오는 정보를 그대로 인터넷 뱅
킹 사이트에서 인터넷 뱅킹 사이트의 정상적인 보안 플러그인을 이용하여 포워딩하는 방법을 사용하는 것 같습니다. 하지만 이런 정
보 역시 다행인지 불행인지 한국 은행의 웹사이트가 매우 복잡하고 '일단은' 소스코드가 암호화가 되어있기 때문에, 보안 관련 스크
립트만 적절하게 제거/수정한 후에 사용자에게 뿌려준다는 것이 쉽지는 않을겁니다. 은행 사이트 전체를 완전히 이해해야하고, 은행
사이트가 조금이라도 변경되면 코드를 다시 작성해야하니까요. (아, 은행 웹사이트가 현재 정기점검중이라 조회 및 이체 메뉴만 활성
화되어있다는 식으로 아예 간단한 가짜 사이트를 보여주는 방법도 있습니다. 해외 씨티뱅크 OTP가 이러한 형태의 피싱 사이트에 당
했었죠.)
어쨌든 굉장히 복잡하고 비용이 드는 일입니다. 꽤 큰 돈을 벌 수 있어야 할만하겠죠. 즉 많은 네트워크를 미리 점거해놓고, 정해
진 한 시간 정도동안 모든 계좌 이체를 본인의 대포 통장으로 이체 시킨 후에, 돈을 인출한 후 도망가야겠습니다. 사실 이 방법으
로 얼마나 벌 수 있을지는 잘 모르겠습니다. 인터넷 계좌 이체가 잦으면서 점거 가능한 네트워크를 찾아야되니까요 ^^; 그러므로
저라면 그냥 키로거 등 모니터 프로그램이나 돌리면서 공인인증서와 보안카드 번호를 최대한 많이 모으는 방법을 택하겠네요.
가장 이상적인 것은 고객들의 보안 의식이겠네요. 사실 이체 전에 SSL 인증서 확인하는 것만 잊지 않는다면, 은행 또는 CA의
개인키가 유출되는 일만 없으면 MITM에 대해서는 안전하지 않나요? 현재 방식은 고객이 주의를 한다고 해도, 정밀한 MITM 공
격에는 속수무책이 아닌가 싶습니다.
youknowit
은행 페이지 소스가 아무리 암호화되어 있다 한들, 공격자는 은행이 내려준 "정품" 플러그인을 사용하여 접속하므로, 공격자 단에
서 모두 복호화 되지 않을까요?
공격자는 그렇게 복호화된 평문(plain text) 웹페이지 소스를 http 로 고객에게 뿌려주면 될 것으로 생각합니다. 보안
플러그인 호출 태그는 모두 제거(strip) 하고.
제가 제시한 방법은, 실은 ssl strip 과 원리는 동일합니다. 서버 - 공격자 간에 아무리 암호화 교신이 되더라도, 그 교
신은 "정상적" 교신이므로, 공격자 단에서 모두 "복호화"됩니다. 이렇게 복호화된 페이지 내용을 이번에는 공격자가 고객(피해자)
에게 http 로 뿌려주는 원리입니다.
e2e 키보드 보안, 웹페이지 소스 암호화, 세션 암호화 등 모든 방어 수단은 공격자가 "진짜 고객"으로서 은행에 접속하므로,
공격자에게는 모두 복호화 되어 전달된다고 저는 생각하고 있습니다.
공격자가 고객에게 내려주는 "fake" 액티브X는 정말로 별다른 내용이 없습니다.
i) 외관은 전자서명 플러그인과 완벽히 동일하게 하고,
ii) 기능은, 인증서 저장위치(C:\Program Files\NPKI\공인인증기관 식별자\ 또는 이동식 저장매체:\NPKI
\공인인증기관 식별자)에 있는 고객의 공인인증서+개인키 파일을 그냥(복호화 할 필요도 없이) 공격자에게 전달(공격자가 비밀번호
를 입력하고, 확인을 누르면, POST method 로 단순히 공격자에게 전달) 하는 기능만 있으면 됩니다. 물론 고객이 입력
한 암호도 공격자에게 전달되어야 하겠지요.
나머지 모든 보안플러그인(은행이 고객에게 설치해 둔)은 아예 구동조차되지 않으므로, 고객-공격자 간에는 완벽하게 clear
channel 로, 아무런 키보드 보안도 없이 그냥 정보가 전달되지 않을까요? 어차피 공격자가 고객의 개인정보 보호에 신경써
줄 필요가 없으니, 굳이 고객 컴퓨터에 있는 암호화/키보드 보안 플러그인을 activate 하는 오브젝트 태그를 포함시킨 페이
지 소스를 뿌려 줄 이유는 전혀 없을 것입니다.
이 방법은 일종의 "보안 플러그인 strip"인 셈입니다. "ssl strip" 과 비교했을 때, 가장 큰 차이점은
(dasony 님도 지적하셨듯이), 이 방법의 공격을 고객이 탐지해낼 수 있는 유일한 방법은 fake 플러그인이 제시될 때 나타
나는 보안경고창의 게시자 명칭이 평소 자기거래 은행이 내려주는 액티브액스 게시자들의 명칭들과는 다르다는 점을 고객이 기억해 내
고, 설치를 거절하는 길 밖에 없습니다. 이 단계에서 고객이 탐지해 내지 못하면, URL 주소까지 완벽하게 같으므로 감지는 불가
능할 것으로 생각합니다.
youknowit
> 공격자에게는 모두 복호화 되어 전달된다고 저는 생각하고 있습니다.
다음과 같이 수정해야 겠네요...
e2e 키보드 보안, 웹페이지 소스 암호화, 세션 암호화 등 모든 방어 수단은 공격자가 "진짜 고객"으로서 은행에 접속하므
로,
비록 네트웍를 이동하는 중에는 해당정보가 암호화 되어 전달되더라도, 공격자 컴퓨터에 와서는 모두 복호화된다고 저는 생각하고 있습
니다.