이하 첨부된 도면을 참조하여 본 발명의 실시예에 대해 상세히 설명한다.

도 1은 본 발명의 일 실시예에 따른 루트킷 탐지 시스템의 개략적인 블록도이다. 도시된 바와 같이 루트킷 탐지 시스템(100)은 파일 테이블 획득부(110), 파일 검색부(120), 루트킷 판단부(130), 및 파일 치료부(140)를 포함하는 것으로서, 파일 시스템(150)으로부터 획득되는 파일 테이블을 이용하여 저장장치(미도시)내에 존재하는 루트킷을 탐지하는 기능을 수행한다.

먼저, 파일 테이블 획득부(110)는 저장장치의 파일 시스템(150)으로부터 파일 테이블을 획득한다. 여기서, 파일 시스템(150)이란 저장장치에 기록되어 있는 파일들의 저장이나 검색을 위한 색인기능을 수행하는 것으로서, 이러한 파일 시스템(150)의 방식에는 크게 FAT(File Allocation Table) 방식과 NTFS(New Technology File System)방식이 있다.

또한, FAT 방식에는 플로피 디스크에서 사용되는 파일 시스템 방식인 FAT 12, 소용량 하드디스크에서 사용되는 파일 시스템 방식인 FAT 16, 및 대용량 하드디스크에서 사용되는 파일 시스템 방식인 FAT 32 가 있다.

이러한 다양한 방식의 파일 시스템은 각 방식마다 고유의 구조를 가지며 구조에 따라 그 기능과 성능이 달라진다. 예컨대, NTFS 방식은 각 파일마다 보안설정을 할 수 있어서 네트워크 상에서 해킹의 위험이 적고 FAT 방식은 보안설정 기능이 없어서 인터넷 상에서 해킹의 위험이 커 개인의 일상 업무용 등과 같이 보안이 중요하지 않은 용도로 사용하기에 적당하다.

이하에서는 도 2 및 3을 참조하여 다양한 파일 시스템의 구조에 대해 간략하게 설명한다.

도 2는 FAT 방식의 파일 시스템의 구조를 보여준다. 도 2를 참조하면, FAT 방식의 파일 시스템은 마스터 부트 레코드 영역(200), 부트 레코드 영역(202), 예약된 영역(204), FAT1 영역(206), FAT2 영역(208), 루트 디렉토리 영역(210), 및 데이터 저장 영역(212)을 포함한다.

마스터 부트 레코드(Master Boot Record) 영역(200)은 운영체제에 관계없이 공통적으로 존재하는 영역으로서 저장장치의 제일 첫 부분에 위치한다.

부트 레코드(Boot Record) 영역(202)은 바이오스 파리미터 블록(BIOS Parameter Block, BPB)으로 정의되기도 하는 영역으로서 볼륨(Volume)의 첫 번째 섹터(Sector)를 의미하거나, 후술할 예약된 영역(204)의 첫 번째 섹터를 의미한다. 이 영역에는 운영체제(Operating System, OS)를 부팅시키기 위한 기계어 코드와 FAT 파일 시스템의 여러 설정 값들이 저장된다.

이 영역은 크기가 1 섹터 밖에 되지 않는 작은 영역이지만 운영체제가 FAT 파일 시스템을 인식하는데 가장 중요한 역할을 담당한다. 이는 운영체제가 볼륨을 인식하려고 할 때, 부트 레코드 영역(202)을 우선적으로 읽어서 분석을 하기 때문이다. 만약 볼륨의 내용이 유효하더라도 부트 레코드 섹터가 삭제된다면 운영체제는 해당 볼륨을 인식할 수 없게 된다.

예약된(Reserved) 영역(204)은 미래를 위해 예약해 놓은 영역으로서, 보통 FAT 16인 경우에는 1섹터를 할당하고, FAT 32인 경우에는 32섹터를 할당한다. FAT 16의 경우 예약된 영역의 크기가 1섹터라면 부트 레코드 영역이 1섹터를 차지하므로 부트 레코드 다음에 바로 FAT 영역이 위치하게 된다.

FAT1 영역(206)은 클러스터들을 관리하는 파일 할당 테이블(File allocation Table, 이하 '파일 테이블'이라 함)이 저장되는 공간으로서, 파일 테이블이란 하나의 파티션 안에서 실제 파일에 해당하는 정보가 어떤 위치에 저장되어 있는 가를 표시해 놓은 것을 의미한다.

FAT2 영역(208)은 FAT1 영역(206)에 저장되어 있는 파일 테이블의 백업본이 저장되는 공간으로서, FAT1 영역(206)이 손상되는 경우를 대비하기 위해 FAT1 영역(206)에 저장되어 있는 파일 테이블의 복사본을 별도로 저장해 두기 위한 것이다.

상술한 실시예에 있어서 FAT 영역(206, 208)은 2개로 구성되는 것으로 기재하였지만, 이러한 FAT 영역은 최소 1개 이상이 되면 되므로, 3개로 구성될 수도 있을 것이다.

다음으로 루트 디렉토리 영역(210)은 FAT 16 방식에만 존재하는 것으로서, 그 위치는 FAT2 영역(208)의 뒤쪽으로 고정되어 있다. 즉, FAT 16 방식에서는 루트 디렉토리를 별도의 루트 디렉토리 영역(210)에 저장함으로써 루트 디렉토리가 어디에 저장되어 있는지를 조사할 필요가 없게 된다. 그러나, 루트 디렉토리를 별도의 영역에 저장하는 경우 루트 디렉토리의 파일 개수가 제한된다는 단점이 있어, FAT 32 방식과 같은 파일 시스템에서는 루트 디렉토리를 별도의 영역에 저장하는 것이 아니라 데이터 저장 영역 내에 저장한다. 단, 이러한 경우라도 부트 레코드가 손상되는 경우를 대비하기 위해 FAT2 영역(208) 바로 뒤쪽에 루트 디렉토리가 위치하도록 하는 것이 바람직하다.

데이터 저장 영역(212)은 파일 또는 디렉토리가 저장된다. 데이터 저장 영역(212)은 상술한 영역들이 섹터 단위로 일기/쓰기가 수행되는 것과는 달리 클러스터(Cluster)라고 불리는 논리적인 단위로 읽기/쓰기가 수행된다.

상술한 도 2에서는 도시하지 않았지만, FAT 방식의 파일 시스템에는 사용하지 않는(Unused) 영역(미도시)이 더 포함될 수 있다. 이 영역은 물리적으로는 사용해도 상관 없는 영역이지만 FAT 방식의 파일 시스템이 볼륨을 구조화시키는 과정에서 발생하는 잉여 영역이다.

상술한 각 영역들의 크기와 각 영역의 접근 단위를 정리하여 보면 아래의 표 1과 같다.

표 1

도 3은 NTFS의 파일 시스템의 구조를 보여준다. 도 3을 참조하면, NTFS 방식의 파일 시스템은 마스터 부트 레코드 영역(314), 파티션 부트 섹터(Partition Boot Sector) 영역(316), 및 MFT 및 데이터 저장 영역(318)을 포함한다.

마스트 부트 레코드 영역(314)은 컴퓨터를 부팅하기 위한 정보와 실제 파티션(Active Partition)에 대한 정보가 저장되는 곳으로 저장장치의 제일 외측에 위치한 공간으로, 저장장치로 들어오는 관문이 되는 영역이라 할 수 있다. 이러한 마스트 부트 레코드 영역(314)의 크기는 1섹터(512byte)이고, 그 위치는 절대섹터 0(실린더 0, 헤드 0, 섹터 1)이다.

파티션 부트 섹터 영역(316)에는 부팅하는 과정 중에 운영체제가 시작될 수 있도록 하기 위한 코드(예컨대, NT Bootstart code)가 존재한다. 또한 NTFS 파티션 내의 섹터, 클러스터 등의 설정에 관한 정보가 저장되며, MFT의 실제 위치 정보가 저장된다.

MFT 및 데이터 저장 영역(318)은 MFT(Master File Table)와 파일/디렉토리가 저장되는 영역으로서, MFT는 상술한 FAT 방식의 파일 시스템에서의 파일 테이블인 FAT에 상응하는 것으로서, NTFS에서는 MFT 상에 디렉토리를 포함한 모든 파일에 대한 정보가 기록된다. 이러한 MFT의 경우에 있어서도 상술한 FAT와 같이 손상이 발생하는 경우를 대비하여 MFT 복사본을 함께 저장한다. 파일/디렉토리와 같은 데이터는 MFT 이후에 기록된다.

즉, 파일 테이블 획득부(110)는 파일 시스템(150)이 FAT 방식인 경우, 파일 시스템(150)으로부터 파일 테이블인 FAT를 읽어 들이고, 파일 시스템(150)이 NTFS 방식인 경우, 파일 시스템으로부터 파일 테이블인 MFT을 읽어 들이는 것이다. 이후, 파일 테이블 획득부(110)는 읽어 들인 파일 테이블을 검색을 위해 메모리(미도시) 상에 로드할 수 있다.

상술한 실시예에 있어서는 파일 시스템(150)이 FAT 방식 또는 NTFS 방식인 것으로 기재하였으나, 이에 한정되지 않고 파일 테이블을 사용하는 파일 시스템 이라면 어떤 것이라도 무방할 것이다. 예컨대, 유닉스 계열의 운영체제에서 사용되는 ext2 방식의 파일 시스템, ext3 방식의 파일 시스템, minix 방식의 파일 시스템, sysV 방식의 파일 시스템일 수도 있을 것이다

파일 검색부(120)는 파일 테이블 획득부(110)에 의해 획득된 파일 테이블 상에 기록되어 있는 파일들에 대해 검색을 수행하여, 파일 테이블 상에 기록되어 있는 파일들의 검색 가능 여부를 판단한다. 일 실시예에 있어서, 파일 검색부(120)는 API(Application Program Interface)를 이용하여 파일 테이블 상에 기록된 파일들에 대한 검색을 수행하며, 이때, 검색 대상 파일의 선정은 사용자로부터 검색 대상 폴더를 선택 받음에 의해 수행될 수 있다.

즉, 파일 검색부(120)는 파일 테이블 상에 기록된 파일들 중 사용자에 의해 선택된 폴더 내에 존재하는 파일들을 API를 이용하여 검색을 수행하는 것이다. 이러한 경우 파일 검색부(120)는 파일 테이블 상에서 사용자에 의해 선택된 폴더에 포함된 파일들 중 정상적인 파일(예컨대 삭제 또는 이동된 파일이 아닌 파일)에 대해서만 검색을 수행하는 것이 바람직하다.

한편, 파일 검색부(120)는 검색을 수행한 결과, 파일 테이블 상에는 존재하지만 실제로 검색되지 않았던 파일들을 리스트 형태로 관리할 수 있다.

루트킷 판단부(130)는 파일 검색부(120)에 의한 판단 결과를 이용하여 해당 파일이 루트킷인지 여부를 판단한다. 즉, 루트킷 판단부(130)는 파일 검색부(120)에 의한 검색 수행 결과, 파일 테이블 상에는 존재하지만 검색이 되지 않았던 파일들에 루트킷인지 여부를 판단하는 것이다.

일 실시예에 있어서, 루트킷 판단부(130)는 검색을 수행한 결과, 파일 테이블 상에는 존재하지만 검색이 되지 않았던 파일들이 악성코드인지 여부를 판단함으로써, 해당 파일이 악성코드인 경우 해당 파일을 루트킷으로 결정하고 악성코드인지 여부를 판단할 수 없는 파일들은 루트킷 의심 파일로 결정할 수 있다. 여기서, 악성코드 여부는 백신 프로그램을 이용하여 판단할 수도 있으며, 악성코드인지 판단할 수 없는 경우는 해당 파일에 최신 루트킷이 적용되어 있거나 종래의 기술을 우회하는 루트킷이 적용되어 있는 경우를 의미한다.

이와 같이, 본 발명은 파일 시스템으로부터 직접 획득된 파일 테이블 상에 기록되어 있는 파일을 API를 이용하여 검색하고, 그 결과를 이용하여 해당 파일이 루트킷인지 여부를 판단하게 되므로 루트킷을 보다 정확하게 탐지할 수 있게 된다.

파일 치료부(140)는 루트킷 판단부(130)에 의해 해당 파일이 루트킷으로 결정되거나 루트킷 의심 파일로 결정되는 경우, 이를 치료하는 기능을 수행한다. 일 실시예에 있어서, 파일 치료부(140)는 해당 파일의 치료 가능 여부를 판단하여 치료가 가능한 경우 해당 파일을 치료하고, 치료가 불가능한 파일이나 루트킷으로 의심되는 파일은 해당 파일을 격리하거나 파일 테이블 상에서 삭제할 수 있다. 이때, 파일의 치료 가능여부를 판단하거나 치료하기 위해서 백신 프로그램을 이용할 수도 있다.

여기서, 파일의 격리라 함은 파일의 경로를 변경시킴으로써 해당 파일의 실행이 불가능하도록 의미하는 것으로서, 루트킷으로 의심되는 파일이지만 추후 루트킷이 아닌 것으로 판단되는 파일은 다시 정상적으로 실행되도록 하기 위해, 삭제하는 것이 아니라 일시적으로 그 경로를 변경함으로써 해당 파일이 정상적으로 실행되지 않도록 하는 것이다. 파일 테이블 상에서의 파일 삭제 또한 해당 파일이 정상적으로 실행되지 않도록 하기 위한 것이다.

상술한 실시예에 있어서는 백신 프로그램을 이용하여 루트킷 또는 루트킷 의심 파일을 치료하는 것으로 기재하였으나, 해당 파일을 치료할 수 있으면 되므로 해당 파일을 치료하기 위한 수단이 백신 프로그램으로 한정되지는 않을 것이다.

도 4는 본 발명의 일 실시예에 따른 루트킷 탐지 방법을 보여주는 플로우차트이다.

도시된 바와 같이, 먼저 파일 시스템으로부터 파일 테이블을 직접 획득한다(S400). 상술한 바와 같이, 파일 시스템이 FAT 방식인 경우 파일 시스템으로부터 FAT를 획득하고, 파일 시스템이 NTFS 방식인 경우 파일 시스템으로부터 MFT를 획득한다. 이렇게 획득된 파일 테이블은 검색을 위해 메모리 상에 로드된다.

다음으로, 획득된 파일 테이블 상에 기록된 파일들에 대한 검색 가능 여부를 판단한다(S410). 일 실시예에 있어서, 검색 가능 여부는 API(Application Programming Interface)를 이용하여 해당 파일을 검색해 봄으로써 판단될 수 있고, 검색 대상이 되는 파일은 파일 테이블 상에서 사용자에 의해 선택된 폴더 내에 존재하는 파일일 수 있다. 검색을 수행함에 있어서, 삭제된 파일 또는 이동된 파일은 검색 대상 파일에서 제외할 수 있다.

한편, S410단계에서의 판단결과, 파일 테이블에 기록된 파일 중 검색 가능하지 않은 파일들을 리스트 형태로 관리할 수 있다.

판단결과, 파일 테이블 상에는 존재하지만 실제로 검색되지 않는 파일들에 대해 해당 파일이 악성코드인지 여부를 판단한다(S420단계). 악성코드인지 여부는 백신 프로그램을 이용하여 판단할 수도 있으며, 악성코드로 판단되는 경우 루트킷으로 결정하고(S430단계), 악성코드인지 여부가 판단되지 않는 파일들은 루트킷 의심 파일로 결정한다(S440단계). 여기서, 악성코드인지 판단할 수 없는 경우라 함은 해당 파일에 최신 루트킷이 적용되어 있거나 종래의 기술을 우회하는 루트킷이 적용되어 있는 경우를 의미한다.

이후, 루트킷 또는 루트킷 의심 파일이 치료가 가능한지 여부를 판단하여(S450단계), 치료가 가능한 경우 해당 파일을 치료하고(S460단계), 치료가 불가능한 경우 해당 파일을 격리시키거나 해당 파일을 파일 테이블 상에서 삭제한다(S470단계). 일 실시예에 있어서, 파일의 치료 가능여부를 판단하거나 해당 파일을 치료하기 위해서 백신 프로그램을 이용할 수 있다. 여기서, 파일의 격리라 함은 파일의 경로를 변경시킴으로써 해당 파일의 실행이 불가능하도록 의미하는 것으로서, 루트킷으로 의심되는 파일이지만 추후 루트킷이 아닌 것으로 판단되는 파일은 다시 정상적으로 실행되도록 하기 위해 해당 파일을 삭제하는 것이 아니라 일시적으로 그 경로를 변경함으로써 해당 파일이 정상적으로 실행되지 않도록 하는 것이다.

상술한 실시예에 있어서는 루트킷 또는 루트킷으로 의심되는 파일이 백신 프로그램으로 치료가 불가능한 경우 해당 파일을 격리 또는 파일 테이블 상에서 삭제하는 것으로 기재하였지만, 변형된 실시예에 있어서는 백신 프로그램으로 치료가 가능한 경우에도 해당 파일을 격리 또는 삭제할 수도 있을 것이다.

한편, S410단계에서의 판단결과, 파일 테이블 상에서 존재하고 검색도 가능한 파일과 S420단계에서의 판단결과, 파일 테이블 상에서 존재하고 검색은 되지 않지만 악성코드가 아닌 것으로 판단된 파일은 정상적인 파일로 결정하게 된다.

상술한 실시예에 있어서는 루트킷 또는 루트킷으로 의심되는 파일을 치료/격리/삭제 중 어느 하나를 수행하는 것으로 기재하였지만, 변형된 실시예에 있어서는 치료/격리/삭제한 후 해당 파일들을 별도의 리스트 형태로 관리할 수도 있을 것이다.

상술한 루트킷 탐지 방법은 다양한 컴퓨터 수단을 이용하여 수행될 수 있는 프로그램 형태로도 구현될 수 있는데, 이때 루트킷 탐지 방법을 수행하기 위한 프로그램은 하드 디스크, CD-ROM, DVD, 롬(ROM), 램, 또는 플래시 메모리와 같은 컴퓨터로 판독할 수 있는 기록 매체에 저장된다.

본 발명이 속하는 기술분야의 당업자는 본 발명이 그 기술적 사상이나 필수적 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다.

그러므로, 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구범위에 의하여 나타내어지며, 특허청구범위의 의미 및 범위 그리고 그 등가 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.