DNS, related vulnerability ( hosts )

DNS cache, hosts file, query order

windows

1. The entries in the ho sts file are loaded into DNS cache by DNS Client Service
2. programs looks for DNS cache as the first step on name resolution.
3. Domain Name System (DNS) servers are queried.
4. If the name is still not resolved, NetBIOS name resolution sequence is used as a backup. This order can be changed by configuring the NetBIOS node type of the client.

실제로 hosts file은 몇 번 안읽힌다. DNS Client Service가 시작할 때 한번 읽히고, 그 이후로는 서비스가 hosts file이 수정되었음을 감지했을 때만 읽힌다. 그리고 읽히는 동시에 cache에 적재되니까, 실제로는 hosts file을 직접 참조하는게 아니라 DNS cache를 보는 것 이다. 생각해보면 DNS Resolution 마다 hosts file에 접근해 읽는 건 비효율적이다.

Note ) The Hosts file location depends on the operating system:

Windows NT                    %Systemroot%\System32\Drivers\Etc\hosts
Windows 95                    <drive>\<Windows folder>
MS-Client 3.0                 <Boot volume>\Net
Lan Manager 2.2c Client       <Boot volume>\Net
-----------------
cat %Systemroot%\System32\Drivers\Etc\hosts

A sample hosts file, Hosts.sam, is installed with the TCP/IP protocol showing the proper format. When resolving names the client will skip methods for which it is not configured. For example, if there is no hosts file on the system, then it will skip step #2 above and try a query to a DNS server. If no DNS server IP addresses are entered in the client TCP/IP configuration, then the client will skip to the next step in the sequence after DNS.

LINUX, UNIX

선택권이 없는 windows와 달리 host.conf의 order 옵션을 통해 query와 hosts파일 참조 순서를 지정할 수 있다. bind를 먼저 쓰면 DNS server에 요청부터 하고, hosts를 먼저 쓰면 hosts cache를 먼저 확인한다.

Zone transfer vulnerability

zone transfer 취약점은 master와 slave DNS 간 zone 동기화를 위해 사용하는 zone transfer에 대한 적절한 접근통제가 이루어지지 않아 발생하는 취약점이다. slave가 master의 백업으로 대기하고 있는게 아니라 로드밸런싱 개념으로 동시에 서비스하는 것이기 때문에 slave도 따로 설정하지 않았다면 nslookup 등의 서비스를 제공하게 된다. master와 slave 간 zone을 공유하기 위한 기능이므로 master에서는 slave로만 전송이 가능하도록, slave에서는 모두 전송 불가능하도록 설정해 놓아야 한다. 그러나 보통 master에서는 slave로만 전송하도록 설정되어 있는데 slave에는 적절한 설정이 되어있지 않아 발생하는 취약점이다. 참고) zone-transfer는 TCP 53을 사용한다. zone transfer는 nslookup, dig, host 등으로 확인 가능하다.

nslookup

nslookup
set type=any           //type을 any로 변경하고 request를 날려 nameserver 정보를 획득( whois 등에서 검색해도 됨. )
server=dnsserver       //request를 보낼 대상을 dnsserver로 설정
ls -d domainname       //dnsserver가 가지고 있는 domain에 대해 zone transfer를 시도한다.
( -d = 모든 레코드 나열. 없어도 된다 )

dig axfr @dnsserver domain.name

axfr은 axfr type query( zone transfer에 사용되는 type )를 보내겠다는 뜻이다.

적절한 설정

LINUX, UNIX

설정파일은 etc/named.conf

master 에서

options {
allow-transfer { slaveIP; };
};

slave 에서

options {
allow-transfer { none; };
};

windows

제어판-관리도구-서버 관리자-DNS

zone transfer를 사용하지 않고 NFS를 이용해 공유하거나, 수동으로 동기화 하는 경우 master도 slave처럼 none으로 설정하면 된다. 취약점을 막기위한 방법으로 이 밖에도 비밀키를 이용해 트랜잭션하는 방법이라던지, 다른 대안들이 더 있다고 한다.

16.09.20 북한 DNS data가 zone transfer 취약점으로 유출됐다. github link

DNS Amplification( Reflection ) Attack

DNS Reflection Attack이라고 하는 사람도 있는 것 같은데 Reflection Attack을 시도할 때 Amplification을 사용할 수 있다고 이해하면 된다. DNS같은 경우 Amplification을 사용하지 않으면 효과가 미미해 Amplification Attack이라고 부르는게 더 맞는 것 같다. DNS Amplification Attack은 DNS server에 victim의 IP로 query를 보내서 다량의 UDP packet(DNS response)가 victim으로 가게 하는 것이다. 여기까지만 보면 reflection인데, amplification하기 위해 EDNS0 DNS protocol extension 을 사용한다. 이 확장 프로토콜은 거대한 DNS 메시지를 허용하거나 DNSSEC에서 메시지 사이즈를 증가시키는데 사용된다. 또한 DNS query type은 ‘ANY’ 로 적어 보내서 single request에 받아올 수 있는 모든 DNS zone information을 받아오게 된다.

이런 방법을 통해 60byte 정도의 DNS request가 4000byte가 넘는 response로 amplification되어 target으로 날아간다.

결과적으로 70배 정도 증폭 된 셈이다. 덧붙여 보통 DNS request를 botnet들을 통해 relay해서 보내기 때문에 추적하기 쉽지 않다고 한다.

List of DNS record types

nslookup에서 set type=X 명령으로 설정할 수 있다. 보통 A+AAAA로 설정되어 있고, ANY, MX, ALL 등으로 변경 가능하다. ANY와 ALL의 차이점은, ALL은 ANY의 출력정보에 추가로 입력url에 연결된 모든 IP를 보여준다.

참고

https://www.linux.co.kr/home/lecture/files/sbHong/securing_zone_transfer.pdf

http://security.stackexchange.com/questions/93820/dns-reflection-attack-vs-dns-amplification-attack