KL Technologies, 성공적인 사업 파트너


전 체 [ 131 ]
구매 및 체험 문의 [ 3 ]회원등록 [ 0 ]
보안 및 제품 정보 [ 7 ]바이러스 문제 [ 4 ]
설치 및 제거 [ 21 ]제품 설정 [ 57 ]
트러블슈팅 [ 14 ]기타문의 [ 4 ]

   
  [보안 및 제품 정보 > ] 루트킷이란?

루트킷(rootkit)이란?

Alexey Monastyrsky
Konstantin Sapronov
Yury Mashevsky
바이러스 분석가, 카스퍼스키 랩

바이러스 제작자들이 처한 가장 큰 어려운 점 중에 하나가 감염된 시스템에서 사용자들에게 악성코드를 들키지 않고 계속 유지시키게 하는 것입니다. 바이러스 제작자들은 안티 바이러스 프로그램에서 악성코드를 탐지하지 못하도록 만들려고 합니다. 개인적인 흥미로 만드는 바이러스는 줄고 있지만 돈벌이를 하려는 악성코드는 점점 늘고 있습니다. 은행 계좌를 훔치거나 시스템 관리자가 모르게 프록시 서버를 설치하여 스팸을 보내는 프로그램을 어떻게 숨길 것인가?

최근의 사이버 범죄는 10년 또는 15년 전에 사용했던 바이러스 기술을 사용하고 있습니다. 그 중에 하나가 최초의 PC 바이러스 Virus.Boot.Brain.a 입니다. 이 부트 섹터 바이러스는 디스크에 접근하는 시스템 함수를 가로챕니다. 부트 섹터가 읽힐 때(예를 들어 안티 바이러스 프로그램이 검사할 때), 바이러스는 감염된 데이터를 깨끗한 데이터와 교체합니다. 이러한 스텔스 메커니즘(시스템 함수를 가로채고 데이터를 바꾸는)은 윈도우 바이러스(Virus.Win32.Cabanas.a)에도 사용되었습니다.

지금까지 유닉스용 악성 코드는 도스나 윈도우 환경에 비해 많이 확산되지를 않았습니다. ‘루트킷’이라는 용어는 유닉스 계열에서 시작되었습니다. 하지만 요즘에는 윈도우 트로이 목마의 제작자에 의해 사용되는 스텔스 기능을 설명하는데 사용되어집니다. 처음에 '루트킷'은 해커들이 탐지를 피하기 위해 사용되는 프로그램의 종류를 의미하였습니다. 이것은 시스템 실행 파일(login, ps, ls, netstat 등) 또는 시스템 라이브러리(libproc.a)를 교체 또는 커널 모듈에 인스톨됩니다. 이 프로그램의 목적은 사용자가 컴퓨터에서 일어나고 있는 일에 대한 정확한 정보를 차단하는 것입니다.

[표 1]에서와 같은 악성 코드에 감염된 시스템에서 루트킷이 점점 더 많이 사용되고 있습니다.



[표 1] 루트킷을 사용하는 악성코드의 증가

루트킷의 사용이 점점 증가되고 있는 이유 중의 하나는 인터넷 상에 많은 루트킷의 소스코드가 공개되어 있기 때문입니다. 바이러스 제작자들이 그 같은 코드를 수정하는 것은 비교적 간단한 일입니다. 루트킷이 증가하는 또다른 이유는 윈도우 사용자들이 별도의 계정을 만들지 않고 administrator 계정을 사용하는 점입니다. 이 때문에 피해 시스템에 루트킷이 더욱 쉽게 설치됩니다.

안티 바이러스 프로그램이 악성 코드를 찾지 못하도록 숨겨주는 특징이 바이러스 제작자들과 스파이웨어 개발자들에게 아주 유용한 기능이 되었습니다.

그럼 윈도우와 유닉스의 루트킷에 대해 조금 더 자세히 알아보도록 하겠습니다.


윈도우 루트킷

숨기는 방법

흔히 루트킷이 시스템에서 악성 코드를 숨기는 방법은 2가지가 있습니다.:

  • 경로 변경(modifying paths)
  • 시스템 구조 변경(modifying system structures)

이 방법들은 네트워크 활동, 레지스트리 키, 프로세스(예를 들어 시스템에 악성코드가 감염되었다는 것을 사용자에 알릴 수 있는 모든 것) 등을 숨기는 것에 사용됩니다.

처음 방법은 사용자와 커널 모드의 루트킷 모두 사용될 수 있습니다. 사용자 모드 루트킷 실행은 비교적 쉽습니다. 가장 많이 사용되는 방법은 API 함수 후킹을 기반으로 한 실행 경로의 변경입니다.



[그림 2] API 함수 후킹

이 방법은 어플리케이션에 의해 호출되는 API함수가 특정한 데이터 필드(import/ export tables)를 사용한다는 점 또는 API GetProcAddress를 이용하여 어드레스를 받아오는 점을 이용합니다. 프로그램 코드는 DLL 모듈에 삽입되고 기존의 시스템 프로세스의 어드레스 공간에 통합된 후, 모든 사용자 어플리케이션의 통제 권한을 원격에 있는 악성 코드 제작자(또는 악성 코드 사용자)에게 넘겨줍니다. 경로 변경은 문서화도 잘 되어있고 쉽게 접근할 수 있어 루트킷 사용을 더욱 쉽게 합니다.

그러나 이러한 방법과 다른 사용자 모드를 사용하는 루트킷의 방법은 많은 장점이 있는 반면 중요한 약점이 있습니다. 비록 루트킷이 활동을 숨기기는 하지만 효과적이지는 않습니다. 이것은 사용자 모드 루트킷이 RootKit Revealer, SoftIce 등과 같은 시스템에서 사용하는 유틸리티에서 쉽게 탐지해냄을 의미합니다. 이 때문에 커널 모드 루트킷이 개발하기가 더욱 어려움에도 불구하고 점점 더 많이 사용되는 이유입니다.

커널 모드 루트킷은 정보를 더욱 잘 감춥니다. 대다수의 커널 모드 루트킷은 문서화 되어 있지 않은 OS의 구조를 활용합니다. 예를 들어 어떤 루트킷은 가끔KeServiceDescriptorTable 서비스를 후킹합니다. 이 테이블의 서비스 수는 OS 버전에 따라 변경할 수 있습니다. 이것은 루트킷 개발자가 테이블 안의 인덱스 핸들러를 찾기 위해 추가로 OS 코드를 분석해야 함을 의미합니다. 이러한 방법은 API 함수 후킹 방식과 매우 유사합니다.

PsActiveProcessList 변경하는 방법은 시스템 구조를 변경하는 방식의 한 예입니다. 이것은FU 루트킷이 사용하는 방법입니다. 어떤 프로세스이든지 주요 시스템 유틸리티의 탐지 또는 보기에서 숨길 수 있습니다.


[그림 3] 루트킷이 실행되기 전의 프로세스 목록



[그림 4] 루트킷이 실행된 후 프로세스 목록

[그림 3]은 메모장이 notepad.exe(빨간색 원) 프로세스로 실행 중인 것을 보여줍니다. [그림 4]의 스크린샷은 프로세스를 숨기기 위해서 명령줄로 FU 루트킷이 실행된 후의 모습입니다. 이 스크린샷은 편집 중인 프로그램이 있더라고 실행 중인 프로세스 목록에서는 그 이름이 빠져 있다는 것을 보여 줍니다.


루트킷 탐지하기

루트킷에 대응하는 첫번째 단계는 탐지하는 것입니다. 루트킷 제작자는 항상 루트킷 탐지 도구보다 한발 앞설 가능성이 있습니다, 그래서 새로운 기술이 계속 개발되어야 하고 안티 바이러스 소프트웨어 개발자들은 그러한 기술을 분석할 시간과 탐지 도구들을 개발해야 합니다. 하지만, 루트킷이 외관상으로 복잡함에도 불구하고, 카스퍼스키 랩 버전 6 제품은 루트킷을 효율적으로 탐지합니다. 그럼 위에서 기술한 FU 루트킷에 대응하기 위해서 우리 제품이 어떻게 해야 할 것인가?

다시 말하면: 루트킷의 설치는 숨겨진 상태로 시스템 프로세스에서 실행됩니다. 안티-루트킷 서브시스템은 이 루트킷을 탐지하고 사용자에게 경고를 줍니다. [그림 5]



[그림 5] 숨겨진 프로세스 탐지

이 서브시스템은 안티바이러스 데이터베이스 업데이트에 이미 추가된 루트킷 뿐만 아니라 그림 6에서 처럼 아직 알려지지 않는 것까지 탐지할 수 있습니다.

사용자 모드 루트킷(다른 프로세스의 DLL 삽입)을 탐지하기 위해서 이와 유사한 서브시스템이 사용되고 있습니다. (이 문서의 첫번째 단락에 기술됨)

그런 경우에는, 서브시스템은 특정 프로세스가 다른 프로세스에 코드 삽입을 시도하면 사용자에게 통지하게 됩니다. [그림 6]



[그림 6] 다른 프로세스에 코드 삽입 탐지


유닉스용 루트킷

시스템에서 존재 숨기기

유닉스 시스템에서 루트킷은 윈도우와 매우 유사한 방식으로 사용됩니다. 공격자는 루트 권한을 얻으면 바로 루트킷을 설치합니다. 루트 권한은 루트킷을 설치하는데 필수적인 요소이고 원격 사용자가 일반 사용자의 권한을 가지고 있다면 알려진 취약점 등을 통하여 루트 권한을 획득할 수 있습니다. 이런 경우에서 원격 사용자는 패스워드 데이터베이스를 크랙하기 위하여 로컬 익스플로잇 또는 유틸리티를 사용할 수 있습니다. 만약 공격자가 권한을 얻지 못한다면 리모트 익스플로잇이 사용되거나 패스워드를 가로채기 위한 스니퍼 등을 사용할 것입니다. 패스워드 가로채기는 텍스트 기반으로 패스워드를 통신하는 서비스(ftp, telnet 등) 영역에서 사용됩니다.

루트킷은 취약한 시스템에 설치된 후 악성 프로그램(Trojan-DDos, backdoor 등)과 통합되어 원격에 있는 악성 사용자의 명령에 응답 할 것입니다. 이 외에도 루트킷은 다른 공격자의 침투를 막기 위하여 취약점의 패치를 포함하는 경우도 있습니다.

윈도우와 마찬가지로 사용자 모드의 루트킷과 커널 모드의 루트킷이 존재합니다.

사용자 모드 루트킷은 기본 프로그램을 트로이 목마와 통합시키고 시스템에서 통합된 프로그램의 존재를 숨깁니다. 그리고 백도어의 시스템 접근을 숨깁니다. 사용자 모드 루트킷의 일례로는 lkr, trOn, ark 등이 있습니다. 사용자 모드 루트킷의 하나인 trOn에 대해 좀 더 자세히 알아보겠습니다. trOn이 설치가 되면 syslogd 데몬을 중지시킨 후, 시스템 유틸리티(du, find, ifconfig, login, ls, netstat, ps, top, sz)를 트로이 목마화 된 버전으로 교체합니다. 여기에 sshd의 트로이 목마 버전을 시스템에 추가합니다. 마지막으로 백그라운드 모드로 스니퍼(sniffer)가 실행됩니다. inetd.conf에 telnetd, rsh, finger 데몬이 추가되고, inetd와 syslogd 가 재시작됩니다.

일반적으로 trOn은 /usr/src/.puta에 위치하지만, 트로이 목마 버전 ls 컴포넌트가 이미 설치되었기에 표시되지 않습니다.

이번에는 커널 모드 루트킷에 대해서 알아보겠습니다. 이 타입의 루트킷은 사용자 모드의 루트킷의 모든 기능이 있지만 하위 레벨에서 작동합니다. 사용자 모드 루트킷은 개별 바이너리 파일을 수정하도록 설계되었지만, 커널 모드 루트킷은 단지 커널만 수정합니다. 이런 루트킷이 더욱 효율적으로 활동을 숨길 수가 있습니다.

시스템 커널에 루트킷을 삽입하는 몇가지 방법이 있습니다.:

1. LKM(Loadable Kernel Module) 사용
리눅스 커널(그 외의 많은 OS와 마찬가지로)은 바로 모듈(또는 디바이스 드라이버)을 업로드하는 것이 가능합니다. 그리고 그것은 원격의 악성 사용자가 시스템 호출과 그 결과값을 수정하는 것을 가능하게 합니다. 이러한 공격은 LKM 의 도움 없이 모놀리스(monolith) 커널 컴파일에 의해 방지할 수 있지만, 이 방법은 모든 드라이버가 커널안에 포함되어야 하는 단점이 있습니다.

2. /dev/kmem에 쓰기
이것은 커널에 의한 메모리 점유 영역의 접속을 허용합니다. 사용자에 정보를 주지 않고 커널의 엔트리를 다시 씁니다. 커널 수정은 메모리 점유 영역을 찾아내는 것으로 간단히 완료할 수 있습니다. 그러나 이 문제에 대한 해결책은 있습니다. 직접 /dev/kmem에 쓰는 것을 불가능하게 수정할 수 있습니다. /dev/kmem에 쓰기는 mmap 호출에 사용될 수도 있습니다.

3. 존재하는 모듈 감염
루트킷 모듈이 별도로 있지 않고, 기존의 모듈에 삽입 연동된다는 점이 첫번째 방법과는 다른 점입니다. 이 방법은 항상 업로드되어서 모듈이 감염(예, 파일 시스템 드라이버)되므로, 시스템 재시작에도 견딘다는 것을 의미합니다.


루트킷 탐지

안타깝게도 루트킷을 찾아내는 방법에 대한 국제 규약을 만드는 것은 불가능합니다. 그러나 다음 방법으로 대다수의 루트킷을 찾아낼 수 있습니다.

  • 파일 동작에 관한 조사
    네트워크 자원 사용, 스케줄 작업 실행, 재시작시 작업, 사용자 계정 모니터링
  • 다음 유틸리티를 사용하여 시스템에서 루트킷 조사
    Saint Jude, Chrootkit, RkScan, Carbonite, Kstat, Rootkithunter, Tripware, Samhain 등.


결론

활동 중인 루트킷을 탐지하는 모든 방법은 어떤 방식으로든 시스템의 기능이 파괴되었다는 사실에 의존합니다. 카스퍼스키랩 제품도 이 방식을 사용합니다. 이 방식은 또한 알려지지 않은 루트킷을 찾아낼 수도 있습니다. 윈도우의 향후 버전에서는 루트킷을 쓰게 되는 것은 어려워지고 시스템 구조와 시스템 코드를 수정하는 것은 불가능합니다. 그렇기에 일시적으로 새로운 윈도우 버전에 대한 새로운 루트킷 숫자는 줄어들게 될 것입니다.

현재 윈도우가 가장 많이 사용되는 운영체제이기에 악성 코드도 유닉스보다 훨씬 많이 있습니다. 그러나 유닉스가 일반적으로 많이 사용하게 된다면 상황은 자연스럽게 변화될 것입니다. 유닉용의 새로운 루트킷이 작성될 것이고 그것을 탐지하기 위한 새로운 방법이 개발될 것입니다.

결론적으로 루트킷에 대한 최선의 방어는 모든 시스템에 적절한 보호를 하여 사전에 예방하는 것입니다.


관련 문헌

1. [VirusList] Kaspersky Lab, Viruslist.com, 2005
2. [iDEF2003] Anton Chuvakin, An Overview of Unix Rootkits, 2003
3. Linux Kernel Rootkit. Rainer Wichmann
4. Rootkit: Attacker undecover tools. Saliman Manap
5. www.phrack.org
6. www.securityfocus.org

원문: http://www.viruslist.com/en/analysis?pubid=168740859



   

메시지 남기기