|
ANTON
|
2009-06-28 05:23:36, 조회 : 170, 추천 : 38 |
kcore의 분석
이 글의 이번 section에서, 나는 프로세스들과 메모리 이미지들의 한 가지 분석 방법을 보여주고자 한다. 이미징(imaging) 작업이 완료된 후에, 여기 전체 단계는 원격 호스트에서 실행되어져야 함을 기억하라. 이 방법의 가장 큰 장점은 사용되는 low-level 프로그램 언어를 몰라도 된다는 것이다. 나는 침입의 징후를 검색하기 위해서 다음의 간단한 도구들을 사용할 것이다.
? strings
? less
? grep
우리는 문자열 도구를 이용함으로써 이미지 파일로부터 모든 출력가능한 문자들을 모을 것이다. 기본 설정은 우리에게 적어도 4개의 문자열길이로 출력가능한 문자의 연속들을 보여준다. 우리는 파일의 시작으로부터 offset을 더하기 위해 -t 스위치를 사용할 것이다.
$ strings -t d kcore > kcore_strings
$ md5sum kcore_strings > kcore_strings.md5
여기 초기 분석에서 grep 도구와 정규표현식(regular expressions)은 중요하다. 몇 분안에 우리는 침입의 증거를 찾을 수 있다. 우리가 찾으려고 하는 데이터가 어떤 종류인지를 우리는 생각하여야 한다. -- 예를 들어, 우리는 침입자가 입력한 명령어들, IP 주소들, 패스워드들 또는 악의적인 코드의 해독된 부분까지를 찾고 있는가?
아래에 찾아야 할 keyword들의 몇 가지 예제가 있다. 우리는 이것들을 우리의 kcore_strings 파일안에서 침입의 증거를 찾는 데 사용한다.
?O host name or prefix of the compromised system
$ grep "root@manhunt" kcore_strings
$ grep "]#" kcore_strings
11921096 [root@manhunt]#
16643784 [root@manhunt root]#
30692969 ]#]#
위의 결과에서 우리는 문자열들의 offset들의 일부를 나열하였다. 다음 단계는 (less 도구와 같은) 텍스트 편집기로 파일을 열고 직접 offset 주소에 근접한 파일안의 위치로 뛰어 넘는 것이다. 운이 좋다면, 우리는 과거에 실행되었던 다른 명령어들을 찾을 것이다. 그러나 물리적 메모리안의 가상메모리의 페이지들과 스왑 공간이 정렬되지 않은 방식으로 쓰여졌고, 그러므로 우리의 결론은 또한 완벽히 무효화될 수 있다는 것을 기억하여야만 한다.
$ less kcore_strings
/11921096
11921096 [root@manhunt]#
11921192 /usr/bin/perl
11921288 perl apache_mod_exploit.pl
...
위의 예제는 공격받은 시스템에서 입력되었던 명령어들의 일부를 보여준다.
O file and directory names
$ grep -e "\/proc\/" -e "\/bin\/" -e "\/bin\/.*?sh" kcore_strings
$ grep -e "ftp" -e "root" kcore_strings
$ grep -e "rm -" kcore_strings
$ grep -e ".tgz" kcore_strings
?O ip addresses and domain names
$ grep -e "[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+" kcore_strings
$ grep -e "\.pl" kcore_strings
2.7 고급 포렌식 분석 (Advanced forensic analysis)
이 마지막 장에서, 나는 gdb 도구를 사용하여 복사된 kcore 파일을 어떻게 분석하는지를 보여줄 것이다. 처음에 나는 syscall 테이블안의 시스템 콜 주소들이 올바른지를 어떻게 검사하는가를 기술한다. 시스템 콜 주소들을 바꾸는 것은 공격받은 시스템상에 LKM 기반의 루트킷을 설치하는 가장 쉬운 방법이다. 다음 예제에서 나는 과거에 공격받은 시스템상에서 실행된 모든 프로세스들을 어떻게 나열하는 지를 보여준다. 이 예제들의 결과들은 단계 7과 8에서 받았던 결과들과 비교해 볼 수 있다.
분석을 시작하기 위해서 우리는 다음의 정보를 필요로 한다:
?O ELF core format 형식의 메모리 이미지 (단계 6을 보아라)
?O 컴파일된 커널 이미지 (우리는 공격받은 시스템의 파일 시스템 이미지들을 마운트하여야 하고 /boot 디렉토리로부터 vmlinux-* 라는 이름의 파일을 복사하여야 한다.)
?O exported symbols의 목록 (System.map 파일은 공격받은 시스템의 /boot 디렉토리에서 찾을 수 있거나 우리는 ksyms 파일을 이용할 수 있다. - 단계 7을 보아라)
?O 공격받은 컴퓨터에 사용된 커널의 소스파일 ( 소스 코드가 공격받은 컴퓨터상에서 사용가능하지 않다면, 우리는 동일한 버전을 인터넷 웹 사이트: www.kernel.org 에서 다운로드 받어야만 한다.)
다음 단계는 아래와 같이 gdb 도구를 실행하는 것이다:
#gdb vmlinux kcore
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
warning: core file may not match specified executable file.
Core was generated by `ro root=/dev/sda2 hdc=ide-scsi'.
#0 0x00000000 in ?? ()
(gdb)
이제 우리는 분석을 시작할 준비가 되었다.
예제 1: 시스템 콜 주소들의 검증
우리의 첫 번째 단계는 시스템 콜 테이블 (sys_call_table)의 주소를 찾는 것이다. 거의 모든 리눅스 운영체제에서 이 정보는 exported 되고 Symbol.map 파일에서 찾을 수 있다.
# cat Symbol.map | grep sys_call_table
c02c209c D sys_call_table
이제 우리는 sys_call_table로부터 등록사항들(entries)을 나열할 수 있다. 각 등록사항(entry)은 시스템 콜의 주소이다. 등록사항들을 적절하게 해석하기 위해서 나는 공격받은 시스템의 커널 소스파일로부터 entry.S 파일을 살펴보기를 권장한다. 이 파일은 시스템 콜들의 올바른 순서를 포함한다.
ENTRY(sys_call_table)
.long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/
.long SYMBOL_NAME(sys_exit)
.long SYMBOL_NAME(sys_fork)
.long SYMBOL_NAME(sys_read)
.long SYMBOL_NAME(sys_write)
.long SYMBOL_NAME(sys_open) /* 5 */
.long SYMBOL_NAME(sys_close)
...
동일한 순서가 sys_call_table안에 있다. 시스템 콜들의 첫 10개의 주소들을 나열하기 위해서 우리는 다음과 같이 한다:
(gdb) x/10x 0xc02c209c
0xc02c209c <sys_call_table>: 0xc01217c0 0xc011ac50 0xc0107510 0xc0138d50
0xc02c20ac <sys_call_table+16>: 0xc0138e50 0xc0138880 0xc01389b0 0xc011b010
0xc02c20bc <sys_call_table+32>: 0xc0138930 0xc01445c0
주소 0xc01217c0는 sys_ni_call 시스템 콜이고, 주소 0xc011ac50는 sys_exit 시스템 콜이고, 등등이다.
만약 우리가 System.map 파일이나 ksyms 파일들로부터 주소들을 신뢰한다면 우리는 거의 모든 각각의 주소를 비교할 수 있다. 물론 침입자들이 시스템 콜들의 각각의 주소를 바꾸지 않고, sys_read, sys_getdents 또는 sys_write와 같은 몇몇 일반적인 것만 바꾼다.
예제 2: 활동중인 프로세스들의 목록
활동중인 프로세스들의 전체 목록을 생성하려면 우리는 init_task_union 구조체의 주소를 찾아야만 한다. 이 구조체는 "process 0" 또는 "swapper"라고 불리우는 첫 번째 프로세서 기술자(descriptor)를 가리킨다.
# cat Symbol.map | grep init_task_union
c02da000 D init_task_union
다음 단계는 이 구조체가 어떻게 생겼는지 알아내는 것이다. init_task 구조체의 예제는 공격받은 시스템의 커널 버전의 소스 코드안에 sched.h 파일내에서 찾을 수 있다. task_struct 구조체도 이 파일 안에서 또한 찾을 수 있다.
#define INIT_TASK(tsk)
{
state: 0,
flags: 0,
sigpending: 0,
addr_limit: KERNEL_DS,
exec_domain: &default_exec_domain,
...
run_list: LIST_HEAD_INIT(tsk.run_list),
time_slice: HZ,
next_task: &tsk,
prev_task: &tsk,
p_opptr: &tsk,
...
우리에게 있어서, 가장 중요한 부분은 (task_struct 형으로 선언된) 각 프로세스 기술자(descriptor)의 prev_task와 next_task이다. 이것들은 우리가 프로세스들의 목록을 만들 수 있도록 도와준다. next_task 항목은 다음 프로세스의 프로세스 기술자를 가리키고, prev_task 항목은 목록안에서 바로 이전에 삽입된 프로세스 기술자를 가리킨다.
아래의 예제에서 나는 주소 0xc514c000에서 찾을 수 있는 프로세서 기술자(task_struct 형으로 선언된)의 일부분들을 나열한다.
(gdb) x/180x 0xc514c000
...
0xc514c040: 0x00000000 0xffffffff 0x00000004 0xc1be0000
0xc514c050: 0xc4dac000 0xc5ea8e40 0xc5ea8e40 0xc02c56d4
...
0xc514c070: 0x00000001 0x00001ace 0x00001ace 0x00000000
...
0xc514c230: 0xffffffff 0xffffffff 0x61620000 0x00006873
0xc514c240: 0x00007974 0x00000000 0x00000000 0x00000000
...
여기서:
0xc1be0000는 next_task이다.
0xc4dac000는 prev_task이다.
0x00001ace는 프로세서 PID(= 6268 십진수 형식)이다.
0x61620000와 0x00006873는 프로세서의 이름이다. (구조체안에서 comm 테이블) 이 특별한 예제에서 = "bash"
다음 프로세서 (task_struct 형으로 선언된)의 프로세스 기술자를 출력하려면 다음과 같이 한다:
(gdb) x/180x 0xc1be0000
각 프로세스 기술자로부터 정보를 가져오면 우리는 활동중인 프로세스들의 완전한 목록을 만들 수 있다.
3. 요약
이 글의 목표는 데이터 수집, 기초 및 고급 분석에 사용되는 방법들의 일부분을 제공하는 것이었다. 특별히 나는 시스템의 전원을 끈 후에 완벽하게 소실되어 버릴 수 있는 데이터에 집중하였다. 포렌식 분석과 침입사고 대응 과정에서 이 부분이 제일 수행하기 어렵다. 우리는 모든 단계들에서 매우 주의하여야 한다. 그리고 또한 우리가 모든 것을 문서화하고 있는 지를 확실하게 해야 한다. 우리는 또한 운용중인 시스템의 소프트웨어적인 수집과정의 이점들과 단점들의 몇몇을 이미 보았다. 결론적으로, 나는 리눅스 운영체제에서 수집과정이 어떻게 되는지를 보여주었지만, 우리는 다른 운영체제에서도 거의 동일한 단계들을 수행할 수 있다. 앞으로 쓰게 될 글은 여러분에게 어떻게 운용중인 윈도우즈 운영체제 시스템으로부터 휘발성의 데이터를 모으는 지를 보여줄 것이다.
|
|
|
