Man – in – the – Browser Attack 에 관하여

1. 2012.5.3 유창훈 Man – in – the – Browser Attack에 관하여 • 국내 인터넷 뱅킹 계좌이체에 대한 MITB 취약점 분석 • Defeating Man-in-the-Browser • :How to prevent the latest malware attacks against consumer and corporate banking

2. Table of Contents • 소 개 • 관련 연구 및 동향 • 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 • 대응방법 • 결 론

3. 소개 • 인터넷 뱅킹이 지속적인 성장세에 있음 • 비대면 거래의 특성상 인증프로토콜의 보안성이 중요 외우는 비밀 고정된 비밀 인증프로토콜 지니는 비밀 고정되지않은비밀 : OTP 비밀 가로채기 문서 전체에 대한 무결성 확인 문서의 자원에 대한 외부프로그램 차단 악의적인 키 데이터 입력 막기 고정되지 않은 비밀 악용 문서변조

4. 관련연구 • 2005, Augusto에 의해 Web Browser에 악성프로그램이 상주하여 공격하는 것이 발표됨. • 2007, Guhring에 의해 MITB라고 불리기 시작함. • 2008, Sharek et al. 사용자가 진짜와 가짜 팝업 에러창 구별 실험 • ( 사용자들의 73%가 가짜를 구별하지 못함) • 2010, Kim et al.은한국의 인터넷 뱅킹이 다양한 보안기술을 제공하고 있음에도 불구하고 더 나은 • 보안성을 기대하기 힘들다는 점을 지적 • 1) 피싱 공격에 무방비 • 2) 공인인증서의 문제점 • 3) 플러그인의 한계 • 4) 공개되지 않은 인증프로토콜의 보안성

5. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 1.공인인증서와 보안수단 • 공개키 기반의 인터넷 뱅킹 시스템 • 공인인증서 발급시Password를 입력은 공인인증서 개인키를 암호화 하기 위함. • Brute-force 공격에 노출될 가능성이 있음 공인인증서 암호를 알아도 계좌이체등의 거래는 안됨. •  보안카드, OTP와 같은 보안 수단이 필요(거래승인시요구) • ▶ But! 사용자를 안전하게 인증 하였다는 것과 서버가 사용자의 비밀을 안전하게 전달받았다는 것이사용자가 의도한 거래 내용이 변조되지 않았다는 것까지 보장하지는 않는다.

6. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 2. 부분적인 암호화와 무결성 및 문서의 변조 • 국내의 Internet Banking은 모든 패킷을 암호화 하지 않고 중요 데이터만 부분적으로 암호화 됨. • 동작 구조 • 1) 서버와 클라이언트에 설치되어 있는 플러그인이Session key를 공유 • 2) 서버가 중요한 데이터를 암호화하여 웹 브라우저에 전송하면, • 3) 자바스크립트가 암호화된 데이터를 플러그인을 이용하여 복호화 한 뒤, 출력 함 • 암호화된 부분은 Session Key가 없으면 공격자 의도대로 수정할 순 없지만, • 문서 전체에 대한 무결성 검증 절차가 없다면암호화되지 않은 부분의 문서가 변조될 수 있다.

7. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 공격자가 문서를 변조할 수 있는 방법 네트워크 수준에서 문서가 IEFrame에 로드되기 전까지 DOM개체 삽입 IEFrame에 로드 된 이후 BHO나 Toolbar를 통한 DOM개체 삽입 IEFrame에 로드 된 이후 또 다른 개체(IEFrame또는 이미지) 를 문서에 덮어씌우는 방식

8. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 1) DOM 개체삽입을 통한 문서의 직접적인 수정 • Internet Banking은 HTML과 스크립트 언어, Active X, BHO와 같은 추가적인 프로그램을 통해 서비스 • HTML문서가 클라이언트에 수신될 때까지는 변조되지 않았다 하여도, 수신이 완료된 이후에 악성코드에 의해서 변조될 수 있다. • 1) 악성 스크립트를 문서 상단에 위치시키고, HTML 문서 BODY의 onLoad이벤트를 이용하여 • 해당 스크립트를 호출할 수 있고 • 2) HTML문서가 부분적으로 암호화 되어 있어도 MSHTML.DLL에 의해 해석될 때는 복호화 된 후에 • IEFrame상에 표현되기 때문에, 해당 부분을 Javascript가 DOM구조로 접근하여 내용을 가져오거나 • 수정하는 것에는 아무런 지장이 없음. • 악성 스크립트는 • 1) 사용자의 비밀(계좌 비밀번호, 이체비밀번호, 보안카드, OTP, 공인인증서 패스워드등)이 입력되는 • form은 수정하지 않고, • 2) 수신자 정보(이체금액, 수신자 계좌번호, 수신자명)와 관련된 입력폼의 복사본을 생성한 이후에 • 이것이 화면에 원래의 이체정보 입력폼 대신 보이도록 상위 계층에 겹쳐놓음 • * CSS(Cascading Style Sheets)의 z-index속성을 이용

9. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 2) 문서위에개체를 덮어씌우는 간접적인 문서변조 • 문서위에 다른 개체를 올려놓는 방법을 고안 • 이미지, 동영상, IEFrame등이 될 수 있음 • 화면에 실제 출력되는 내용은 최상의 계층만 출력된다는 점을 악용하여 사용자가 바라보는 문서를 • 간접적으로 수정 • IHTMLDocument2를 이용한 Dialog 형태

10. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 3. 키보드 보안 프로그램 • 악성프로그램이 설치되어 있다는 가정 하에 사용자가 입력하는 비밀이 노출되는 것을 방지하기 위함. • 키 입력 정보를 가로채는 구간은 다양 • 1) 키보드 인터럽트 • 2) 키보드 드라이버 • 3) DLL Injection을 통한 메모리 영역 • 4) BHO등을 이용한 컴퓨터 메모리 영역 • 키보드 보안 프로그램은 각자 구현 방법에 따라 키 입력 값을 암호화 하거나 더미값을올려보내 노출이나 변조되는 것을 방지함.

11. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 3. 키보드 보안 프로그램 • nProteck Key Crypt • ‘기존 경로’ 의 키보드 드라이버로는 NULL 값을 전송하여 상위 계층에서 해킹도구가 동작하더라도 키보드 입력값을 얻지 못하도록함 • 보안 키보드 드라이버는 키 입력이 있을 때마다 ‘*’ 표시가 나타나도록 보안 입력창에 지시하고 , 확인 버튼이 눌러지면 버퍼에 저장된 입력값을 암호화 하여 보안 입력창제어부로 전송

12. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 • 보안기능이 최소화된 키보드 보안 프로그램 • 1) 사용자 동의 하에 보안 기능이 최소화된 키보드 보안 프로그램 제공(S사) • 2) 해당 프로그램은 보안기능을 제공하지 않기 때문에 문제가 됨. • 3) 공격자는 제공되는 보안프로그램의 Class ID 와 같은 프로그램을 사용자 모르게 설치. • 악의적인 키 데이터 삽입 • 1) 윈도우 API 수준의 Keybd_event로도 수신계좌번호를 입력하는 것이 가능 • 2) SendInput을 통한 수신계좌번호 입력 • 계좌번호목록을 이용한 수신계좌번호 변경 • 1) 스크립트 조작으로 사용자가 입력한 계좌번호를 취소하고 대신 계좌번호목록(자주쓰는 계좌, • 최근 입금 계좌등)에 존재하는 어떤 계좌로 수신계좌를 변경하는 것이 가능

13. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점 4. 문서변조 및 악성 키 데이터 입력 실험 결과

14. 문서 변조 공격 실제 사례 시나리오 • 사용자 컴퓨터에 설치되어 있는 악성프로그램이 계좌이체 페이지를 자동으로 변조하고, • 이 변조된 문서에서 사용자가 어떤 수신자에게 계좌이체를 시도하면, • 이체 가능금액 모두를 공격자의 계좌로 이체되도록 하는 공격 1. 이체정보 입력화면-가짜 이체화면 출력 • 1) 출금계좌정보(출금계좌번호, 계좌비밀번호) 가 입력되는 곳은 수정하지 않고 입금계좌정보와 • 이체금액은 공격자의 의도대로 조작 • 2) 입금계좌정보와 이체 금액의 입력폼을 복사하여 CSS의 Z-index 속성을 이용, 동일한 위치의 • 상위계층 설정 • 3) 가짜 입력폼을 작성한 후에는 이와 관련한 이벤트와 자바스크립트들을 오버라이딩을 통해 • 가짜 입력폼에서 동작하도록 수정함

15. 문서 변조 공격 실제 사례

16. 문서 변조 공격 실제 사례 1. 이체정보 입력화면 – 이체금액 조작 • 이체금액폼에 이체 가능 ‘전액’을 입력 • ‘전액’버튼은 팝업창을 통해 사용자에게 전액 이체 여부를 확인한 후 입력되도록 되어 있지만, • 스크립트수준에서 구현된 것이기 때문에 함수 오버라이딩을 통해 사용자 확인 없이 입력 가능

17. 문서 변조 공격 실제 사례 1. 이체정보 입력화면 – 입금계좌번호 조작 • 입금계좌정보는 입금은행과 입금계좌번호로 이루어짐. • DOM의 SELECT로 구성된 입금은행은 스크립트 수준에서 조작할 수 있음. • 키보드 보안 프로그램이 작동 중인 경우 계좌번호를 키보드 보안 프로그램이 보관하고 암호화 하여 보내기 때문에 입금계좌를 조작하는 것이 쉽지 않음 • 키보드 보안 프로그램이 적용된 경우 계좌정보목록에 있는 계좌 중에 선택하여 적용 • 입금계좌목록에만 조작이 가능할 시 공격 대상이 제한적일 수밖에 없음. • 키보드 보안이 적용된 경우에도 입금계좌번호를 조작할 수 있어야 함 • 1) Keybd_event와 같은 키 입력 함수 악용 • 2) 해당 함수를 사용 불가로 할 경우 보안성은 향상되나 유저 편의성 • 저하( 원격 데스크탑9/ 스마트폰/ 태블릿PC등에서 사용 불가) <자주쓰는입금계좌번호를 자동으로 입력하는 스크립트>

18. 문서 변조 공격 실제 사례 1. 이체정보 입력화면 – 사용자가 입력한 이체정보 유지 • 조작된 계좌이체가 공인증서를 통해 승인받기 전까지 의심받지 않으려면, 사용자가 입력한 계좌정보를 유지 해야 할 필요성이 있음.

19. 문서 변조 공격 실제 사례 2. 수신자명을 통한 입금계좌 확인 – 수신자명 조작 • 스크립트를 사용하여 사용자가 입력한 계좌에 대한 서버 질의를 하여 수신자명을 알아냄 • 상황1) • 1) 사용자가 입력한 계좌번호에 대한 서버 질의 • 2) 서버의 응답으로 부터 수신자명 확인. • 3) 서버에 사용자가 입력한 계좌번호에 대한 거래 취소 요청. • 4) 공격자가 입금계좌에 대한 서버 질의 • 5) 이체 계좌 확인 화면에 사용자가 입력한 입금계좌에 대한 정보만을 출력 • 6) 보안카드나 OTP 입력을 기다리는 화면이 보여짐. • 상황2) • 1) 계좌이체 추가를 통해 사용자가 입력한 계좌번호와 공격자가 입력한 계좌번호를 서버에 질의 • 2) 서버의 응답으로 부터 사용자가 입력한 계좌 번호에 대한 수신자명을 확인. • 3) 사용자가 입력한 계좌번호에 대해 그냥 그대로 이체하거나, 이체 금액을 줄여 이체하여 서버측의 • 이상탐지가 불가능하도록 함. • 4) 이체 계좌 확인 화면에는 사용자가 입력한 입금계좌에 대한 정보만 출력 • 5) 보안카드나 OTP입력을 기다리는 화면이 보여짐.

20. 문서 변조 공격 실제 사례 3. 공인인증서를 통한 이체 승인 – 이체내용 조작 • 이체 시 보안카드 or OTP를 입력한 이후에 공인인증서의 사용을 통해 최종적으로 계좌이체에 대한 사용자 승인이 필요 • 공인인증서를 사용하는 상단에는 계좌이체 정보가 표시되는데, 계좌이체가 두 건 이상인 경우에는 계좌이체 정보가 나타나지 않음을 이용 나타남 • 거래내역이 변조된 상태에서 승인이 되도록 하기 위하여. • 1) 공인인증서 창에 나타나는 이체내역을 수정 • - A은행의 경우, submitCert함수를 통해 공인인증서 창에 출력할 이체내역이 출력되기 때문에, • 이 함수를 오버라이딩하여 공격자의 계좌정보가 아닌 사용자가 입력한 계좌정보를 출력하도록 수정 • 2) 두 건 이상의 계좌이체를 수행하도록 하여 이체내역을 띄우지 않도록 한다.  확인가능

21. 문서 변조 공격 실제 사례 4. 이체 결과 – 이체결과의 조작 • 계좌이체 후 잔액은 사용자가 의도했던 금액만큼만 제외하고 출력함. • 이후 조회화면 또한 조작하여 사용자가 다른 채널을 통해 계좌를 조회하지 않는 이상 공격사실을 인지하지 못한다. (현재 등급은 폐지됨)

22. 대응방법 CAPTCHA에 거래 내역을 포함시키는 방법 신뢰할 수 있는 다른 채널(부가 장치)을 이용한 승인 방법

23. 대응방법 1. CAPTCHA를 이용한 부정승인 방지 방법 • 거래내역을 포함시킨 형태의 확장된 CAPTCHA • 1) ArcotVPS • -> 서버에서 사용자가 입력한 거래정보와 함께 OTP값을 CAPTCHA로 구성하여 사용자에 검증요청 • 2) 취약점 • -> 배경과 문자열의 색이 다르고 이미지에서 문자가 차지하는 비율이 낮다는 근거를 이용. • -> 문자열을 읽을 순 없지만 서버에서 보내준 CAPTCHA중 랜덤하게 하나만 선택하여 이미지 재생성. • -> CAPTCHA문자열이 4가지 이므로 25%의 확률로 공격에 성공.(4가지문자열중 하나를 정해 추출)

24. 대응방법 1. CAPTCHA를 이용한 부정승인 방지 방법 2) MS 워터마크 -> 일반 폰트로 거래내역이 표현된 배경 위로 CAPTCHA가 표현됨 -> CAPTCHA의 폰트가 더욱 두껍고 크기 때문에 문자열 분리 가능 -> 문자열이 분리가 가능하게 되면, 악성코드는 변조된 거래내역 위에 문자열을 덮어씌워 이미지생성.

25. 대응방법 1. CAPTCHA를 이용한 부정승인 방지 방법 3) 문맥 기반 CAPTCHA -> 50개의 CAPTCHA 이미지 중에 사용자의 거래와 관련된 CAPTCHA 만 을 선택하도록 요구. -> malware는 그라데이션+ 뒤틀림은 문자열의 해석이 불가능함. -> 수신은행, 수신계좌, 수신자명, 이체금액, 송신자, 송신은행 + 44개의 더미 CAPTCHA -> 최소한의 콘텐츠 변경은 수신계좌, 수신자 + 48개의 더미 CAPTCHA -> 입력 형태가 아닌 선택의 형식을 사용하여 복잡도가 높은(더 심하게 뒤틀린) CAPTCHA사용가능 -> 사용자는 거래내역을 알고 있으므로 복잡한 CAPTCHA를 인식하는데 지장이 없음.

26. 대응방법 2. 부가장치를 이용한 승인방법 • 부가장치에서 거래내역을 출력하고 이 장치를 통해 거래내역 확인 또는 거래승인하도록하는 것이 목적. • 현재 사용중인 것은 인터넷뱅킹 계좌이체의 전화승인 서비스가 유일 • :사용자에게 전화를 걸어 거래내역확인 • 트랜잭션 서명기법 • 1) 사용자 토큰(추가적으로 발급받은 기기)에 거래내역의 일부를 입력하면 토큰에 출력된 MAC을 • 컴퓨터에 수작업으로 입력하는 방법 • 2) 1)에 기반하여 사용자 토큰에 인증서를 저장한 형태 또는 사용자가 입력한 MAC을 컴퓨터에서 • 공인인증서를 통해 사인하는 방법으로 부인방지를 추가적으로 제공 • 3) IBM의 ZTIC은 USB 장치의 display를 통해 거래내역을 출력하고, 두개의 버튼을 통해 승인 or 취소 • ZTIC은 컴퓨터에 연결되면 USB 저장장치로 인식됨과 동시에 사전에 정의되어 있는 은행사이트로 • 연결되도록 프록시를 설정하고, 웹 프라우저와 해당 사이트와의 통신을 ZTIC을 통해 하도록 함. • 부가적인 장치를 써야 하기 때문에 유저 편의성에서 떨어짐.

27. 결론 • 악성코드에 의한 문서변조로 공격자가 의도한 계좌로 이체 될 수 있다는 사실이 확인됨. • 이 공격은 모든 보안 프로그램이 정상 작동하는 상태에서도 유효하다는 점에서 위험성이 매우 높음 • 키보드 보안 프로그램이 이상적으로 동작하는 상태에서(keybd_event제한) 공격자가 의도한 계좌로 이체되는 것은 제한된다. • 사용자 편의성을 위해 제공되는 이벤트함수(keybd_event)가 허용된다면 악성코드가 이용할 수 있음. • 모바일뱅킹에서도PC와 같이 MITB 공격이 충분히 가능할 수 있으므로 해당 대책이 시급 마련되야 함

28. 2012.5.3 유창훈 Man – in – the – Browser Attack에 관하여 • Defeating Man-in-the-Browser • :How to prevent the latest malware attacks against consumer and corporate banking

29. Table of Contents • Introduction. • What is a Man-in-the-middle-Browser Attack? • What Can be Done ? • Summary

30. What Can Be Done? • Online 사용자를 보호하기 위한 Active & Passive Safeguard 존재 • Active Safeguards • 유저가 취할 수 있는 추가적인 인증 수단을 통하여 authentication steps, transaction execution time 을 보호 • Passive Safeguards • 추가적인 인증 수단이 아닌 사용자가 인지하지 못하는 범위 내에서 Monitoring 과 Detection 수행

31. What Can Be Done? - Active safeguards 1

32. What Can Be Done? - Active safeguards

33. What Can Be Done? - Active safeguards 2

34. What Can Be Done? - Passive safeguard

35. What Can Be Done? - Passive safeguard

36. What Can Be Done? - Passive safeguard

37. Summary • MITB 공격을 좌절시키는 것은 매우 어려움 • 보다 효과적인 접근이 필요 • 기존의 Two-factor 인증 솔루션은 더 이상 MITB에 효율적이지 않음 • Out-of-band transaction detail confirmation • : Malware의 영향을 받는 UserPC를 벗어난 상황에서 거래 내역 • 을 다시 한번 확인하는 과정이 필요함. • Fraud detection that monitors user behavior • : 은행사이트를 통하여 사용자의 움직임을 서버에서 모니터링 하고 • 수상한 패턴을 감지하여 즉시 간섭함.