국내 금융권이 그동안 사용해 온 보안의 기본 콘셉트는 "plugin over http"로 요약할 수 있습니다.

그리고 challenge factor 의 수를 증가시키면 더욱 안전하다는 전제에 입각해 있습니다. 따라서, 로그인 단계에서 인증서와 인증서(개인키) 암호를 요구하고, 계좌 이체 단계에서 i) 계좌비밀번호, ii) 보안카드 번호(일종의 OTP), iii) 인증서(개인키) 암호를 요구하는 것입니다.

그뿐 아니라, End2End 키보드 보안프로그램 플러그인도 사용하고, 안티바이러스 프로그램도 플러그인으로 구동합니다. 물론, 암호화 교신도 플러그인으로 구현합니다. 이 수준의 방비책이면 "고객<-->은행 간의 교신 구간"은 가히 철통수비라고 저는 생각합니다.

그러나, 문제는 이 모든 것이 http 채널에서 이루어진다는 점입니다. 따라서 공격은 의외로 "싱겁게" 이루어질 수 있습니다. 플러그인들이 작동하는 구간에 공격자가 끼어들기는 어렵고, 그럴 필요도 없습니다. 하지만, 모든 교신이 http 로 이루어지므로, 고객이 은행과 접속할 때, http MITM 공격을 가하는 것은 매우 쉽습니다(ssl strip 을 할 필요도 없습니다; 단순 프록시 공격이면 족합니다).

이것은 어렵습니다.

이것은 쉽습니다.

은행의 웹페이지 소스에는 각종 보안 플러그인을 호출, 구동하는 오브젝트 태그 들이 있고, 그 태그 안에는 해당 플러그인(ActiveX)을 고객이 내려받는 주소(codebase)가 기재되어 있습니다. 공격자는 은행으로부터 받은 페이지 소스에서 이것들을 모두 제거(strip)하고, 자신이 준비한 플러그인만을 호출, 구동하는 오브젝트 태그를 삽입하고, 그것을 내려받는 주소를 자신의 서버로 기재한 페이지 소스를 고객에게 전달합니다.

고객이 은행에 http 로 접속할 때 이런 공격자가 중간에 끼어들면, 고객의 화면에는 한국의 모든 뱅킹 고객에게 너무나도 익숙한 "보안경고창"이 뜹니다: "이 소프트웨어를 설치하시겠습니까?" 한국 뿐 아니라, 모든 나라의 이용자들은 액티브액스 보안경고창이 나타날때, 그 신뢰여부를 "게시자" 명칭을 보고 판단하기보다는(그렇게 해야 옳고, MS사도 이렇게 하라고 말하긴 하지만, 아무리 게시자 명칭을 봐도, 신뢰여부 판단에 유용한 정보는 현실적으로는 없습니다), 자신이 접속한 사이트가 믿을 만한지 여부에 기초해서 판단합니다.

여기 제시한 방법으로 공격이 이루어지면, 고객은 은행 웹페이지와 100% 동일한 외관, 그리고 url 주소까지도 은행과 100% 동일한 상황에 처합니다. 자신이 거래하는 은행이 내려주는 액티브액스를 거부할 고객은 없을 것입니다(만일 거부하면, "반드시 예"를 누르라는 안내 페이지로 연결되도록 할 수도 있겠지요).

고객이 이 보안경고창에서 "예"를 클릭하면, 고객의 PC에는 다음과 같은 외관과 기능을 가진 액티브X 콘트롤이 하나 설치 됩니다:

1. 외관은 전자서명 플러그인과 완전히 동일하고,
2. 인증서 저장위치(C:\Program Files\NPKI\공인인증기관 식별자\  또는 이동식 저장매체:\NPKI\공인인증기관 식별자)에 있는 고객의 공인인증서와 개인키 파일을 단순히(복호화 할 필요 없이) 공격자에게 전달하는 기능(공격자가 비밀번호를 입력하고, 확인을 누르면, POST method 로 단순히 공격자에게 전달)
   
3. 고객이 입력한 인증서 암호도 공격자에게 전달하는 기능(역시 POST method)
   

이렇게 되면, 고객은 무방비 상태에서 공격자가 필요로 하는 모든 파일과 정보를 공격자에게 제공하게 됩니다. 계좌비밀번호, 보안카드 비밀번호 역시, 고객이 입력하는 대로 고스란히 공격자에게 전달하게 됩니다.

물론, '가짜' 플러그인이 고객화면에 최초로 떴을 때, 고객이 비밀번호를 입력하고, OK를 누르면, 그때 비로소 고객의 인증서 파일과 비밀번호가 공격자에게 전달되므로, 은행서버는 "인증서를 선택하십시오"라는 메세지를 띄우게 됩니다. 공격자는 이것을 물론 무시하고, 고객에게는 "비밀번호가 잘못 입력되었습니다"라는 메세지와 함께 다시한번 입력하도록 유도합니다. 고객이 다시한번 입력하면, 이때에는 이미 공격자의 컴퓨터에는 고객의 인증서와 개인키가 제대로 된 위치에 저장되어 있고, 고객의 비밀번호도 공격자가 알고 있으므로, 그 후부터는 모든 거래가 정상적으로 이루어 집니다.

물론, 처음부터 실시간으로 고객의 인증서를 공격자의 컴퓨터에 저장하고, 고객이 입력하는 인증서 암호를 공격자가 은행과의 접속에서 정확히 제시하도록 프로그램을 짤 수도 있습니다. 고객은 단지 접속량이 많나보다 생각하고 2-3초 더 기다리게 될 뿐입니다.

이 방법은, 공격자가 은행과 거래하는 광경을 (그 사실을 전혀 모르는) 고객의 화면에 보여주면서, 비밀번호를 입력해야 할 때, 고객이 입력하도록 하는 셈입니다. 보안카드 번호의 조합을 여러차례에 걸쳐서 공격자가 힘들여 짐작할 필요도 없습니다. 은행이 요구하는 바로 그 번호가 고객의 화면에 뜨고, 고객이 자신의 보안카드를 열심히 보고, 해당번호를 입력하면 공격자는 그것을 받아서 은행에게 전달하면 됩니다.

E2E 키보드 보안도 아무 소용이 없습니다. 은행이 내려줘서 고객의 컴퓨터에 설치된 여러 액티브액스 콘트롤들이 있지만, 공격자가 고객에게 날려주는 웹페이지 소스에는 이들 플러그인을 호출하는 태그들이 모두 제거(strip)된 상태이므로, 고객 컴퓨터에 있는 액티브액스들은 아예 작동을 하지 않습니다.

고객은 무방비 상태에서 공격자에게 모든 정보를 일러주고, 그 정보를 받은 공격자는 은행이 내려준 여러 훌륭한 보안 플러그인들을 모두 그대로 사용하여 "안전하게" 은행과 거래하게 됩니다.

물론, 뛰는 놈 위에 나는 놈이 있으니, 공격자와 은행간의 거래에 끼어들어 가로채가는 제2의 공격자도 있겠지만, 우리 은행들이 주는 플러그인들이 워낙 철통수비를 해주기 때문에 공격자가 불의의 피해를 보는 일은 없을 것입니다. 하긴, 공격자가 당한다 하더라도, 손해는 고객이 보게 되겠지요.

이러한 공격은 "SSL strip" 과 그 원리는 같습니다. 공격자와 서버 간에는 secure connection 이 정상적으로 이루어지고, 고객과 공격자 간에는 insecure connection 이 형성되어, 공격자가 필요로 하는 정보를 고객이 충실히 전달하는 일종의 pipeline 역할을 하는 셈입니다. 국내 은행이 secure connection 을 구현하는 수단은 plugin 이므로, 제가 제시한 공격방법은 "plugin strip"으로 이해하시면 되겠습니다. 다만, SSL strip 과의 차이는, 고객의 웹페이지 주소창에 나타나는 주소는 서버 주소와 완벽하게 동일하다는 점입니다. (SSL strip 의 경우, 고객의 웹브라우저 주소창에는 http:// 로 시작하는 주소가 나타나므로, 적어도 이론적으로는, 주의깊은 고객이라면 의심해 볼 수는 있습니다.)