[Tech Report] 웹에서 벌어지는 矛盾 대결, 창과 방패의 전술 공개

[ 최신 웹 해킹 툴의 공격 기법 및 방어 기술 ]

 

중국 고서 한비자(韓非子)에는 ‘모순(矛盾)’이라는 유명한 일화가 소개되어 있다. 무엇이든지 뚫을 수 있는 창과 무엇이든지 막을 수 있는 방패를 파는 상인에 대한 이야기이다.

보안에서 해커와 보안 회사 역시 ‘모순’ 관계이다. 실력을 과신하는 해커들은 어떠한 보안 시스템이든지 모두 뚫을 수 있다고 말하고, 보안 회사들은 어떠한 보안 위협이든지 모두 막을 수 있다고 한다. 
정보 보안은 발견된 취약점에 대하여 보완 가능한 부분을 찾는 것이다. 정확히 말하면 제거할 수 없는 보안 위험들을 대응 가능한 수준으로 낮추는 것이 목표이다.
이 글에서는 점차 위험성이 증가하고 있는 웹에 대한 보안을 강화하기 위해, 최신 웹 해킹 툴의 공격 기법과 방어 기술을 소개하고자 한다.

 

 

메모리 해킹(Memory Hacking)

메모리 해킹은 2010년 국내 증권사 HTS의 메모리 취약점 문제로 이슈가 되었던 공격이다. 이는 프로세스의 메모리에 접근하여 특정 주소의 값을 빼내거나 변조시키는 공격으로, 주로 게임 해킹에 많이 사용되었다. 하지만, 최근에는 금융거래 해킹에도 메모리 해킹 기술이 이용되고 있다. 메모리 해킹 기법은 비밀번호 등의 사용자 중요 정보 해킹은 물론, 증권 시세 변조 및 주문 변조에 대한 위험도 알려져 있다.

 

[그림 1] 사용자의 아이디, 비밀번호가 메모리 상에 그대로 노출

 

그럼 본격적으로 메모리 해킹이 어떻게 이루어지는지 살펴보자. 외부에서 프로세스의 메모리에 접근하기 위해서는 파일을 사용하는 것과 매우 유사한 방법을 사용한다. 프로세스의 메모리에 접근하기 위해서는 OpenProcess, ReadProcessMemory, WriteProcessMemory 과정을 거치게 된다. 해킹 프로그램은 이러한 과정을 거쳐 프로세스 외부에서도 마치 파일을 읽고, 수정하는 것처럼 프로세스 메모리에 접근하여 중요 정보를 유출하거나 변조시킨다.
 

[그림 2] 사용자 및 커널 레벨의 프로세스 메모리 접근 API 함수

 

그럼 이러한 악의적인 접근을 막는 방법은 무엇일까? 보안 프로그램은 프로세스 메모리 접근을 위하여 사용되는 API 함수의 호출 과정을 감시하여, 허락되지 않은 프로그램의 접근이 감지되면 차단하거나 혹은 위험을 알리는 방법을 사용하고 있다. 이때 함수를 감시하는 방법으로 API 후킹(Hooking)이라는 기술을 사용하게 된다. 이 API 후킹은 메모리 해킹을 감시하는 기술로도 사용되지만 해킹 공격에서도 많이 이용되고 있다.

 

 

API 후킹(Hooking)

다음으로 알아볼 해킹 공격 방법이 바로 API 후킹이다. 이 기법은 특정 API를 자신의 함수로 변경하여 공격하는 방법으로 해킹 툴의 핵심 기능이라고 할 수 있다.
그럼, API를 후킹(Hooking)하여 무엇을 할 수 있는가? 이 질문에는 ‘무엇이든지 할 수 있다’고 대답할 수 있다. 실제로 해킹 툴인 제우스(ZeuS)는 WININET 계열의 API 함수를 후킹하는 방법으로 인터넷 전송 정보를 탈취하여 계좌 정보를 유출하거나 주요 정보를 도용했다.

 

[그림 3] 제우스(ZeuS)에 감염된 시스템의 메모리에 로드 되어 있는 HttpSendRequest API 함수 코드

 

[그림 3]은 해킹 툴인 제우스(ZeuS)에 감염된 시스템에서 디버그 명령어로 메모리에 로드 되어 있는 HttpSendRequest API 함수의 코드 내용을 살펴본 것이다. 정상적인 시스템에서와는 달리 함수 진입점 부분에 Jump Code(0xE9)가 삽입되어 있으며, 이를 통하여 함수가 호출되어도 다른 주소의 코드로 이동하고 있음을 보여 주고 있다.

 

최근 제우스의 소스코드가 인터넷상에 유출되어 이슈가 되기도 했다. [그림4]는 유출된 제우스 소 스코드의 일부분이다.

 

[그림 4] ZeuS의 소스의 WRITE_JUMP 매크로 코드 내용

 

디버그를 통해 확인한 결과 제우스는 함수 진입점에 Jump Code(0xE9) Write 하고, 그 뒤에 점프(Jump)할 주소를 넣는 전형적인 인라인 후킹(Inline Hooking) 방법을 사용하고 있다.

 

그렇다면, API가 후킹되어 있는지 알아내기 위해서는 함수 진입점에 점프 코드가 존재하는지 여부를 검사하면 될 것이다. 하지만 이것은 정확한 방법이 아닐 수 있다. 점프 코드 이외의 우회 코드가 사용될 수도 있기 때문이다. 그럼 어떤 방법으로 API가 후킹됐는지 알아낼 수 있을까?

 

[그림 5] PE 뷰어로 본 wininet.dll의 “Export Address Table"

 

일반적으로 EXE, DLL 등의 파일은 정해진 포맷을 가지고 있는데, 실행 파일은 OS가 읽어 들이는 문서 파일이라고 생각하면 쉽게 이해할 수 있을 것이다. EXE, DLL 파일들의 포맷이 바로 PE(Portable Executable) 형식으로, 이 곳에는 실행 파일들에 대한 각종 정보들이 저장되어 있다. 그 중 "Export Address Table"이라는 부분이 있는데, 이 부분에는 실제 함수 코드가 있는 주소 값이 저장되어 있다.

 

"Export Address Table"에 접근하기 위해서 먼저 헤더 부분인 IMAGE_NT_HEADER를 읽어 접근한다. 그리고 검사하려는 함수의 코드가 저장된 주소를 읽어 함수 코드에 접근하여 함수 코드를 읽어 들인 후, 읽어온 코드와 메모리에 실제 로딩 된 함수의 코드와 비교하여 함수 후킹 여부를 확인한다. 만약에 함수가 후킹되어 있다면 읽어 들인 원래의 코드로 복원하는 방법을 사용한다.

 

그런데, 여기서 한 가지 문제가 있다. API 후킹은 악성코드 이외에도 보안 프로그램 등에서 많이 사용하고 있는 방법이다. 악성코드는 이런 것에 상관없이 코드를 작성하면 되지만 방어하는 입장에서는 이런 점을 고려하지 않을 수 없다. 이러한 점 때문에 방어가 공격보다 힘들다고 할 수 있다.

 

정상적인 프로그램이 후킹하고 있는지 확인하기 위해서는 실제 점프된 주소가 어떤 모듈을 가리키고 있는지 검사하여야 한다. 그리고 만약 후킹하고 있는 모듈이 정상적인 모듈일 경우 복원하지 말아야 하는데, 이를 확인하기 위하여 미리 정상적인 프로그램들의 목록을 가지고 있어야 한다.

 

HTML 인젝션(Injection)

웹 페이지의 특정 부분을 변조하거나 수정하여 정보를 유출하는 방법으로, 비교적 단순한 기술로 높은 수준의 보안 시스템을 간단히 우회할 수 있는 방법이 있다. 그것이 지금 소개하고자 하는 HTML 인젝션 공격이다.

 

HTML 인젝션 공격으로 웹 페이지에 다른 정보를 삽입 혹은 변경하거나 쿠키(Cookie) 등의 다양한 웹 페이지 정보에 접근이 가능하다. ‘OddJob‘ 이라는 악성코드는 중간에 가로챈 쿠키 값을 이용하여 사용자가 브라우저를 종료했음에도 불구하고, 계속적으로 로그인 세션을 유지시켜 금용 정보에 대한 해킹을 시도한 사례도 있다. 이러한 공격 방법들은 보안 시스템을 간단히 우회할 수 있는 반면, 서버 측에서는 이를 전혀 알 수 없어 매우 심각하다.
 

[그림 6] DCOM의 RCP 통신 과정 중의 악성 코드 삽입

 

윈도우에는 DCOM(Distributed Component Object Model)이라는 분산 컴포넌트 간 통신을 위한 기술을 제공하고 있는데, 우리가 많이 사용하고 있는 IE 브라우저도 DCOM 기술로 개발되어 있다. DCOM을 통하여 브라우저의 내부에 접근하는 방법을 사용하면, HTML 페이지의 구조나 쿠키 정보에 쉽게 접근할 수 있게 된다. DCOM은 RPC(Remote Procedure Call)라는 통신 방법을 사용하는데, 이때 Client Stub과 Sever Stub을 통하여 프로시저에 연결한다. 바로 이 부분에서 HTML 인젝션 방어의 실마리를 찾을 수 있다.

 

[그림 7] RCP Stub Call 부분에 대한 접근 차단 및 허용

 

외부에서 브라우저의 내부에 접근하기 위해서는 Stub 함수를 사용하고, 이곳에서 RCP 통신의 목적지와 RCP 통신 ID를 Stub 함수에 요청한다. 여기서 목적지와 RCP ID를 검사하면 악의적으로 접근하는 프로세스의 차단이 가능하다.

 

현재 안철수연구소의 웹 트렌잭션 방어 제품인 AOS Secure Browser 에서도 RPC 통신이 이루어지는 Stub 부분을 감시하여 get_value, get_cookie 등을 요청하는 프로세스를 선별하여 허용 및 차단하는 방법으로 HTML 인젝션 공격을 예방하고 있다.

 

페이크 윈도우(Fake Windows)

최근 국내 금융사만을 공격 목표로 하는 악성코드가 발견되어 이슈가 된 바 있다. 해당 악성코드는 웹 페이지의 입력창에 위에 가짜 입력창을 덮어 씌워서 사용자를 속이는 방법을 사용했다. 그 방법이 바로 페이크 윈도우(Fake Windows) 공격이다.

 

[그림 8] 페이크 윈도우 : 공격 대상 윈도우 위에 같은 크기의 창 생성

 

이 공격의 원리는 다른 공격에 비해 비교적 간단하다. 비밀번호 입력창의 윈도우 핸들(Windows Handle)을 찾아 그 위에 가짜 창을 생성하는 방법을 사용하고 있다. 앞에서 언급한 국내 금융사를 공격 목표로 했던 '뱅커(Banker)'라는 악성코드는 각 금융사의 공인인증서 프로그램의 입력창 위에 가짜 창을 생성하여 비밀번호 해킹을 시도한 것이다.

 

[그림 9] 전체 윈도우를 대상으로 보호대상 창과 같은 크기의 창이 생성되어 있는지를 검사

 

이러한 페이크 윈도우 공격을 방어하기 위해서는 보호대상 입력창의 입력이 시작되는 시점에서 보호대상 창의 크기와 유사한 다른 윈도우 창이 생성되어 있는지를 전체 윈도우를 대상으로 검사하는 방법을 사용하고 있다. 단순한 방법이지만, 단순한 공격을 막아내는 데는 단순한 방법이 더 효과적일 때가 많다.

 

 

페이크 SSL (Fake SSL)
마지막으로 페이크 SSL 공격에 대해 소개하고자 한다. 이 공격은 HTTPS 통신 패킷을 중간에 가로채는 수법을 사용한다. SSL 통신 중간에 가짜 인증서를 이용하여 SSL 통신 데이터를 훔쳐보는 페이크 SSL 공격은 현재 원격지에서도 패킷 감시가 가능 수준으로 진화되었다.

 

[그림 10] 페이크 인증서를 이용하여 SSL 통신을 암복호화하여 평문 상태의 내용 확인 가능

 

페이크 SSL 공격 방법을 사용하는 대표적인 해킹 툴에는 ‘카인&아벨(Cain&Abel)‘이라는 악성코드를 들 수 있다. 카인&아벨은 원격지에서 ARP 스푸핑(Spoofing) 방식으로 패킷을 가로채서 가짜 인증서를 전송하는 방법으로 SSL 통신을 모니터링할 수 있다. 이 툴은 재미있게도 카인 모드와 아벨 모드가 있는데, 아벨 모드에서는 좋은 패킷 모니터링 툴로 동작하다가 카인 모드로 변경하게 되면 무서운 공격 툴로 돌변한다.

 

페이크 SSL 공격의 방어는 SSL 통신 과정에서 이용되는 인증서의 검증을 통하여 이루어진다. 인증서에는 여러 가지 정보가 담겨 있는데 Subject에는 인증서를 발급받은 업체와 서버 주소에 대한 부분이 있으며, Issuer에는 인증서를 발급한 기관의 정보가 저장되어 있다.

 

이러한 정보를 이용하여 안철수연구소의 보안제품은 보호 대상 SSL 서버에서 사용하고 있는 인증서 정보가 실제로 유효한지를 검증하여 페이크 SSL 공격의 차단 및 알림 기능을 구현하고 있다. 그런데, 최근 이러한 인증서의 정보조차도 수정 가능하다고 알려져 있다. 따라서 한 단계 더 나아가 인증서를 발급한 기관의 서명을 검증하여 정상적인 인증서인지 여부를 판단하는 기능이 필요하다.

해커들은 보안이 잘 되어 있는 곳은 노리지 않는다. 그들은 취약점을 찾으며, 그 취약점을 이용하여 해킹을 시도한다. 일반적으로 알려져 있는 것과 달리 대부분의 해커들은 어려운 기술을 사용하지도, 높은 수준의 지식을 가지고 있지도 않다. 단지, 보안이 허술한 취약점을 찾아 간단한 방법으로도 쉽게 해킹을 시도하는 것이다.

지금까지 웹 해킹 툴의 공격 기법 및 방어 기술에 대하여 살펴보았다. 그런데, 공개된 방법들이 악용될 수 있기 때문에, 해킹 기법을 소개하는 것 자체가 고민이 되는 일이다. 하지만, 정보는 공개되어야 하며, 여러 사람들과 함께 고민하는 것이 더 좋은 효과를 얻을 수 있다는 믿음으로 이 글을 작성하였다. 다양한 공격 방법에 대한 연구가 활발하게 진행되어 이러한 공격들이 이제는 위험한 공격이 되지 않았으면 하는 바람이다.@