약 1년간 진행되었던 프로젝트는 1차와 2차로 나누어 진행되었는데, 프로젝트 주제는 "알려지지 않은 또는 보고되지 않은 악성코드를 탐지하기 위한 기술들이 적용된 프로그램 개발"이었습니다.
해당 프로젝트가 진행되었던 계기는 당시 중국 법인 기술 지원 담당자의 요청에서부터 시작되었습니다. 당시 기술 지원 담당자가 중국의 보안 업체 중 지앙민(JiangMin) 보안 제품에는 보고 되지 않은 악성코드를 탐지 할 수 있는 기능이 있어, 감염이 의심되는 PC에서 악성코드로 의심되는 파일들을 자동으로 수집하는데 본사에서도 이러한 기능을 검토해달라는 요청이었습니다.
당시 연구소장님과 함께 회의에 참석했던 저는 그 자리에서 연구소장님으로부터 바로 프로젝트를 진행해보라는 말씀을 듣고 프로젝트 PM으로 약 1년가까이 진행하게 되었습니다. 사실 어떻게 악성코드로 의심되는 파일들을 자동 수집해야 할까로 많은 고민이 있었습니다. 그래서 당시 처음 시작한 것이 휴리스틱(Heuristic) 및 제너릭(Generic) 탐지 기법과 관련된 해외 논문들부터 행위 기반(Behavior Detection) 탐지 기법 등 다양한 악성코드 탐지 기법 관련 논문들과 서적들을 찾아보며 이런 저런 아이디어들로 약 2달 정도를 보내게 되었습니다.
재미있는 일화로 당시 휴일마다 도서관에서 책과 논문들을 읽으며 연습장에 떠오르는 아이디어들을 정리해 가면서 계속 생각을 하고 있던 시기였습니다. 그 때 저도 모르게 아이디어들에 대한 고민이 컸던지 꿈속에서 마저 제가 연습장에다 알고리즘들을 그려보고 있더군요....
약 2달 정도 생각을 하다 몇 가지 알고리즘들을 생각해내고 프로토타입(Prototype)을 만들어 테스트하기로 연구소장님께 보고드렸고 인턴들과 함께 개발하였습니다. 1차 프로토타입의 결과는 중상 이상의 수준으로 나쁘지 않은 결과를 보였습니다. 2차 프로토타입에서는 1차 결과에서는 발견되었던 문제점들과 새로운 알고리즘을 추가하여 다시 개발하여 그 결과 역시 괜찮은 수준으로 연구소장님께 보고드리게 되었습니다.
그래서 약 1년간 연구 및 개발하였던 그 알고리즘과 기술은 최종적으로 지금도 많은 고객들의 악성코드 감염이 의심되는 시스템을 분석하는데 쓰이는 안레포트(AhnReport)에 의심 파일 수집 기능으로 반영되었습니다.
그래서 나름 많은 고민과 생각들을 하는 과정에서 정리된 결과물이라 이제까지 썼던 원고들 중에서 가장 많이 기억나는 원고들 중 하나입니다.
+--------------------
2006년은 컴퓨터 바이러스가 제작 된지 20주년을 기념하는 한 해였다. 이 20년이라는 긴 세월 속에서 컴퓨터 바이러스는 파일 감염을 목적으로 하는 바이러스(Virus)로부터 네트워크를 통한 급속한 확산을 시도하는 웜(Worm) 그리고 데이터 유출을 위한 트로이목마(Trojan Horse)에 이르기까지 다양한 모습으로 발전하였다. 이러한 악성 코드의 위협은 해가 갈수록 증가 추세를 이루고 있으며 기술적인 면에서도 더욱더 위험성을 더해 가고 있어 컴퓨터 사용자들을 불안하게 만들고 있는 것이 사실이다. 그러나 이렇게 증가하는 악성 코드의 위협 에 맞서는 안티 바이러스(Anti-Virus) 업체 역시 새로운 악성 코드의 위협들로부터 컴퓨터 시스템을 보호하기 위해 다양한 대응 방안들을 활발하게 연구하고 있다. 이러한 다양한 대응 방안들의 기본 전제가 바로 "급속하게 확산되는 알려지지 않은 새로운 악성 코드에 어떻게 대응할 것인가?"라는 점이다. 이 명제는 결국 새로운 악성 코드를 어떻게 효과적으로 탐지할 것인가의 문제로 볼 수 있다. 이러한 문제를 해결하기 위해 안티 바이러스(Anti-Virus) 업체의 알려지지 않은 악성 코드 위협에 대응하기 위한 다양한 안티 바이러스(Anti-Virus) 탐지 기법들과 그 탐지 기법들의 특징들에 대해서 알아 보도록 하자.
1. 악성 코드의 증가와 조기 대응의 필요성
본 글의 서두에서 악성 코드는 해가 갈수록 증가하고 있다고 이야기 하였다. 이러한 사실은 아래 [그림 1]의 안철수연구소 시큐리티대응센터(ASEC, AhnLab Security Emergency response Center)에서 발행하는 ASEC Annual Report 2005 자료를 참고하면 더욱 명확하게 이해가 될 것이다.
1988년부터 2005년도까지 년도 별 악성 코드 피해신고 건수를 나타낸 [그림 1]에서와 같이 악성 코드의 수치적인 증가는 단순하게 악성 코드 형태의 다양화를 넘어서 악성 코드에 대한 안티 바이러스(Anti-Virus) 업체의 신속한 대응 자체가 어려울 정도로 심각한 문제를 유발하고 있다. 신속한 대응이 어려워지게 된다는 것은 결국 악성 코드로부터 피해를 입는 컴퓨터 시스템의 수치가 증가하는 문제로 볼 수 있다.
[그림 2]가 바로 신속한 대응과 컴퓨터 시스템의 피해와 상관관계를 나타낸 그래프이다. 이 그래프에서와 같이 어느 단계에서 대응이 가능해지냐에 따라서 악성 코드의 피해가 판이하게 달라지게 되는 것을 알 수 있다. 일반적으로 악성 코드 대응에서 가장 이상적인 형태의 대응을 말하는 <1>에서는 운영체제에서 발견된 취약점을 사전에 분석 한 후 조치를 취하여 실제 해당 취약점을 공격하는 악성 코드가 발견되더라도 해당 악성 코드에 의한 피해가 발생하지 않도록 조치를 취하는 단계이다
[그림 2] 단계별 악성 코드의 확산과 시간의 상관 관계
그러나 아무리 빠르게 악성 코드 샘플을 확보하고 스캐닝 엔진(Scanning Engine)을 제작하여 배포한다고 하더라도 스캐닝 엔진(Scanning Engine)이 제작되는 그 1분, 1초의 시간 사이에서도 악성 코드에 감염되어 피해를 입는 컴퓨터 시스템이 발생하기 마련이다. 그러므로 안티 바이러스(Anti-Virus) 업체에서는 알려지지 않은 새로운 악성 코드를 탐지할 수 있는 다양한 탐지 기법들을 연구하여 조금 더 효율적이고 효과적인 신속한 대응이 가능하도록 하고 있다.
2. 파일 기반의 탐지 기법 (File Base Detection Tech)
현재까지 알려진 안티 바이러스(Anti-Virus) 소프트웨어 대부분이 파일 기반(File Base)의 진단법을 사용하고 있다. 이는 대부분의 악성 코드가 특정 운영체제에서 실행되기 위해서는 해당 운영체제에서 실행이 가능한 특정한 파일 형태로 되어 있다는 점에서 기인한 것이다. 그러므로 악성 코드가 윈도우 시스템(Windows System)에서 실행되기 위해서는 윈도우 시스템에서 실행 가능한 파일 포맷인 PE(Portable Executable) 형식을 가지고 있어야 된다는 것이다.
[그림 3] PE(Portable Executable) 형식의 악성 코드 파일
이러한 PE(Portable Executable) 형식의 악성 코드를 진단하기 위해서는 안티 바이러스(Anti-Virus) 소프트웨어 역시 이러한 파일 형식을 인식하고 악성 코드로 판단을 내릴 수 있는 특정 형식의 시그니처(Signature)를 가지고 있어야 된다. 이러한 진단법이 대부분의 안티 바이러스(Anti-Virus) 소프트웨어가 사용하는 시그니처 기반(Signature Base) 또는 스트링(String - 여기서 말하는 스트링이란 일반적인 문자열이 아닌 파일의 헥사코드(Hex Code)를 의미하는 것이다.) 검사 방식이라고 이야기하는 진단법이다. 이러한 시그니처 기반(Signature Base)의 진단법은 악성 코드로 분류된 파일의 특정 부분 또는 고유한 부분을 검사의 대상으로 삼으므로 오탐(False Positive)과 미탐(False Negative)을 최소화하는 정확한 진단이 가능하다는 것과 파일 검사 시에 파일들의 특징적인 부분들만 비교 함으로 빠른 스캐닝(Scanning)을 장점으로 들 수 있다.
그러나 이러한 시그니처 기반(Signature Base) 진단법은 악성 코드의 파일 자체가 몇 백 바이트(Byte)만 바뀌어도 진단이 되지 않는 미탐(False Negative)이 발생함으로 파일이 조금만 변경된 새로운 변형에 대해서는 대응을 할 수가 없게 된다. 그리고 기존에 알려진 악성 코드에 대해서만 대응을 할 수 있으므로 새로운 형태의 알려지지 않은 악성 코드에 대해서는 대응을 할 수 없다는 단점을 가지고 있다.
1) 휴리스틱 탐지 기법 (Heuristic Detection Tech)
이러한 시그니처 기반(Signature Base)의 진단법이 가지고 있는 한계를 극복하고자 개발한 탐지 기법 중 하나가 휴리스틱 탐지(Heuristic Detection) 기법이다. 휴리스틱 탐지(Heuristic Detection) 기법은 일반적인 악성 코드가 가지고 있는 특정 폴더에 파일 쓰기와 특정 레지스트리 부분에 키 생성과 같은 명령어(Instruction)들을 스캐닝 엔진(Scanning Engine)에서 시그니처(Signature)화하여 파일을 검사할 때 이를 사용한다. 그래서 검사 대상 파일이 휴리스틱 시그니처(Heuristic Signature - 이 것을 부스터(Booster)라고도 한다.)와 비교를 통하여 일반적으로 알려진 악성 코드와 얼마나 높은 유사도를 가지고 있는지를 판단하여 알려지지 않은 새로운 악성 코드를 탐지하는 기법이다.
이러한 휴리스틱 탐지(Heuristic Detection) 기법은 검사 대상이 되는 파일에 대해서 휴리스틱(Heuristic) 검사 시에 스캐닝 엔진(Scanning Engine)이 어떠한 형태를 취하는가 에 따라서 아래와 같이 크게 2가지 형태로 나누어서 볼 수 있다.
- 동적 휴리스틱 탐지 기법 (Dynamic Heuristic Detection Tech)
동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 검사 대상이 되는 파일을 가상화된 영역 또는 운영체제와 분리된 특정 공간에서 파일 실행(File Execution)을 통해 수집한 다양한 정보들을 휴리스틱 시그니처(Heuristic Signature)와 비교를 통하여 검사를 수행하는 기법이다. 즉 검사 대상이 되는 파일이 어떠한 형식으로든 실행이 되어야 하며 이러한 점으로 인해 런 타임 휴리스틱 탐지 (Run-Time Heuristic Detection) 기법이라고도 불리고 있다. 이러한 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 이 후에 다룰 에뮬레이터(Emulator)과 샌드박스(Sandbox)에서 조금 더 자세하게 알아 보도록 하자.
- 정적 휴리스틱 탐지 기법 (Static Heuristic Detection Tech)
정적 휴리스틱 탐지(Static Heuristic Detection) 기법은 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과는 반대로 파일에 대해서 어떠한 형식의 파일 실행(File Execution) 없이 파일 자체를 그대로 스캐닝 엔진(Scanning Engine)에서 읽어 들여 휴리스틱 시그니처(Heuristic Signature)와 비교를 수행하는 탐지 기법이다.
[그림 4] 정적 휴리스틱(Static Heuristic)과 동적 휴리스틱(Dynamic Heuristic)
이 외에도 네거티브 휴리스틱(Negative Heuristic - 이 것을 스토퍼(Stopper)라고도 한다.)탐지 기법도 있다. 이는 이제까지 기술한 휴리스틱 탐지(Heuristic Detection) 기법과는 반대로 악성 코드에서 전형 사용하지 않은 윈도우 팝업 창 생성과 같은 명령어(Instruction)들이 존재 할 경우에는 악성 코드로 판단하지 않는 기법이다. 즉, 휴리스틱 시그니처(Heuristic Signature)와 동일한 명령어들이 존재하지 않는 부정의 경우에만 악성 코드로 판단한다.
이러한 형태들의 휴리스틱 탐지(Heuristic Detection) 기법은 기존에 알려진 악성 코드도 탐지가 가능하며 알려지지 않은 새로운 악성 코드 역시 탐지가 가능하다는 점에서 매력적인 탐지기법이라고 할 수 있다. 그러나 이 탐지 기법은 정상 파일을 악성 코드라고 판단하게 되는 오탐(False Positive)의 발생이 가장 큰 단점으로 작용한다. 특히나 파일을 삭제하고 치료하는 안티 바이러스(Anti-Virus) 소프트웨어의 특성상 오탐(False Positive)율이 높게 된다면 컴퓨터 시스템 자체에 큰 문제를 유발할 수 있게 됨으로 이는 치명적인 문제점이라고 볼 수 있다.
2) 제너릭 탐지 기법 (Generic Detection Tech)
앞서 설명한 휴리스틱 탐지(Heuristic Detection) 기법 외에도 알려지지 않은 악성 코드를 탐지하기 위한 기법 중에는 제너릭 탐지(Generic Detection) 기법이라는 것이 있다. 이 탐지 기법은 유사한 형태의 악성 코드 집합을 탐지하기 위해 해당 집합을 이루는 악성 코드 파일들의 공통된 코드 영역(Code Section)을 진단하도록 한다. 그러므로 소스 코드(Source Code)상에서 사용자 코드(User Code)의 변화가 없거나 약간의 수정만 가하여 컴파일(Compile)만 새롭게 하여 생성한 새로운 악성 코드 변형들에 대해 탐지가 가능함으로 유사한 형태의 악성 코드 변형들이 지속적으로 제작되더라도 시그니처(Signature) 업데이트 없이 탐지가 가능하다는 장점이 있다.
이러한 제너릭 탐지(Generic Detection) 기법에서는 일반적으로 파일에 대한 OPcode(Operation Code) 명령어 비교 방식이 많이 사용되고 있다. 이 OPcode(Operation Code) 명령어 비교 방식에는 크게 와일드카드 비교(Wildcard Matching - Don't Care 비교라고도 한다)와 미스매칭(Mismatching) 방식으로 나누어진다. 먼저 와일드카드 비교(Wildcard Matching)는 유사한 형태의 악성 코드 변형들의 특정 코드 영역(Code Section)에서 사용되는 OPcode(Operation Code) 명령들이 조금씩만 다르고 동일할 경우 해당 다른 OPcode(Operation Code) 명령어 부분에 와일드카드를 적용하여 다른 OPcode(Operation Code) 명령어가 사용되어도 이를 무시하겠다는 것이다.
[그림 5] 메모장(Notepad.exe) 프로그램의 OPcode(Operation Code) 명령어들
[그림 5]를 예로 들어 메모장 프로그램을 원본 악성 코드라고 가정을 한다면 이 원본 악성 코드의 일부 OPcode(Operation Code) 명령어들은 [그림 5]의 붉은색 박스 영역의 순서대로 진행된다. 이렇게 PUSH, PUSH, PUSH, PUSH 순서로 진행되는 OPcode(Operation Code) 명령어들이 다른 악성 코드 변형들에서는 PUSH, PUSH, PUSH, MOV가 사용된다면 마지막 MOV 부분을 와일드카드(Wildcard)로 적용하여 마지막 4번째 OPcode(Operation Code) 명령은 어떠한 것이 사용되더라도 이에 구애 받지 않겠다는 것이다. 이렇게 적용하게 되면 원본 악성 코드와 변형 악성 코드의 전체 OPcode(Operation Code) 명령어 진행 순서는 유사한데 일부가 조금 틀리더라도 모두 진단하게 되는 효과를 구현할 수가 있다. 그러나 미스매칭(Mismatching) 방식은 와일드카드 비교(Wildcard Matching)와는 반대로 MMX(Multi Media eXtension) 명령어 또는 FPU(Floating Point Unit) 명령어와 같이 악성 코드에서 잘 사용되지 않는 명령어들이 [그림 5]의 해당 붉은색 박스영역과 같이 특정 부분에 사용 될 경우, 해당 파일을 악성 코드 변형으로 판단하지 않겠다는 것이다. 이런 미스매칭(Mismatching) 방식은 앞서 설명한 네거티브 휴리스틱(Negative Heuristic) 탐지 기법과 기본적인 개념은 동일하다고 볼 수 있다.
그러나 이러한 제너릭 탐지(Generic Detection) 기법은 악성 코드의 공통된 코드 영역을 진단함으로 새로운 악성 코드 변형들이 제작되더라도 탐지가 가능하다는 장점이 있지만 새로운 악성 코드 변형들이 완전히 새로운 OPcode(Operation Code) 명령어 순서로 진행된다던가 아니면 안티 디버깅(Anti-Debugging)과 암호화(Encryption) 등과 같이 실행 파일 보호 기법을 통해 OPcode(Operation Code) 명령어의 진행 순서를 뒤섞어 놓게 된다면 스캐닝 엔진(Scanning Engine)에서는 이를 탐지하지 못하게 되는 문제가 발생할 수가 있다.
이상으로 파일을 기반으로 알려지지 않은 악성 코드 탐지 기법들에 대해서 알아 보았다. 다음으로는 파일 실행을 통해서 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법 설명 시에 잠시 언급한 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아보도록 하자.
3. 에뮬레이터(Emulator)과 샌드박스(Sandbox)
앞 장에서 설명한 새로운 악성 코드 탐지기법들은 모두 실행 파일(Executable File) 자체를 대상으로 한 탐지 기법들이다. 그러나 이번 장에서 설명하는 에뮬레이터(Emulator)와 샌드박스(Sandbox)는 모두 실행 파일(Executable File) 자체에 관한 탐지 기법이 아니라 해당 실행 파일(Executable File)의 실행을 통해 수집한 정보들을 이용하여 새로운 악성 코드를 탐지하는 기법들이다. 그러므로 앞서 이야기한 바와 같이 실행 파일(Executable File)의 실행을 통하여 새로운 악성 코드를 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과도 상당히 밀접한 연관 관계를 가지고 있는 것이다.
1) 에뮬레이터(Emulator)
사전적인 의미에서 에뮬레이터(Emulator)는 대리 실행기 라는 의미를 가지고 있다. 대리 실행기 라는 의미에서와 같이 에뮬레이터(Emulator)는 실제 컴퓨터 시스템 상에서 실행 파일(Executable File)을 직접적으로 실행하는 것이 아니라 실제 컴퓨터 시스템에 가상(Virtual)의 환경이나 가상의 하드웨어(Hardware) 이미지를 생성하여 해당 가상 하드웨어(Hardware)를 통하여 간접적으로 실행하는 것을 의미한다. 이러한 의미로 인해 일부에서는 에뮬레이터(Emulator)를 이용한 탐지 기법을 코드 에뮬레이션(Code Emulation) 또는 CPU 에뮬레이션(CPU Emulation) 이라고도 이야기 한다.
이 탐지 기법은 실제 컴퓨터 상에서 스캐닝 엔진(Scanning Engine)이 검사를 수행하지만 컴퓨터 시스템 내부에 가상의 CPU와 메모리 등의 가상의 환경을 제공하여 실행 파일(Executable File)을 실행하고 정보를 수집함으로 실제 컴퓨터 시스템에서는 악성 코드로 인한 어떠한 감염 피해도 발생하지 않는다. 이러한 점으로 인해 알려지지 않은 악성 코드를 탐지하기 위한 부분에서는 상당히 강력한 방법이라고 할 수 있다.
이러한 가상의 환경을 이용하는 에뮬레이터(Emulator)가 컴퓨터 시스템에서 구현되기 위해서는 크게 다음과 같은 4가지가 포함 되어야 한다.
- 가상 CPU 환경
실행 파일을 실제 CPU를 이용한 연산과 동일하게 처리하기 위해 일반적인 모든 명령어들뿐만이 아니라 MMX(Multi Media eXtension) 명령어와 FPU(Floating Point Unit) 명령어까지도 모두 처리 할 수가 있어야 한다.
- 가상 메모리 환경
32비트(Bit) 주소 체계에서는 최고 4 기가바이트(GB)까지 확장이 가능하지만 가상의 메모리 환경에서는 이렇게 많은 메모리는 필요하지 않다. 다만, 실행 파일(Executable File)이 실행되었을 때 변경하는 메모리 주소들에 대해 모두 기록하고 이를 추적할 수 있어야 하며 논리적인 메모리 주소와 물리적인 메모리 주소들을 모두 제공할 수 있어야 한다.
- 가상 저장 장치 환경
물리적인 저장 장치와 동일하게 실행 파일(Executable File) 실행 시 발생하는 저장 장치에 대한 파일 읽기 및 쓰기처럼 저장 장치에 대한 I/O(Input/Output)가 발생할 때 에뮬레이터(Emulator)에서는 실제 하드웨어와 동일한 환경을 제공 할 수 있어야 한다.
- 에뮬레이션 제어기(Emulation Controller)
에뮬레이션 제어기(Emulation Controller)는 에뮬레이터(Emulator)에서 가장 핵심이 되는 부분이다. 실행 파일(Executable File)이 가상 환경에서 실행 시 악성 코드로 판단 할 수 있을 정도의 충분한 정보를 수집하고 이를 제어하는 것이 바로 에뮬레이션 제어기(Emulation Controller)이기 대문이다. 그래서 에뮬레이션 제어기(Emulation Controller)에서는 실행 중인 악성 코드를 어느 시점에서 실행을 중단할 것인가와 얼마 정도의 시간을 실행에 소비할 것인가를 판단하고 제어할 수 있어야 한다. 일반적으로는 인텔 X86 CPU에서 에뮬레이션(Emulation)을 수행 하기 위해서는 최소 1,000개에서 최대 30,000개의 CPU 명령어 수행과 함께 45초 정도의 시간 소요를 기본으로 설정 한다.
이렇게 가상의 환경에서 실행 파일(Executable File)을 실행하고 수집된 실행 결과들을 통해서 악성 코드로 판단하는 에뮬레이터(Emulator)는 실제 시스템에 전혀 감염의 피해를 입히지 않고 알려지지 않은 악성 코드를 탐지할 수 있다는 점에서는 상당히 강력한 방법이라고 이야기 하였다. 하지만 에뮬레이터(Emulator)는 스캐닝 엔진(Scanning Engine)이 실행 파일(Executable File)을 검사 할 때마다 모두 가상의 환경에서 실행을 하고 분석을 해야 된다는 점에서는 컴퓨터 시스템에 대한 자원 소모가 커지게 되는 부담을 안고 있다. 이 문제로 인해 전반적인 스캐닝 엔진(Scanning Engine)의 검사 속도 저하로 이어지는 점이 가장 큰 단점이라고 할 수 있다.
2) 샌드박스(Sandbox)
에뮬레이터(Emulator)와 샌드박스(Sandbox)는 실행 파일(Executable File)의 실행을 통하여 수집된 정보를 통하여 악성이라고 판단하는 점에서는 유사한 형태라고 할 수 있다. 그러나 에뮬레이터(Emulator)와 샌드박스(Sandbox)의 가장 큰 차이점은 어떠한 형태로 실행 파일(Executable File)을 실행하고 어떠한 방식으로 악성 코드로 판단할 수 있는 정보들을 수집하는가에 가장 큰 차이점을 가지고 있다.
일반적으로 샌드박스(Sandbox)는 어플리케이션 에뮬레이터(Application Emulator)라고도 알려져 있는데 이러한 명칭에서 알 수 있듯이 샌드박스(Sandbox)는 에뮬레이터(Emulator)와는 달리 가상의 공간을 생성하는 것이 아니라 실제 컴퓨터 시스템상에서 바로 실행 파일(Executable File)을 실행하고는 정보를 수집한다는 점에서 가장 큰 차이점을 가지고 있다.
[그림 6] CWSandbox의 기본 구조
일반적인 어플리케이션 에뮬레이터(Application Emulator)로 널리 알려져 있는 CWSandbox는 [그림 6]과 같은 기본적인 구조로 되어 있다. CWSandbox의 경우 실행 파일(Executable File)이 실행되면 해당 파일의 스레드(Thread)로 모니터링 모듈인 CWMonitor.dll 파일을 인젝션(Injection) 시킨다. 인젝션(Injection) 이 후 해당 실행 파일(Executable File)이 실행되는 되는 모든 절차를 추적하여 해당 정보를 모두 CWSnadbox로 전달하게 된다.
[그림 7] CWSnadbox에서 윈도우 API 호출의 후킹(Hooking)
그리고 실행 파일(Executable File)이 실행되는 과정에서 발생하는 윈도우 API(Windows API) 호출 모두를 API 후킹(API Hooking) 기법을 이용하여 가로챈 후 CWSandbox로 전달 된 다. 전달 된 윈도우 API(Windows API) 호출은 CWSandbox를 통해 윈도우 커널 레벨(Windows Kernel Level)로 전달하는 정상적인 절차를 수행하게 되고 호출되는 윈도우 API(Windows API) 역시 호출한 해당 실행 파일(Executable File)로 바로 전달하는 것이 아니라 CWSandbox를 거쳐서 전달하게 되는 것이다. 이러한 과정을 표현한 것이 바로 [그림 7]과 같다.
그런데 여기에서 바로 어플리케이션 에뮬레이터(Application Emulator)인 샌드박스(Sandbox)의 가장 큰 특징이 나타난다. 호출 되는 윈도우 API(Windows API)가 CWSandbox를 통해 실행 파일(Executable File)로 전달 된 후 다시 그 리턴 값이 윈도우 운영체제로 바로 전달 되는 것이 아니라 CWSandbox를 통해 전혀 다른 리턴 값을 윈도우 운영체제로 전달하게 된다는 것이다. 이러한 다른 리턴 값을 전달하게 됨으로 실행 파일(Executable File)이 악성 코드여서 감염으로 인해 발생하는 악의적인 기능들이 모두 CWSandbox에 의해 걸러지게 됨으로 실질적인 컴퓨터 시스템에는 감염으로 인한 피해가 발생하지 않게 된다. 그리고 수집된 윈도우 API(Windows API) 호출과 리턴된 값과 같은 정보들을 통하여 CWSandbox는 해당 실행 파일(Executable File)이 알려지지 않은 악성 코드인지 판단을 하게 된다.
그러나 에뮬레이터(Emulator)와 같이 가상의 공간이 아닌 실제 컴퓨터 시스템의 환경에서 실행 파일(Executable File)을 실행하는 샌드박스(Sandbox) 역시 윈도우 응용 프로그램이다. 그러므로 샌드박스(Sandbox)가 특정 악성 코드를 정상적으로 제어하지 못하게 될 경우에는 그 감염으로 인한 피해가 고스란히 실제 시스템으로 전달되게 됨으로 예측하지 못하는 문제가 발생할 가능성이 크다.
이제까지는 실행 파일(Executable File)의 실행을 통해서 알려지지 않은 악성 코드를 탐지 할 수 있는 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아 보았다. 하지만 다음 장에서는 일반적인 윈도우 실행 파일 포맷이 아닌 전자 메일로 형태는 급속한 확산을 시도하는 알려지지 않은 매스 메일러 웜(Mass Mailer Worm)을 탐지 할 수 있는 기법에 대해서 알아 보도록 하자.
4. MIME 필터링 탐지 기법 (MIME Filtering Detection Tech)
필자가 악성 코드를 분석하고 대응을 하면서 기억에 남는 악성 코드들을 이야기하라고 한다면 그 중에 하나가 바로 베이글 웜(Win32/Bagle.worm), 넷스카이 웜(Win32/Netsky.worm) 그리고 마이둠 웜(Win32/Mydoom.worm)과 같이 전자메일에 자신의 복사본을 첨부하여 대량으로 발송하는 매스 메일러 웜(Mass Mailer Worm)이다. 이러한 매스 메일러 웜(Mass Mailer Worm)은 감염된 시스템에서 메일 주소를 수집하여 대량으로 전자메일을 발신함으로 만약 유럽에서 확산되었다면 지구 반대편인 한국까지 웜(Worm)이 첨부된 전자메일이 전달되는데 에는 서너 시간이면 충분할 정도로 급속하게 확산된다. 특히나 대량의 전자메일이 전송됨으로 기업의 전산 환경에서는 전자메일을 수신하는 메일 서버에도 엄청난 부하가 가중됨으로 정상적인 일반 메일의 전송이 느려지게 되거나 어려워 질 수도 있게 된다.
이러한 매스 메일러 웜(Mass Mailer Worm) 역시 일반적인 전자메일과 동일하게 베이스64(Base64)로 인코딩(Encoding)된 MIME(Multi-Purpose Internet Mail Extensions) 형태로 전송된다.
[그림 8] 베이스64(Base64)로 인코딩(Encoding)된 매스 메일러 웜(Mass Mailer Worm)
위 [그림 8]과 같은 형태로 되어 있는 매스 메일러 웜(Mass Mailer Worm)을 탐지하기 위해서 가장 쉽게 적용할 수 있는 부분이 바로 콘텐츠 필터링(Contents Filtering) 방식이다. 콘텐츠 필터링(Contents Filtering) 방식이란 급속하게 확산되는 매스 메일러 웜(Mass Mailer Worm)이 발견되었을 때 해당 매스 메일러 웜(Mass Mailer Worm)이 전송하는 전자메일 형태, 즉 메일 제목(Subject), 메일 본문(Body) 그리고 첨부파일(Attachment File) 명칭과 같이 특징적인 문구로 탐지하는 것이다. 앞서 설명한 파일 기반 탐지(File Base Detection) 기법으로 설명하자면 시그니처 기반(Signature Base)의 진단법과 유사한 개념으로 이해하면 될 것이다. 이 콘텐츠 필터링(Contents Filtering) 기법이 가능한 것이 매스 메일러 웜(Mass Mailer Worm) 역시 윈도우 시스템에서 실행되는 응용 프로그램의 형태임으로 자신의 복사본을 전송할 때 프로그래밍화된 고정된 형태의 전자메일 형태로 전송하기 때문이다. 그러나 이 방식은 이미 매스 메일러 웜(Mass Mailer Worm)이 확산되고 있다는 것을 알고 그 악성 코드가 어떠한 형태의 전자메일을 발송한다는 것 역시 이미 알고 있어야 됨으로 전혀 알려지지 않은 새로운 악성 코드를 탐지할 수는 없다. 다만 스캐닝 엔진(Scanning Engine)이 업데이트 되기 전인 초기 확산 단계에 적용하여 메일 서버의 부하와 매스 메일러 웜(Mass Mailer Worm)의 기업 전산망으로 유입되는 것을 조기에 효과적으로 차단할 수가 있다.
1) 첨부 파일 탐지 기법 (Attachment File Detection Tech)
전자메일을 이용하여 급속하게 확산되는 알려지지 않은 매스 메일러 웜(Mass Mailer Worm)을 탐지할 수 있는 기법 중 하나가 전자메일에 첨부된 첨부 파일 탐지(Attachment File Detection) 기법이다. 앞서 설명한 바와 같이 매스 메일러 웜(Mass Mailer Worm)이 전송하는 전자메일 역시 베이스64(Base64)로 인코딩(Encoding)된 MIME(Multi-Purpose Internet Mail Extensions) 형태로 전송된다고 하였다. 특히 매스 메일러 웜(Mass Mailer Worm)은 자신의 복사본을 첨부 파일로 사용하는데 일반적인 실행 파일(Executable File)이 전자메일에 첨부되기 위해서는 파일 형태 역시 베이스64(Base64)로 인코딩(Encoding)되어야 한다.
[그림 9] 베이스64(Base64)로 인코딩(Encoding)된 첨부 파일
최근에 발견되는 대부분의 악성 코드는 UPX, FSG 등과 같은 실행 압축(Packer)이라는 실행 파일 보호 기법을 이용하여 악성 코드 제작자가 안티 바이러스(Anti-Virus) 연구원들의 분석을 지연시키고자 하고 있다. 그런데 이러한 실행 압축(Packer)이라는 실행 파일 보호 기법이 적용된 실행 파일(Executable File)이 베이스64(Base64)로 인코딩(Encoding) 되면 재미있는 현상이 나타나게 된다. 여기서 베이스64(Base64)로 인코딩(Encoding) 된다는 것은 4개의 7 비트(Bit) 아스키(ASCII) 문자로 표현되도록 원래의 파일에서 각 3 바이트(Byte)씩을 4개의 6 비트(Bit) 단위로 나누어주게 되는 것이다.
이렇게 실행 압축(Packer)된 실행 파일(Executable File)이 베이스64(Base64)로 인코딩(Encoding)되면 실행 압축(Packer)별로 유사한 코드 형태를 가지게 된다는 것이다. 이렇게 인코딩(Encoding)된 실행 압축(Packer) 파일의 유사한 코드 부분을 휴리스틱 시그니처(Heuristic Signature)로 적용하게 되면 알려지지 않은 매스 메일러 웜(Mass Mailer Worm)이 특정 실행 압축(Packer)으로 되어 있을 경우에는 모두 탐지가 가능해지게 된다.
이상으로 급속하게 확산되는 알려지지 않은 매스 메일러 웜(Mass Mailer Worm)을 첨부 파일을 이용하여 탐지하는 기법에 대해서 알아 보았다. 다음 장에서는 이제까지 설명하였던 알려지지 않은 악성 코드 탐지 기법들과는 조금 다른 접근법을 가진 실제 컴퓨터 시스템에서 실행 파일이 실행되어 나타나는 다양한 행위를 바탕으로 알려지지 않은 악성 코드를 탐지하는 행위 기반 탐지 기법(Behavior Detection)에 대해서 알아 보도록 하자.
5. 행위 기반 탐지 기법 (Behavior Detection Tech)
최근 들어 안티 바이러스(Anti-Virus) 업계뿐만이 아니라 일반적인 보안 업체에서도 많은 주목을 받고 있는 탐지 기법 중 하나가 바로 이 행위 기반 탐지 기법(Behavior Detection)이다. 이 행위 기반 탐지 기법(Behavior Detection)은 실행 파일(Executable File)의 실행을 통해서 알려지지 않은 악성 코드를 탐지한다는 면에서는 에뮬레이터(Emulator) 또는 샌드박스(Sandbox)와 동일하지 않은가라는 의구심이 들 수가 있다. 그러나 엄밀하게 말해서 에뮬레이터(Emulator)는 실제 컴퓨터 시스템 내에서 가상의 공간을 구성하는 점과 샌드박스(Sandbox)는 실제 컴퓨터 시스템과 실행 파일(Executable File)의 중간에서 이를 가로챈다는 특징으로 인해 행위 기반 탐지 기법(Behavior Detection)과는 다르다고 할 수 있다.
행위 기반 탐지 기법(Behavior Detection)은 일반적으로 크게 하나의 컴퓨터 시스템 내에서 발생하는 행위들에 바탕을 두고 있는 시스템 기반 탐지(System Base Detection) 기법과 전체 네트워크(Network) 내에서 발생하는 행위들에 바탕을 두고 있는 네트워크 기반 탐지(Network Base Detection) 기법 이렇게 2가지로 나누어진다. 그러나 필자의 전문 분야가 실행 파일(Executable File)을 기반으로 한 악성 코드 분석임으로 여기에서는 네트워크 기반 탐지(Network Base Detection) 기법에 대해서는 다루지 않도록 하겠다.
1) 시스템 기반 탐지 기법 (System Base Detection Tech)
시스템 기반 탐지(System Base Detection) 기법은 앞서 설명한 바와 같이 하나의 컴퓨터 시스템 내에서 발생하는 다양한 행위들의 탐지를 바탕으로 하고 있다. 이 탐지 기법 역시 크게 무결성 검사(Integrity Check) 기법과 행위 차단 (Behavior Block) 기법으로 나누어지는데 이 두 기법 모두 실행 파일(Executable File)이 하나의 컴퓨터 시스템에서 실행되는 행위에 대해서 탐지를 한다는 공통점은 있으나 실행이 이루어지고 난 이후에 어떠한 방식으로 알려지지 않은 악성 코드를 탐지하는가에 따라서 구분되고 있다.
- 무결성 검사 기법(Integrity Check)
무결성(Integrity)은 일반적인 정보 보호(Information Security)에서 이야기하는 보안의 3대 구성 요소 중 하나이다. 여기에서 말하는 무결성(Integrity)은 원본 데이터 또는 자료의 왜곡이 없이 순수한 상태를 그대로 유지하는 것을 의미한다. 이러한 의미를 가지고 있는 무결성(Integrity)은 무결성 검사(Integrity Check) 기법에서도 역시 컴퓨터 시스템이 데이터, 실행 파일(Executable File)들과 시스템 자체에 대한 어떠한 변화가 없이 유지되는 상태를 의미하는 것이다. 즉, 무결성 검사(Integrity Check) 기법은 이러한 컴퓨터 시스템의 무결성(Integrity) 상태가 지속적으로 유지되고 있는가를 주기적으로 검사를 수행 하는 것을 이야기 한다. 예를 들어 어떤 컴퓨터에서 30분전에 마지막으로 무결성 검사(Integrity Check)를 수행하여 무결성(Integrity)이 유지되는 것을 확인하였으나 지금 다시 검사를 수행하니 30분전에 존재하지 않았던 특정 실행 파일(Executable File)이 윈도우 시스템 폴더에 생성된 것을 확인하였다면 해당 실행 파일(Executable File)을 악성 코드로 의심해 볼 수가 있다는 것이다.
무결성 검사(Integrity Check)가 수행되는 방식은 최초 악성 코드에 감염되지 않은 깨끗한 컴퓨터 시스템상에 존재하는 주요 실행 파일과 폴더에 대해서 MD5(Message Digest 5)와 같은 해쉬값(Hash)을 계산하여 모두 기록을 하게 된다. 그 이후 앞서 이야기한 바와 같이 특정 시간 단위로 해당 컴퓨터 시스템에서 MD5(Message Digest 5)가 기록된 실행 파일(Executable File)과 폴더에 변경된 또는 존재하지 않던 해쉬값(Hash)이 있는지를 비교하는 작업을 수행하게 되는 것이다.
이러한 무결성 검사(Integrity Check) 기법은 주기적인 무결성 검사(Integrity Check)로 인해 컴퓨터 시스템에 감염된 알려지지 않은 악성 코드를 탐지할 수 있는 장점이 있는 반면에 이러한 장점이 오히려 단점도 된다. 이미 컴퓨터 시스템이 악성 코드에 감염이 되어 감염 피해를 받고 난 이후 임으로 조기 대응이 전혀 불가능하다는 것이다. 특히나 데이터베이스(Database)와 같이 중요한 시스템이 감염 피해를 입게 되었다면 복구에 상당히 많은 시간과 노력을 유발하게 된다.
- 행위 차단 기법 (Behavior Block)
일반적으로 행위 기반 탐지 기법(Behavior Detection)이라고 이야기하는 것은 대부분이 이 행위 차단(Behavior Block) 기법이 발전한 형태로 볼 수 있다. 그리고 에뮬레이터(Emulator) 또는 샌드박스(Sandbox)와도 다른데 이 행위 기반 탐지 기법(Behavior Detection)은 에뮬레이터(Emulator)처럼 컴퓨터 시스템 내에 가상의 공간을 구성한다던가 샌드박스(Sandbox)처럼 컴퓨터 시스템과 실행 파일(Executable File)의 중간에서 리턴값 조작 등을 하지는 않는다.
행위 차단(Behavior Block) 기법은 단순하게 컴퓨터 시스템에서 발생하는 모든 행위들을 모니터링하고만 있을 뿐이다. 그러나 이 모니터링 과정에서 악성 코드와 유사한 행위가 발생하게 되면 이 행위를 유발한 실행 파일(Executable File)이 어떠한 것인지를 추적하여 해당 실행 파일(Executable File)이 더 이상 진행을 하지 못하도록 차단시킨 이후 컴퓨터 시스템 사용자에게 조치를 할 수 있는 경고창을 발생시킨다. 만약 사용자가 해당 실행 파일(Executable File)이 정상 파일이라면 그 이후의 행위를 지속적으로 수행할 수 있도록 진행시키게 된다. 그러나 반대로 사용자가 악성 코드로 의심되는 파일일 경우에는 해당 실행 파일(Executable File)이 더 이상 시스템에서 실행되지 못하도록 강제 종료 시켜 버릴 수가 있다.
[그림 10] 게이트키퍼(GateKeeper)의
기본 구조
그렇다면 이러한 행위 차단(Behavior Block) 기법의 대표적인 소프트웨어 중 하나인 게이트키퍼(GateKeeper)를 통해서 자세히 살펴보도록 하자. [그림 10]은 게이트키퍼(GateKeeper) 프로그램의 기본 구조를 도식화한 것이다.
위 [그림 10]과 같이 게이트키퍼(GateKeeper)는 모니터링 엔진(Monitoring Engine)에 의해서 현재 시스템에서 실행 중인 모든 파일들에 대해서 감시를 하게 된다. 이 과정에서 새로운 실행 파일(Executable File)이 실행되면 이 모니터링 엔진(Monitoring Engine)은 해당 파일의 처음 시작부터 감시를 진행하며 해당 실행 파일(Executable File)이 어떠한 순서로 실행이 되는지를 모두 추적한 후 복귀 엔진(Undo Engine)을 통하여 로그(Log)를 모두 남기게 된다. 그리고는 해당 실행 파일(Executable File)의 추적을 통하여 생성한 로그(Log)를 비교 엔진(Matching Engine)을 통하여 해당 실행 파일(Executable File)이 악성 코드의 실행 형태와 얼마나 유사한 행위를 유발하고 있는지를 측정하게 된다.
여기에서 만약 해당 실행 파일(Executable File)이 악성 코드로 판단되면 시스템 사용자에게 게이트키퍼(GateKeeper)는 현재 실행 중인 파일이 악성 코드로 판단된다는 경고를 유발하게 된다. 시스템 사용자는 해당 판단을 근거로 실행 차단을 선택하게 될 경우, 복귀 엔진(Undo Engine)은 자신이 기록한 해당 실행 파일(Executable File)의 로그(Log)들 분석하여 실행된 순서를 역으로 시스템에 대한 복구 작업을 수행하게 된다. 이 복구 작업을 통하여 게이트키퍼(GateKeeper)는 해당 실행 파일(Executable File)에 의해서 발생한 시스템 변화에 대해서 실행되기 전의 상태로 복구를 할 수가 있게 된다.
이러한 형태의 행위 차단(Behavior Block) 기법은 알려지지 않은 악성 코드가 실행될 경우에는 이를 사용자에게 알려주고 차단할 수가 있다는 면을 장점으로 볼 수가 있다. 그러나 오탐(False Positive)으로 인하여 너무나도 자주 경고 창이 발생된다면 이는 오히려 시스템 사용자에게 어떠한 것이 알려지지 않은 악성 코드인지 정확한 판단을 하기가 어려워지게 된다. 그리고 이러한 경고 창으로 인하여 오히려 시스템 사용자에게 정상적인 시스템 사용이 방해될 정도의 불편함을 유발 할 수도 있게 된다. 그리고 행위 차단(Behavior Block) 기법 역시 알려지지 않은 악성 코드가 실행이 될 경우 이를 탐지해야 되는 윈도우 응용 프로그램임으로 앞서 설명한 샌드박스(Sandbox)와 동일한 문제점을 안고 있다. 즉, 행위 차단(Behavior Block) 기법이 적용된 시스템이 악성 코드의 실행을 정상적으로 컨트롤을 하지 못하게 될 경우에는 시스템이 악성 코드에 감염이 되는 치명적인 문제를 유발 할 수도 있다는 것이다.
성숙한 보안 의식의 필요성
우리 사회는 이제 컴퓨터 시스템이 없으면 정상적인 사회 생활을 할 수가 없을 수준에 이르렀다. 병원에서는 환자의 진료 기록과 은행에서는 고객의 신용정보 그리고 통장 관리 등 다양한 목적으로 사용되고 있는 컴퓨터 시스템을 보호하기 위해서 안티 바이러스(Anti-Virus) 업체에서는 다양한 알려지지 않은 악성코드 탐지 기법들을 연구하고 개발하고 있다고 이야기 하였다. 그러나 이러한 다양한 기법들이 개발되더라도 가장 중요한 부분은 바로 컴퓨터 시스템을 사용하고 있는 컴퓨터 사용자의 보안 의식이라고 할 수 있다.
일반적으로 정보 보호(Information Security)에서는 보안에서 가장 취약한 부분은 컴퓨터 시스템이나 응용 프로그램이 아니라 보안 의식 없이 컴퓨터 시스템을 사용하는 컴퓨터 사용자라고 정의하고 있다. 이렇게 주용한 성숙한 보안 의식은 복잡하고 어려운 것이 아니라 자신이 자주 사용하는 컴퓨터 시스템에는 안티 바이러스(Anti-Virus) 소프트웨어를 설치하고 사용하는 운영체제의 주기적인 보안 패치(Security Patch)를 확인하고 설치하는 등 악성 코드에 감염이 될만한 요소들을 사전에 자신의 컴퓨터 시스템에서 제거를 하여 보호를 하는 것에서부터 출발한다고 할 수가 있다. 이렇게 가볍게 출발할 수 있는 성숙한 보안 의식이 바로 알려지지 않은 악성 코드를 사전에 탐지 할 수 있는 가장 훌륭한 방안이 아닐까 하는 생각을 해본다.
참고 문헌
The Art of Computer Virus Research and Defense - Peter Szor (2005)
Computer Viruses and Malware - John Aycock (2006)
Heuristic Engines - Francisco Fernandez (Virus Bulletin 2001 Paper)
Full Potential of Dynamic Binary Translation for AV Emulation Engine - Ji Yan Wu (Virus Bulletin 2006 Paper)
Sandbox Technology inside AV Scanners - Kurt Natvig (Virus Bulletin 2001 Paper)
Description of the CWSandbox - Carsten Willems
Heuristic Detection of Viruses within E-mail - Alex Shipp (Virus Bulletin 2001 Paper)
Prevalence of PE packers in e-mail traffic - Maksym Schipka (AVAR 2006 Paper)
Behavior Oriented Detection of Malicious Code at Run-Time - Matthew Evan Wagner (F.I.T 2004 Paper)
Behavioral Classification - Tony Lee & Jigar J. Mody (EICAR 2006 Paper)
Anti-Malware Tools: Intrusion Detection Systems - Martin Overton (EICAR 2005 Paper)
댓글 없음:
댓글 쓰기