시스템공격점검을 통한 보안 개선 방안시스템공격점검을 통한 보안 개선 방안
페이지 정보
작성자 MintState 댓글 0건 조회 11,811회 작성일 08-12-04 22:13본문
시스템공격점검을 통한 보안 개선 방안
Dan Farmer
Sun Microsystems
2550 garcia ave MS PAL1-407
Mountain View CA 94043
zen@sun.com
Wietse Venema
Eindhoven University of Technology
P.O. Box 513, 5600 MB
Eindhoven, NL
wietse@wzv.win.tue.nl
원본: http://www.certcc.or.kr/paper/x2.txt
개요
최근 전산망을 통한 침입이 매우 잦아지고 있으며, 이 수법들도 매우 복잡해지는 수준에 있다. 많은 경우가 패스워드의 문제점에 기인하다고 믿지만 최근 보다 우수한 침입기법을 이용하는 경우가 많이 발견된다. 이러한 기법들은 잘 발견되기 어려우므로 아직은 덜 알려져 있는 실정이다.
보통의 시스템 침입자들의 이미지라고 할 수 있는 단순한 시스템 id 의 반복적인 시도가 아니라 보다 위험한 경우들이 있다. 최근의 시스템 감사 및 침입도구의 사용법을 잘 알고 있다든가, 어떤 특정 공격 방법을 수정할 수 있다든가, 또 자신이 스스로 프로그램을 만들 수 있다든가 하는 식의 전문 침입자들이 그들이다. 또한 새로 발견된 시스템의 취약점을 잘 알수 있다든가, 새로운 버그나 취약점들을 발견하기도 하는데, 이들을 "Uebercracker"라고 한다.
개요
이 논문에서는 일반적인 시스템보안에 대한 접근방법을 얘기하는 것이 아니며, 잠재적인 침입자의 입장에서 "어떻게", "왜"라는 입장에서 접근하고자 한다. 시스템의 취약점을 찾기위해 불필요한 네트워크 서비스가 도움을 주는 도구이며, 이러한 서비스들이 운영체제에서 정확하게 동작한다 하도라도 이러한 도구가 될 수 있는 것이다.
여기에서는 보다 우수한 침입방법들에 대해 초점을 맞추고, 침입자들이 사용하는 혹은 시스템의 시험 등을 통해 침입자들을 점검하는 것에 대해 알아 본다. 보통 시스템관리자들이 간과하기 쉬운 일반적인 공격 이상에 대해 알아보고자 하며, 어떤 자원이 보호되어야 한다는 것을 잘 알고는 있지만 네트워크나 시스템의 보호를 위해 어떤 수준의 평가가 필요한지는 잘 모르고 있다는 점도 알아야 한다. 침입자들이 어떤 접근을 하려고 하는지를 보임으로서 시스템관리자들이 어떻게 보안을 세눌 것인지 결정하는데 도움을 주고자 한다.
이 논문에서는 단순히 시스템의 버그나 보안취약점을 나열하지는 않는다. 이 논문의 목적은 어떤 관리자가 자신의 시스템의 보안을 위해 새로운 관점에서 침입 가능성을 이해시키고자 함이다.
이 논문에는 4개의 주된 부분으로 나누어진다. 첫째는 개요이며, 두번째 부분은 침입자들이 어떻게 시스템의 보안 메카니즘에 대해 모르면서 침입할 수 있는지 그 경향을 알게금 하는 부분인데 실질적인 네트워크의 보안취약점을 어떻게 알아내고 정보를 알아내 들어가는가에 대한 구체적인 기법들을 보인다. 여기에서는 특히 NIS나 NFS 등을 이용한 기법 등에 대해서도 조금 다룰 것이며, 시스템이나 운영체제에 특정적인 구성문제 등에 대해서도 다루며, 이에 대한 대비책도 보일것이다.
세번째 부분에서는 어떻게 시스템의 보안이 다른 시스템의 무결성에 따라 달라지는지 보일 것이며, 이러한 신뢰(Trust)문제는 매우 복잡한 이슈이다.
네번째 부분에서는 시스템 관리자들이 취해야 할 보안의 기본적인 절차에 대해 말하고자 한다.
이 논문의 사례나, 보안 관련 정보, 소프트웨어 등은 이 논문의 마지막에 부록에서 보이고 있다.
이 논문에서 설명된 침입 방법, 기법들은 SATATN(Security Analysis Tool for Auditing Networks.) 을 우리는 발표하였다. 이것은 shell, perl, C 등으로 만들었으며, 원격지의 시스템에 대해 NIS, finger, NFS, ftp and tftp, rexd 등을 검사할 수 있다. 뿐만 아니라 잠재적인 보안 문제로서, 잘못된 시스템 구성, 잘못된 네트워크 서비스 구성, 시스템이나 네트워크의 잘 알려진 버그 등을 점검하게 된다. 이것은 데이타나 잠재적인 보안 문제를 향후 검사하기 위한 전문가 시스템을 제공한다. 부록 A가 이러한 기능들을 보여주고 있다.
이 하나의 논문에서 모든 침입방법들을 다 다룰 수는 없으며, 또한 우리의 관심이 아니다. 사회공학이나 패스워드 Cracking 등이 있으나 가령 패스워드 공격방법에 대해서는 사실 여기에서도 다루고 있으며, 특히 X Window 공격도 있지만 사실 대부분의 침입자들이 이러한 비트맵을 볼 수 있는 단말기등을 가지고 있지 않기 때문에 여기에 기술하지 않는다.
정보를 획득하기
맨 먼저 무엇을 할 것인가? 먼저 소속한 공격 대상 시스템의 정보를 수집하라. 이 것을 알 수 있는 방법이 있다. finger, showmount, rpcinfo등을 맨처음 이용할 수 있을 것이다. 하지만 그밖에도 DNS, whois, sendmail(smtp), ftp, uucp 등의 여러가지 기법들을 이용할 수 있으며 이러한 정보들은 소속 기관의 전체 네트워크 침입에 이용될 수 있지만 지금은 우선 단지 특정 목표시스템에 대해 알아본다.
먼저 finger 명령을 보도록 한다.
이것은 하나의 사용자이며, 현재 Idle하므로 아무도 당신의 침입에 대해 신경쓰지 않을 것이다. 또 다른 전략으로서, "@", "0", "", root, bin, ftp, system, guest, demo, manager, 등을 finger하여 보다 많은 정보들을 보기로 한다. 이러한 정보들은 시스템의 버젼에 따라 다르지만 보통 계정이름과 홈 디렉토리, 마지막 로그인한 호스트 이름 들을 밝혀 주게 된다.
여기에 더해 사용자들의 정보를 보기 위해 rusers("-l"옵션으로)를 사용한다.
이것으로 victim.com 은 다음을 더 보여줄 것이다.
SATAN이나 침입자들의 활동을 보는 경험에 비추어 finger 는 매우 위험한 서비스이다. 하지만 이것은 다른 데이타와 함께 활용하면 더욱 유용하게 된다.
예를 들어 showmount 를 실행하여 보자.
/export/foo 가 완전히 개방되어 있음을 알 수 있다. 뿐만 아니라 이것의 사용자는 guest의 홈디렉토리이다. 이 경우 "guest" 사용자의 홈디렉토리를 마운트하여
침입에 성공할 수 있을 것이다. 자신의 시스템에 대응되는 계정도 없으며, root가 NFS 마운트된 파일시스템의 파일을 수정할 수 없으므로 자신의 시스템이 있는
패스워드 파일에 "guest" 계정을 만든다. 목표시스템의 "guest" 홈 디렉토리에 .rhosts 를 만들어 패스워드 없이 로그인할 수 있을 것이다.
만약 홈디렉토리가 아닌 사용자 명령어(/usr or /usr/local/bin)디렉토리를 개방하 였다면, 명령어를 당신의 의도대로 만든 트로이목마 프로그램등으로 대치해 두면 다음 사용자가 이를 실행하면 당신이 원하는 명령을 목표 시스템에 실행할 수 있다.
파일 시스템은,
- 특별히 신뢰하는 클아이언트에만 read/write only 로 개방하며,
- 가능한 Read-only로 만든다.
만약 /etc/hosts.equiv 에 "+"를 가지고 있다면(대부분 업체에서는 이것이 디폴트) 혹은 netgroups 버그(CERT advisory 91:12)의 경우 목표시스템의 패스워드 파일내에 있는 계정을 가진 사용자면 패스워드 없이 로그인할 수 있다. "bin" 사용자는 중요한 디렉토리나 파일을 소유주이므로 목표시스템에 다음 들어갈 경우에는 root로 접근할 수 있도록 패스워드 파일을 수정할 수 있다.
rsh 을 finger나 who로 보이지 않도록 wtmp나 utmp 시스템 로그를 이용한 어떤 추적도 남기지 않으므로 시스템에 접근할 수 있다. COPS(부록D) 은 관리자가 아닌 어떠한 사용자가 주요한 파일에 대해 쓰기권한을 가질 수 있는지 보고한다. 만약 SunOS 4.x 을 사용한다면 패치 100103 을 이용하여 파일 접근 권한문제를 해결할 수 있다. 위의 rsh 방법은 적당한 자료를 남기지 않으므로 tcp wrapper(부록 D)는 들어오는 접속에 대해 적당한 로그를 남긴다.
---------------------------------------------------------------------------
이제 무엇을 하나? 목표 시스템의 모든 취약점을 다 찾은 것이 아닐 것이다.
다시 "finger" 를 이용하여 목표 시스템이 "ftp" 게정을 가지고 있다는 것을 알게 된다면, 이는 anonymous ftp를 구성하고 있다는 것을 알려주는 것이다.
anonymous ftp는 잘못 구성됨으로서 쉽게 외부에서 접근 할 수 있게 해준다. 예를 들어 목표 시스템이 ~ftp/etc 디렉토리에 /etc/passwd 파일 전체 카피를 가지고 있다면 victim.com의 ftp 계정의 홈디렉토리는 쓰기가 가능해진다. 이것은 목표시스템에 remote 명령을 실행할 수 있도록 해주는, 예를 들어 전자우편을 통해 패스워드 파일을 보내게한다든가 하는 식의, 즉 ftp로 메일이 왔을 때 명령을 실행하도록 .forward 파일을 만들 수 있는 것이다. 이것은 "vacation" 프로그램이 메일에 자동 응답하도록 사용하는 파이프의 개념을 이용하는 것이다.
이제 당신은 단순히 패스워드 파일이 올때 까지 기다리면 되는 것이다.
COPS가 Anonymous FTP 가 올바른지 점검할 수 있으며, ftp 매뉴얼 페이지나, COPS의 문서나 코드 혹은 CERT-Advisory 93:10 을 참고하여 올바르게 Anonymous FTP를 설치할 수 있도록 한다. ftp 의 취약성은 주요한 파일이나 디렉토리의 잘못된 소유주 문제에서도 비롯될 수 있으며, 최소한 ~ftp와 ~ftp 아래에 있는 모든 시스템디렉토리 및 파일의 소유주룰 root로 해야 하며, 기타 어떤 사용자에게도 쓰기 권한을 허용해서는 안된다.
ftp 에 대해서는 예전에도 많이 공격하는 수법의 대상이 된 버그를 이용할 수 있다.
만약 이것이 동작된다면 root로 로그인하여 패스워드 파일을 수정하거나 어떤 작업도 할 수 있게 된다. 만약 이런 버그를 아직 가지고 있다면 업체나 ftp.uu.net 에서 새 버젼을 가져와 교체해야 한다.
기존의 ftp 교체 버젼인 Washington 대학에서 만든 wuarchive ftp도 같은 문제를 가지고 있으며 1993 4월 8일 이전 버젼을 사용한다면 최신버젼으로 교체해야 한다. 마지막으로 ftp와 유사한 tftp가 있는데, 패스워드나 다른 인증을 거치지 않는 방법이므로 inetd.conf에 secure 옵션플래그를 두어 접근을 제한하지 않는다면 침입자는 어떠한 디렉토리의 어떤 파일에 대해서도 읽기/쓰기가 가능해진다. 보통 이를 통해 패스워드 파일을 가져와서 /tmp디렉토리에 둘 수 있다.
보안을 위해 가능한 tftp는 사용하지 않는 것이 좋으며, 만약 필요하다면, 공개하는 정보만 있는 디렉토리로 접근을 제한한 secure 옵션 프래그를 두어 사용하거나 chroot wrapper 의 제어하에 사용한다.
이상의 방법이 통하지 않는 경우 어떤 의미에서는 finger 보다 더욱 편리한 rpcinfo를 사용할 수 있다. rpc를 이용하는 많은 시스템이 공격당할 수 있는데, rpcinfo가 portmapper와 대화하여 그 방법을 알려준다. 호스트가 NIS를 사용하는지, NIS가 서버인지 slave인지, 디스크없는 워크스테이션이 있는지 없는지, rusersd나 rstatd 등의 서비스가 있는지 없는지와 NFS에 대한 정보 등을 알려준다. 아까와 같은 목표시스템에서 예를 들어 본다.
여기에서 많은 중요한 정보들을 볼 수 있는데, 첫째 이 시스템이 NIS 서버란 사실이다. 아마 많이 알려져있지는 않았서도 서버의 NIS 도메인네임을 한번 알게되면, 이 NIS 서버의 서브네트 바깥에 있다할지라도 간단한 rpc query를 통해 NIS Maps 의 어떤 것도 알아낼 수 있다. 예를 들어 ftp.uu.net의 comp.sources.misc에서 찾을 수 있는 YPX를 사용할 수 있다. 더우기 패스워드를 짐작할 수 있는 것과 마찬가지로 NIS 도메인네임도 쉽게 짐작 할 수 있다. 부분적으로 혹은 전체적으로 알게된 호스트이름(예를 들어 victim 이나 victim.com등), 기관 이름, "showmount" 등으로 알게된 netgroups 이름 등으로 짐작할 수 있다. "victim"으로 짐작하고 싶다면 다음을 이용한다.
이것은 실패한 경우이다. 만약 성공한 경우라면 victim.com의 NIS서버 호스트이름을 반환받게 된다. 그러나 victim.com이 "/var"를 완전히 개방하고 있다는 사실을 NFS에서 알수 있었다. 이 디렉로리를 마운트하여 "yp"서브디렉토리를 볼 수 있는데, 혹은 다른 서브디렉토리에서 목표시스템의 도메인네임을 알 수도 있을 것이다.
이 경우 'foo_bar"가 NIS 도메인 이름이다. 그리고 가끔 NIS 맵은 크랙킹을 위한 패스워드 뿐 아니라 user/employee나 내부 호스트이름 리스트 등을 가지고 있을 수있다. 부록 C는 NIS 패스워드 파일에 대한 사례의 결과가 상세히 실려있다.
---------------------------------------------------------------------------
rpcinfo 가 victim.com이 rexed를 사용하고 있다는 것도 알려주고 있다. rshd와 마찬가지로 rexed는 원격지에 명령을 실행할 수 있도록 요청하는 서비스이다.
하지만 rshd와는 달리 hosts.eqiv나 .rhost의 존재 유무에 상관없다. 보통 rexed 클라이언트 프로그램이 명령어에 있지만 단지 적은 C 프로그램을 가지고 있으며 어떤 클라이언트 호스트와 사용자 정보를 서버에게 보내면 서버는 이 명령을 실행하게 된다. 이러한 이유로 rexed를 이용하는 것은 아무 패스워드를 가지고 있지 않는 것과 같으며 클라이언트에 보안 책임이 있게 된다. rexed의 보안은 securerpc를 사용함으로서 이루어질 수 있다.
---------------------------------------------------------------------------
rpcinfo의 결과에 따라 우리는 victim.com이 디스크없는 워크스테이션을 위한 서버임을 알 수 있다. 이것은 디스크없는 워크스테이션의 부팅을 위한 bootparam이 있는 것을 보고 알 수 있다. 만약 BOOTPARAMPROC_WHOAMI와 클라이언트의 어드레스를 이용하여 잘 요청하면 NIS 도메인네임을 알수 있다. 이것은 도메인네임을 알아 NIS 맵(예를 들어 패스워드 파일과 같은 것)과 잘 결합하면 우수한 효과를 가질 수 있다. 여기 간단한 사례 프로그램이 있다.(bootparam 은 SATAN의 일부)
"showmout"결과는 victim.com의 디스크없는 워크스테이션들이 쉽다는 것을 알 수 있는데, 우리는 이것들의 어드레스를 BOOTPARAMPROC_WHOAMI query에 사용한다.
---------------------------------------------------------------------------
NIS 마스터는 NIS 도메인 에서의 질문에 대한 mail alias를 제어한다. 한 시스템에서의 mail alias 파일 처럼 메일이 전송될때 명령어를 실행하도록 mail alias를 만들 수 있다. 가장 흔한 사례는 메일을 전달할 때 uudecode 를 실행하는 "decode" alias 이다. 예를 들어 "foo" 라는 alias 를 만들어 다음과 같이 단순히 메일을 보냄으로서 evil.com으로 패스워드를 메일로 보내게금 할 수 있다.
침입자가 NIS마스터 호스트에 대한 제어를 갖지 않아야 하겠지만, 또한 명백한 교훈은 NIS가 보안이 적절하지 않아, 침입자가 NIS 마스터를 제어할 수 있다면 침입자는 클라이언트에 명령을 실행하는 것과 같은 식으로 디스크없는 워크스테이션에 대해 제어할 수 있다.
클라이어트와 서버사이에 적절한 인증방법이 제공되지 않은 보안이 적절하지 못한 NIS 공격에 대한 여러가지 대응책이 없는 편이다. 더우기 나쁜 것은 어떤 맵은 마스터 서버에게도 강요될 수 있어서 NIS서버가 클라이언트가 되도록 조정할 수 있기도 하다. 만약 꼭 NIS를 사용하고자 한다면 도메인네임이 쉽게 짐작할 수 없도록 하는 것이 조금 도움이 될 것이다. 이 경우 만약 잠재적인 공격자에게 디스크 없는 클라이언트가 공개된다면 도메인네임을 얻기위한 bootparam 트릭을 사용하는 간단한 방법이 소용없게 만들 수 있다.만약 NIS가 패스워드 맵을 전파하기 위해 사용된다면 이미 root 권한을 가진 침입자가 아직도 접근할 수 있으므로 shadow 패스워드는 더 이상 좋은 보안이 되질 않는다. 좋은 것은 NIS를 사용하지 않는 것이며, 맵이 잠재적으로 어떠한 강제에의해 종속되지 않도록 최소화하는 것이다.
Secure RPC는 이러한 위협을 막는 또 다른 방버이긴 하지만 이것은 관리하기에도 어려우며 여기에서 사용된 암호 기법이 우수하지도 않다. SUN이 새롭게 선보인 NIS+가 이러한 문제점을 해결하였다고 하지만 제한된 SUN에서만 동작하며 원래의 설계 상의 잇점을 살릴 수도 없다. 마지막으로 패킷 필터링(port 111)을 이용하거나 Securelib, SUN의 sunpatch 100482-02 가 도움이 될 것이다.
---------------------------------------------------------------------------
portmapper 는 단지 rpc 서비스에 대해서만 알려주는 것은 아니다. 다른 네트워크 서비스에 대해서도 모든 네트워크 포트에 대해 강제적인 방법으로 위치시킬 수 있다. 마치 sendmail은 25번, telnet 은 23 번, x window 는 6000 번 이듯이 모든 네트워크 서비스는 특정 포트에 대해 듣고있다. SATAN 은 원격지 시스템에 대해 네트워크 포트를 스캐닝하며 발견한 정보를 보고 하는 프로그램을 가지고 있다. 목표시스템에 대해 실행하면 다음을 볼 수 있다.
이 시스템은 X Window 시스템을 실행하고 있다는 것을 알려준다. 만약 magic cookie 나 xhost 메카니즘 등을 실행하여 적절히 보호하고 있지 않고 있다면, 원도우 디스플레이가 캡춰당하거나 보일 수 있으며, 혹은 사용자의 키입력이 도용되거나 프로그램이 원격지에서 실행될 수 있다. 그리고 목표 시스템이 X 를 실행하고 포트 6000번으로의 telnet 을 받아들인다면 목표 시스템의 x window 시스템의 동작을 일시 정지시키는 것과 같은 서비스거부 공격에 이용될 수 있다. X 서버의 취약점을 알 수 있는 또다른 방법은 XOpenDisplay() 함수를 이용하는 것으로서 만약 이 함수가 NULL 을 반환한다면 목표의 디스플레이에 접근할 수 없다. 이 기능은 SATAN에 포함된 기능이다.
완전한 유닉스 보다는 떨어지는 X 터미널도 자체의 보안문제를 가질 수 있다. 많은 X 터미널은 제한이 없는 rsh 접근을 허용하고 있으며, 이것은 목표시스템의 터미널에서 X 클라이언트를 시작하게 하면서 결과가 자신의 스크린에 나오게 할 수 있는 것이다.
어떤 경우에도 패스워드 없는 계정이나 hosts.eqiv 의 "+" 처럼 당신의 시스템의 보안을 침해하는 것과 같은 파일시스템과 네트워크 보안 처럼 X 윈도우의 보안도 많은 생각을 하게금 한다.
---------------------------------------------------------------------------
이제는 sendmail을 보자. sendmail은 이제는 대부분의 시스템에서 못쓰게금 되어있기는 하지만 악명높은 "wiz" 명령의 문제를 포함한 많은 보안 문제를 가지고 있는 매우 복잡한 프로그램이다. sendmail 이 반환한 버젼번호를 보아 목표시스템의 OS 나 때때로 버젼번호 등을 알 수 있다. 이것은 여러가지 버그들 중 어떤 취약점이 해당하는지를 알수있게금 한다. 더우기 만약 상대편이 "decode" alias 를 가지고 있다면 많은 문제를 알 수 있는 것이다.
"decode" alias 는 매우 위험한 보안문제를 야기하는데, 이것은 공격자가 어떤 파일에 대해 쓰기를 할 수 있도록한다. 특히 대부분은 소유주가 데몬인 파일이지만 잠재적으로는 어떤 사용자의 파일도 가능한 것이다. 다음 메일을 보면 이것은 "evil.com" 의 zen 사용자의 .rhosts 파일을 보내는 것이다.
만약 어떠한 홈 디렉토리도 못찾고 또한 쓰기를 할 수 없다면 다른 변형으로서 목표시스템에 어떤 명령을 실행하도록 /etc/aliases.pag 파일에 무언가 첨가하는 것이다. 대부분의 시스템들이 메일 alias 를 제어하는 /etc/aliases.pag나 aliases.dir 파일들이 완전히 쓰기 개방되어있어 성공할 가능성이 높다.
만약 vrfy로 어드레스를 확인하거나 expn 을 통해 어드레스 확장이 된다는 것을 sendmail 과의 대화를 통해 알 수있다면 많은 것을 발견할 수 있다.
finger나 rusers 를 사용할 수 없을 때 vrfy 나 expn 는 사용자나 목표 시스템을 확인하는데 사용될 수 있다. Vrfy 나 expn 은 vacation 이나 mail sorter 와 같은 문제있는 프로그램과의 파이프를 찾는데 사용될 수 있다. vrfy 와 expn 등을 금지하는 것이 좋은데 대부분의 버젼에서는 srvrsmtp.c의 소스를 보고 CmdTab structure내 "vrfy" 와 "expn" 라인을 지우거나 바꾸는 것이 좋다. 소스가 없는 곳에서도 바이너리 에디터를 통해 2개의 스트링을 공백으로 교체하여 지울 수 있다. 부록 D 에서 보이는 것과 같이 최신의 sendmail 버젼으로 교체하는 것도 하나의 방법이다.
---------------------------------------------------------------------------
sendmail-sendoff 에서도 잘 알려진 버그가 2개 있다. 처음 버그는 Berkeley 에서 5.59 버젼에서 분명하게 문제를 해결하였다. 이전 버젼에 대해서는 "evil.com"이 에러메세지에도 불구하고 지정한 파일이 메일 헤더에 첨부되어 받을 수 있다.
2번째 문제는 최근에 발견된 것으로서 송신자가 어떤 쉘 명령을 정의하거나 송신자나 목적지 어드레스 등의 패스이름을 지정하는 것을 허용하는 것이다. 여기에서 자세한 설명은 생략하지만 usenet news 나 기타에서 알려진 바가 있으므로 생략하며 대부분의 sendmail 에서 문제가 있다. 하지만 대표적인 공격 형태는 다음과 같다.
지금 sendmail 버젼 8.6.4 는 단지 몇몇 엄체에서만 많은 보안취약점들을 해결하고 있는 것으로 알려지고 있으며 부록 D 를 참고하기 바란다.
Trust
우리의 마지막 주제로서 약간 이론적인 입장에서 신뢰(Trust) 문제를 살펴 보기로 한다. 이것은 대부분 어떤 기관 내부에서 자원 공유의 입장에서 패스워드나 기타 인증 방법을 통하지 않는 것을 의미하는데, 클라이언트에 대한 제한을 어떻게 할 수 있나에 대해 말하려는 것이다.
호스트가 신뢰하는 방법은 여러가지가 있을 수 있다. hosts.equiv 나 .rhosts 에서 패스워드를 묻지 않고 접근을 허용하는 방법, 원격지시스템이 권한을 사용하거나 남용하도록 해주는 X 서버, NFS 제어를 통한 파일의 개방 등이다. 모든 것들은 클라이언트들의 어드레스를 호스트이름으로 변환할때 이 서비스를 받을수 있을지 없을지가 결정된다. 직접 하는 방법은 /etc/hosts 를 이용한 간단한 방법이며, 현재는 대부분이 DNS, NIS 등을 이용하고 있다. 클라이언트가 접속 요청시 IP 어드레스에 의해 역 lookup 이 이루어져 원하는 클라이언트인지 확인을 바라게 된다.
이러한 확인 방법에 대해 많는 관리자들이 이해하고 있지만 중요한 실질적인 보안문제는 호스트이름 위장의 경우이다. 이것은 단순히 관리자들이 잘 알고 있는 hosts.equiv 나 .rhosts 문제, X 윈도우, NFS 문제의 차원을 넘어선 문제이다. 어떠한 신뢰이라 할지라도 위장되거나 무력화되거나 바꿔치기 될 수 있는데,이는 서버의 관리영역 밖에 있는 authority 가 클라이언트의 신뢰성(Credential)을 점검하거나 신뢰하는 메카니즘이 매우 취약한 경우에서 비롯되는 것이다. 명백히 NIS, DNS 등에서의 데이타베이스가 만약침해 당했다면 침입자는 신뢰하는 시스템에서의 접근인 것 처럼 위장할 수있으며, 이것으로 목표시스템이 신뢰하는 어떤 호스트가 있는지 충분히 알수 있기 때문이다. 이 작업은 시스템관리자나 root 와 같은 계정이 어떤 호스트에서 접근하는지를 검사하면 매우 도움이 된다.
다시 victim.com 의 사례로 돌아가서 관리자가 big.victim.com 에서 접근하는 것을 알았다고 가정해보자. evil.com의 DNS PTR 레코드를 교체하여 evil.com 에서 victim.com 으로 rlogin 하려하면 victim.com 은 호스트이름을 보려고 하여 교체한 레코드를 보게될 것이다.
다음은 원래의 PTR 레코드와 교체한 PTR 레코드이다.
다음에는 victim.com 에 달려있는데, big.victim.com 이 /etc/hosts.equiv 나 .rhosts 에 존재한다면 접속을 허용하여 패스워드 없이 접근할 수 있을 것이다. NIS 에서는 침입자가 만약 NIS 마스터를 제어하고 있다면 호스트데이타베이스를 수정하는 것은 더욱 쉬운 일이며, 원하는 정보를 가진 목표 시스템을 이용하여 NIS 를 위장하거나 강제화할 수 있을 것이다.
이러한 공격을 막기위한 2가지 방법이 있다. 첫째는 매우 직접적이지만 비현실적인 것으로서 단순히 어떠한 호스트도 믿지 않는 것이다. 다른 방법은 암호프로토콜을 사용하는 것으로서 Secure NFS, NIS+ 등의 Secure RPC를 사용하는 방법인데, 만약 암호가 깨진다 하더라도 암호를 사용하지 않는 기존의 인증 방식보다 훨씬 우수하다. 다른 방법으로서 smartcard 하드웨어를 사용하거나, kerberos 등의 소프트웨어를 사용할 수 있는데, 전자는 아직 잘 개발된 상태가 아니며, 후자는 시스템의 전반적인 수정이 요구된다.
부록 B 는 인터넷 여러군데에서 검토한 비공식자료로서 보다 자세히 설명하고 있다.
Protecting the system
시스템보안을 위한 일반적인 제안들을 보이고자 한다.
- 만약 finger 서비스를 꼭 해야 한다면 수정된 버젼을 설치하라. 사용자의 홈 디렉토리니, 로그인 한 호스트이름 등을 알릴 필요는 없는 것이다.
- 절대적으로 필요하지 않다면 NIS 를 사용하지 말것이며, NFS 도 가능한 사용하지 않는다.
- 절대로 NFS 파일시스템을 완전히(Worldwide) 공개하지 말것이며, 가능한 읽기 전용으로 만들어라.
- 서버를 방어하고 보호한다. 단지 관리할 수 있는 계정만을 허용한다.
- inetd 나 portmapper 등에서 불필요한 서비스가 없는지 점검한다. 만약 접속하는 시스템의 로그를 기록하고 싶다면 wrapper 를 사용하는 것이 좋은데, 표준 유닉스보다 우수한 로그와 특히 네트워크 공격에 대한 기록이 우수하다. 그리고 가능한 보안 관련 정보를 입수하기 위해 syslog 의 loghost 메카니즘을 이용하라.
- 완벽하게 믿을 수 있는 시스템이 없다면 신뢰하는 호스트를 없앤다.
- Shadow 패스워드와 잘못된 패스워드를 가려내는 패스워드 명령을 사용한다. 사용하지 않는 계정과 시스템을 없앤다.
- 최근의 자료(참고문헌)와 도구들을 수집하며, 보안 사고 문제나 보안관련 문제를 지속적으로 남들과 대화한다. 최소한 CERT mailing list와 보안잡지, Firewall mailing list, 보안 관련 뉴스그룹 등에 가입한다. 무관심도 보안 문제에 가장 큰 적이다.
- 기관의 모든 호스트에 대해 가능한 최신 패치를 설치한다.
네트워크 방하벽시스템, Kerberos, 일회용 패스워드시스템 등이 보안문제를 해경하는데 도움이 되지만 위에서 여기에서 알려진 이러한 공격에 모무 안전한 것은 아니다. 즉 위 3, 4 가지 우수한 보안 기법을 사용하는 것이 좋다고 권고하지만 모두 해결되는 것은 아니라는 말이다.
Conclusions
Perhaps none of the methods shown here are surprising; when writing this paper, we didn't learn very much about how to break into systems. What we _did_ learn was, while testing these methods out on our own systems and that of friendly sites, just how effective this set of methods is for gaining access to a typical (UNIX) Internet host. Tiring of trying to type these in all by hand, and desiring to keep our own systems more secure, we decided to implement a security tool (SATAN) that attempts to check remote hosts for at least some of the problems discussed here. The typical response, when telling people about our paper and our tool was something on the order of "that sounds pretty dangerous -- I hope you're not going to give it out to everybody. But you since you can trust me, may I have a copy of it?"
We never set out to create a cookbook or toolkit of methods and programs on how to break into systems -- instead, we saw that these same methods were being used, every day, against ourselves and against friendly system administrators. We believe that by propagating information that normally wasn't available to those outside of the underworld, we can increase security by raising awareness. Trying to restrict access to "dangerous" security information has never seemed to be a very effective method for increasing security; indeed, the opposite appears to be the case, since the system crackers have shown little reticence to share their information with each other.
While it is almost certain that some of the information presented here is new material to (aspiring) system crackers, and that some will use it to gain unauthorized entrance onto hosts, the evidence presented even by our ad hoc tests shows that there is a much larger number of insecure sites, simply because the system administrators don't know any better -- they aren't stupid or slow, they simply are unable to spend the very little free time that they have to explore all of the security issues that pertain to their systems. Combine that with no easy access to this sort of information and you have poorly defended systems. We (modestly) hope that this paper will provide badly-needed data on how systems are broken into, and further, to explain _why_ certain steps should be taken to secure a system. Knowing why something is a problem is, in our opinion, the real key to learning and to making an informed, intelligent choice as to what security really means for your site.
---------------------------------------------------------------------------
부록 A: SATAN (Security Analysis Tool for Auditing Networks)
SATAN은 보다 크고 이해하기 쉬운 프로토타입 보안 도구이다. SATAN 은 목표하는 시스템의 일반적이고 도움이 될 정보를 상세하게 보고하거나 네트워크와 윈도우 시스템의 버그나 보안 취약요소들을 점검하여 보고한다. 그리고 결과 데이타에 대해 정해진 규칙에 따른 필터링을 하고 최종 분석 결과를 요약하기 위한 전문가프로그램이 사용된다. 이것은 빠르게 처리되지는 않지만 잘 모듈화되어있으며, 쉽게 수정할 수 있다.
SATAN 은 여러개의 서브프로그램으로 구성되며, 각각은 Perl, Shell, C 로 구현되어 있으며, 각각 주어진 목표를 공격 점검할 수 있다. 추후 확장을 위해서는 메인 디렉토리에 ".sat"식의 실행프로그램을 추가하면 된다. 드라이버는 주어진 복표들에 대해 DNS, ping 등으로 존재 유무를 확인하고 실행파일들이 실제 그 시스템을 공격한다. 결과를 분석하는 필터링, 인터프리트 프로그램이 실행되어 마지막으로 사용자가 읽을 수 있는 형태로 요약 보고한다.
---------------------------------------------------------------------------
부록 B: 전산망 보안 점검 및 분석 사례
비공식적으로 대학, 군사기관 및 기업체의 200 여호스트 및 40000여개의 계정에 대해 점검을 실행한바 기관의 평균 10%가 .rhosts를 가지고 있었으며 이것들은 평균 6개의 신뢰하는 호스트들을 가지고 있었다. 하지만 어떤 경우에는 100개 이상의 엔트리를 가지거나 심지어 400 여개의 엔트리를 가진 .rhosts 를가진 곳도 있었다. 그리고 대부분의 경우 인터넷에 직접 연결되어 있었고 단지 하나의 기관만이 방화벽을 운영하고 있었는데, 대부분 기관 외부에 신뢰하는 호스트들을 가지고 있어 대부분 관리자의 통제 밖에 있다고 보인다. 규모가 큰 기관들은 .rhosts를 별로 가지고 있지 않았지만 신뢰하지 않는 호스트 뿐 아니라 .rhosts 파일의 크기는 대단히 컸다.
비록 얼마나 많은 엔트리들이 정당한지 확인하기 어려웠고, 특히 와일드카드, "Makefile". "Message-id:", "^Cs^A^C^M^Ci^C^MpNu^L^Z^O" 등에 대해서는 올바르게 신뢰하는 시스템으로서 구성되었는지를 확인하기 어려웠지만, 각 기관은 자신의 보안을 각 사용자에게 맡기고 있다는 것을 알 수 있었다. 많은 량의 엔트리를 가진 .rhosts 파일의 경우에는 쉘 형태의 코멘트를 많이 가지고 있었는데, 대부분의 유닉스에서는 이러한 형태를 올바르게 해석하지 않으며, 침입자의 NIS, DNS 로 호스트이 름을 "#"으로 위장한 공격으로 자유롭게 접근한다.
여기 조사한 기관들이 인터넷에서의 대표적인 기관으로 발하기는 어렵고 사실이 아닐지도 모른다. 하지만 많은 관리자들은 보안연구나 보안제품에 대해 작업들을 많이 하고 있었을 뿐만 아니라 취미나 전문으로 프로그램을 만들고 보안 관련 작업을 많이 하고 있었던 것으로 보인다.
---------------------------------------------------------------------------
부록 C: 시스템 진단 사례
우리가 가진 시스템의 하나에서 출발한 침입을 알리는 전자우편을 받고 조사에 착수하여 어떤 기업체에서 온 침입자가 패스워드를 훔치기 쉬운 기관들을 검토하고 있는 것을 발견하였다. 이때 패스워드를 훔치기 쉬운 기관이란 NIS 도메인이름을 쉽게 유추할 수 있다든가 NIS 서버에 쉽게 접근할 수 있는 기관을 의미한다. 침입자가 얼마나 진전이 있었는지 는 모르지만 이 기관에 경고를 주는 일을 하기로 하였다. 침입자는 656개의 호스트리스트를 가지고 있었는데, 그중에서 25개의 호스트에서 24개는 쉽게 훔쳐낼 수 있었으며, 이 중 3 분의 1은 적어도 하나의 패스워드 없는 계정으로 대화형 쉘을 가지고 있었다. 총 1594개의 패스워드 파일 엔트리에서 낮은 수준의 SUN 시스템에서 10분망에 50개 이상의 패스워드를 알아내었으며, 40%는 다음 20분 만에, root 의 패스워드를 1 시간만에 하나 알아애었다. 마음 며칠 만에는 5개의 root 패스워드를 알아내었다. 결국 24개(80%)의 패스워드 파일이 적어도 하나의 잘알려진 패스워드를 가지고 있었으며, 1594개의 엔트리중 259(6분의 1)개의 패스워드가 쉽게 추정 할 수 있었다.
---------------------------------------------------------------------------
부록 D: 무료 인터넷 보안 자료를 받으려면
Mailing lists:
* The CERT (Computer Emergency Response Team) advisory mailing list. Send e-mail to cert@cert.org, and ask to be placed on their mailing list.
* The Phrack newsletter. Send an e-mail message to phrack@well.sf.ca.us and ask to be added to the list.
* The Firewalls mailing list. Send the following line to majordomo@greatcircle.com: subscribe firewalls
* Computer Underground Digest. Send e-mail to tk0jut2@mvs.cso.niu.edu, asking to be placed on the list.
Free Software:
COPS (Computer Oracle and Password System) is available via anonymous ftp from archive.cis.ohio-state.edu, in pub/cops/1.04+.
The tcp wrappers are available via anonymous ftp from ftp.win.tue.nl, in pub/security.
Crack is available from ftp.uu.net, in /usenet/comp.sources.misc/volume28.
TAMU is a UNIX auditing tool that is part of a larger suite of excellent tools put out by a group at the Texas A&M University. They can be gotten via anonymous ftp at net.tamu.edu, in pub/security/TAMU.
Sources for ftpd and many other network utilities can be found in ftp.uu.net, in packages/bsd-sources.
Source for ISS (Internet Security Scanner), a tool that remotely scans for various network vulnerabilities, is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume40/iss.
Securelib is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume36/securelib.
The latest version of berkeley sendmail is available via anonymous ftp from ftp.cs.berkeley.edu, in ucb/sendmail.
Tripwire, a UNIX filesystem integrity checker+, is available via anonymous ftp at ftp.cs.purdue.edu, in pub/spaf/COAST/Tripwire.
---------------------------------------------------------------------------
참고문헌:
Baldwin, Robert W., Rule Based Analysis of Computer Security, Massachusetts Institute of Technology, June 1987.
Bellovin, Steve, Using the Domain Name System for System Break-ins, 1992 (unpublished).
Massachusetts Institute of Technology, X Window System Protocol, Version 11, 1990.
Shimomura, Tsutomu, private communication.
Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992.
---------------------------------------------------------------------------
추천 참고문헌:
Bellovin, Steve -- "Security Problms in the TCP/IP Protocol Suite", Computer Communication Review 19 (2), 1989; a comment by Stephen Kent appears in volume 19 (3), 1989.
Garfinkel, Simson and Spafford, Gene, "Practical UNIX Security", O'Reilly and Associates, Inc., 1992.
Hess, David, Safford, David, and Pooch, Udo, "A UNIX Network Protocol Study: Network Information Service", Computer Communication Review 22 (5) 1992.
Phreak Accident, Playing Hide and Seek, UNIX style, Phrack, Volume Four, Issue Forty-Three, File 14 of 27.
Ranum, Marcus, "Firewalls" internet electronic mailing list, Sept 1993.
Schuba, Christoph, "Addressing Weaknesses in the Domain Name System Protocal", Purdue University, August 1993.
Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM 27 (8), 1984.
Dan Farmer
Sun Microsystems
2550 garcia ave MS PAL1-407
Mountain View CA 94043
zen@sun.com
Wietse Venema
Eindhoven University of Technology
P.O. Box 513, 5600 MB
Eindhoven, NL
wietse@wzv.win.tue.nl
원본: http://www.certcc.or.kr/paper/x2.txt
개요
최근 전산망을 통한 침입이 매우 잦아지고 있으며, 이 수법들도 매우 복잡해지는 수준에 있다. 많은 경우가 패스워드의 문제점에 기인하다고 믿지만 최근 보다 우수한 침입기법을 이용하는 경우가 많이 발견된다. 이러한 기법들은 잘 발견되기 어려우므로 아직은 덜 알려져 있는 실정이다.
보통의 시스템 침입자들의 이미지라고 할 수 있는 단순한 시스템 id 의 반복적인 시도가 아니라 보다 위험한 경우들이 있다. 최근의 시스템 감사 및 침입도구의 사용법을 잘 알고 있다든가, 어떤 특정 공격 방법을 수정할 수 있다든가, 또 자신이 스스로 프로그램을 만들 수 있다든가 하는 식의 전문 침입자들이 그들이다. 또한 새로 발견된 시스템의 취약점을 잘 알수 있다든가, 새로운 버그나 취약점들을 발견하기도 하는데, 이들을 "Uebercracker"라고 한다.
개요
이 논문에서는 일반적인 시스템보안에 대한 접근방법을 얘기하는 것이 아니며, 잠재적인 침입자의 입장에서 "어떻게", "왜"라는 입장에서 접근하고자 한다. 시스템의 취약점을 찾기위해 불필요한 네트워크 서비스가 도움을 주는 도구이며, 이러한 서비스들이 운영체제에서 정확하게 동작한다 하도라도 이러한 도구가 될 수 있는 것이다.
여기에서는 보다 우수한 침입방법들에 대해 초점을 맞추고, 침입자들이 사용하는 혹은 시스템의 시험 등을 통해 침입자들을 점검하는 것에 대해 알아 본다. 보통 시스템관리자들이 간과하기 쉬운 일반적인 공격 이상에 대해 알아보고자 하며, 어떤 자원이 보호되어야 한다는 것을 잘 알고는 있지만 네트워크나 시스템의 보호를 위해 어떤 수준의 평가가 필요한지는 잘 모르고 있다는 점도 알아야 한다. 침입자들이 어떤 접근을 하려고 하는지를 보임으로서 시스템관리자들이 어떻게 보안을 세눌 것인지 결정하는데 도움을 주고자 한다.
이 논문에서는 단순히 시스템의 버그나 보안취약점을 나열하지는 않는다. 이 논문의 목적은 어떤 관리자가 자신의 시스템의 보안을 위해 새로운 관점에서 침입 가능성을 이해시키고자 함이다.
이 논문에는 4개의 주된 부분으로 나누어진다. 첫째는 개요이며, 두번째 부분은 침입자들이 어떻게 시스템의 보안 메카니즘에 대해 모르면서 침입할 수 있는지 그 경향을 알게금 하는 부분인데 실질적인 네트워크의 보안취약점을 어떻게 알아내고 정보를 알아내 들어가는가에 대한 구체적인 기법들을 보인다. 여기에서는 특히 NIS나 NFS 등을 이용한 기법 등에 대해서도 조금 다룰 것이며, 시스템이나 운영체제에 특정적인 구성문제 등에 대해서도 다루며, 이에 대한 대비책도 보일것이다.
세번째 부분에서는 어떻게 시스템의 보안이 다른 시스템의 무결성에 따라 달라지는지 보일 것이며, 이러한 신뢰(Trust)문제는 매우 복잡한 이슈이다.
네번째 부분에서는 시스템 관리자들이 취해야 할 보안의 기본적인 절차에 대해 말하고자 한다.
이 논문의 사례나, 보안 관련 정보, 소프트웨어 등은 이 논문의 마지막에 부록에서 보이고 있다.
이 논문에서 설명된 침입 방법, 기법들은 SATATN(Security Analysis Tool for Auditing Networks.) 을 우리는 발표하였다. 이것은 shell, perl, C 등으로 만들었으며, 원격지의 시스템에 대해 NIS, finger, NFS, ftp and tftp, rexd 등을 검사할 수 있다. 뿐만 아니라 잠재적인 보안 문제로서, 잘못된 시스템 구성, 잘못된 네트워크 서비스 구성, 시스템이나 네트워크의 잘 알려진 버그 등을 점검하게 된다. 이것은 데이타나 잠재적인 보안 문제를 향후 검사하기 위한 전문가 시스템을 제공한다. 부록 A가 이러한 기능들을 보여주고 있다.
이 하나의 논문에서 모든 침입방법들을 다 다룰 수는 없으며, 또한 우리의 관심이 아니다. 사회공학이나 패스워드 Cracking 등이 있으나 가령 패스워드 공격방법에 대해서는 사실 여기에서도 다루고 있으며, 특히 X Window 공격도 있지만 사실 대부분의 침입자들이 이러한 비트맵을 볼 수 있는 단말기등을 가지고 있지 않기 때문에 여기에 기술하지 않는다.
정보를 획득하기
맨 먼저 무엇을 할 것인가? 먼저 소속한 공격 대상 시스템의 정보를 수집하라. 이 것을 알 수 있는 방법이 있다. finger, showmount, rpcinfo등을 맨처음 이용할 수 있을 것이다. 하지만 그밖에도 DNS, whois, sendmail(smtp), ftp, uucp 등의 여러가지 기법들을 이용할 수 있으며 이러한 정보들은 소속 기관의 전체 네트워크 침입에 이용될 수 있지만 지금은 우선 단지 특정 목표시스템에 대해 알아본다.
먼저 finger 명령을 보도록 한다.
이것은 하나의 사용자이며, 현재 Idle하므로 아무도 당신의 침입에 대해 신경쓰지 않을 것이다. 또 다른 전략으로서, "@", "0", "", root, bin, ftp, system, guest, demo, manager, 등을 finger하여 보다 많은 정보들을 보기로 한다. 이러한 정보들은 시스템의 버젼에 따라 다르지만 보통 계정이름과 홈 디렉토리, 마지막 로그인한 호스트 이름 들을 밝혀 주게 된다.
여기에 더해 사용자들의 정보를 보기 위해 rusers("-l"옵션으로)를 사용한다.
이것으로 victim.com 은 다음을 더 보여줄 것이다.
SATAN이나 침입자들의 활동을 보는 경험에 비추어 finger 는 매우 위험한 서비스이다. 하지만 이것은 다른 데이타와 함께 활용하면 더욱 유용하게 된다.
예를 들어 showmount 를 실행하여 보자.
/export/foo 가 완전히 개방되어 있음을 알 수 있다. 뿐만 아니라 이것의 사용자는 guest의 홈디렉토리이다. 이 경우 "guest" 사용자의 홈디렉토리를 마운트하여
침입에 성공할 수 있을 것이다. 자신의 시스템에 대응되는 계정도 없으며, root가 NFS 마운트된 파일시스템의 파일을 수정할 수 없으므로 자신의 시스템이 있는
패스워드 파일에 "guest" 계정을 만든다. 목표시스템의 "guest" 홈 디렉토리에 .rhosts 를 만들어 패스워드 없이 로그인할 수 있을 것이다.
만약 홈디렉토리가 아닌 사용자 명령어(/usr or /usr/local/bin)디렉토리를 개방하 였다면, 명령어를 당신의 의도대로 만든 트로이목마 프로그램등으로 대치해 두면 다음 사용자가 이를 실행하면 당신이 원하는 명령을 목표 시스템에 실행할 수 있다.
파일 시스템은,
- 특별히 신뢰하는 클아이언트에만 read/write only 로 개방하며,
- 가능한 Read-only로 만든다.
만약 /etc/hosts.equiv 에 "+"를 가지고 있다면(대부분 업체에서는 이것이 디폴트) 혹은 netgroups 버그(CERT advisory 91:12)의 경우 목표시스템의 패스워드 파일내에 있는 계정을 가진 사용자면 패스워드 없이 로그인할 수 있다. "bin" 사용자는 중요한 디렉토리나 파일을 소유주이므로 목표시스템에 다음 들어갈 경우에는 root로 접근할 수 있도록 패스워드 파일을 수정할 수 있다.
rsh 을 finger나 who로 보이지 않도록 wtmp나 utmp 시스템 로그를 이용한 어떤 추적도 남기지 않으므로 시스템에 접근할 수 있다. COPS(부록D) 은 관리자가 아닌 어떠한 사용자가 주요한 파일에 대해 쓰기권한을 가질 수 있는지 보고한다. 만약 SunOS 4.x 을 사용한다면 패치 100103 을 이용하여 파일 접근 권한문제를 해결할 수 있다. 위의 rsh 방법은 적당한 자료를 남기지 않으므로 tcp wrapper(부록 D)는 들어오는 접속에 대해 적당한 로그를 남긴다.
---------------------------------------------------------------------------
이제 무엇을 하나? 목표 시스템의 모든 취약점을 다 찾은 것이 아닐 것이다.
다시 "finger" 를 이용하여 목표 시스템이 "ftp" 게정을 가지고 있다는 것을 알게 된다면, 이는 anonymous ftp를 구성하고 있다는 것을 알려주는 것이다.
anonymous ftp는 잘못 구성됨으로서 쉽게 외부에서 접근 할 수 있게 해준다. 예를 들어 목표 시스템이 ~ftp/etc 디렉토리에 /etc/passwd 파일 전체 카피를 가지고 있다면 victim.com의 ftp 계정의 홈디렉토리는 쓰기가 가능해진다. 이것은 목표시스템에 remote 명령을 실행할 수 있도록 해주는, 예를 들어 전자우편을 통해 패스워드 파일을 보내게한다든가 하는 식의, 즉 ftp로 메일이 왔을 때 명령을 실행하도록 .forward 파일을 만들 수 있는 것이다. 이것은 "vacation" 프로그램이 메일에 자동 응답하도록 사용하는 파이프의 개념을 이용하는 것이다.
이제 당신은 단순히 패스워드 파일이 올때 까지 기다리면 되는 것이다.
COPS가 Anonymous FTP 가 올바른지 점검할 수 있으며, ftp 매뉴얼 페이지나, COPS의 문서나 코드 혹은 CERT-Advisory 93:10 을 참고하여 올바르게 Anonymous FTP를 설치할 수 있도록 한다. ftp 의 취약성은 주요한 파일이나 디렉토리의 잘못된 소유주 문제에서도 비롯될 수 있으며, 최소한 ~ftp와 ~ftp 아래에 있는 모든 시스템디렉토리 및 파일의 소유주룰 root로 해야 하며, 기타 어떤 사용자에게도 쓰기 권한을 허용해서는 안된다.
ftp 에 대해서는 예전에도 많이 공격하는 수법의 대상이 된 버그를 이용할 수 있다.
만약 이것이 동작된다면 root로 로그인하여 패스워드 파일을 수정하거나 어떤 작업도 할 수 있게 된다. 만약 이런 버그를 아직 가지고 있다면 업체나 ftp.uu.net 에서 새 버젼을 가져와 교체해야 한다.
기존의 ftp 교체 버젼인 Washington 대학에서 만든 wuarchive ftp도 같은 문제를 가지고 있으며 1993 4월 8일 이전 버젼을 사용한다면 최신버젼으로 교체해야 한다. 마지막으로 ftp와 유사한 tftp가 있는데, 패스워드나 다른 인증을 거치지 않는 방법이므로 inetd.conf에 secure 옵션플래그를 두어 접근을 제한하지 않는다면 침입자는 어떠한 디렉토리의 어떤 파일에 대해서도 읽기/쓰기가 가능해진다. 보통 이를 통해 패스워드 파일을 가져와서 /tmp디렉토리에 둘 수 있다.
보안을 위해 가능한 tftp는 사용하지 않는 것이 좋으며, 만약 필요하다면, 공개하는 정보만 있는 디렉토리로 접근을 제한한 secure 옵션 프래그를 두어 사용하거나 chroot wrapper 의 제어하에 사용한다.
이상의 방법이 통하지 않는 경우 어떤 의미에서는 finger 보다 더욱 편리한 rpcinfo를 사용할 수 있다. rpc를 이용하는 많은 시스템이 공격당할 수 있는데, rpcinfo가 portmapper와 대화하여 그 방법을 알려준다. 호스트가 NIS를 사용하는지, NIS가 서버인지 slave인지, 디스크없는 워크스테이션이 있는지 없는지, rusersd나 rstatd 등의 서비스가 있는지 없는지와 NFS에 대한 정보 등을 알려준다. 아까와 같은 목표시스템에서 예를 들어 본다.
여기에서 많은 중요한 정보들을 볼 수 있는데, 첫째 이 시스템이 NIS 서버란 사실이다. 아마 많이 알려져있지는 않았서도 서버의 NIS 도메인네임을 한번 알게되면, 이 NIS 서버의 서브네트 바깥에 있다할지라도 간단한 rpc query를 통해 NIS Maps 의 어떤 것도 알아낼 수 있다. 예를 들어 ftp.uu.net의 comp.sources.misc에서 찾을 수 있는 YPX를 사용할 수 있다. 더우기 패스워드를 짐작할 수 있는 것과 마찬가지로 NIS 도메인네임도 쉽게 짐작 할 수 있다. 부분적으로 혹은 전체적으로 알게된 호스트이름(예를 들어 victim 이나 victim.com등), 기관 이름, "showmount" 등으로 알게된 netgroups 이름 등으로 짐작할 수 있다. "victim"으로 짐작하고 싶다면 다음을 이용한다.
이것은 실패한 경우이다. 만약 성공한 경우라면 victim.com의 NIS서버 호스트이름을 반환받게 된다. 그러나 victim.com이 "/var"를 완전히 개방하고 있다는 사실을 NFS에서 알수 있었다. 이 디렉로리를 마운트하여 "yp"서브디렉토리를 볼 수 있는데, 혹은 다른 서브디렉토리에서 목표시스템의 도메인네임을 알 수도 있을 것이다.
이 경우 'foo_bar"가 NIS 도메인 이름이다. 그리고 가끔 NIS 맵은 크랙킹을 위한 패스워드 뿐 아니라 user/employee나 내부 호스트이름 리스트 등을 가지고 있을 수있다. 부록 C는 NIS 패스워드 파일에 대한 사례의 결과가 상세히 실려있다.
---------------------------------------------------------------------------
rpcinfo 가 victim.com이 rexed를 사용하고 있다는 것도 알려주고 있다. rshd와 마찬가지로 rexed는 원격지에 명령을 실행할 수 있도록 요청하는 서비스이다.
하지만 rshd와는 달리 hosts.eqiv나 .rhost의 존재 유무에 상관없다. 보통 rexed 클라이언트 프로그램이 명령어에 있지만 단지 적은 C 프로그램을 가지고 있으며 어떤 클라이언트 호스트와 사용자 정보를 서버에게 보내면 서버는 이 명령을 실행하게 된다. 이러한 이유로 rexed를 이용하는 것은 아무 패스워드를 가지고 있지 않는 것과 같으며 클라이언트에 보안 책임이 있게 된다. rexed의 보안은 securerpc를 사용함으로서 이루어질 수 있다.
---------------------------------------------------------------------------
rpcinfo의 결과에 따라 우리는 victim.com이 디스크없는 워크스테이션을 위한 서버임을 알 수 있다. 이것은 디스크없는 워크스테이션의 부팅을 위한 bootparam이 있는 것을 보고 알 수 있다. 만약 BOOTPARAMPROC_WHOAMI와 클라이언트의 어드레스를 이용하여 잘 요청하면 NIS 도메인네임을 알수 있다. 이것은 도메인네임을 알아 NIS 맵(예를 들어 패스워드 파일과 같은 것)과 잘 결합하면 우수한 효과를 가질 수 있다. 여기 간단한 사례 프로그램이 있다.(bootparam 은 SATAN의 일부)
"showmout"결과는 victim.com의 디스크없는 워크스테이션들이 쉽다는 것을 알 수 있는데, 우리는 이것들의 어드레스를 BOOTPARAMPROC_WHOAMI query에 사용한다.
---------------------------------------------------------------------------
NIS 마스터는 NIS 도메인 에서의 질문에 대한 mail alias를 제어한다. 한 시스템에서의 mail alias 파일 처럼 메일이 전송될때 명령어를 실행하도록 mail alias를 만들 수 있다. 가장 흔한 사례는 메일을 전달할 때 uudecode 를 실행하는 "decode" alias 이다. 예를 들어 "foo" 라는 alias 를 만들어 다음과 같이 단순히 메일을 보냄으로서 evil.com으로 패스워드를 메일로 보내게금 할 수 있다.
침입자가 NIS마스터 호스트에 대한 제어를 갖지 않아야 하겠지만, 또한 명백한 교훈은 NIS가 보안이 적절하지 않아, 침입자가 NIS 마스터를 제어할 수 있다면 침입자는 클라이언트에 명령을 실행하는 것과 같은 식으로 디스크없는 워크스테이션에 대해 제어할 수 있다.
클라이어트와 서버사이에 적절한 인증방법이 제공되지 않은 보안이 적절하지 못한 NIS 공격에 대한 여러가지 대응책이 없는 편이다. 더우기 나쁜 것은 어떤 맵은 마스터 서버에게도 강요될 수 있어서 NIS서버가 클라이언트가 되도록 조정할 수 있기도 하다. 만약 꼭 NIS를 사용하고자 한다면 도메인네임이 쉽게 짐작할 수 없도록 하는 것이 조금 도움이 될 것이다. 이 경우 만약 잠재적인 공격자에게 디스크 없는 클라이언트가 공개된다면 도메인네임을 얻기위한 bootparam 트릭을 사용하는 간단한 방법이 소용없게 만들 수 있다.만약 NIS가 패스워드 맵을 전파하기 위해 사용된다면 이미 root 권한을 가진 침입자가 아직도 접근할 수 있으므로 shadow 패스워드는 더 이상 좋은 보안이 되질 않는다. 좋은 것은 NIS를 사용하지 않는 것이며, 맵이 잠재적으로 어떠한 강제에의해 종속되지 않도록 최소화하는 것이다.
Secure RPC는 이러한 위협을 막는 또 다른 방버이긴 하지만 이것은 관리하기에도 어려우며 여기에서 사용된 암호 기법이 우수하지도 않다. SUN이 새롭게 선보인 NIS+가 이러한 문제점을 해결하였다고 하지만 제한된 SUN에서만 동작하며 원래의 설계 상의 잇점을 살릴 수도 없다. 마지막으로 패킷 필터링(port 111)을 이용하거나 Securelib, SUN의 sunpatch 100482-02 가 도움이 될 것이다.
---------------------------------------------------------------------------
portmapper 는 단지 rpc 서비스에 대해서만 알려주는 것은 아니다. 다른 네트워크 서비스에 대해서도 모든 네트워크 포트에 대해 강제적인 방법으로 위치시킬 수 있다. 마치 sendmail은 25번, telnet 은 23 번, x window 는 6000 번 이듯이 모든 네트워크 서비스는 특정 포트에 대해 듣고있다. SATAN 은 원격지 시스템에 대해 네트워크 포트를 스캐닝하며 발견한 정보를 보고 하는 프로그램을 가지고 있다. 목표시스템에 대해 실행하면 다음을 볼 수 있다.
이 시스템은 X Window 시스템을 실행하고 있다는 것을 알려준다. 만약 magic cookie 나 xhost 메카니즘 등을 실행하여 적절히 보호하고 있지 않고 있다면, 원도우 디스플레이가 캡춰당하거나 보일 수 있으며, 혹은 사용자의 키입력이 도용되거나 프로그램이 원격지에서 실행될 수 있다. 그리고 목표 시스템이 X 를 실행하고 포트 6000번으로의 telnet 을 받아들인다면 목표 시스템의 x window 시스템의 동작을 일시 정지시키는 것과 같은 서비스거부 공격에 이용될 수 있다. X 서버의 취약점을 알 수 있는 또다른 방법은 XOpenDisplay() 함수를 이용하는 것으로서 만약 이 함수가 NULL 을 반환한다면 목표의 디스플레이에 접근할 수 없다. 이 기능은 SATAN에 포함된 기능이다.
완전한 유닉스 보다는 떨어지는 X 터미널도 자체의 보안문제를 가질 수 있다. 많은 X 터미널은 제한이 없는 rsh 접근을 허용하고 있으며, 이것은 목표시스템의 터미널에서 X 클라이언트를 시작하게 하면서 결과가 자신의 스크린에 나오게 할 수 있는 것이다.
어떤 경우에도 패스워드 없는 계정이나 hosts.eqiv 의 "+" 처럼 당신의 시스템의 보안을 침해하는 것과 같은 파일시스템과 네트워크 보안 처럼 X 윈도우의 보안도 많은 생각을 하게금 한다.
---------------------------------------------------------------------------
이제는 sendmail을 보자. sendmail은 이제는 대부분의 시스템에서 못쓰게금 되어있기는 하지만 악명높은 "wiz" 명령의 문제를 포함한 많은 보안 문제를 가지고 있는 매우 복잡한 프로그램이다. sendmail 이 반환한 버젼번호를 보아 목표시스템의 OS 나 때때로 버젼번호 등을 알 수 있다. 이것은 여러가지 버그들 중 어떤 취약점이 해당하는지를 알수있게금 한다. 더우기 만약 상대편이 "decode" alias 를 가지고 있다면 많은 문제를 알 수 있는 것이다.
"decode" alias 는 매우 위험한 보안문제를 야기하는데, 이것은 공격자가 어떤 파일에 대해 쓰기를 할 수 있도록한다. 특히 대부분은 소유주가 데몬인 파일이지만 잠재적으로는 어떤 사용자의 파일도 가능한 것이다. 다음 메일을 보면 이것은 "evil.com" 의 zen 사용자의 .rhosts 파일을 보내는 것이다.
만약 어떠한 홈 디렉토리도 못찾고 또한 쓰기를 할 수 없다면 다른 변형으로서 목표시스템에 어떤 명령을 실행하도록 /etc/aliases.pag 파일에 무언가 첨가하는 것이다. 대부분의 시스템들이 메일 alias 를 제어하는 /etc/aliases.pag나 aliases.dir 파일들이 완전히 쓰기 개방되어있어 성공할 가능성이 높다.
만약 vrfy로 어드레스를 확인하거나 expn 을 통해 어드레스 확장이 된다는 것을 sendmail 과의 대화를 통해 알 수있다면 많은 것을 발견할 수 있다.
finger나 rusers 를 사용할 수 없을 때 vrfy 나 expn 는 사용자나 목표 시스템을 확인하는데 사용될 수 있다. Vrfy 나 expn 은 vacation 이나 mail sorter 와 같은 문제있는 프로그램과의 파이프를 찾는데 사용될 수 있다. vrfy 와 expn 등을 금지하는 것이 좋은데 대부분의 버젼에서는 srvrsmtp.c의 소스를 보고 CmdTab structure내 "vrfy" 와 "expn" 라인을 지우거나 바꾸는 것이 좋다. 소스가 없는 곳에서도 바이너리 에디터를 통해 2개의 스트링을 공백으로 교체하여 지울 수 있다. 부록 D 에서 보이는 것과 같이 최신의 sendmail 버젼으로 교체하는 것도 하나의 방법이다.
---------------------------------------------------------------------------
sendmail-sendoff 에서도 잘 알려진 버그가 2개 있다. 처음 버그는 Berkeley 에서 5.59 버젼에서 분명하게 문제를 해결하였다. 이전 버젼에 대해서는 "evil.com"이 에러메세지에도 불구하고 지정한 파일이 메일 헤더에 첨부되어 받을 수 있다.
2번째 문제는 최근에 발견된 것으로서 송신자가 어떤 쉘 명령을 정의하거나 송신자나 목적지 어드레스 등의 패스이름을 지정하는 것을 허용하는 것이다. 여기에서 자세한 설명은 생략하지만 usenet news 나 기타에서 알려진 바가 있으므로 생략하며 대부분의 sendmail 에서 문제가 있다. 하지만 대표적인 공격 형태는 다음과 같다.
지금 sendmail 버젼 8.6.4 는 단지 몇몇 엄체에서만 많은 보안취약점들을 해결하고 있는 것으로 알려지고 있으며 부록 D 를 참고하기 바란다.
Trust
우리의 마지막 주제로서 약간 이론적인 입장에서 신뢰(Trust) 문제를 살펴 보기로 한다. 이것은 대부분 어떤 기관 내부에서 자원 공유의 입장에서 패스워드나 기타 인증 방법을 통하지 않는 것을 의미하는데, 클라이언트에 대한 제한을 어떻게 할 수 있나에 대해 말하려는 것이다.
호스트가 신뢰하는 방법은 여러가지가 있을 수 있다. hosts.equiv 나 .rhosts 에서 패스워드를 묻지 않고 접근을 허용하는 방법, 원격지시스템이 권한을 사용하거나 남용하도록 해주는 X 서버, NFS 제어를 통한 파일의 개방 등이다. 모든 것들은 클라이언트들의 어드레스를 호스트이름으로 변환할때 이 서비스를 받을수 있을지 없을지가 결정된다. 직접 하는 방법은 /etc/hosts 를 이용한 간단한 방법이며, 현재는 대부분이 DNS, NIS 등을 이용하고 있다. 클라이언트가 접속 요청시 IP 어드레스에 의해 역 lookup 이 이루어져 원하는 클라이언트인지 확인을 바라게 된다.
이러한 확인 방법에 대해 많는 관리자들이 이해하고 있지만 중요한 실질적인 보안문제는 호스트이름 위장의 경우이다. 이것은 단순히 관리자들이 잘 알고 있는 hosts.equiv 나 .rhosts 문제, X 윈도우, NFS 문제의 차원을 넘어선 문제이다. 어떠한 신뢰이라 할지라도 위장되거나 무력화되거나 바꿔치기 될 수 있는데,이는 서버의 관리영역 밖에 있는 authority 가 클라이언트의 신뢰성(Credential)을 점검하거나 신뢰하는 메카니즘이 매우 취약한 경우에서 비롯되는 것이다. 명백히 NIS, DNS 등에서의 데이타베이스가 만약침해 당했다면 침입자는 신뢰하는 시스템에서의 접근인 것 처럼 위장할 수있으며, 이것으로 목표시스템이 신뢰하는 어떤 호스트가 있는지 충분히 알수 있기 때문이다. 이 작업은 시스템관리자나 root 와 같은 계정이 어떤 호스트에서 접근하는지를 검사하면 매우 도움이 된다.
다시 victim.com 의 사례로 돌아가서 관리자가 big.victim.com 에서 접근하는 것을 알았다고 가정해보자. evil.com의 DNS PTR 레코드를 교체하여 evil.com 에서 victim.com 으로 rlogin 하려하면 victim.com 은 호스트이름을 보려고 하여 교체한 레코드를 보게될 것이다.
다음은 원래의 PTR 레코드와 교체한 PTR 레코드이다.
다음에는 victim.com 에 달려있는데, big.victim.com 이 /etc/hosts.equiv 나 .rhosts 에 존재한다면 접속을 허용하여 패스워드 없이 접근할 수 있을 것이다. NIS 에서는 침입자가 만약 NIS 마스터를 제어하고 있다면 호스트데이타베이스를 수정하는 것은 더욱 쉬운 일이며, 원하는 정보를 가진 목표 시스템을 이용하여 NIS 를 위장하거나 강제화할 수 있을 것이다.
이러한 공격을 막기위한 2가지 방법이 있다. 첫째는 매우 직접적이지만 비현실적인 것으로서 단순히 어떠한 호스트도 믿지 않는 것이다. 다른 방법은 암호프로토콜을 사용하는 것으로서 Secure NFS, NIS+ 등의 Secure RPC를 사용하는 방법인데, 만약 암호가 깨진다 하더라도 암호를 사용하지 않는 기존의 인증 방식보다 훨씬 우수하다. 다른 방법으로서 smartcard 하드웨어를 사용하거나, kerberos 등의 소프트웨어를 사용할 수 있는데, 전자는 아직 잘 개발된 상태가 아니며, 후자는 시스템의 전반적인 수정이 요구된다.
부록 B 는 인터넷 여러군데에서 검토한 비공식자료로서 보다 자세히 설명하고 있다.
Protecting the system
시스템보안을 위한 일반적인 제안들을 보이고자 한다.
- 만약 finger 서비스를 꼭 해야 한다면 수정된 버젼을 설치하라. 사용자의 홈 디렉토리니, 로그인 한 호스트이름 등을 알릴 필요는 없는 것이다.
- 절대적으로 필요하지 않다면 NIS 를 사용하지 말것이며, NFS 도 가능한 사용하지 않는다.
- 절대로 NFS 파일시스템을 완전히(Worldwide) 공개하지 말것이며, 가능한 읽기 전용으로 만들어라.
- 서버를 방어하고 보호한다. 단지 관리할 수 있는 계정만을 허용한다.
- inetd 나 portmapper 등에서 불필요한 서비스가 없는지 점검한다. 만약 접속하는 시스템의 로그를 기록하고 싶다면 wrapper 를 사용하는 것이 좋은데, 표준 유닉스보다 우수한 로그와 특히 네트워크 공격에 대한 기록이 우수하다. 그리고 가능한 보안 관련 정보를 입수하기 위해 syslog 의 loghost 메카니즘을 이용하라.
- 완벽하게 믿을 수 있는 시스템이 없다면 신뢰하는 호스트를 없앤다.
- Shadow 패스워드와 잘못된 패스워드를 가려내는 패스워드 명령을 사용한다. 사용하지 않는 계정과 시스템을 없앤다.
- 최근의 자료(참고문헌)와 도구들을 수집하며, 보안 사고 문제나 보안관련 문제를 지속적으로 남들과 대화한다. 최소한 CERT mailing list와 보안잡지, Firewall mailing list, 보안 관련 뉴스그룹 등에 가입한다. 무관심도 보안 문제에 가장 큰 적이다.
- 기관의 모든 호스트에 대해 가능한 최신 패치를 설치한다.
네트워크 방하벽시스템, Kerberos, 일회용 패스워드시스템 등이 보안문제를 해경하는데 도움이 되지만 위에서 여기에서 알려진 이러한 공격에 모무 안전한 것은 아니다. 즉 위 3, 4 가지 우수한 보안 기법을 사용하는 것이 좋다고 권고하지만 모두 해결되는 것은 아니라는 말이다.
Conclusions
Perhaps none of the methods shown here are surprising; when writing this paper, we didn't learn very much about how to break into systems. What we _did_ learn was, while testing these methods out on our own systems and that of friendly sites, just how effective this set of methods is for gaining access to a typical (UNIX) Internet host. Tiring of trying to type these in all by hand, and desiring to keep our own systems more secure, we decided to implement a security tool (SATAN) that attempts to check remote hosts for at least some of the problems discussed here. The typical response, when telling people about our paper and our tool was something on the order of "that sounds pretty dangerous -- I hope you're not going to give it out to everybody. But you since you can trust me, may I have a copy of it?"
We never set out to create a cookbook or toolkit of methods and programs on how to break into systems -- instead, we saw that these same methods were being used, every day, against ourselves and against friendly system administrators. We believe that by propagating information that normally wasn't available to those outside of the underworld, we can increase security by raising awareness. Trying to restrict access to "dangerous" security information has never seemed to be a very effective method for increasing security; indeed, the opposite appears to be the case, since the system crackers have shown little reticence to share their information with each other.
While it is almost certain that some of the information presented here is new material to (aspiring) system crackers, and that some will use it to gain unauthorized entrance onto hosts, the evidence presented even by our ad hoc tests shows that there is a much larger number of insecure sites, simply because the system administrators don't know any better -- they aren't stupid or slow, they simply are unable to spend the very little free time that they have to explore all of the security issues that pertain to their systems. Combine that with no easy access to this sort of information and you have poorly defended systems. We (modestly) hope that this paper will provide badly-needed data on how systems are broken into, and further, to explain _why_ certain steps should be taken to secure a system. Knowing why something is a problem is, in our opinion, the real key to learning and to making an informed, intelligent choice as to what security really means for your site.
---------------------------------------------------------------------------
부록 A: SATAN (Security Analysis Tool for Auditing Networks)
SATAN은 보다 크고 이해하기 쉬운 프로토타입 보안 도구이다. SATAN 은 목표하는 시스템의 일반적이고 도움이 될 정보를 상세하게 보고하거나 네트워크와 윈도우 시스템의 버그나 보안 취약요소들을 점검하여 보고한다. 그리고 결과 데이타에 대해 정해진 규칙에 따른 필터링을 하고 최종 분석 결과를 요약하기 위한 전문가프로그램이 사용된다. 이것은 빠르게 처리되지는 않지만 잘 모듈화되어있으며, 쉽게 수정할 수 있다.
SATAN 은 여러개의 서브프로그램으로 구성되며, 각각은 Perl, Shell, C 로 구현되어 있으며, 각각 주어진 목표를 공격 점검할 수 있다. 추후 확장을 위해서는 메인 디렉토리에 ".sat"식의 실행프로그램을 추가하면 된다. 드라이버는 주어진 복표들에 대해 DNS, ping 등으로 존재 유무를 확인하고 실행파일들이 실제 그 시스템을 공격한다. 결과를 분석하는 필터링, 인터프리트 프로그램이 실행되어 마지막으로 사용자가 읽을 수 있는 형태로 요약 보고한다.
---------------------------------------------------------------------------
부록 B: 전산망 보안 점검 및 분석 사례
비공식적으로 대학, 군사기관 및 기업체의 200 여호스트 및 40000여개의 계정에 대해 점검을 실행한바 기관의 평균 10%가 .rhosts를 가지고 있었으며 이것들은 평균 6개의 신뢰하는 호스트들을 가지고 있었다. 하지만 어떤 경우에는 100개 이상의 엔트리를 가지거나 심지어 400 여개의 엔트리를 가진 .rhosts 를가진 곳도 있었다. 그리고 대부분의 경우 인터넷에 직접 연결되어 있었고 단지 하나의 기관만이 방화벽을 운영하고 있었는데, 대부분 기관 외부에 신뢰하는 호스트들을 가지고 있어 대부분 관리자의 통제 밖에 있다고 보인다. 규모가 큰 기관들은 .rhosts를 별로 가지고 있지 않았지만 신뢰하지 않는 호스트 뿐 아니라 .rhosts 파일의 크기는 대단히 컸다.
비록 얼마나 많은 엔트리들이 정당한지 확인하기 어려웠고, 특히 와일드카드, "Makefile". "Message-id:", "^Cs^A^C^M^Ci^C^MpNu^L^Z^O" 등에 대해서는 올바르게 신뢰하는 시스템으로서 구성되었는지를 확인하기 어려웠지만, 각 기관은 자신의 보안을 각 사용자에게 맡기고 있다는 것을 알 수 있었다. 많은 량의 엔트리를 가진 .rhosts 파일의 경우에는 쉘 형태의 코멘트를 많이 가지고 있었는데, 대부분의 유닉스에서는 이러한 형태를 올바르게 해석하지 않으며, 침입자의 NIS, DNS 로 호스트이 름을 "#"으로 위장한 공격으로 자유롭게 접근한다.
여기 조사한 기관들이 인터넷에서의 대표적인 기관으로 발하기는 어렵고 사실이 아닐지도 모른다. 하지만 많은 관리자들은 보안연구나 보안제품에 대해 작업들을 많이 하고 있었을 뿐만 아니라 취미나 전문으로 프로그램을 만들고 보안 관련 작업을 많이 하고 있었던 것으로 보인다.
---------------------------------------------------------------------------
부록 C: 시스템 진단 사례
우리가 가진 시스템의 하나에서 출발한 침입을 알리는 전자우편을 받고 조사에 착수하여 어떤 기업체에서 온 침입자가 패스워드를 훔치기 쉬운 기관들을 검토하고 있는 것을 발견하였다. 이때 패스워드를 훔치기 쉬운 기관이란 NIS 도메인이름을 쉽게 유추할 수 있다든가 NIS 서버에 쉽게 접근할 수 있는 기관을 의미한다. 침입자가 얼마나 진전이 있었는지 는 모르지만 이 기관에 경고를 주는 일을 하기로 하였다. 침입자는 656개의 호스트리스트를 가지고 있었는데, 그중에서 25개의 호스트에서 24개는 쉽게 훔쳐낼 수 있었으며, 이 중 3 분의 1은 적어도 하나의 패스워드 없는 계정으로 대화형 쉘을 가지고 있었다. 총 1594개의 패스워드 파일 엔트리에서 낮은 수준의 SUN 시스템에서 10분망에 50개 이상의 패스워드를 알아내었으며, 40%는 다음 20분 만에, root 의 패스워드를 1 시간만에 하나 알아애었다. 마음 며칠 만에는 5개의 root 패스워드를 알아내었다. 결국 24개(80%)의 패스워드 파일이 적어도 하나의 잘알려진 패스워드를 가지고 있었으며, 1594개의 엔트리중 259(6분의 1)개의 패스워드가 쉽게 추정 할 수 있었다.
---------------------------------------------------------------------------
부록 D: 무료 인터넷 보안 자료를 받으려면
Mailing lists:
* The CERT (Computer Emergency Response Team) advisory mailing list. Send e-mail to cert@cert.org, and ask to be placed on their mailing list.
* The Phrack newsletter. Send an e-mail message to phrack@well.sf.ca.us and ask to be added to the list.
* The Firewalls mailing list. Send the following line to majordomo@greatcircle.com: subscribe firewalls
* Computer Underground Digest. Send e-mail to tk0jut2@mvs.cso.niu.edu, asking to be placed on the list.
Free Software:
COPS (Computer Oracle and Password System) is available via anonymous ftp from archive.cis.ohio-state.edu, in pub/cops/1.04+.
The tcp wrappers are available via anonymous ftp from ftp.win.tue.nl, in pub/security.
Crack is available from ftp.uu.net, in /usenet/comp.sources.misc/volume28.
TAMU is a UNIX auditing tool that is part of a larger suite of excellent tools put out by a group at the Texas A&M University. They can be gotten via anonymous ftp at net.tamu.edu, in pub/security/TAMU.
Sources for ftpd and many other network utilities can be found in ftp.uu.net, in packages/bsd-sources.
Source for ISS (Internet Security Scanner), a tool that remotely scans for various network vulnerabilities, is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume40/iss.
Securelib is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume36/securelib.
The latest version of berkeley sendmail is available via anonymous ftp from ftp.cs.berkeley.edu, in ucb/sendmail.
Tripwire, a UNIX filesystem integrity checker+, is available via anonymous ftp at ftp.cs.purdue.edu, in pub/spaf/COAST/Tripwire.
---------------------------------------------------------------------------
참고문헌:
Baldwin, Robert W., Rule Based Analysis of Computer Security, Massachusetts Institute of Technology, June 1987.
Bellovin, Steve, Using the Domain Name System for System Break-ins, 1992 (unpublished).
Massachusetts Institute of Technology, X Window System Protocol, Version 11, 1990.
Shimomura, Tsutomu, private communication.
Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992.
---------------------------------------------------------------------------
추천 참고문헌:
Bellovin, Steve -- "Security Problms in the TCP/IP Protocol Suite", Computer Communication Review 19 (2), 1989; a comment by Stephen Kent appears in volume 19 (3), 1989.
Garfinkel, Simson and Spafford, Gene, "Practical UNIX Security", O'Reilly and Associates, Inc., 1992.
Hess, David, Safford, David, and Pooch, Udo, "A UNIX Network Protocol Study: Network Information Service", Computer Communication Review 22 (5) 1992.
Phreak Accident, Playing Hide and Seek, UNIX style, Phrack, Volume Four, Issue Forty-Three, File 14 of 27.
Ranum, Marcus, "Firewalls" internet electronic mailing list, Sept 1993.
Schuba, Christoph, "Addressing Weaknesses in the Domain Name System Protocal", Purdue University, August 1993.
Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM 27 (8), 1984.
|
|
댓글목록
등록된 댓글이 없습니다.
