DNS/BIND관련 최근 취약점과 그 대책 분석보고서
1. DNS/BIND란?
DNS(Domain Name System)이란 이름과 IP주소를 mapping하여 주는 거대한 분산 네이밍 시스템 방법론이다. 인터넷에 존재하는 수많은 네임서버는 각각 도메인 계층상의 일부분을 관리하고, 정보를 요구하는 client Resolver는 규칙에 따라 분산된 자료중 원하는 정보를 찾을수 있게 해주는 방법을 말한다. BIND(Berkeley Internet Name Domain)는 이러한 DNS를 운용하게 위한 네임서버측의 데몬프로그램으로서 UNIX에서 사용되도록 구현된 프로그램을 말한다.
BIND는 2000년 1월 현재 BIND-4와 BIND-8두가지가 존재한다. BIND-4시리즈는 1998년 5월 BIND 4.9.7이 발표되면서 전통적인 BIND-4시리즈는 개발이 완료되었고, BIND-8시리즈는 현재 8.2.2 p7 까지 발표되었다. BIND-8은 RFC2136, RFC1996을 수렴하여 매커니즘과 보안이 많이 개선되었으나 새로운 보안문제들도 발생하였다. 장기적으로는 BIND-8시리즈가 많이 사용될 것이지만 현재는 대부분 도메인 에서 안정화된 BIND-4시리즈를 압도적으로 많이 사용하고 있다. 이 두 시리즈는 앞으로도 상당기간 공존할 것으로 예상된다. BIND-4와 BIND-8의 외부적인 차이는 부트파일의 형식의 변화이다. BIND-4에서는 부트파일이 named.boot이고, BIND-8에서는 named.conf이며 작성 형식도 BIND-8의 named.conf는 마치 C프로그램의 형식을 보는듯이 다소 복잡한 느낌을 주는 감이 있으나 기타 Zone파일과 캐시파일등은 동일하다.
2. Name Server의 유형
네임서버는 Primary(Master)서버, Secondary서버 , Cache only서버로 구분된다. Primary서버는 해당 도메인은 관리하는 주 네임서버이며, Secondary서버는 특정 도메인에 대한 back-up copy를 유지하는 서버이다. Cache only서버는 도메인에 대한 데이터는 가지고 있지 않고, resolving 만을 처리해주는 서버를 말한다.
3. DNS의 보안 이슈
최근 보안에 대한 관심이 많이 생겨서 각 네트웍마다 외부로부터 내부 네트웍을 보호하기 위한 패킷필터링 등을 적용하고 있다. 그러나 인터넷망에 연동함에 있어서는 어쩔수 없이 외부로부터의 incoming을 막아서는 안되는 패킷들이 있게되는데, 예를 들어 SMTP (TCP 25번 포트), HTTP (TCP 80번 포트) 가 있으며 또한 DNS (TCP, UDP 53번 포트) 관련 패킷도 패킷 필터링에서 대부분 제외된다. 따라서 공격자 입장에서는 라우터등에 적용되어 있는 패킷 필터링 규칙을 통과하여 바로 내부 시스템을 직접 공격할 수 있는 위 3가지 공격방법을 집중적으로 연구하게 되었다. 그중에서 SMTP는 그동안 sendmail 프로그램이 보안상 많은 문제점이 지적되어 와서 지금 현재는 상대적으로 보안 측면에서는 안정적인 내성을 갖게 되어 왔으나(spam문제는 별도의 문제), HTTP나 DNS 같은 경우에는 최근 보안문제가 매우 심각하게 대두되고 있다. 이 문서에서는 특히 DNS의 보안 문제점에 대해 다루어 보겠다.
4. UNIX용 BIND관련 최근 보안 취약점
o Inverse Query 취약점 (Buffer Overflow)
BIND 4 시리즈중 4.9.7 이전버전과 BIND 8 시리즈 중 8.1.2이전 버전은 외부에서 inverse query요청에 대하여 응답을 수행할때에 메모리에서의 적절한 한계값 검사를 하지 않아서 buffer overflow취약점이 존재한다. 공격자는 교묘히 조작한 패킷을 전송하여 root권한을 획득할 수 있게 된다.
이에 대한 대책으로는 최신버젼으로 업그레이드를 하거나, BIND 4.x의 경우에는 named.boot파일에서 "fake-iquery" 라인을 없애거나 "fake-iquery no;" 로 한다. BIND 8.x의 경우에는 named.boot파일에서 "fake-iquery"라인을 없애거나 아예 컴파일할때 conf/options.h에서 INVQ변수는 define하는 라인을 코멘트처리한후 컴파일하여 설치하는 것이다. 이 버그에 의한 버퍼오버플로우 공격에 의하여 루트쉘을 탈취당한 시스템중 일부는 /var/named/ADMROCKS라는 empty 디렉토리가 생기기도 하며,
/etc/inetd.conf에는 2222번 port의 back door가 생성되기도 한다.
2222 stream tcp nowait root /bin/sh sh -i
o NXT버그 (buffer overflow)
일반적으로 네임서버의 도메인 데이터베이스 정보를 저장하는 파일들은 모두 동일한 기본포맷을 가지고 같은 종류의 데이터베이스 레코드를 사용한다. 이러한 표준 리소스 레코드 중 BIND 8.2이상 버전부터는 NXT record라는 것이 있는데 NXT RR은 어떤 네임인터벌 안에서 owner name을 갖는 리소스레코드가 zone테이터베이스에 존재하지 않을때 이를 알려주는 기능과 존재하고있는 name에 대하여 어떠한 zone signed 리소스 레코드들이 부여되는지를 알려주는 기능을 가진다.
그런데 BIND 8.2, 8.2 p1, 8.2.1버젼에서는 NXT레코드에 대한 적절한 validate를 하지 못하는 버그를 가지고 있다. 이러한 NXT 레코드 확인 작업수행중의 버그를 이용하여 외부에서 buffer를 overflow시켜 임의의 code를 수행함으로써 named를 수행하고 있는 권한에 해당하는 권한의 쉘을 획득할수 있게된다.
NXT버그는 BIND 8.2부터 등장한 버그로서 기존에 많이 쓰이는 BIND 4.x시리즈는 이 버그를 걱정할 필요는 없지만, 앞으로는 BIND 8.x의 사용이 점차 증가될 것이 예상되므로 BIND 8.x의 사용시에는 가장 최신 버젼을 사용하여야 한다.
한편 NXT버그를 이용하는 exploit code는
ADM named 8.2/8.2.1 NXT remote overflow exploit 라는 소스코드가 1999년 말에 인터넷상에 공개되어 있는 상태다. 이 exploit코드를 실행시킨 상태에서 목표네임서버가 이 name space상에서 이 exploit 프로그램에 query를 하게끔 조작을 하게되면 목표네임서버가 버퍼오버플로우가 일어나면서 named데몬이 다운되면서 root권한으로 /tmp/bob 파일이 만들어진다.
ingreslock stream tcp nowait root /bin/sh sh -i
이란 내용을 파일안에 써놓게 된다. 동시에 다음과 같은 명령이 실행한다.
/usr/sbin/inetd -s /tmp/bob;/bin/rm -f /tmp/bob
이렇게 되면 침입당한 시스템에서는 ingreslock (1524/tcp) 포트가 백도어로 열려있는 상태가 되어 나중에도 재차 침입을 쉽게 허용하게 된다.
이 버퍼오버플로우 공격을 당하는 과정에서 어떤 시스템에서는 다음과 같은 empty 디렉토리가 생성되기도 한다.
/var/named/ADMROCKS
혹은 /var/named/O
named공격에 의해 관리자 권한을 뺏긴 시스템에는 이 시스템을 경유하여 다른 시스템의 named 취약점 정보를 수집하여 다시 공격하기 위한 공격용 툴들이 많이 설치되곤 한다.
o solinger버그 (Denial of Service)
BIND 4.x시리즈에는 이 버그가 존재하지 않으나 BIND 8.1 이상 버전에서는 외부에서 비정상적인 TCP session을 사용합으로써 named데몬을 120초 정도까지 수행정지상태로 만드는 서비스거부 공격이 가능하다. 이 공격이 주기적으로 반복되는 경우 네임서버의 처리능력이 현저히 저하된다.
현재 이러한 기법에 의한 네임서버에 대한 서비스 거부공격피해사례가 외국에서 보고된바 있으며 이 공격에 대한 대책은 최신버전 (현재BIND 8.2.2 p7)을 사용하는 것이다.
o fdmax 버그 (Denial of Service)
보통 named데몬은 수행되면서 일정한 수의 file descriptor들을 manage하게 되어 있는데, 외부에서 공격용 프로그램을 실행시킴으로서 /usr/include/sys/select.h에 정의되어 있는 FD_SETSIZE에서 지정된 수보다 많은 수의 file descriptor를 사용해버리게 되면 실행되고 있던 named데몬이 crash되게 된다.
이 버그는 BIND 8.1 이후 버전에 존재하며 현재 이러한 기법에 의한 네임서버에 대한 서비스 거부공격피해사례가 외국에서 보고된바 있으며 ,
이 공격에 대한 대책으로는 named.conf의 options에서 { files #; } 를 설정하면서 #수를 /usr/include/sys/select.h에 정의되어 있는 FD_SETSIZE에서 지정된 수보다 작게 설정하면 된다.
o Zone 데이터베이스 정보유출 방지
해커들은 종종 해당 도메인에 대한 정보를 얻기위해 네임서버로부터 zone 데이터베이스를 유출해내려 한다.
이를 막으려면 다른 특정한 name server에서만이 보호하려는 네임서버(primary, secondary)의 zone 데이터베이스를 transfer할수있게 해야한다.
BIND 4.9에서는 xfernets를 사용하여
nameserver# xfernets <address>[&<netmask>] [<address>[&<netmask>]
예) xfernets 207.69.231.3&255.255.255.255
BIND 8에서는 /etc/named.boot파일 (일부시스템에서는 named.conf파일)에서 allow-transfer 구문을 이용하여 다음과 같이 설정한다.
options { allow-transfer { address_match_list; }; };
한가지 유의할점은 zone transfer제한을 하려면 보통 primary서버에서만 제한하고 마는 경우가 있는데 zone
데이터베이스 유출을 막으려면 secondary서버에서도 확실히 제한을 해야 한다는 점이다.
예를 들어 ppp.jjj.co.kr 시스템의 네임서버는 다음과 같은 방법으로 알아낼수 있다.
napun.certcc.or.kr# nslookup
Default Server: ns.certcc.or.kr
Address: 203.233.150.1
> set q=ns
> ppp.jjj.co.kr
Server: ns.certcc.or.kr
Address: 203.233.150.1
ppp.jjj.co.kr
origin = ns.jjj.co.kr
mail addr = root.ns.jjj.co.kr
serial = 2000120104
refresh = 10800 (3H)
retry = 900 (15M)
expire = 864000 (1w3d)
minimum ttl = 21600 (6H)
> ns.jjj.co.kr
Server: ns.certcc.or.kr
Address: 203.233.150.1
ns.jjj.co.kr nameserver = ns.jjj.co.kr
ns.jjj.co.kr internet address = 188.188.29.1
이것으로부터 jjj.co.kr 도메인의 네임서버는 188.188.29.1 이라는 것을 알았다.
그런데 188.188.29.1 네임서버의 Zone transfer제한이 적절히 되어있지 않은 경우에는
다음과 같은 방법으로 zone 정보가 그대로 보인다.
napun.certcc.or.kr# dig @188.188.29.1 ns.jjj.co.kr axfr
; <<>> DiG 8.2 <<>> @188.188.29.1 ns.jjj.co.kr axfr
; (1 server found)
$ORIGIN ns.jjj.co.kr.
@ 20H IN SOA ns hostmaster.jjj.co.kr (
2000111001 ; serial
5H ; refresh
1H ; retry
4d4h ; expire
1D ) ; minimum
1H IN NS ns.jjj.co.kr.
20H IN A 188.188.29.85
1D IN HINFO "Pentium 133" "Red Hat 6.1"
1D IN MX 10 mail
mail 1D IN A 188.188.29.2
really 1D IN A 188.188.29.20
1D IN TXT "Admin's Trusted Workstation"
1D IN HINFO "Athlon 850" "Red Hat 6.1"
rather 1D IN A 188.188.29.15
1D IN HINFO "Pentium 266" "Mandrake 7.1"
serious 1D IN CNAME extra
extra 1D IN A 188.188.29.80
ns 1D IN A 188.188.1.30
r_g 1D IN A 188.188.1.68
roblimo 1D IN MX 10 r_g
1D IN A 188.188.1.44
tahara 1D IN A 188.188.1.27
;; Received 9 answers (9 records).
;; FROM: napun.certcc.or.kr to SERVER: 188.188.29.1
;; WHEN: Fri Dec 1 22:23:48 2000
이렇게 조회된 결과로서 현재 이 도메인에서 사용하고 있는 IP주소를 알수가 있으며, 또한 HINFO 데이터를 보면 시스템의 OS를 알수 있는 경우도 있다. 이렇게 확보된 IP주소 리스트는 도메인에 대한 네트웍 단위의 취약점 스캔에 사용되게 된다.
o Dynamic Update기능의 장단점
BIND 8.x부터는 dynamic update라는 기능이 추가되었는데 이는 zone데이터베이스 관리에 편리함도 있지만 동시에 보안관점에서 보면 위험한 기능이기도 하다. 따라서 이 기능을 굳이 사용하려면 named.boot에서 엄격히 제한된 범위에서만 사용하여야 한다. (BIND 8.x 메뉴얼을 참조)
5. UNIX용 BIND 보안취약점 대책
o Solaris 7 의 경우
SUN에서는 위와 같은 취약점을 보완하고자 다음과 같은 patch를 발표하였다.
Solaris 7 (SPARC) 107018-02 106938-03
Solaris 7 (Intel) 107019-02 106939-03
위의 patch는 다음 사이트에서 구할 수 있다.
http://sunsolve.sun.com/securitypatch
o RedHat Linux 6.x (또는 이와 유사한 리눅스버전) 의 경우
RedHat Linux 6.0의 named(bind)에 존재하는 취약점을
다음의 사이트에서 패치를 구하셔서 보완하여야 한다.
http://www.redhat.com/support/errata/RHSA1990054-01.6.0.html
6. MS Windows NT의 DNS취약점
o 개요
Microsoft NT 4.0에서 사용하는 MS-DNS에서도 서비스 거부 공격(Denial Of ervice)을 통한 보안 문제가 보고 되었다. 한글/ 영문 NT 4.0에서 MS DNS가 작동하고 있는 경우에 문제되는 것으로서 . 영문 NT4.0의 경우에는 서비스팩 3가 설치되어 있어도 취약점이 존재한다.
DNS 서비스의 이용을 위해 사용되는 53번 포트로 다량의 데이타를 한꺼번에 날리게 되면 NT의 서비스가 중지되거나, 시스템이 크래쉬 하는 상태가 발생하는 것이다.
o 설명
유닉스에서는 과거부터 chargen이라는 방법으로 charcter를 generate 하는 서비스가 존재한다. 그동안 echo와 더불어 chargen을 통한 서비스 거부공격으로 몇몇 유닉스 시스템의 운용이 중단 되는 보안 관련 문제가 보고 되기도 했는데, NT에 대한 서비스 거부공격에서도 chargen이 이용될 수 있다.
보통 chargen 서비스는 TCP 19번 포트를 통해 이루어지며, 이 chargen을 통해서 생성되는 character는 서비스 request를 한 쪽에서 중단할 때까지 계속되게 되어져 있다. 이 chargen의 특성을 이용하여 TCP 53을 이용하는 DNS에게 순간적으로 다량의 데이타를 보냄으로써, DNS 또는 NT시스템이 crash되는 것이다.
다음과 같이 19번 chargen 포트를 통해서 생성된 데이타를 53번 DNS 포트 전송하는 경우에 위의 상황이 발생할 수 있다.
attack% telnet NTbox 19 | telnet NTbox 53
여기서 attack%은 공격을 시도하는 UNIX시스템을 의미하며, NTbox는 인터넷 상에 연결되어진 NT 시스템이다. 먼저 NT 시스템의 19번 포트(chargen 포트) 접근하여 발생된 데이터들을 pipe ( | )를 이용하여 53번(DNS 포트)로 standard input이 되도록 redirect 시키는 것이다.
o 해결책
chargen 서비스 중지
임시방편으로는 chargen 서비스를 중지하는 방법이 있으며, 그러나 이는 근본적인 해결책이 되지는 못한다.
1. 시작 -> 실행 -> regedit 를 실행시켜서.
2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SimpTcp\Parameters
를 선택한다.
3. 아래의 키값 중, 0x1로 선택된 값들을 모두 0x0으로 바꾼다.
EnableTcpChargen, EnableTcpDaytime, EnableTcpDiscard, EnableTcpEcho, EnableTcpQotd, EnableUdpChargen, EnableUdpDiscard, EnableUdpDaytime, EnableUdpEcho,EnableUdpQotd
4. 시스템을 재부팅한다.
새로운 Bind 설치
새로운 Bind를 통한 DNS Server를 운용하고자 하는 경우도 일단은 위의 레지스트리 값을 변경하여 chargen서비스를 중지해주는 것이 좋다. 그렇지 않으면 chargen서비스는 다른 종류의 서비스거부공격에 사용될 수 있기 때문이다.
NT용 BIND는 공개 혹은 쉐어/평가판이 다수 릴리즈되어 있으며 성능도 괜찮은 것으로 평가된다.
NT관련 공개/쉐어용 프로그램 사이트 :
http://www.bhs.com
Power PC용 NT Bind : powerpc-bind493p12.zip
Dec Alpha용 NT Bind : alpha-bind493p12.zip
PC용 NT Bind : intel-bind493p12.exe
Windows 95/ NT 공용 Bind : winbind.zip
7. 관련 정보를 얻을 수 있는 곳
o
http://www.isc.org/products/BIND/
Internet Software Consortium의 BIND관련 정보가 있는 곳.
o BIND의 최신버전
4.9.7:
ftp://ftp.isc.org/isc/bind/src/4.9.7/bind-4.9.7-REL.tar.gz
8.2.2 p7:
http://www.isc.org/products/BIND/bind8.html
