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

Presentation on theme: "Man – in – the – Browser Attack에 관하여"— Presentation transcript:

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

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

3 Introduction 온라인 뱅킹이 활성화됨에 따라 새로운 서비스 제공의 기회가 주어짐 ( Operation cost의 감소, 고객층의 증가 ) 그로 인한 범죄의 가능성도 증가하게 됨. 보안과 사용자 편의성 측면에서 서비스 제공이 되어야 함. Phishing & Spear-phishing Attack 을 통해 malware를 설치하도록 디자인. 유저의 브라우저를 통해 malicious transaction을 실행.

4 Introduction 개인뿐만 아니라 조직에 대한 공격이 늘어나고 있음.
정치적 목적의 ‘Hactivism’ 해킹공격이 늘어나고 있는 추세. 단순히 인터넷 뱅킹 세션을 가로채는 수준이 아님.

5 What is a Man-in-the-Browser Attack?
Malicious Software를 사용자 PC에 설치함으로써 공격이 가능함. ( Social Engineering을 이용 / AV Scanning에도 탐지되지 않음) Browser Helper Object(BHO), User Script, Active X Control등을 이용함. (Internet과 Browser 사이에서 Capture and Modifying Information) 사용자가 정상적으로 인지하고 있는 상황에서 사용자의 의도와는 다르게 거래가 일어남 전통적인 방법으로는 효율적이지 않음(static and one-time passcode ..) 최근 기업뱅킹 고객을 대상으로 한 MITB공격이 이루어 지고있음. Zeus, SilentBaker Trojans, Ruyssian-born Spy Eye.

6 MITB Attack Phase One : Infection
Infected Download 을 통한 Phishing & spear-phishing Phishing을 통해 Identity 관련 정보를 요구하는 것과 더불어 Malware를 배포하는 것에도 목적을 두고 있음. Video Codec, Pirated Software Package, Interesting PDF Document등 사용자 흥미를 돋구는 주제로 Download 유도 Browser Vulnerability 특정 사이트를 방문 했을 때 unpatched browser vulnerability 를 공격하여 Malware를 설치

7 MITB Attack Phase Two : Transaction Takeover
브라우저의 동작과 함께 activated / 사용자는 인지할 수 없는 상태 Malware가 특정 online-banking site 감지. 사용자가 성공적으로 인증(OTP를 통한 강력한인증) 후에, 사용자의 권한으로, Transaction modify, initiate new transaction 결과적으로 사용자의 돈은 공격자의 의도대로 이체되는 결과.

8 MITB Attack Phase Two : Transaction Takeover

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

10 What Can Be Done? - Active safeguards

11 What Can Be Done? - Active safeguards

12 What Can Be Done? - Active safeguards

13 What Can Be Done? - Active safeguard
유저 기본적인 보안 노력이 중요 금융서비스 기관은 정보제공을 해야 함 OS나 Browser의 최신 패치를 유지. 백신소프트웨어의 실행. 최신 OS나 Browser은 취약점에 대해 대응책을 가지고 있음(안전하지않은사이트목록, 취약점 패치) 취약점이 패치 되기 전에 감염될 가능성 있음.

14 What Can Be Done? - Passive safeguard

15 What Can Be Done? - Passive safeguard

16 What Can Be Done? - Passive safeguard

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

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

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

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

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

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

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

24 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
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속성을 이용

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

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

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

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

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

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

31 문서 변조 공격 실제 사례

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

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

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

35 문서 변조 공격 실제 사례 2. 수신자명을 통한 입금계좌 확인 – 수신자명 조작
스크립트를 사용하여 사용자가 입력한 계좌에 대한 서버 질의를 하여 수신자명을 알아냄 1) 서버에 질의한 순간, 해당 입금계좌는 예비계좌이체로 지정되기 때문에, 2) 서버에 계좌이체 취소 요청을 하거나, 3) 그냥 그대로 이체하거나, 이체 금액을 줄여 이체하여 서버측의 이상탐지가 불가능하도록 함. 4) 이체 계좌 확인 화면에는 사용자가 입력한 입금계좌에 대한 정보만 출력

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

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

38 대응방법 1. CAPTCHA를 이용한 부정승인 방지 방법
1) ArcotVPS -> 서버에서 사용자가 입력한 거래정보와 함께 OTP 값을 CAPTCHA로 구성하여 사용자에 검증요청 -> 배경과 문자열의 색이 다르고 이미지에서 문자가 차지하는 비율이 낮다는 근거를 이용하여 -> CAPTCHA문자열이 4가지 이므로 25%의 확률로 공격에 성공.(4가지문자열중 하나를 정해 추출)

39 대응방법 1. CAPTCHA를 이용한 부정승인 방지 방법 2) MS 워터마크

40 대응방법 1. CAPTCHA를 이용한 부정승인 방지 방법 3) 문맥 기반 CAPTCHA

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

42 결론 악성코드에 의한 문서변조로 공격자가 의도한 계좌로 이체 될 수 있다는 사실이 확인됨.
이 공격은 모든 보안 프로그램이 정상 작동하는 상태에서도 유효하다는 점에서 위험성이 매우 높음 다만, 키보드 보안 프로그램이 이상적으로 동작한다면(keybd_event가 제한) 공격자가 의도한 계좌로 이체되는 것은 매우 제한되고, 계좌목록에 존재하는 계좌에만 이체할 수 있다. 사용자 편의성을 위해 화상키보드, 원격테스크톱을 이용한 인터넷 뱅킹이 허용되면, 본 논문에서 행한 공격을 막는 것은 쉽지 않아 보임. 모바일 뱅킹에서도 PC와 같이 MITB 공격이 충분히 가능할 수 있으므로 해당 대책이 시급 마련되야 함