국내 인터넷 뱅킹 보안의 취약점
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 를 선택해도 되지 않겠습니까)이 구축
될 것이라는 것이지요.