suckit rootkit의 확산과 대응방법

suckit rootkit 의 확산과 대응 방법
오늘과내일 시스템운영부 홍석범(antihong@tt.co.kr)
1. 개요
최근 침해 사고를 당한 리눅스 시스템을 살펴보면 웹 해킹이나 brute force 등을 통해 일반
유저 권한을 획득 후 커널 등의 취약성을 이용해 root 권한을 획득한 후에는 suckit 이라는
rootkit 을 설치하는 경우가 자주 발견되고 있다. suckit 의 작동원리는 2001 년 phrack 의
Appendix 에 처음 소개되었는데, 아래 문서를 보면 비교적 상세한 실행 방법까지 소개되어
있다.
관련 phrack 홈페이지 : http://www.phrack.org/phrack/58/p58-0x07
suckit 의 경우 이전의 kernel 기반의 rootkit 과는 다른 방식으로 작동하는데, 특히 설치
과정에서 /sbin/init 를 변조하기 때문에 만약 루트킷 컴파일이 제대로 되지 않았을 경우
재부팅시 부팅 자체가 안 되는 현상도 일부 보이고 있다. 또한 뒤에서 자세히 설명하겠지만
작동 원리상 커널 모듈 설정이나 버전에 관계없이 일반적인 시스템에 모두 설치/작동되므로
그 피해가 커지고 있다.
2. suckit 의 특징
suckit 은 'super user control kit'의 의미로서 다음과 같은 특징을 가지고 있다.
① 적어도 필자가 아는 한 suckit 은 kernel module 이 지원되지 않아도 LKM(Loadable
Module Kernel)의 기능을 그대로 사용할 수 있는 유일한 rootkit 이다.
대부분의 kernel 기반 루트킷은 LKM 형태로 작동하므로 시스템에서 반드시 kernel module
기능이 enable 되어 있어야 하며 그렇지 않은 경우 module 을 적재(load)할 수 없고 결국
루트킷을 설치할 수 없다.
참고) module 기능이 제공되지 않는 커널 예
# lsmod
Module Size Used by Not tainted
lsmod: QM_MODULES: Function not implemented
② reverse telnet의 일종인 connect back 기능을 제공한다.
suckit 이 설치되어 있는 시스템의 경우 connect back 을 이용하여 별도의 백도어 포트를
bind 하지 않아도 원격지에서 직접 접근 및 제어가 가능하다. 아래는 실제 작동 예이다.
(필자의 테스트 결과로는 성공하지 못했다.)
[root@attacker tmp]# ./xxxx -x 192.168.1.2
[===== SucKIT version 1.3a, Jul 26 2004 <http://sd.g-art.nl/sk>
=====]
[====== ⓒoded by sd <sd@cdi.cz> & devik <devik@cdi.cz>,
2002 ======]
Listening to port 34245
password: xxx
Trying 192.168.1.2:53...
connect: Connection refused
Trying 192.168.1.2:79...
connect: Connection refused
Trying 192.168.1.2:110...
connect: Connection refused
Trying 192.168.1.2:220...
connect: Connection refused
Trying 192.168.1.2:21...
connect: Connection refused
Trying 192.168.1.2:22...
Trying...
Server connected. Escape character is '^K'
[===== SucKIT version 1.3a, Jul 26 2004 <http://sd.g-art.nl/sk>
=====]
[====== ⓒoded by sd <sd@cdi.cz> & devik <devik@cdi.cz>,
2002 ======]
[root@hacked .sk12]# <-- 해킹된 시스템에 접속
③ 재부팅시에도 적용되기 위해 별도의 추가 설정이 필요 없다.
이 말은 엄밀히 말하면 정확한 표현은 아니다. 그러나 대부분의 kernel 기반 루트킷은
재부팅 이후에도 자동으로 실행을 위해 cron 에 설정하거나 /etc/* 내 특정 부팅
스크립트에 교묘하게 추가하는 형태이다. 하지만 이 방법은 rkhunter 와 같은 보안
프로그램을 이용하거나 세심한 관리자라면 rootkit 의 설치를 쉽게 알아낼 수 있게 되지만
suckit 은 다른 방식으로 작동하므로 실행 파일 자체를 보이지 않도록 하기 때문에
발견하기가 매우 어렵게 된다.
suckit 은 설치 과정에서 pid 1 번인 /sbin/init 를 변조하거나 이후에는 /dev/kmem 을
변조함으로써 system call 을 intercept 하게 된다. 이것이 바로 suckit 작동시 커널 모듈이
필요하지 않은 이유이기도 하다.
④ 특정 파일과 디렉토리, 특정 process 등을 숨기는 기능이 있다.
이는 다른 LKM 기반의 rootkit 에서도 제공되는 기능중 하나이며 lids 와 같은 보안
커널모듈에서도 제공되는 기본 기능이다. 이를 통해 공격자는 각종 루트킷이나 백도어등을
다소 안전하게(?) 감출 수 있는 것이다. 특히 특정 파일이나 디렉토리는 설치 과정에서
특정한 이름으로 끝나기만 하면 모두 보이지 않게 되고, 공격자가 지정한 특정 process 는
ps 나 netstat등 어떠한 시스템 명령어로도 보이지 않게 된다.
⑤ 기본적으로 sniffing 기능이 포함되어 있다.
sniffing 은 root 권한을 획득한 공격자의 전형적인 절차이다. 그러나 서버나 네트워크
관리자에게는 이만큼 치명적인 피해가 없는데, 별도의 설정 없이 suckit 을 실행하기만 하면
스니핑을 하게되며 테스트해 본 결과 telnet 접속만 스니핑하는 것 같다. 스니핑 파일은
설치 디렉토리에 .sniffer 파일로 저장된다.
⑥ 변형된 rootkit 이 나오고 있다.
suckit 의 기본 실행 파일은 줄임자인 sk 이다. suckit 의 홈페이지는 http://sd.gart.
nl/sk/으로 되어 있는데, 접속이 되지 않는 것으로 보아 현재는 개발이 중단된 것으로
보이며 1.3b 가 최종 버전인 것으로 파악된다. 그러나 이후 zk 등 변형된 rootkit 이 나오고
있으며 메일링리스트에 따르면 소스를 일부 수정하여 개인적으로 변형하여 사용되는 경우도
있다고 한다.
3. suckit 의 설치 디렉토리 및 파일
suckit 은 설치 과정에서 다음과 같은 절차가 있다. 여기에서 처음 입력하는 xxxxx 암호는
이후 connect back 을 통해 원격지에서 해킹된 시스템에 접근시 인증하는 암호이며
시스템의 실제 root 암호와는 무관하다. 따라서 suckit 루트킷이 설치된 후 root 암호를
변경한다 하더라도 루트킷을 삭제하지 않는 한 그다지 의미가 없다 하겠다.
Please enter new rootkit password:xxxxx
Again, just to be sure:xxxxx
OK, new password set.
Home directory [/usr/share/locale/sk/.sk12]:
Magic file-hiding suffix [sk12]:
그 다음 rootkit 이 설치되는 Home directory 는 기본적으로 /usr/share/locale/sk/.sk12/
가 된다. 물론 이는 기본 디렉토리이며 공격자가 다른 경로를 지정했다면 설치 경로는
달라질 수 있다. 이 경로는 이후 여러 가지 방법으로 추적할 수 있다.
다음 설정 부분이 바로 파일이나 디렉토리를 숨길 수 있는 부분으로 여기에서 지정한
문자로 끝나는 파일이나 디렉토리는 보이지 않게 된다. 즉, 위와 같이 sk12 로 지정하였을
경우 aaaask12 나 .11sk12 와 같은 디렉토리나 파일은 find 나 ls 등으로도 보이지 않게
된다. 물론 wwwsk12333 과 같이 sk12 가 중간에 들어간 파일이나 디렉토리는 보일
것이다.
참고로 suckit 은 /sbin/init 를 변조한다고 하였는데, 위에서 지정한 접미사로 /sbin/init 의
백도어 파일도 존재하게 된다. 즉, 접미사를 sk12 로 지정하였을 경우 /sbin/initsk12 라는
파일이 존재하게 되는 것이다. (이 파일이 suckit 백도어일 수도 있고, 원본 init 파일일
수도 있다.)
그렇다면 공격자는 재부팅시에도 suckit 루트킷이 자동 실행되도록 어떻게 지정할까?
먼저 공격자는 앞의 기능을 활용하여 /etc/rc.d/rc3.d/S98sk12 와 같은 파일을 만들어 둔다.
이러한 경우 파일이 보이지 않기 때문에 관리자의 눈에 보이지도 않으면서 재부팅시에도
원하는 명령어를 실행하도록 설정할 수 있을 것이다. 또는 /sbin/init 를 변조하였다면 이
binary 자체에 특정 경로의 파일을 자동 실행하도록 되어 있기 때문에 이 경로에 있는
스크립트를 이용해도 된다. 만약 기본 설정으로 설치했다면 /usr/share/locale/sk/.sk12/.rc
파일을 자동 실행하게 된다. 이 경로는 “strings /sbin/init” 명령어로 확인할 수 있다.
다음은 suckit rootkit 이 설치된 후 실행 파일인 s k 를 실행하였을 때 보이는 메뉴이다.
옵션에 따라 특정 파일이나 process 등을 보이게 하거나 보이지 않도록 할 수 있는 기능이
있다는 것을 알 수 있다.
[root@antihong /usr/share/locale/sk/.sk12]# ./sk
/dev/null
Detected version: 1.3b
use:
./sk <uivfp> [args]
u - uninstall
i - make pid invisible
v - make pid visible
f [0/1] - toggle file hiding
p [0/1] - toggle pid hiding
4. suckit 을 발견 및 삭제하는 방법
그렇다면 suckit 은 어떻게 발견할 수 있을까? 설치 과정에서 설치 경로나 hidden
접미사를 임의로 설정하였을 경우 실제로 찾기는 쉽지 않다. 제일 쉽고 좋은 방법은
chkrootkit (http://www.chkrootkit.org/)을 이용하는 방법이다.
(ckkrootkit 이용에 대해서는 필자의 저서 “리눅스 서버 보안관리 실무” 9 장에 자세히
설명되어 있다.)
chkrootkit 을 실행시 /sbin/init 가 INFECTED 라고 나온다면 99% suckit 일 가능성이
높으며 이때는 strings 로 원본의 깨끗한 /sbin/init 와 비교해 보면 설치 경로와 hiding
suffix 등을 확인할 수 있다. 또한 chkproc 를 실행시 hidden process 가 확인되면 다음과
같이 확인해 보기 바란다. (아래는 13524 가 hidden process 인 경우)
# ls -al /proc/13524
total 0
dr-xr-xr-x 3 root root 0 Feb 22 14:08 .
dr-xr-xr-x 79 root root 0 May 8 2004 ..
-r--r--r-- 1 root root 0 Feb 22 14:08 cmdline
lrwxrwxrwx 1 root root 0 Feb 22 14:08 cwd -> /
-r-------- 1 root root 0 Feb 22 14:08 environ
lrwxrwxrwx 1 root root 0 Feb 22 14:08 exe -> /usr/share/locale/sk/.sk12/sk
(deleted)
위의 경우 hidden process 의 경로가 기본 경로인 /usr/share/locale/sk/.sk12/ 인 것을 알
수 있다.
자. 그럼 suckit 이 설치되었을 경우 어떻게 조처하여야 할까?
① 혹시 모르니 먼저 데이터를 백업받기 바란다.
아울러 /sbin/init 파일도 /sbin/initbak 등과 같은 파일로 백업받기 바란다.
② rkhunter 등과 같은 보안 프로그램을 활용하여 다른 변조된 파일은 없는지 확인해
보기 바란다. 어떤 시스템의 경우 부팅 스크립트인
/etc/rc.d/init.d/syslog 파일에
/etc/locale/zh/LC_MESSAGES/initscclkkspps/utmpd.pidxlkkspps 와 같이 지정되어 있어
syslog 데몬 실행시 suckit 이 자동 실행되도록 설정한 경우도 있었다. (이러한
경우 hiding suffix 는 lkkspps 이었다.)
③ suckit 삭제툴을 이용한다.
suckit 을 삭제하는 방법은 두 가지가 있다.
suckit 자체적으로 지원되는 삭제 옵션을 이용하거나 전용 삭제툴을 이용하는 방법이다.
먼저 sk 를 그대로 이용하는 방법이다.
먼저 sk 실행 파일을 찾는다. 위와 같이 hidden process 를 찾아 경로를 확인하기 위해
실행했을 때 삭제된(deleted) 상태라면
# cp -a /proc/pid/exe /root/sk
와 같이 실행하면 해당 파일을 /root/sk 파일로 복원할 수 있다. 파일은 삭제되었어도
메모리상에는 그대로 존재하기 때문에 가능한 것이다.
이후 sk 를 실행시 아래와 같이 uninstall 의 의미인 u 옵션을 주어 실행하면 된다.
[root@antihong /usr/share/locale/sk/.sk12]# ./sk u
/dev/null
Detected version: 1.3b
Suckit uninstalled sucesfully!
suckit 이 process 에서 삭제된 것을 알 수 있다.
이후 만약 /sbin/init 가 변조되었다면 이 파일을 삭제하고 원본의 깨끗한 /sbin/init 로
덮어쓰거나 /sbin/initsk12 와 같이 숨김 상태로 있는 파일을 찾아 대체하면 된다.
두 번째는 skdetect라는 별도의 전용 삭제툴을 이용하는 방법이다.
이는 http://tsd.student.utwente.nl/skdetect/ 디렉토리에 접속하거나
http://tsd.student.utwente.nl/skdetect/skdetect-0.4b.tar.gz 파일을 직접 다운로드 해도
된다. 다운로드 및 압축을 해제하고 make all 로 컴파일하면 된다.
이후 아래와 같이 실행하기만 하면 되는데, 만약 suckit 이 process 상에 설치되어 있지
않다면 아래와 같이 보이게 된다.
[root@antihong ~/skdetect-0.4b]# ./skdetect
suckit rootkit not detected.
만약 설치되어 있었다면 아래와 같이 성공적으로 삭제되었다는 메시지가 보이게 된다.
이후, 위의 방법과 마찬가지로 /sbin/init 의 변조 여부를 확인한 후 적절히 처리하면 된다.
[root@antihong ~/skdetect-0.4b]# ./skdetect
suckit version '1.3b' DETECTED (0000013b), unloading kernel-part.
kernel-part uninstall seems succesful.
5. 결 론
지금까지 suckit 의 작동원리와 확인 및 삭제하는 방법에 대해 살펴보았는데, 그럼 suckit 과
같은 rootkit 에 대해 어떻게 대응하여야 할까?
① 커널에서 module 기능을 해제하고 사용한다.
이는 suckit rootkit 에 대한 대응 방법은 아니지만 이러한 경우 대부분의 LKM 기반의
커널 백도어에 대한 방어가 될 수 있다. 만약 module 기능을 해제하려면 커널
메뉴에서 Loadable module support ---> 선택후 [ ] Enable loadable module
support 와 같이 선택하지 않으면 된다.
② anti kernel 백도어 module 을 이용한다.
StMichael(http://sourceforge.net/projects/stjude/)등과 같이 kernel 백도어에 대응하기
위한 anti 모듈을 이용하는 방법도 있다. StMichael 의 경우 suckit 에 대해서도
잘 방어하는데, 만약 실행하기전 이미 suckit 이 작동중인 상태에서는 작동하지 않는다.
그러나 언제나 그러하듯 커널 모듈은 매우 critical 하므로 load 시에는 주의하여야 한다.
③ grsecurity 등의 security kernel 을 이용함으로써 /dev/kmem device 에 대한 write 기
능을 제한하도록 한다. 아직 사용해 보지는 않았지만 이러한 경우 몇몇 정상적인 서비
스에 장애가 발생할 수 있다고 한다.
그러나 가장 좋은 방법은 역시 꾸준한 관리와 관심으로 해킹을 당하지 않도록 하는 것이다.
그리고 해킹을 당했다고 해서 무조건 재설치가 능사는 아니다. 해킹을 당했다면 어떤
취약성을 통해 어떤 경로로 공격하게 되었는지 그리고 수법은 어떠한지 역추적하는 것이
매우 중요하다. 그래야만 이후에라도 더 큰 사고를 예방할 수 있기 때문이며 그렇지 않은
경우 재설치를 해도 다시 해킹을 당할 가능성이 있기 때문이다.
공격자 입장에서 시스템의 일반 유저 권한을 획득하는 것은 어려워도 이후 일반유저에서
root 권한을 획득하는 것은 그리 어렵지 않다. 따라서 쉬운 암호를 사용하는 계정은 없는지,
웹 해킹은 가능하지 않은지, 불필요한 서비스는 떠 있지 않은지등 기본적인 보안 설정부터
살펴보는 것이 보안의 왕도로 할 수 있을 것이다.
혹 잘못된 내용이나 추가될 내용 등이 있으면 언제든 메일(antihong@tt.co.kr) 을 주기
바란다.