해킹정보.. 보안관련 FAQ 해커가 침입하기 가장 좋은 시기와 환경은? 전산망을 구성하는 네트워크의 끝에는 네트워크를 구성하기 위한 컴퓨터들(호스트)들이 붙어 있 어야 하고 이 호스트들은 운영체제를 돌리게 마련이다. 하지만 OS 는 인간이 짠 프로그램인 이상 버그가 있게 마련이고 이 버그로 말미암아 보안상의 문제가 유 발되는 것이다. 유닉스 시스템과 같이 멀티유저들이 사용하는 시스템은 보안상 완벽해질 수 없다 는 것이 수학적으로 증명이 됐다 . 더군다나 이 호스트를 네트워크 상에 연결해놓게 되면 더 문제가 일어나게 되는데, 호스트 내부 의 버그를 패치하지 않은 채 네트워크 상에 올려놓게 되면 '밥을 차려 놓았으니 밥을 먹도록 하 시오'라고 해커들에게 내주는 셈이 된다. 그래서 가장 완벽하게 보안 을 유지하고 싶으면 네트워 크에 올려놓기 전에 내부 홀(hole)을 완전히 패치를 하고, 그 다음에 네트워크에 연결해놓는 것이 좋다. OS를 갓 인스톨하고 난 직후에는 OS의 버그들이 아직 남아 있는 상태여서 이 때 해커들에게 침 입을 받게 되면 속수무책이 된다. 또한 불필요한 서비스를 많이 하는 경우 해커들이 침입을 하기 더 좋아지게 되므로, 가급적이면 불필요한 서비스는 하지 않는 것 이 좋다.(guest 아이디 제공이나 sonnim 아이디 제공 같은 경우) 보안을 강화해주는 도구에는 어떤 것이 있나 (혹은 보안을 자동화해주는 프로그 램은?) 우선 보안을 자동화해주는 툴은 있을 수도 없고, 있어서도 안되고, 있지도 않다. 전세계적으로 컴 퓨터 보안은 활발한 연구의 대상이 되고 있다. {{{{ftp://cert.org }} }}이나, {{{{ftp://coast.cs.purdue.edu }} }} 등에서 좋은 툴을 얻을 수 있고 또 KUS 팀 도 서서히 툴 개발을 시작하고 있다. 보안도구는 크게 점검 도구와 감시도구로 나눠지는데 다시 로컬 호스트용과 네트워크용으로 나눌 수 있다. Local host check : cops, tiger, crack monitor: tripwire, ttywatcher Network check : satan, iss, nfsbug, ypx monitor: netlog 해커가 컴퓨터에 침입하는 방법에는 어떤 것이 있나 null &default passwd account or passwd guessing tftp attack ethernet sniffing /etc/hosts.equiv exploit (특히 SunOS 4.1.x) NFS mount attack NIS domain name guessing Sendmail Attack X window System Attack WWW Attack NFS file handle guessing DNS hack IP Spoofing 그 외 다수(예: rexd, AIX rlogin -froot...) 해커가 슈퍼유저의 권리를 획득하는 방법에는 어떤 것이 있 나. OS마다 다르지만 대부분 허술한 set-user-id root 프로그램들을 이용한다. SunOS 4.1.x를 예를 들어보면 /usr/local/bin/autoreply /usr/ucb/rdist /bin/mail race /bin/passwd race /usr/openwin/bin/loadmodule sun sendmail 4.1 sendmail 8.6.9 debug hole 위의 리스트는 일반적으로 잘 알려진 것들인데 그것들 말고도 suid root 프로그램들을 일단 모두 스캔해 본 후 OS외에 다른 소프트웨어 인스톨 과정에서 생긴 것이 있으면 system call들을 추적하 며 조사한다. 혹, 소스 파일이 같이 있다면 좋다. 어느 suid root 프로그램의 소스 중에서.. if (!(editor = getenv("EDITOR"))) editor = "vi"; if (fork()) (void) wait(&junk); else { (void) execlp(editor, editor, fname, NULL); fprintf(stderr, "Whoops! Failed to exec %s\n", editor); exit(1); } 위의 경우라면 해커는 search path list에(current directory)를 맨 처음 놓고 루트 쉘을 만드는 vi 라 는 자신의 프로그램을 만 든 후 위의 suid root 프로그램을 실행시킨다. 그러면 루트 권한으로 해 커의 프로그램이 실행되어 루트 쉘이 만들어진다. /usr/openwin/bin/loadmodule, IRIX 4.0.x 의 /usr/lib/vadmin/serial_port 등을 그와 같은 조건을 이용해서 공격한다. 컴퓨터에 침입자가 있는지 어떻게 파악하는가 관리자의 지속적인 관심이 중요하다. 늘 시스템 로그를 확인하고 파일 시스템을 모니터한다면 조 금이라도 변화가 생기더라도 파악이 가능하다. 보안 관련 도구와 자료는 어디서 구할 수 있나 {{{{http://www.cert.org }} }} {{{{http://www.8lgm.org }} }} {{{{http://www.cert-kr.or.kr }} }} news://comp.security.unix {{{{ftp://ftp.cert.org }} }} {{{{ftp://coast.cs.purdue.edu }} }} {{{{ftp://ftp.cert-kr.or.kr }} }} 파이어월은 어느 선까지 신뢰할 수 있나 설치를 하는 사람의 보안 지식 및 파이어월 툴킷 매뉴얼에 대한 이해 정도에 따라 편차가 심하 다. 상당수의 파이어월은 잘못 셋업된 채 운영된다. 시스템 및 네트워크 모니터링으로 인한 성능저하와 개개인의 프라이버시 침해문제 는 어떻게 해결하나? 시스템 모니터링으로 인한 성능 저하는 거의 없다고 보아도 좋다. 세션 모니터 툴인 ttywatcher나 파일 시스템 모니터 툴인 tripwire는 관리자가 필요할 때 잠시 사용하거나 cron job으로 실행되기 때문에 별다른 영향이 없다. 그러나 네트워크 모니터링은 엄청난 성능 저하를 가져온다. 썬의 nit 를 사용하면 필터 패턴에 따라 달라지긴 하지만 30~70% 까지의 패킷 손실이 생기므로(spray했을 때) 네트워크 쪽의 퍼포먼스가 많이 떨어진다. 그래서 tcpdump 3.0부터는 BPF(BSD Packet Filter)를 사용하여 스택 구조를 사용하는 Sun의 NIT보다는 10~150배, CSPF(CMU/Stanford Packet Filter) 보 다는 1.5~20배 빠른 성 능향상을 거두었다(Comment by {{{{chan@ra.snu.ac.kr }} }}) 개인의 프라이버시 침해 문제는 관리자의 도덕성에 달려 있는데 외국에서는 시스템, 혹은 시큐리 티 관리자는 반드시 선서를 거 친다고 한다. 보안을 일방적으로 강화하다 보면 컴퓨터의 편리성이 떨어진다고 하는데, 어느 선 까지 보안을 강화하는 게 바람직한가. 일례로 X윈도우 시스템의 보안을 강화하는 것으로 MIT-MAGIC-COOKIE 라는 토큰방식을 이용한 xauth라는 프로그램이 있다. 그러나 이것의 사용방법은 가히 살인적이다. X 애플리케이션을 실행 할 때마다 일일이 토큰을 넘겨줘야 하기 때문이다. 따라서 적당한 선이 중요하다. 그리고 그것은 컴퓨터의 중요성에 밀접한 관계가 있다. 국가 정보기관의 호스트와 인터넷 실습용으로 사용 하는 대학의 낡은 워크스테이션을 비교해서 생각하면 된다. 실제로 국내의 많은 대학의 호스트들 은 전혀 보안이 고려되고 있지 않아서 초보 해커들의 좋은 연습 대상이 되기도 한다. 적당한 선을 실용적으로 규정지어 본다면 "관리자의 메일박스에 사용자들로부터의 불평 과 불만 메일이 시스템 로그 리포트 메일보다 더 많이 쌓이는 때이다" 최신 해킹 유형들 최근에는 해킹기술이 고도로 발달돼 예전에는 상 상할 수도 없었던 고난도의 해킹 기술들이 존재 하게 됐다. 예전에는 기껏해봐야 관리자의 실수나 OS에서 실수를 한 프로그램들을 악용해 관리자 의 권한을 얻는 것이 고작이었지만, 이제는 네트워크 상을 흘러 다니는 정보의 기본단위인 패킷 (packet: 네트워크상에 정보를 송수신할 때 가장 기본이 되는 정보단위)을 하나하나 조작해 해 킹 을 하게 됐다. 이런 고난도 해킹의 예는 패킷 스니퍼링(packet sniffing)과, IP 스푸핑(IP Spoofing: IP 사기 치기), NFS(Network File System) file handle guessing, dns server cache poisoning(네임 서버(IP 에 일대일 매치되는 네임 어드레스를 관리하는 호스트)에 잠입해 가짜 호스트들을 만들고 나오는 것) 등이 있는데 이중에서 스니퍼링 과 스푸핑에 대해서만 다뤄 보기로 하자. 가장 심각한 해킹 기술, Sniffing 패킷들은 이더넷 케이블을 타고 전송이 된다. 이 패킷들은 어떤 유저가 어느 호스트에 로긴했다 는 정보 따위를 가지고 있는데, 이더넷 디바이스를 컨트롤해 흘러가는 패킷에서 원하는 정보인 유저들의 패스워드를 알아내는 것 으로서 요즘 가장 심각한 문제가 되는 해킹 기술이다. 최근 해 커들의 공격들의 통계를 내본 자료를 보면 스니핑에 의한 공격이 가장 많은 것으로 나타나고 있 다. 스니퍼(Sniffer)란 무엇인가? 스니퍼는 네크워크의 한 호스트에서 실행되어 그 주위를 지나다니는 패킷들을 엿보는 프로그램 으로서 계정과 패스워드를 알아 내기 위해서 침입자들에 의해 자주 사용되는데 아무리 네트워크 보안에 신경을 쓴 호스트라도 주 변의 호스트가 공격당해서 스니핑을 위해 사용된다면 무력해질 수밖에 없다. 이해를 돕기 위해 실제 스니핑 세션을 가지고 설명한다. mordor# ./sniffit Log started at => Mon Apr 8 20:29:04 [pid 10937] -- TCP/IP LOG -- TM: Mon Apr 8 20:29:44 -- PATH: rohan.kaist.ac.kr(1270) => gondor.kaist.ac.kr(telnet) STAT: Mon Apr 8 20:29:48, 30 pkts, 77 bytes [TH_FIN] DATA: (255)(253)^C(255)(251)^X(255)(251)^_(255)(251) (255)(251)!(255)(251)"(255)(253)^E(255)(251)#(255)(251)$(255)(250)^X : IRIS-ANSI-NET(255)(240)(255)(253)^A(255)(252)^Aaragorn : evenstar : cls : du -s -k * : elm awen -- TCP/IP LOG -- TM: Mon Apr 8 20:31:57 -- PATH: mordor.kaist.ac.kr(2389) => gondor.kaist.ac.kr(telnet) STAT: Mon Apr 8 20:32:24, 106 pkts, 128 bytes [DATA LIMIT] DATA: (255)(253)&(255)(251)&(255)(253)^C(255)(251)^X(255)(251)^_(255)(251) (255)(251)!(255)(251)"(255)(251)$(255)(253)^E(255)(251)#(255)(250)^_ : P : ^X(255)(240)(255)(250) : 9600,9600(255)(240)(255)(250)^X : XTERM(255)(240)(255)(253)^A(255)(252)^Agaladriel : shwjdtjr=JD : : setenv DISPLAY rohan.kaist.ac.kr:0.0 : ne 위는 스니퍼 프로그램을 돌린 결과이다. gondor, mordor, rohan은 M학과의 전산실의 기계들인데 이미 침입자는 mordor에서 루트 권한을 따냈었고 스니퍼 프로그램을 실행시키고 있다(스니퍼가 동작하기 위해서는 네크워크 디 바이스의 조작이 필요한데 이는 루트(시스템 관리자)만이 할 수 있다). 그렇다면 물리적인 네크워크 구도에서 인접해있는 호스트 들은 모두 스니핑을 당하게 된다 . 처음 블럭에서 rohan에서 gondor로 aragorn이라는 계정으로 telnet 로긴을 한 것이 잡혔는데 이때 패스워드가 evenstar임을 알 수 있다. 그리고 로긴 직후에 실행한 몇몇 명령까지 잡혔다. 일반적으 로 스니퍼 프로그램은 비교 적 작은 크기의 제한된 버퍼를 사용하는데 필요에 따라 그것을 늘이 기도 한다. 이더넷의 설계상 약점과 네트워크 스니퍼의 원리 가장 일반적인 LAN의 구성 방법은 이더넷을 사용하는 것으로 주변에서 가장 쉽게 접하는 경우이 다. 이더넷을 통한 통신 방법은 매우 간단하다. A라는 호스트가 B라는 호스트로 패킷을 보내고 싶다면 호스트 A는 B와의 배타적 인 연결을 통하는 것이 아니라 그 패킷을 이더넷에 뿌린다. 그 리고 그 패킷은 일반적으로 수신 주소의 호스트만이 받도록 기대된 다. 즉 일반적으로 자신에게 오지 않는 패킷은 받지 않으므로 호스트 B만이 A가 보내는 패킷을 받게 된다. 그러나 그것은 기대 사항일 뿐 언제라도 깨어질 위험부담을 안고 있는 프로토콜이다. 네크워크 디바이스는 자신에게 오지 않고 다른 호스트를 향해 지나가는 패킷까지 받는 상태에 들어갈 수 있는데, 그때를 'Promiscuous mode'라고 부른다. 스니퍼는 바로 그 상태에서 동작한다. 이렇게 네 트워크의 설계상의 커다란 약점이 있기 때문에 스니퍼에 의한 공격은 치명적이며 일부 OS를 제 외하고는 찾아내기가 곤란한 경우가 많고 막기 위해서도 많은 부담이 따른다. 스니퍼의 설계 스니퍼는 너무나 쉽고, 비열하게 해킹을 할 수 있기 때문에 해커들 간에서는 스니퍼를 이용하는 해커를 3류 취급해 상대도 하지 않는다. 이처럼 스니퍼는 해커들 사이에서조차 금기(?)시되는 치 사한 프로그램이지만 그 자체로 는 아주 훌륭한 네크워크 프로그램이다. 실제로 대부분의 네트워 크 분석 프로그램들은 Promiscuous mode에서 동작하며 또 그럴 수밖에 없다. 그리고 스니퍼의 핵심을 이루는 코드는 대부분의 OS에서 독립된 프로토콜로서 지원을 하는데 SunOS의 NIT, IRIX의 SNOOP이 좋은 예이다. 잘만 이용하면 침입자들을 상대하는 관리자들에게 큰 무기가 될 수 있다. 네트워크를 감 시하는 데 사용할 수 있다는 말 이다. netlog({{{{ftp://ftp.cert-kr.or.kr/pub/tools/etc/netlog/netlog -1.2.tar.gz }} }})라는 좋은 툴이 이미 있다. 이 툴의 성격을 잘 말해주듯이 telnet과 ftp의 모듈은 제외돼 있다. 패스워드 스니핑에 사용되는 것을 막기 위함일 것이다. 스니퍼는 일반적으로 다음과 같은 일련의 동작을 하는 코드로 구성된다. 네트워크 디바이스를 열어서 Promiscuous mode로 만든다. 지나가는 모든 패킷을 읽는다. 패킷을 필터링해서 발신 및 수신 주소, 서비스(telnet, rlogin, ftp, smtp 등), 그리고 계정과 패 스워드가 포함된 데이터를 구분해서 출력한다. 3번의 기능을 하는 코드가 생략된 스니퍼 소스를 참고로 소개한다. IRIX에서 SNOOP을 사용해 제 작되었다. /* sgisniff.c by poison@baikdu.kaist.ac.kr uses SNOOP(7P) tested on IRIX 5.2, 5.3 */ #include #include #include #define ETHERHDRPAD RAW_HDRPAD(sizeof(struct ether_header)) struct etherpacket { struct snoopheader snoop; char pad[ETHERHDRPAD]; struct ether_header ether; char data[ETHERMTU]; }; main() { int s; struct sockaddr_raw sr; struct snoopfilter sf; struct etherpacket ep; int cc = 60000, on = 1; char buf[100]; s = socket(PF_RAW, SOCK_RAW, RAWPROTO_SNOOP); sr.sr_family = AF_RAW; sr.sr_port = 0; strncpy(sr.sr_ifname, "ec0", sizeof sr.sr_ifname); bind(s, &sr, sizeof sr); memset((char *)&sf, 0, sizeof sf); ioctl(s, SIOCADDSNOOP, &sf); setsockopt(s, SOL_SOCKET, SO_RCVBUF, (char *) &cc, sizeof cc); ioctl(s, SIOCSNOOPING, &on); for (;;) { cc = read(s, (char *) &ep, sizeof ep); write(1, (char *)&ep, sizeof ep); sleep(2); } } 스니퍼, 그 대책과 예방 스니퍼 탐지 스니퍼는 Promiscuous mode에서 동작하기 때문에 네크워크 디바이스의 상태 플래그에 'PROMISC' 가 있다면 일단 스니퍼가 돌고 있다고 생각해도 좋다. SunOS 4.1.x 같은 BSD 계열의 유닉스나 IRIX에서는 'ifconfig'를 사용해서 스니퍼의 존재를 확인할 수 있으나 대부분의 다른 유닉스(특히 Solaris)에서는 그것이 불가능하 다. [baikdu:/circ/kus/poison 2 ] uname -a SunOS baikdu 4.1.3-KL 3 sun4m [baikdu:/circ/kus/poison 3 ] ifconfig le0 le0: flags=163 inet 143.248.1.8 netmask ffffff00 broadcast 143.248.1.0 [eru:/eldar/people/poison 16 ] uname -a IRIX eru 5.3 11091812 IP22 mips [eru:/eldar/people/poison 17 ] ifconfig ec0 ec0: flags=d63 inet 134.75.100.53 netmask 0xffff0000 broadcast 134.75.255.255 SunOS 4.1.3, IRIX 5.3 에서 스니퍼 프로그램을 실행시키면서 ifconfig로 확인하면 다음과 같 다. 두 기계에서 모두 flags를 나타내는 행에 'PROMISC'가 있는 것으로 스니퍼가 확인된다. SunOS 4.1.x에서 사용 가능한 cpm이라는 프로그램이 있는데 ifconfig로 플래그를 조사하는 것과 같은 기 능을 가진다. 일반적으로 스니퍼는 로그 파일을 만들어 데이터를 모은다. 따라서 그 로그 파일을 찾을 수 있으면 스니퍼를 찾기가 쉬어진다. 우선 다음과 같은 간 단한 방법이 있다. 다른 호스트로 연결을 하면 스니퍼 로그 파일에 로그가 새로 만들어지게 되므로 미리 만들어 두 었던 /tmp/sniff_trap이란 파일을 기준으로 해 찾을 수가 있다. 단 빠른 결과를 위해 루트에서 프로 세스의 우선권을 최대로 한다. 보다 확실히 하기 위해서 현재 열려져 있는 모든 파일의 리스트를 알 수 있다면 그 속에 스니퍼 로그 파일도 포함돼 있을 것이 므로 스니퍼를 찾는데 도움이 된다. lsof({{{{ftp://ftp.cert-kr.or.kr/pub/tools/lsof }} }}) 이라는 툴 의 사용을 권한다. 스니퍼 로그 파일을 찾아 없앴다면 스니퍼 프로세스를 찾도록 노력해본다. 시스템을 리부팅하면 되겠지만 그보다 침입자를 추적 하고 싶다면 그 프로세스를 직접 찾아내는 것이 바람직하다. 루 트로 실행되고 있는 프로세스 중 에서 수상한 것들을 찾는다. ./a.out, ./in.telnetd, in.uucpd 등으로 숨겨지는 게 보통인데 알아내기 어렵잖다. # touch /tmp/sniff_trap # telnet gondor.kaist.ac.kr SunOS UNIX (gondor) login: blah Password: Login incorrect login:^D Connection closed by foreign host. # nice -19 find / -newer /tmp/sniff_trap -print BSD ps(/usr/ucb/ps)가 사용 가능하다면 e옵션을 추가해서 프로세스가 시작됐을 때의 환경변수를 알아내어 어떤 계정이 해킹에 사용됐는지를 알아낼 수 있다. 어떻게 예방해야 하나? 스니퍼에 대비하는 방법의 원칙은 패스워드가 네트워크를 통해 전달되지 않게 하는 것이다. 그것 의 구현은 암호화를 이용하거나 (secure shell, kerberos) 패스워드를 대신하는 토큰을 이용(S/key)하 는 것을 예로 들 수 있다. 그런 부류의 소프트웨어들은 상 당수가 제작돼있는데 그중 공개 소프 트웨어인 ssh(Secure Shell: {{{{http://www.cs.hut.fi/ssh }} }})이 사용하기에 가장 무난하다 . 이것은 패킷을 암호화해 sshd(서버)에게 보내는 ssh,scp(클라이언트)가 telnet, rlogin, ftp를 대신하 는 패키지이다. 다음 페이지로..