국내인터넷뱅킹 계좌이체에 대한 MITB분석

Report
Man – in – the – Browser Attack에 관하여
1. 국내 인터넷 뱅킹 계좌이체에 대한 MITB 취약점 분석
2. Defeating Man-in-the-Browser
:How to prevent the latest malware attacks against consumer and corporate banking
2012.5.3
유창훈
Table of Contents
1. 소
개
2. 관련 연구 및 동향
3. 국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
4. 대응방법
5. 결
론
소개
 인터넷 뱅킹이 지속적인 성장세에 있음
 비대면 거래의 특성상 인증프로토콜의 보안성이 중요
외우는 비밀
인증프로토콜
고정된 비밀
지니는 비밀
고정되지않은비밀
고정되지 않은
비밀 악용
비밀 가로채기
문서변조
: OTP
1. 문서 전체에 대한 무결성 확인
2. 문서의 자원에 대한 외부프로그
램 차단
3. 악의적인 키 데이터 입력 막기
관련연구
 2005, Augusto에 의해 Web Browser에 악성프로그램이 상주하여 공격하는 것이 발표됨.
 2007, Guhring에 의해 MITB라고 불리기 시작함.
 2008, Sharek et al. 사용자가 진짜와 가짜 팝업 에러창 구별 실험
( 사용자들의 73%가 가짜를 구별하지 못함)
 2010, Kim et al.은 한국의 인터넷 뱅킹이 다양한 보안기술을 제공하고 있음에도 불구하고 더 나은
보안성을 기대하기 힘들다는 점을 지적
1) 피싱 공격에 무방비
2) 공인인증서의 문제점
3) 플러그인의 한계
4) 공개되지 않은 인증프로토콜의 보안성
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
1.공인인증서와 보안수단
 공개키 기반의 인터넷 뱅킹 시스템
 공인인증서 발급시 Password를 입력은 공인인증서 개인키를 암호화 하기 위함.
 Brute-force 공격에 노출될 가능성이 있음  공인인증서 암호를 알아도 계좌이체등의
거래는 안됨.
 보안카드, OTP와 같은 보안 수단이 필요(거래승인시요구)
▶ But! 사용자를 안전하게 인증 하였다는 것과 서버가 사용자의 비밀을 안전하게 전달받았다
는 것이 사용자가 의도한 거래 내용이 변조되지 않았다는 것까지 보장하지는 않는다.
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
2. 부분적인 암호화와 무결성 및 문서의 변조
 국내의 Internet Banking은 모든 패킷을 암호화 하지 않고 중요 데이터만 부분적으로 암호화 됨.
 동작 구조
1) 서버와 클라이언트에 설치되어 있는 플러그인이 Session key를 공유
2) 서버가 중요한 데이터를 암호화하여 웹 브라우저에 전송하면,
3) 자바스크립트가 암호화된 데이터를 플러그인을 이용하여 복호화 한 뒤, 출력 함
 암호화된 부분은 Session Key가 없으면 공격자 의도대로 수정할 순 없지만,
 문서 전체에 대한 무결성 검증 절차가 없다면 암호화되지 않은 부분의 문서가 변조될 수 있다.
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
공격자가 문서를 변조할 수 있는 방법
1. 네트워크 수준에서 문서가 IEFrame에 로드되기 전까지 DOM개체 삽입
2. IEFrame에 로드 된 이후 BHO나 Toolbar를 통한 DOM개체 삽입
3. IEFrame에 로드 된 이후 또 다른 개체(IEFrame 또는 이미지) 를 문서에
덮어씌우는 방식
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
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속성을 이용
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
2) 문서위에 개체를 덮어씌우는 간접적인 문서변조
 문서위에 다른 개체를 올려놓는 방법을 고안
 이미지, 동영상, IEFrame 등이 될 수 있음
 화면에 실제 출력되는 내용은 최상의 계층만 출력된다는 점을 악용하여 사용자가 바라보는 문서를
간접적으로 수정
 IHTMLDocument2를 이용한 Dialog 형태
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
3. 키보드 보안 프로그램
 악성프로그램이 설치되어 있다는 가정 하에 사용자가 입력하
는 비밀이 노출되는 것을 방지하기 위함.
 키 입력 정보를 가로채는 구간은 다양
1) 키보드 인터럽트
2) 키보드 드라이버
3) DLL Injection을 통한 메모리 영역
4) BHO등을 이용한 컴퓨터 메모리 영역
 키보드 보안 프로그램은 각자 구현 방법에 따라 키 입력 값을
암호화 하거나 더미값을 올려보내 노출이나 변조되는 것을
방지함.
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
3. 키보드 보안 프로그램
 nProteck Key Crypt
 ‘기존 경로’ 의 키보드 드라이버로는 NULL 값을
전송하여 상위 계층에서 해킹도구가 동작하더라
도 키보드 입력값을 얻지 못하도록함
 보안 키보드 드라이버는 키 입력이 있을 때마다
‘*’ 표시가 나타나도록 보안 입력창에 지시하고 ,
확인 버튼이 눌러지면 버퍼에 저장된 입력값을
암호화 하여 보안 입력창 제어부로 전송
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
 보안기능이 최소화된 키보드 보안 프로그램
1) 사용자 동의 하에 보안 기능이 최소화된 키보드 보안 프로그램 제공(S사)
2) 해당 프로그램은 보안기능을 제공하지 않기 때문에 문제가 됨.
3) 공격자는 제공되는 보안프로그램의 Class ID 와 같은 프로그램을 사용자 모르게 설치.
 악의적인 키 데이터 삽입
1) 윈도우 API 수준의 Keybd_event로도 수신계좌번호를 입력하는 것이 가능
2) SendInput을 통한 수신계좌번호 입력
 계좌번호목록을 이용한 수신계좌번호 변경
1) 스크립트 조작으로 사용자가 입력한 계좌번호를 취소하고 대신 계좌번호목록(자주쓰는 계좌,
최근 입금 계좌등)에 존재하는 어떤 계좌로 수신계좌를 변경하는 것이 가능
국내 인터넷 뱅킹 환경 및 문서변조 공격에 대한 취약점
4. 문서변조 및 악성 키 데이터 입력 실험 결과
문서 변조 공격 실제 사례
시나리오
 사용자 컴퓨터에 설치되어 있는 악성프로그램이 계좌이체 페이지를 자동으로 변조하고,
 이 변조된 문서에서 사용자가 어떤 수신자에게 계좌이체를 시도하면,
 이체 가능금액 모두를 공격자의 계좌로 이체되도록 하는 공격
1. 이체정보 입력화면-가짜 이체화면 출력
1) 출금계좌정보(출금계좌번호, 계좌비밀번호) 가 입력되는 곳은 수정하지 않고 입금계좌정보와
이체금액은 공격자의 의도대로 조작
2) 입금계좌정보와 이체 금액의 입력폼을 복사하여 CSS의 Z-index 속성을 이용, 동일한 위치의
상위계층 설정
3) 가짜 입력폼을 작성한 후에는 이와 관련한 이벤트와 자바스크립트들을 오버라이딩을 통해
가짜 입력폼에서 동작하도록 수정함
문서 변조 공격 실제 사례
문서 변조 공격 실제 사례
1. 이체정보 입력화면 – 이체금액 조작
 이체금액폼에 이체 가능 ‘전액’을 입력
 ‘전액’버튼은 팝업창을 통해 사용자에게 전액 이체 여부를 확인한 후 입력되도록 되어 있지만,
 스크립트수준에서 구현된 것이기 때문에 함수 오버라이딩을 통해 사용자 확인 없이 입력 가능
문서 변조 공격 실제 사례
1. 이체정보 입력화면 – 입금계좌번호 조작
 입금계좌정보는 입금은행과 입금계좌번호로 이루어짐.
 DOM의 SELECT로 구성된 입금은행은 스크립트 수준에서 조작할 수 있음.
 키보드 보안 프로그램이 작동 중인 경우 계좌번호를 키보드 보안 프로그램이 보관하고 암호화 하여 보
내기 때문에 입금계좌를 조작하는 것이 쉽지 않음
 키보드 보안 프로그램이 적용된 경우 계좌정보목록에 있는 계좌 중에 선택하여 적용
 입금계좌목록에만 조작이 가능할 시 공격 대상이 제한적일 수밖에 없음.
 키보드 보안이 적용된 경우에도 입금계좌번호를 조작할 수 있어야 함
1) Keybd_event와 같은 키 입력 함수 악용
2) 해당 함수를 사용 불가로 할 경우 보안성은 향상되나 유저 편의성
저하( 원격 데스크탑 9/ 스마트폰 / 태블릿PC등에서 사용 불가)
<자주쓰는입금계좌번호를 자동으로 입력하는 스크립트>
문서 변조 공격 실제 사례
1. 이체정보 입력화면 – 사용자가 입력한 이체정보 유지
 조작된 계좌이체가 공인증서를 통해 승인받기 전까지 의심받지 않으려면, 사용자가 입력한 계좌정보를
유지 해야 할 필요성이 있음.
문서 변조 공격 실제 사례
2. 수신자명을 통한 입금계좌 확인 – 수신자명 조작
 스크립트를 사용하여 사용자가 입력한 계좌에 대한 서버 질의를 하여 수신자명을 알아냄
상황1)
1)
2)
3)
4)
5)
6)
사용자가 입력한 계좌번호에 대한 서버 질의
서버의 응답으로 부터 수신자명 확인.
서버에 사용자가 입력한 계좌번호에 대한 거래 취소 요청.
공격자가 입금계좌에 대한 서버 질의
이체 계좌 확인 화면에 사용자가 입력한 입금계좌에 대한 정보만을 출력
보안카드나 OTP 입력을 기다리는 화면이 보여짐.
상황2)
1) 계좌이체 추가를 통해 사용자가 입력한 계좌번호와 공격자가 입력한 계좌번호를 서버에 질의
2) 서버의 응답으로 부터 사용자가 입력한 계좌 번호에 대한 수신자명을 확인.
3) 사용자가 입력한 계좌번호에 대해 그냥 그대로 이체하거나, 이체 금액을 줄여 이체하여 서버측의
이상탐지가 불가능하도록 함.
4) 이체 계좌 확인 화면에는 사용자가 입력한 입금계좌에 대한 정보만 출력
5) 보안카드나 OTP 입력을 기다리는 화면이 보여짐.
문서 변조 공격 실제 사례
3. 공인인증서를 통한 이체 승인 – 이체내용 조작
 이체 시 보안카드 or OTP를 입력한 이후에 공인인증서의 사용을 통해 최종적으로 계좌이체에 대한 사
용자 승인이 필요
 공인인증서를 사용하는 상단에는 계좌이체 정보가 표시되는데, 계좌이체가 두 건 이상인 경우에는 계좌
이체 정보가 나타나지 않음을 이용  나타남
 거래내역이 변조된 상태에서 승인이 되도록 하기 위하여.
1) 공인인증서 창에 나타나는 이체내역을 수정
- A은행의 경우, submitCert 함수를 통해 공인인증서 창에 출력할 이체내역이 출력되기 때문에,
이 함수를 오버라이딩하여 공격자의 계좌정보가 아닌 사용자가 입력한 계좌정보를 출력하도록 수정
2) 두 건 이상의 계좌이체를 수행하도록 하여 이체내역을 띄우지 않도록 한다.  확인가능
문서 변조 공격 실제 사례
4. 이체 결과 – 이체결과의 조작
 계좌이체 후 잔액은 사용자가 의도했던 금액만큼만 제외하고 출력함.
 이후 조회화면 또한 조작하여 사용자가 다른 채널을 통해 계좌를 조회하지 않는 이상 공격사실을 인지
하지 못한다.
(현재 등급은 폐지됨)
대응방법
1. CAPTCHA에 거래 내역을 포함시키는 방법
2. 신뢰할 수 있는 다른 채널(부가 장치)을 이용한 승인 방법
대응방법
1. CAPTCHA를 이용한 부정승인 방지 방법
 거래내역을 포함시킨 형태의 확장된 CAPTCHA
1) ArcotVPS
-> 서버에서 사용자가 입력한 거래정보와 함께 OTP 값을 CAPTCHA로 구성하여 사용자에 검증요청
2) 취약점
-> 배경과 문자열의 색이 다르고 이미지에서 문자가 차지하는 비율이 낮다는 근거를 이용.
-> 문자열을 읽을 순 없지만 서버에서 보내준 CAPTCHA중 랜덤하게 하나만 선택하여 이미지 재생성.
-> CAPTCHA문자열이 4가지 이므로 25%의 확률로 공격에 성공.(4가지문자열중 하나를 정해 추출)
대응방법
1. CAPTCHA를 이용한 부정승인 방지 방법
2) MS 워터마크
-> 일반 폰트로 거래내역이 표현된 배경 위로 CAPTCHA가 표현됨
-> CAPTCHA의 폰트가 더욱 두껍고 크기 때문에 문자열 분리 가능
-> 문자열이 분리가 가능하게 되면, 악성코드는 변조된 거래내역 위에 문자열을 덮어씌워 이미지생성.
대응방법
1. CAPTCHA를 이용한 부정승인 방지 방법
3) 문맥 기반 CAPTCHA
-> 50개의 CAPTCHA 이미지 중에 사용자의 거래와 관련된 CAPTCHA 만 을 선택하도록 요구.
-> malware는 그라데이션 + 뒤틀림은 문자열의 해석이 불가능함.
-> 수신은행, 수신계좌, 수신자명, 이체금액, 송신자, 송신은행 + 44개의 더미 CAPTCHA
-> 최소한의 콘텐츠 변경은 수신계좌, 수신자 + 48개의 더미 CAPTCHA
-> 입력 형태가 아닌 선택의 형식을 사용하여 복잡도가 높은(더 심하게 뒤틀린) CAPTCHA사용가능
-> 사용자는 거래내역을 알고 있으므로 복잡한 CAPTCHA를 인식하는데 지장이 없음.
대응방법
2. 부가장치를 이용한 승인방법
 부가장치에서 거래내역을 출력하고 이 장치를 통해 거래내역 확인 또는 거래승인하도록 하는 것이 목
적.
 현재 사용중인 것은 인터넷뱅킹 계좌이체의 전화승인 서비스가 유일
:사용자에게 전화를 걸어 거래내역확인
 트랜잭션 서명기법
1) 사용자 토큰(추가적으로 발급받은 기기)에 거래내역의 일부를 입력하면 토큰에 출력된 MAC을
컴퓨터에 수작업으로 입력하는 방법
2) 1)에 기반하여 사용자 토큰에 인증서를 저장한 형태 또는 사용자가 입력한 MAC을 컴퓨터에서
공인인증서를 통해 사인하는 방법으로 부인방지를 추가적으로 제공
3) IBM의 ZTIC은 USB 장치의 display를 통해 거래내역을 출력하고, 두개의 버튼을 통해 승인 or 취소
ZTIC은 컴퓨터에 연결되면 USB 저장장치로 인식됨과 동시에 사전에 정의되어 있는 은행사이트로
연결되도록 프록시를 설정하고, 웹 프라우저와 해당 사이트와의 통신을 ZTIC을 통해 하도록 함.
 부가적인 장치를 써야 하기 때문에 유저 편의성에서 떨어짐.
결론
 악성코드에 의한 문서변조로 공격자가 의도한 계좌로 이체 될 수 있다는 사실이 확인됨.
 이 공격은 모든 보안 프로그램이 정상 작동하는 상태에서도 유효하다는 점에서 위험성이 매우 높음
 키보드 보안 프로그램이 이상적으로 동작하는 상태에서(keybd_event제한) 공격자가 의도한 계좌로 이
체되는 것은 제한된다.
 사용자 편의성을 위해 제공되는 이벤트함수(keybd_event)가 허용된다면 악성코드가 이용할 수 있음.
 모바일 뱅킹에서도 PC와 같이 MITB 공격이 충분히 가능할 수 있으므로 해당 대책이 시급 마련되야
함
Man – in – the – Browser Attack에 관하여
1. Defeating Man-in-the-Browser
:How to prevent the latest malware attacks against consumer and corporate banking
2012.5.3
유창훈
Table of Contents
1. Introduction.
2. What is a Man-in-the-middle-Browser Attack ?
3. What Can be Done ?
4. Summary
What Can Be Done?
Online 사용자를 보호하기 위한 Active & Passive Safeguard 존재
1. Active Safeguards
•
유저가 취할 수 있는 추가적인 인증 수단을 통하여 authentication steps,
transaction execution time 을 보호
2. Passive Safeguards
•
추가적인 인증 수단이 아닌 사용자가 인지하지 못하는 범위 내에서
Monitoring 과 Detection 수행
What Can Be Done? - Active safeguards
1.
1
What Can Be Done? - Active safeguards
What Can Be Done? - Active safeguards
1.
2
What Can Be Done? - Passive safeguard
What Can Be Done? - Passive safeguard
What Can Be Done? - Passive safeguard
Summary
•
MITB 공격을 좌절시키는 것은 매우 어려움
•
보다 효과적인 접근이 필요
•
기존의 Two-factor 인증 솔루션은 더 이상 MITB에 효율적이지 않음
1. Out-of-band transaction detail confirmation
: Malware의 영향을 받는 UserPC를 벗어난 상황에서 거래 내역
을 다시 한번 확인하는 과정이 필요함.
2. Fraud detection that monitors user behavior
: 은행사이트를 통하여 사용자의 움직임을 서버에서 모니터링 하고
수상한 패턴을 감지하여 즉시 간섭함.

similar documents