'안티키로거'에 해당되는 글 1건

  1. 2008.11.14 키보드 보안
Hacking & Security/System2008. 11. 14. 11:04
국내의 키보드 보안 업체는 여러곳 있으며, 현재 Cross-Hacking 과 과다경쟁에 의해서 스펙상의 보안수준은 다들 비슷하며 기본적으로 프로그램이 보호하는 구간에서의 해킹은 거의(!) 불가능 할 정도로 보안 수준은 향상되었습니다. 키보드 보안 프로그램 들은 키보드장치 (H/W) 에서 키보드 포트나 USB 포트로 입력되는 사용자의 입력값을 안전하게 특정 어플리케이션(IE 등) 에 전달하는 역할을 합니다.
즉, PC 단에서 발생하는 모든 '개인정보' 유출에 관해서 모든 이슈를 키보드 보안 프로그램으로 방어할 수 있는 것은 아니라는 말이죠. 예를들면, 멕시코 등 남미쪽에서 2006년 이후 극성이었던 overlap 형 spyware 나 iframe injection 에 의한 form 삽입등으로 사용자 정보를 빼내가는 행위를 단지 키보드 보안 프로그램이 설치되었다고 해서 막을 수는 없는 것입니다.

그러나 대부분의 키보드 보안 제품들이 금융감독원의 지침에 의해서 금융권에 적용되다 보니 보수적인 기업 문화와 기술에 대한 이해 부족으로 어려운 점도 참 많았습니다.
키보드 보안 프로그램들이 OS 커널레벨에서 다른 상용프로그램에 비해 더 깊숙한 곳을 컨트롤 하는 제품이다 보니 여러가지 Hardware 적 software 적 충돌도 많은데, 적용되는 곳이 '돈' 과 밀접한 곳이다 보니 장애가 생기면 무척이나 난감한 상황이 발생하게 됩니다.

생각하면 생각할 수록 별의별 일들이 많았네요.. 끝이 없을 것 같아 이만 사설은 접어야 겠습니다. ^^

* 키보드 타입

키보드 보안 제품은 말 그대로 키보드에서 입력되는 데이타를 보호하는 것입니다.
여기서 구분에 사용되는 키보드 타입이란 키보드 데이타가 전달되는 포트에 따른 구분입니다.
USB 타입과 PS/2 타입, 무선키보드로 나눌수 있습니다.
또 무선키보드는 통신방식에 따라 블루투스와
IrDA, RF 등으로 구분할 수 있습니다.
화상키보드는 뭘까요? 화상키보드는 소프트웨어 어플리케이션 키보드 이므로 여기서는 논외로 합니다.
키보드 보안 프로그램은 각각의 타입에 따라서 보호하는 드라이버를 별도로 개발해야 합니다.
따라서 PS/2, USB, 무선키보드 드라이버를 개발하는 것이 키보드 업체들이 서비스 해야 할 영역이지요.
보통 PS/2, USB 는 표준에 명확하므로 대부분의 업체들은 이들 키보드사용을 지원합니다.
무선키보드의 경우에는 USB 동글이를 사용하는 경우 USB 포트로 데이타로 변환되어 OS 로 전달되므로
이러한 경우 USB 키보드로 간주됩니다.
그러나 적외선키보드나 블루투스 키보드 등의 경우는 별도의 포트를 사용하므로 별도의 드라이버를 지원해야 합니다. 요즘은 블루투스 키보드가 많이 사용되고 있어서 이를 지원하는 업체들도 늘어나고 있습니다.
본 포스트에서는 PS/2, USB 형 키보드 보안에 대해서만 기술합니다.


* 키보드 입력 처리 절차 취약점

Kernel Level

Port Monitoring (PS/2 타입 키보드)
사용자의 키 입력 후 키보드 Port 에 쓰여진 입력 값은 일정 시간 메인보드의 키보드 Port 에 남아있게 됩니다. 악성프로그램이 메인보드의 키보드 Port 에 남아있는 키보드 데이터를 읽어갈 수 있으며, 이를 Port Scanning/Monitoring 이라 합니다.

IDT Hooking
(PS/2 타입 키보드)
IDT (Interrupt Descriptor Table) 은 인터럽트를 처리하는 루틴인 ISR (Interrupt Service Routine) 의 주소를 저장하고 있으며, 악성 프로그램은 사용자의 키보드 인터럽트가 발생했을 때 입력을 가로채기 위해 IDT 에 저장된 ISR 의 주소를 자신의 ISR 의 주소로 변경할 수 있습니다.

USB Bus Hooking (USB 타입 키보드)
USB Driver Stack 상에 존재하여 사용자 키보드 입력 값을 모니터링 할 수 있습니다.

Filter(Client) Driver Hooking/Filtering (PS/2, USB 타입 키보드)
Windows OS 커널은 키보드 입력 데이터를 제어하기 위해 Filter Driver (Client Driver) 의 형태로 사용자의 키 입력을 얻을 수 있도록 지원합니다. 악성프로그램은 일반적인 키보드 Filter Driver Client Driver 의 하단으로 설치되어 사용자의 입력값을 획득 할 수 있습니다.

User Level

Message Hooking

악성 프로그램이 윈도우에서 사용하는 메시지 큐 (System Message Queue, Thread Message Queue) hooking 하여 사용자의 키 입력 값을 획득 할 수 있습니다.

 
SubClassing

각 윈도우 어플리케이션은 메시지 처리를 위해서 Windows Procedure 를 가지고 있다. 악성 프로그램은 이 Windows Procedure 를 재 설정 하는 방법으로 사용자의 키보드 입력 값을 획득 할 수 있습니다.


BHO Hooking

BHO (Browser Helper Object) 는 브라우저 구동 시 동시에 로딩되어 브라우저에서 일어나는 일을 감시할 수 있도록 IE 가 지원하는 기능을 사용하는 모듈이며, 악성 프로그램은 BHO 의 형태로 IE 에서 사용자의 키보드 입력 값을 획득 할 수 있습니다.


API Hooking
실행중인 프로세스에 Injection 한 후 키보드 입력 처리에 관련된 windows API, , DrawText, DrawTextEx, ExtTextOut 등의 함수를 Hooking 하여 입/출력 파라미터를 모니터링 하는 방식으로 사용자의 키보드 입력 값을 획득 할 수 있습니다.

Memory Scan

실행중인 프로세스의 메모리를 Scan 하여 메모리 상에 저장된 사용자의 키보드 입력 값을 획득 할 수 있습니다.

Screen Capture
사용자의 입력 값이 Text 인 경우 화면에 입력된 값을 screen capture 기능을 통해서 획득할 수 있습니다.


* PS/2 키 입력 처리 방법 및 보안 취약성

[PS/2 포트를 통한 키 입력 흐름]


사용자 삽입 이미지

1.     PS/2 Port : PS/2 방식 키보드로부터 키보드 입력 값 접수

2.     8042 Register : 키보드 입력 값 임시 저장 버퍼

3.     IDT (Interrupt Descriptor Table) : 시스템 인터럽트 발생시에 인터럽트 핸들러와 연결되는 테이블 (키보드 입력 시에 ISR 호출)

4.     ISR (Interrupt Service Routine) : 인터럽트 처리 핸들러 (키보드 입력 시 입력 값을 처리하기 위해 호출됨)

5.     Keyboard Filter Driver : 키보드 입력 값 Filtering (optional)

6.     Keyboard Class Driver : PS/2, USB 공통으로 사용하는 OS 기본 최 상단 드라이버

7.     System Message Queue : 윈도우 OS 의 메시지 처리과정

8.     Thread Message Queue : 윈도우 OS 의 메시지 처리과정

9.     Application Program (IE ) : 최종적으로 키보드 입력 값 접수

 

[보안위협]

1.     PS/2 Port 를 감시하여 사용자 키 입력 획득

2.     IDT hooking 하여 사용자 키 입력 획득

3.     Keyboard Filter Driver 를 삽입하여 사용자 키 입력 획득

4.     System Message Queue Hooking 하여 사용자 키 입력 획득

5.     Thread Message Queue Hooking 하여 사용자 키 입력 획득

6.     SubClassing (Application Message 처리루틴 변경) 을 통해 사용자 키 입력 획득

7.     Application API Hooking 을 통한 사용자 키 입력 획득

8.     BHO(Browser Helper Object) 를 통한 사용자 키 입력 획득

9.     Screen Capture 를 통한 사용자 키 입력 획득

10.   사회공학적 방법을 통한 사용자 키 입력 획득


[키보드 보안 프로그램 구현방법]

A 업체에서 구현하는 방식입니다.
보호모드로 들어가면 커널구간에서 Random 키를 발생시켜서 사용자 키 입력과 섞는 방법을 사용합니다.
커널구간에 KeyLogger 가 설치되어 사용자의 입력값을 가로채어도 유효한 데이타를 추출할 수 없도록 하는 기법입니다. 커널레벨에서 드라이버가 보안 프로그램으로 직접 사용자의 입력값을 전달하므로
유저구간에서 설치된 KeyLogger 로부터 데이타를 보호합니다.

사용자 삽입 이미지

다른 업체들의 경우는 대부분 다음과 같은 방법으로 키보드 보안을 구현하고 있습니다.
즉, IDT hooking 을 통한 ISR 의 교체 등을 사용하고 있습니다. 약간씩 구현상 상이한 점이 있지만 대부분 컨셉은 비슷합니다
.

사용자 삽입 이미지

위와 같은 방식 외에 Keyboard 필터 드라이버를 설치하여 사용자의 키 입력값을 보호하는 경우 등이 있을 수 있지만, 보안성이 낮아서 국내 서비스 프로그램 중에는 그러한 방식으로 사용중인 곳은 없습니다.

PS/2 키보드 보안 프로그램들이 위와 같은 기술로 보안을 제공하고 있지만
위의 [보안위협] 에서 설명한 것들 중 다음의 공격에는 보안을 제공하는데 한계가 있습니다.

1.     PS/2 Port
를 감시하여 사용자 키 입력 획득 --> 보호
2.     IDT
hooking 하여 사용자 키 입력 획득 --> 보호
3.     Keyboard Filter Driver 를 삽입하여 사용자 키 입력 획득 --> 보호
4.     System Message Queue Hooking 하여 사용자 키 입력 획득 --> 보호
5.     Thread Message Queue
Hooking 하여 사용자 키 입력 획득 --> 보호
6.     SubClassing (Application Message
처리루틴 변경) 을 통해 사용자 키 입력 획득 --> 보호
7.     Application API Hooking
을 통한 사용자 키 입력 획득 --> 보호
8.     BHO(Browser Helper Object)
를 통한 사용자 키 입력 획득 --> 보호못함
9.     Screen Capture
를 통한 사용자 키 입력 획득 --> 보호못함
10.  
사회공학적 방법을 통한 사용자 키 입력 획득 --> 보호못함

왜일까요?
BHO 는 브라우저에서 DOM 을 읽을 수 있습니다. 키보드 보안 프로그램이 아무리 열심히 데이타를 보호해서 브라우저에 사용자 키 값을 전달하는 순간, BHO 형태의 keylogger 에게 노출될 수 밖에 없는 것이죠.
이를 막을 수 있는 방법은 없을까요? 키보드 보안 프로그램 자체로서는 DOM 에 노출되는 시간을 최소화 시킬 수는 있어도 Form 이 Submit 되기 직전에 사용자 입력값을 가져가는 것을 막기란 불가능 한 일입니다.
그래서 2005년 금융감독원은 BHO 취약점을 해결하라는 지침을 내렸지요.
그런데 어떻게 해결할 수 있을 까요? 그래서 국내 금융권에서 E2E 보안 이니 확대 E2E 보안이니 하는 것들이 생겼습니다. 이것은 키보드보안 프로그램과 PKI Client 프로그램을 연동해서 사용자 키보드 데이타를 서버까지 직접 전달한다는 개념입니다. 이렇게 n 개의 키보드 보안 업체와 m 개의 PKI 업체가 서로 업체별 프로토콜로 서로 E2E 연동이란 것을 하다보니, 그야말로 이때부터 본격적인 스파게티가 되 버립니다.. -_-;


* USB 키 입력 처리 방법 및 보안 취약성

[USB 포트를 통한 키 입력 흐름]


사용자 삽입 이미지

       1.    
USB Bus : USB 방식 키보드로부터 키보드 입력 신호 전달

2.     PCI Bus Driver

3.     Host Controller Driver : USB Driver Stack 의 가장 최하위 단. Port driver miniport 드라이버()로 구성된다. 시스템이 USB Device (H/W) 를 발견하면 적당한 miniport 드라이버를 로드한다. 로드된 miniport 드라이버는 port driver 를 로드하며 port 드라이버는 H/W independent host controller driver 역할을 수행한다. USB Transaction, Power management bus enumeration을 수행한다.

4.     USB Hub Driver : Host Controller Driver root hub enumerate 하게 되면 로드된다. USB Bus Driver 라고도 불리우며, 시스템의 각각의 허브에 대한 Device Driver 이다.

5.     USB Generic Driver : 각각의 vendor 나 사용자 가 정의한 Client Driver 들은 Hub Driver 상단에 위치할 수 있으며, 특정장치의 특성에 맞는 Client 드라이버가 사용될 수 있다. 만약 특정 장치에 대한 것이 아닌 일반적인 Client Driver 를 작성하여 사용할 때 USB Generic Driver 상단에 Client Driver 가 설치될 수 있으며, 이 경우 사용되는 공통 parent 드라이버이다.

6.     HID USB Driver 

7.     Keyboard HID Class Driver :

8.     Keyboard Class Driver : PS/2, USB 공통으로 사용하는 OS 기본 최 상단 드라이버

9.     System Message Queue : 윈도우 OS 의 메시지 처리과정

10.   Thread Message Queue : 윈도우 OS 의 메시지 처리과정

11.  Application Program (IE ) : 최종적으로 키보드 입력 값 접수


 

[보안위협]

      1. USB Bus Driver hooking 하여 사용자 키 입력 획득
2. USB Hub Driver hooking 하여 사용자 키 입력 획득
3. USB Generic Driver hooking/Filtering 하여 사용자 키 입력 획득
4. HID USB Driver hooking/Filtering 하여 사용자 키 입력 획득
5. Keyboard HID Class Driver hooking/Filtering 하여 사용자 키 입력 획득
6. Keyboard Class Driver hooking/Filtering 하여 사용자 키 입력 획득
7. System Message Queue 를 Hooking 하여 사용자 키 입력 획득
8. Thread Message Queue 를 Hooking 하여 사용자 키 입력 획득
9. SubClassing (Application Message 처리루틴 변경) 을 통해 사용자 키 입력 획득
10. Application API Hooking 을 통한 사용자 키 입력 획득
11. BHO(Browser Helper Object) 를 통한 사용자 키 입력 획득
12. Screen Capture 를 통한 사용자 키 입력 획득
13. 사회공학적 방법을 통한 사용자 키 입력 획득


[키보드 보안 프로그램 구현방법]

2006년 정도까지만 하더라도 국내의 대부분의 업체들은 업체별로 약간의 차이가 있겠으나 대부분 USB Generic Driver 레벨에서의 필터링이나 후킹 방식으로 사용자의 키 입력을 받아서 안전한 경로를 통해 어플리케이션에 전달하는 방식으로 키 입력을 보호하였습니다. 이러한 방식은 OS 가 제공하는 API 를 통한 구현으로 안전하게 구현할 수 있는 방식이었으며 동작에 안정성을 어느정도 제공받을 수 있었지요.

그러나 고려대 학생들에 의해서 USB 버스 하운드 였던가요? USB 드라이버 개발자 들 사이에서 사용하는 USB 버스 모니터링 툴이 있습니다. 이 툴을 이용하면 사용자의 키 입력값이 보인다는 공공연한 사실이 기사화 되었고, 금감원으로 부터 키보드 보안 프로그램을 적용한 국내 금융권에도 이 보안 취약성을 패치하라는 지령이 떨어집니다.

USB 드라이버를 개발한 보안 업체들은 고대 학생들이 굳이 이야기 해 주지 않아도 다들 알고 있는 사실이었을 것입니다. 그럼 키보드 프로그램 개발 업체들이 왜 이 취약성을 허용하고 있었던 것일까요?
키보드 보안분야에서 일했던 사람으로 변명을 좀 하자면, USB 버스는 PS/2 포트와는 다르게 키보드 전용 장치가 아니기 때문에, USB 버스를 후킹한 후 입력데이타 들 중 키보드 장치를 정확히 분간해 내고, OS 레벨에서 처리해 주던 여러가지 처리들을 직접 해야 하는 상당히 까다로운 작업이 요구되었기 때문입니다.
단지 어렵기 때문이 아니라, USB 보안 수준을 내릴 경우 국내 금융권/포탈 등에 서비스 되고 있고, 아마 천만 이상의 사용자들이 매일 사용하는 키보드 보안 프로그램이 별별 USB 장치들과 충돌을 일으키지 않을까(오동작) 걱정하지 않을 수 없었습니다. 키보드 보안 프로그램은 보안 프로그램이면서 금융권을 사용하기 위해 반드시! 설치되어야 하는 상용 프로그램이었기 때문이죠!!
보안성과 가용성 사이의 저울질은 상용 보안 프로그램을 만드는 업체라면 항상 고민하게 되는 문제입니다.

물론 덕분에(?) 두려워서 적용하지 못했던 기술을 '지침' 입니다.. 하고 필드에 적용해 볼 수 있는 명분이 생겼죠. 결국 지금은 몇몇 업체들은 아래와 같이 Bus Driver 레벨에서 보안을 제공하고 있습니다.

사용자 삽입 이미지

1. USB Bus Driver hooking 하여 사용자 키 입력 획득 --> 보호
2. USB Hub Driver hooking 하여 사용자 키 입력 획득 --> 보호
3. USB Generic Driver hooking/Filtering 하여 사용자 키 입력 획득 --> 보호
4. HID USB Driver hooking/Filtering 하여 사용자 키 입력 획득 --> 보호
5. Keyboard HID Class Driver hooking/Filtering 하여 사용자 키 입력 획득 --> 보호
6. Keyboard Class Driver hooking/Filtering 하여 사용자 키 입력 획득 --> 보호
7. System Message Queue 를 Hooking 하여 사용자 키 입력 획득
--> 보호
8. Thread Message Queue 를 Hooking 하여 사용자 키 입력 획득 --> 보호
9. SubClassing (Application Message 처리루틴 변경) 을 통해 사용자 키 입력 획득 --> 보호
10. Application API Hooking 을 통한 사용자 키 입력 획득 --> 보호
11. BHO(Browser Helper Object) 를 통한 사용자 키 입력 획득 --> 보호못함
12. Screen Capture 를 통한 사용자 키 입력 획득--> 보호못함
13. 사회공학적 방법을 통한 사용자 키 입력 획득 --> 보호못함


* User Level 키 입력 처리 방법 및 보안 취약성

위에서 설명한 바와 같이 Message Queue 나 Subclassing 에 대한 방어는 커널레벨에서 유저레벨의 어플리케이션에 직접 사용자의 입력값을 전달하는 것으로 보호를 진행하고 있습니다.
그러나 앞에서 설명한 BHO 를 통한 사용자 키 입력 획득은 키보드 보안 프로그램에서 처리할 수 있는 영역이 아닙니다. 즉, 키보드 보안 프로그램이 보호하는 영역이란 사용자의 키보드 입력부터 특정 어플리케이션(보통 브라우저가 많겠죠) 에 키 입력 값을 전달하는 그 순간까지입니다.
어플리케이션에서 키 입력 값을 노출하게 되면 도로아미타불 이란 말이죠 ^^

* 마치며..

지금까지는 매우 원론적으로 키보드 보안 프로그램의 동작방식을 설명했습니다.
그러나 위에 보호한다고 하는 영역이 100% 안전한가? 라고 묻는다면 솔직히 '그렇지는 않다' 고 할 수 밖에 없습니다. 예를 들면 키로거 들이라고 해서 위와 같이 구현을 못할까요?
키로거들도 할 수 있습니다.. 그래서 키보드 보안 프로그램들에서는 곳곳에서 타 프로그램에 의해서 중요한 자원이 선점된 것들이 있는지 확인하고 복구하는 기능도 포함되어 있습니다.

국내의 대부분의 키보드 보안 프로그램들은 그들간의 과열 경쟁으로 인해서 이러한 선점과 복구 등에 대해서는 대응하는 최고의 기술을 가지고 있다고 생각합니다.

그럼 키입력을 가로채는 키로거들은 주로 어떤 형태를 가지고 있을까요?
정확한 통계는 알 수 없습니다만, 안철수연구소의 ASEC 의 키로거 수집 현황을 보면 드라이버 후킹/필터링 방식의 키로거보다는 phishing 등의 방식을 이용한 스파이웨어 형태가 더 많은 것 같습니다.

ASP 형 키보드 보안 프로그램이라는 것들은 어플리케이션(브라우저)가 프로그램을 구동시킨 후 부터 그 역할을 수행하게 되는데, phishing 사이트에서 사용자의 키 입력을 가로채는 것에 대한 대안은 아니겠지요 -_-;
그럼 PC 상주형 키보드 보안 프로그램을 사용하면 되는 건가요?
PC 상주형 키보드 보안 프로그램들은 최종적으로 데이타를 전달해야 할 어플리케이션이 정해져 있지 않기 때문에 프로그램들이 키 입력 값을 사용 할 수 있도록 특정 구간에서 특히 유저레벨에서 사용자의 키 입력 흐름을 정상 궤도로 흘려 보내야 할 것 입니다. 취약성이 발생하겠죠.
그럼 메모리 해킹은 어떨까요?
브라우저의 메모리를 모니터링해서 사용자 키 입력 값이 메모리 상에서 떠 다니는 것을 방지할 수 있을까요?
키보드 보안 프로그램과 E2E 연동된 PKI 프로그램에서는 내부적으로 데이타를 암호화 해서 저장하고 있습니다만, 그것도 언젠가 풀릴 때를 노려서 값을 획득하는 프로그램이 있다면요? 즉, 100% 신뢰된 보안이란 존재하지 않는다는 것입니다.

그럼 키보드보안 프로그램이 필요없는 것인가요?
키보드 보안 프로그램이 여러가지 한계를 가지고 있어도 키보드 보안 프로그램이 적용된 사이트가 있다면 그렇지 않은 사이트에 비해서 더 안전한 것은 확실합니다. 보안이란 단계적으로 적용되어야 하는 것이며, 하나의 어플리케이션이나 어플라이언스 장비들로 커버할 수 있는 부분이 아닙니다.

사용자 개인정보가 '돈' 으로 직결되는 시대이다 보니, 정말이지 개인정보보호란 중요한 분야입니다.
PC 단에서 개인정보보호를 위한 방안으로 키보드 보안 프로그램이 필요한 것은 사실이지만, 이젠 PC 단에서의 개인정보 보호도 키보드 보안 프로그램에 의존하는 것이 아니라 패러다임 쉬프트가 일어날 때가 되지 않았나 싶습니다..

Posted by skensita