テクニカルエンジニア（ネットワーク）DNSキャッシュポイズニングがポイント！

大学も大慌てでした
DNSキャッシュぽいズニング
ARPスプーフィング
やっぱネットワークとセキュリティの関係は深い
DNSキャッシュサーバーにウソの情報（ポイズン）
原理的にキャッシュへの毒入れ脆弱性
DNSが偽の応答を返すようにしてしまう攻撃
気づかずにフィッシングサイト
DNSサーバ（権威サーバ＆キャッシュサーバ）
一定時間記憶（キャッシュ）
権威サーバより前に偽の応答をキャッシュサーバに流す
キャッシュサーバ＝ISPが顧客に提供
キャッシュサーバ＝企業が社内利用者に提供
個人は利用する立場
まずはquery portをraodom化しよう（patch!)
キャッシュサーバを一般公開することは危険
コンテンツサーバとは分離しよう
アクセス制限しても内部からの間接攻撃
オープンリゾルバは危険
＝DNSの再帰名前解決を誰にでも許すキャッシュサーバ
管理者を信じるのではなく、自己責任
dns hijack
dan kaminskyさんがDNSプロトコルそのものの脆弱性発見
cache poisoning
ドメイン名が乗っ取られる
嘘を真実より先に返す
フィッシングによる通信＆情報の横取り
TTLを無視した連続攻撃が可能？
20分で50％の攻撃成功率
数時間で必ず乗っ取られる
DNSプロトコル時代のメカニズムの問題
→根本的な対処方法が存在しない
→根本的な解決にはデジタル署名を組み込んだDNSSEC
→まだ実装、普及が不十分
じゃあ、攻撃確率だけでも減らそう
正規ネームサーバを増やす
対応パッチ（port randomize）を当てる
Open Recursive(外部へのcache応答）を止める
→内部ネットワークからの攻撃のみに限定
→Botに感染する危険性も残っている
単位時間当たりの単一ネームサーバからの応答クエリを制限
→普通は１問い合わせ＆１応答
→Poisoningの時には大量の似せ応答
DNSのTXIDは16bit→65535回に１回は攻撃成功
存在しないドメイン名を大量に作って攻撃回数を増やす
test my dns→ヤバイ結果→ISPの変更を検討
DNSクエリのIDが16bitしかない
問い合わせを送信する際のソースポート固定→危険
DNSサーバに存在するセキュリティ・ホール
ソースポートとトランザクションIDの予測
ルックアップ（聞くこと）
応答パケット（answerパケット）
要求パケット（questionパケット）
つまり、ポートもIDもばれなければ大丈夫
でもばれちゃう
デスティネーション/ポートは通常53番
DNSの応答と要求のパケットの中身を知る必要（テスト用）
１：DNS問い合わせに使用するポート番号＝ランダム
２：DNS問い合わせに使用するID＝ランダム
３：外部からの再帰的なDNS問い合わせに対して回答してしまう
本来DNSサーバ（DNSコンテンツサーバ）は
再帰的なDNS問い合わせに回答するべきではない
DNSキャッシュサーバと別にする？
再帰的なDNS問い合わせ？←ダメ。でも50％はそう

DNSキャッシュポイズニングの新しい手法

DNSサーバの機能が、
ドメイン名を公開するコンテンツDNSと、
公開されているコンテンツDNSの情報を検索するキャッシュDNS
の２つに分かれていることはご存じのことと思います
IPとドメインの組み合わせを変更されたら危険
2008/7 dan kaminskyが発見
キャッシュDNSが騙されてしまう！
なんで？
自身がDNSクエリした際のSource IPアドレス／ポートあての応答＆
トランザクションID（TXID)に対するDNS応答である
→信じちゃう
ポートとIDがばれれば騙されちゃうのですね
今回のポイントは「存在しないFQDN」を用いること
fqdn:fully qualified domain name
今まではTTLが生きている間はキャッシュし続けるので
攻撃の機会がなかった
（攻撃するならキャッシュが切れたときのみだった）
しかし「存在しないFQDN」でその障壁を越える！
被害：メールが正常に届けられない
（送信先メールアドレスのドメイン名の汚染）
被害：Webサイトを正常に閲覧できない
（意図しない通信先とHTTP通信）
被害：Webサービスの危険性がいっそう高まる
（Webサービスサイトが新機能をメールで報告→偽サイト）
被害：SSLの意味がなくなる
（お客は偽サイトと知らずに、SSL証明書警告も無視して
偽サイトにパスワードなど打ち込んでしまう）
ファーミング（pharming）：
DNSを書き換えて閲覧者を偽のサイトに誘導する行為のこと
フィッシング詐欺とはちょっと違うね
DNSの書き換え：DNSサーバの内部のアドレス情報を書き換える
DNSの書き換え：脆弱なブラウザのDNS情報を書き換える
ドライブバイ・ファーミング：
ブロードバンドルータの設定を変えるスクリプト
→DNSサーバアドレスを書き換える
→偽のDNSサーバを信じるようになる
フィッシングからファーミングへ（より自動化）
フィッシングは偽メールを蒔く必要がある
ファーミングは種さえ蒔いておけばいい
悪意のあるWebサイトへのリダイレクト
ウイルス（ワーム）などを使って
クライアントのhostsファイルを書き換えるor
DNSサーバに虚偽の情報をキャッシュさせる（DNSポイズニング）
自分でURL打ち込んでも無駄
DNS応答の正当性を確認できるDNSSEC
→権威DNSサーバ、キャッシュDNSサーバを対応させる必要→課題
カミンスキー・アタック
DNSを守る３つの仕組み
TTL
クエリの処理待ち（聞いたことなら聞こう）
レスポンスのマッチング（ID)
TTL防御を突破するために存在しないネームで攻撃
さらにQ防御（クエリの処理待ち）も破られる
IDしか防御がない状態→総当たりで破れる
カミンスキー脆弱性
有効な対策：DNSキャッシュサーバのソースポートをランダムに
IDとポートがランダムになるので2^32=43億分の１が成功確率
今までは（IDのみ）1/65546
これでも危ない（2^32は総当たりで破られる時代）
DNSポイズニングというより、DNSキャッシュ・ポイズニング
ドメイン・ジャック
Webハイジャック
対策：DNSキャッシュサーバに対応パッチ
（sourceポートランダマイズかな）
キャッシュDNSサーバの設定を確認・変更
外部DNSサーバの「再帰問い合わせ」機能を無効化
キャッシュDNSサーバを二重にする
不要なネットワークからの再帰問い合わせを拒否するのは重要
再帰問い合わせ可能なDNSサーバの放置は自殺行為＆犯罪行為とも
そっか、DNSで聞いてくるのは普通は中の人（？）
外からの再帰問い合わせは無視すればいいんだね
（中からもワームというものがいるので注意）
攻撃者が汚染したいDNS情報は、あなたのドメインじゃない
もっと有名なサイトのドメインを書き換えたい
（そのために誘導者であるあなたを騙す）
DNSパケットが増えたら危ない（IDS？）
偽造したresponseパケット
queryパケットの送信元ポートをランダムに変更しよう
recursive queryを受け付けるIPアドレスを制限
再帰問い合わせを外部DNSでは禁止、内部DNSでは許可
再帰問い合わせって何？
＝キャッシュで保存すること？（→そうすれば何度も答えられる）
DNSは問いあわせて「リソースレコード」を手に入れる
UDPを使う
ポート番号は５３
UDPだけど、５１２バイトを超えるならTCPに変更する
DNSリゾルバにIPアドレスを問い合わせる（ソフトウェア）
DNSキャッシュ知りたいならipconfig /displaydns
TTL=0で消える
キャッシュがなかったら「ネームサーバ」に問い合わせをする
DNSの問い合わせには２種類ある
「再帰問い合わせ」
「反復問い合わせ」
再帰→「知らなかったら他に聞いてくる方法」
反復→ドメイン名前空間を上から順にたどっていく
んー、イマイチ
「リゾルバは再帰問い合わせでネームサーバに聞く」
「ネームサーバは反復問い合わせで他のネームサーバに聞く」
何が再帰なわけ？

まあ、だいたい分かったということにしておこう。DNSについてもっと詳しく知っておく必要があるな。

ここからDNS-DDoSについて（踏み台になってもらうよ）

参考：■
DNSの再帰的問い合わせ→悪用してDDoS攻撃
DNSを踏み台
「教えてよー」問い合わせデータを踏み台DNSサーバへ
宛先は攻撃先にしておく
踏み台DNSサーバがアンプ（増幅器）の役割をして攻撃
送信データの40倍に増幅して攻撃できる
DNSで上まで聞きに行く→再帰的問い合わせ
「んー、分からないから上に聞いて？」これが
再帰的問い合わせを行うDNSキャッシュサーバ
キャッシュサーバはTTL時間だけ保持する
それで？
攻撃準備：大きなTXTレコードを自らのDNSサーバに用意
TXTレコードは任意の目的に利用できる→大きくできる
攻撃者サーバにTXTを置いておく。攻撃の武器
踏み台サーバに「TXT知ってる？」って聞く
踏み台サーバは知らないので攻撃者サーバに聞きに行く
そしてTXTレコードを知って、キャッシュする
攻撃者サーバ（コンテンツサーバ）はTTLを決められる
長くしておく→キャッシュが消えないので長い攻撃
攻撃段階：送信元IPアドレスを攻撃対象のIPアドレスに詐称
踏み台DNSサーバに大量に再帰問い合わせを送信
踏み台DNSサーバは「知ってるよ！」と嬉々として返す
DNSはUDP
DNSサーバからの応答のサイズが512バイトを超えるなら
通信方式をTCPに変える
よってUDPでの攻撃の１度の大きさは512が限界
「おしえてよー」攻撃者は40バイト送ればいい
「おしえるよ！」踏み台は512バイト送る
実際はEthernetヘッダ、IPヘッダを追加するので
それぞれ86, 558byteになり、約6.5倍に増幅攻撃
イーサ＆IPヘッダ＝46バイト
EDNS0（DNSの拡張機能）で4096バイトのUDP攻撃も可能
4096バイトはイーサネットフレームに入りきらないので
３個に分割してUDP送信する
結果、4096+46*3-8*2=4218バイトのUDP
（UDPヘッダ8バイトは最初の１フレームだけでいい）
→49倍に増幅攻撃
さて、どうやって防ぐ？
DNSサーバはキャッシュサーバとコンテンツサーバがある
WindowsやBINDなどのDNSサーバソフトウェア→設定せよ！
「再帰的な問い合わせを断る」と！
WindowsではまずコンテンツSVとキャッシュSVを分けること
コンテンツSVには再帰的問い合わせを断るように、
キャッシュSVにはFWによるパケットフィルタリング
IPアドレスの詐称を防止するのもいい
→DNS-DDoS, SYN flood, UDP floodの防止
DNSサーバに進入することなく攻撃踏み台にできちゃう！

いや−、とにかく目についたフレーズを消化して書き連ねた。DNSキャッシュぽいズニングと、DNS-DDoSについて書いたね。次はこれを見ながら、「キーワード」を拾ってまとめていけば、記憶の碇（いかり）をおろすことができそうだ。