Wikipedia DNS_spoofingに書かれている攻撃手法の実装と注入にかかる時間の期待値、及び攻撃ツールの最適化について
Kazunori Fujiwara, JPRS
fujiwara@jprs.co.jp
2014/6/27

本日の目的と範囲• 攻撃の原理をわかりやすく伝えることで理解を深め、対策を考えるうえでの参考とする• 攻撃にかかる時間の期待値を示すことで、正しく運用していれば問題がないことを示す• RFC 2181のランキングの問題については触れない– 今後IETFで動きます– フルリゾルバを作りたくなってきた
Copyright © 2014 Japan Registry Services Co., Ltd.

2DNS spoofing• Wikipedia英語版：
http://en.wikipedia.org/wiki/DNS_spoofing• 何年も前に書かれていたらしいので引用
Redirect the target domain's nameserver
The first variant of DNS cache poisoning involves redirecting
the nameserver of the attacker’s domain to the nameserver ofthe target domain, then assigning that nameserver an IP
address specified by the attacker.

• 委任応答を偽造する

Copyright © 2014 Japan Registry Services Co., Ltd.

3

DNS spoofing• 英語版Wikipediaの該当エントリに「対策はPort RandomizationとDNSSEC」と書かれている– 通信路の暗号化については、最近のIETF DNSprivacyの議論を先取りしている• 攻撃手法・対策ともに既知• RFC 3833の「2.2. ID guessing and queryprediction」に分類されるもの– IDの推測と問合せの予測– RFC 3833：Threat Analysis of the Domain
Name System (DNS) (DNSの脅威の分析)
Copyright © 2014 Japan Registry Services Co., Ltd.

4

攻撃イメージ①を送って、③⑤⑦より先に③⑤⑦のふりをした偽造応答を注入してやればよい
Full-Resolver(Cache)
End user’squery

Stub Resolver

2345

TLD (TopLevel Domain)
JP

6718

Root

Root

NET COM

example.jp

jprs.co.jp

Organization
Authoritative DNS Servers
Copyright © 2014 Japan Registry Services Co., Ltd.

5

Kaminsky型攻撃手法• 攻撃対象の名前の前にランダムなラベルをつけたクエリ名を使用– 攻撃対象のサブドメイン– 攻撃対象を管理する権威DNSサーバーから返る正当な応答は名前エラー(NXDOMAIN)– 正当な応答が先に到達した(攻撃失敗)場合、クエリ名のエラー情報だけがキャッシュされる• 攻撃対象の注入には影響がない– このため、一度攻撃に失敗してもランダムなラベルを変更することで、連続して攻撃できる
Copyright © 2014 Japan Registry Services Co., Ltd.

6

Kaminsky型攻撃手法• ランダムなラベルをつけたクエリ名はキャッシュされていないため、フルリゾルバはクエリを受信するごとに権威サーバにクエリを送る• これに対する応答を偽造して先に返す• Kaminsky型攻撃手法では、攻撃者が以下の双方を送ることがポイント– ランダムなラベルをつけたクエリ名– そのクエリに対応する、権威DNSサーバーからの応答のふりをした偽の応答
Copyright © 2014 Japan Registry Services Co., Ltd.

7

Kaminsky型の偽装応答攻撃
例：www.example.jp というホスト名を注入する場合
1. (random).www.example.jp Aクエリを攻撃対象に送る– example.jpを管理する権威DNSサーバは名前エラーを返す– 偽造応答の注入が成功しなかった場合、• (random).www.example.jpのエラーのみキャッシュされる• www.example.jpの情報はキャッシュされない

2. 偽造応答”www.example.jp IN NS my-server”をexample.jpのサーバのアドレスから注入する– my-serverにwww.example.jp zoneを事前準備しておく
実際の攻撃では、ID(問合せと応答を紐付ける番号)のみを変更した、多数の偽造応答を同時に送る

Copyright © 2014 Japan Registry Services Co., Ltd.

8

Kaminsky型の偽装応答攻撃
ns1.example.jp
Full-Resolver port P
ns1.example.jp port 53
ID mmm, Query(random).www.example.jp A

送信元
送信先
DNSヘッダ
クエリ情報
応答

Full-Resolver(Cache)
1 8
Attacker port any
Full-Resolver port 53
ID any, Query(random).www.example.jp A

example.jp

67

ns1.example.jp port 53
Full-Resolver port P
ID mmm, Response(random).www.example.jp A(random).www.example.jpは存在しない⑦より前に偽装応答を送信
ns1.example.jp port 53
Full-Resolver port P
ID mmm, Response(random).www.example.jp A
www.example.jp NS my-server

Attacker

IPアドレス、ポート番号、ID、クエスチョンセクションを正規の応答と同じにし、応答部分だけ違う偽装応答
Copyright © 2014 Japan Registry Services Co., Ltd.

9

対象ドメイン名• ランダムラベルを前置すると存在しない名前になるドメイン名を「トリガードメイン名」とする– (random).www.example.jpの場合、www.example.jpがトリガードメイン名となる• トリガードメイン名の権威DNSサーバが管理するドメイン名のうち、以下の条件をともに満たすものを注入可能
1. トリガードメイン名とその祖先のドメイン名
2. 最も短いゾーン頂点ではないドメイン名

Copyright © 2014 Japan Registry Services Co., Ltd.

10

対象ドメイン名(ほとんどのホスト名)
例1：トリガードメイン名がwww.example.jpである場合
www.example.jpはexample.jpの権威DNSサーバーが管理しており、この権威DNSサーバーは他のゾーンを一つも管理していないものとする• www.example.jpを注入できる• example.jpは「管理するドメイン名のうち最も短いゾーン頂点」であるため注入できない• jpや“.”は管理していないため注入できない

Copyright © 2014 Japan Registry Services Co., Ltd.

11

対象ドメイン名(いくつかの中間ドメイン名)
例2：トリガードメイン名がroot-servers.netである場合(ルートサーバーは“.”とroot-servers.netを管理しており、netの委任情報を持つ)• root-servers.netを注入できる• netは「トリガードメイン名の祖先」であるため注入できる• “.”は「管理するドメイン名のうち最も短いゾーン頂点」であるため注入できない

Copyright © 2014 Japan Registry Services Co., Ltd.

12

攻撃成功確率と期待値の計算• 作ってみただけでは格調高くないので、モデル化• モデル化に用いた変数
変数

単位

数値の範囲

www.google.com
での実績

フルリゾルバのポート数

1~2

1

QID数

265536

権威サーバアドレス数

1~13

権威サーバへのRTT

秒

繰り返し時間秒

偽応答数の送出レート

0.001~0.2

40.039パケット/秒
Copyright © 2014 Japan Registry Services Co., Ltd.

13

一度目の試行で入る確率• ID, port, アドレスが一致すると確実に入るとする• 一度の試行(時間)で入る確率• ただしは制御できないのでという条件でCopyright © 2014 Japan Registry Services Co., Ltd.

を用いる

14

連続攻撃時に入る確率繰り返せば入るので になることを示す
回目までに入らなくて 回目に入る確率(1)回目までに入る確率 は の和
(2)
• 変形すると(3)を無限大に近づけるとCopyright © 2014 Japan Registry Services Co., Ltd.

15

連続攻撃時に入る回数の期待値
回目までに入らなくて 回目に入る確率(1)回目までに入る期待値 は回数*確率の和(2)• 変形すると(3)を無限大に近づけると成功する場合の期待値なので0の(3)右辺の第二項は常に正かつ(2)より は単純増加なので、は1/ を上界とする単調増加数列
Copyright © 2014 Japan Registry Services Co., Ltd.

116

攻撃にかかる時間の期待値• サーバ数4とし、100000ppsで偽装応答を送ると• Port randomizationしていない場合
65536*1*4/100000 = 2.62秒• Port randomizationしていると65536*64000*4/100000= 167772.16秒(約2日)• 2日間も10万ppsの怪しいパケットがくれば気がつくでしょう
Copyright © 2014 Japan Registry Services Co., Ltd.

17

攻撃ツール試作• Cで500行、標準ライブラリのみ使用– selectでタイミングと送受信の管理– raw socketで偽造レスポンス送出• 与えるパラメータ– 攻撃対象のフルリゾルバのIPアドレス、ポート番号– トリガードメイン名 (連続攻撃向けのドメイン名)– 注入したいNS RRのドメイン名、サーバ名– トリガードメイン名の権威サーバのIPアドレスリスト• 攻撃例– ./a.out 192.2.0.2 20001 www.google.com
www.google.com ns.dnslab.jp
216.239.32.10/216.239.34.10/216.239.36.10/216.2
39.38.10
Copyright © 2014 Japan Registry Services Co., Ltd.

18

攻撃ツールの構造
初期化
socket 2個作成
普通のUDPとRaw
タイマー初期化
初回のクエリ送信

トリガークエリ送信(random)を生成
攻撃対象のport 53へクエリを送信

Loop
select応答を受けたら、注入が成功したか判定
成功したら終了失敗したら、トリガークエリ送信へ
Tloop時間たったら、トリガークエリ送信へ
Raw socketにかけたら、偽造応答送信へ終了
成果の表示

自分のアドレス port any
Full-Resolver port 53
ID any, Query(random).トリガードメイン名 A

偽造応答送信
IDをランダムに生成
権威サーバアドレスをランダムに選択
引数であたえたアドレスリストより偽造応答を生成
Question Sectionはクエリ送信と同じAuthority Sectionに注入するNS RR
権威サーバのport 53から攻撃対象の指定ポートへ
Raw socketで送信
権威サーバアドレス port 53
Full-Resolver port P
ID random, Response(random).トリガードメイン名 A
注入するNSリソースレコード

Copyright © 2014 Japan Registry Services Co., Ltd.

19

Tips
• Raw socketでのbyte order– FreeBSD: The ip_len and ip_off fields must be
provided in host byte order. All other fields must
be provided in network byte order.
– BSD以外はすべてnetwork byte orderのはず• 終了判定方法– 誘導先権威DNSサーバに *.domainname A を書いておくことで、トリガーとなるランダムクエリに存在する応答が戻る• デバッグツール– tcpdump– rndc dumpdb
Copyright © 2014 Japan Registry Services Co., Ltd.

20

実験環境
• 箱庭を準備するのは面倒なので• より現実に近い評価にするために• JPRSの研究ネットワークで実施– グローバルアドレスを割り当て• DNS trafficをNATしたらNAT箱のＣＰＵがあふれたため– ローカルネットワークは1Gbps– 対外線は10MbpsでWIDEインターネットに接続– 攻撃対象の名前解決クエリが外に漏れるが気にしない• マシンはVM 2個– Xeon 2.5GHz 8コアのHVからcpu 2個, 3GB割り当て– 同じネットワークセグメントに設置
Copyright © 2014 Japan Registry Services Co., Ltd.

21

攻撃の前提と実験の条件• 前提: 攻撃ツール以外からのクエリなし– 本物が入ったらTTL時間は攻撃成功しにくいため• Port randomizationをoffにしたBIND 9,Unboundを用意– 203.178.129.2 port 20001• 誘導先のDNSサーバとしてns.dnslab.jp– 実験で攻撃してみたゾーンが多数書いてある– *.domainname Aを書いておく (終了判定のため)• 簡略化のためIPv4でのみ評価
Copyright © 2014 Japan Registry Services Co., Ltd.

22

実験1: www.google.com (1)• (random).www.google.com Aクエリを送り• google.comの権威サーバのIPアドレスから以下のパケットを大量に送信– Question: (random).www.google.com A– Authority: www.google.com NS ns.dnslab.jp– ID ランダム, サーバアドレスを4通りランダムに• 入るまで(random)を変えながら繰り返し• 入らないときはrndc dumpdbして確認– 正規のAと、偽造NSが混ざることあり
Copyright © 2014 Japan Registry Services Co., Ltd.

23

実験1: www.google.com (2)% sudo ./a.out 203.178.129.2 20001 www.google.com
www.google.com ns.dnslab.jp
216.239.32.10/216.239.34.10/216.239.36.10/216.239.38.1
0elapsed: 46.012747
num_sent_queries=1273 27.666246 pps
num_sent_responses=3070290 66726.944166 pps
2411.853888/queries
num_received=1255 98.586017 %% drill @203.178.129.2 www.google.com
www.google.com. 86400 IN
A
203.178.129.44
www.google.com. 86139 IN
NSns.dnslab.jp.
• 46秒で注入成功、28qpsのクエリと66726ppsの偽造応答
Copyright © 2014 Japan Registry Services Co., Ltd.

24

実験2: net (1)• (random).root-servers.net A クエリを送り• ルートサーバのIPアドレスから以下の応答パケットを大量に送信– Question: random.root-servers.net A– Authority: net NS ns.dnslab.jp– ID, サーバアドレスを変えながら• 入るまで(random)を変えながら繰り返し• 入らないときはrndc dumpdbして確認• 本物のnetがキャッシュされていたらflush
Copyright © 2014 Japan Registry Services Co., Ltd.

25

実験2: net (2)% sudo ./a.out 203.178.129.2 20001 root-servers.net net
ns.dnslab.jp
198.41.0.4/192.228.79.201/192.33.4.12/199.7.91.13/192.
203.230.10/192.5.5.241/192.112.36.4/128.63.2.53/192.36.148.17/192.58.128.30/193.0.14.129/199.7.83.42/202.12.
27.33
elapsed: 8.050168
num_sent_queries=241 29.937263 pps
num_sent_responses=556740 69158.805133 pps% drill @203.178.129.2 www.apnic.net
www.apnic.net. 86400 IN
A
203.178.129.44
net. 86272 INNS
ns.dnslab.jp.
• 8秒で注入成功、30qpsのクエリと69158ppsの偽造応答
Copyright © 2014 Japan Registry Services Co., Ltd.

26

攻撃手法のまとめ• Port Randomizationしていないと数秒から数分で注入できる• ターゲットはほとんどのドメイン名– A, AAAA, PTRなどがついているほとんどのホスト名– いくつかの中間のドメイン名 (netなど)• Port Randomizationしていると、数時間では入らない– random.www.google.comやrandom.root-servers.netという怪しいクエリを出し続けるのはいやなので止めた• 成功しないときは攻撃対象のcacheをflushする– net, root-servers.netへの攻撃は、キャッシュにnet, rootservers.net NSがあると成功しない– www.google.com Aがあっても、www.google.com NSは入ることに注意
Copyright © 2014 Japan Registry Services Co., Ltd.

27

試作した手法の欠点• 攻撃がばれやすい– 送ってない応答が大量に到達するので、入出力のパケット数を見るだけでわかる– トリガークエリが多めなことと、送っていない応答を捨てる処理のためにフルリゾルバの負荷が上がる• 攻撃者を特定しやすい– トリガーとなるクエリを送り、応答を確認するために、そのIPアドレスを詐称できない– 誘導先のDNSサーバを用意する必要がある• 攻撃側にもリソースが必要– 帯域と、高性能機器
Copyright © 2014 Japan Registry Services Co., Ltd.

28

期待値と実績の比較
変数 単位
Port randomization
フルリゾルバポート数 Nport
ID数
Nqid
権威サーバアドレス数 Nns

変数の www.google.com
net攻撃
範囲 攻撃
noyes
noyes
1~
1 64000
1 64000
2^162^1665536←65536 ←
1~134
←
13 ←

Nauth 秒0.001 0.036~~0.2 0.094

繰り返し時間Nloop 秒
偽装応答の送出レート Rans pps

0.03666726

権威サーバへのRTT

一度目攻撃成功確率
攻撃成功の期待値
攻撃時間の実測値秒秒←←←
0.00000
0.00916014
3.9 251434
46 ×

Copyright © 2014 Japan Registry Services Co., Ltd.

0.006~
0.272←

0.03369158←←.000000
0.0026704
12.3 788425
8 ×29期待値と実績の比較、まとめ• 期待値と実績の違い– www.google.comでは期待値3.9秒、実測値46秒– netでは期待値12.3秒、実測値8秒– それぞれ一度の試行のため、違いが出た– 多数試行して平均を取ると期待値に近づくと考えられる• Port randomizationしていると注入にかかる時間の期待値がそれぞれ、2.9日と9日になる– 3日間も6万ppsの怪しいパケットがくれば気がつく
はずCopyright © 2014 Japan Registry Services Co., Ltd.

30

攻撃時間を短縮する最適化• 基本的には、偽造応答の送出レートを上げてやることと、に注意すること• たとえば、偽装応答を1Gbpsで送ると応答パケットサイズ100の場合、1,000,000pps• ポートランダマイゼーションしていない場合
65536 * 1 * 4 / 1000000 = 0.262秒 瞬殺• ポートランダマイゼーションしている場合
65536 * 64000 * 4 / 1000000 = 16777 4時間半
Copyright © 2014 Japan Registry Services Co., Ltd.

31

本攻撃手法への対策• Port Randomization– 時間の猶予が得られる• 監視• TCP transportの使用– 権威サーバとの間の通信をTCPにするとこのツールでは攻撃できない– 一般的にはシーケンス番号が32ビットになることと少なくとも2パケットを推定しないといけないため、ハイジャックは困難
Copyright © 2014 Japan Registry Services Co., Ltd.

32

本攻撃手法への対策: 監視• フルリゾルバの負荷– 多量の不在クエリ– 知らない応答• 入出力のパケット数– DNSはクエリ、レスポンスがほぼ一対一なので、非対称なパケット数は攻撃の可能性あり• 送ってない応答をログに出す– http://member.wide.ad.jp/~fujiiwara/ にBIND
9.3.2 patch– ログを出すのは重いのでパフォーマンスに注意• フルリゾルバ権威サーバ間の通信を監視– Farsight Security, Nominumによるサービスあり– 応答を過去のログと比較
Copyright © 2014 Japan Registry Services Co., Ltd.

33

DNSSEC検証による攻撃検知• BIND 9とUnboundではDNSSEC検証していてもキャッシュには入る• DNSSEC検証によりエラー検知でき、スタブリゾ
ルバにはServer failureを返す• netにNSを注入できても、net DNSKEYを検証できないため、検証エラー• TLDは概ねDNSSEC対応– ただし複雑な構造を持つTLDでNSEC3 OptOutしている場合に、検証できない中間ドメイン名ができる場合がある– RFC 5155を細かく読むとわかるし、対策も簡単– co.jpはあの対策では変化しなかった– 別のドメイン名をいってもらえたら反応したのに、、、
Copyright © 2014 Japan Registry Services Co., Ltd.

34

まとめ
• 委任情報を注入する攻撃は容易である– ほとんどのドメイン名を攻略できる– しかし、足がつく• Port randomizationで攻撃の効果を弱くできる– DNSSEC検証で検知可能• 守るにはPort randomizationと監視が重要• 攻撃にはそれなりの体力がいるので、攻撃者に利益があるところしか狙われにくい• だれかraw socketでのDoSツールに詳しい人いらっしゃいませんか、性能上げたいのでCopyright © 2014 Japan Registry Services Co., Ltd.

35