DNS の猛威とその対策, 参加レポ #interop2012

 Posted on June 16, 2012  |  jedipunkz

interop 2012 で ‘DNS の猛威とその対策’ を傍聴してきました。簡単にレポート書い ておきます。ちょっと油断しただけで大きな問題のアップデートが出てくる DNS。怖い です..。

本講義の概要

ブラジルで大規模な ISP への DNS ポイゾニング攻撃が発生。それら猛威について理解 すると同時に技術的対応策や具体的な対応プロセスについて説明。

イントロダクション : インターネットエクスチェンジ 石田さん

DNS を取り巻く状況

  • DNS を乗っ取って悪事を働く試み : DNS Changer
  • DNS そのものをセキュアにする方向性 : DNSSEC
  • DNS に様々な制御を任せる方向性 : SPF, AAAA, DANE, 児童ポルノブロッキング

事例 : IIJ 松崎さん

2011⁄11 ブラジルの事例

著名サイトへのアクセスを行うと malware が仕込まれたサイトへ誘導。ホームルータ のキャッシュがポイゾニングされた。

とあるホームルータの問題

  • admin パスワードが管理 web で見える
  • wan からのアクセスが有効
  • 同じチップセットを使っている製品で同様の問題..
  • wan からルータへアクセスすると html ソースにアカウント情報が平文で書かれてい た

これは怖い..。

攻撃活動の実施

攻撃者が行う手順。

  • 脆弱性な CPE 発見
  • パスワード書き換え
  • CPE が参照する DNS の書き換え
  • 著名サイト向け DNS への応答を書き換え
  • malware サイトへ誘導
  • 銀行の安全客員ツールを無効にする malware をインストールさせる
  • 幾つかの銀行向け DNS 応答を書き換え、目的のフィッシングサイトに誘導。DNS 書 き換えは短い期間のみであった。

規模

2011年時点、450万の CPE の DNS が書き換えられていた。今年も 30万以上の CPE が 影響を受けたまま。

その後

攻撃者が脆弱な CPE を探す試みはまだ続いている。ブラジル以外でも被害報告が。

その他の事例 DNS Changer

LAN 内の DHCP サーバに攻撃して配布する DNS を書き換えるとも言われている。 その後、FBI が参照用 DNS(攻撃者管理) を差し押さえ。いきなり止めると、ユーザが インターネットへの接続ができなくなるので、同じ IP アドレスでキャッシュサーバを 運用。まだ35万程度の感染ホストがあるので、キャッシュ DNS の運用を 2012/7/9 ま で延長決定。

  • JPCERT が用意している、確認サイト

このサイトにアクセスすることで自環境が汚染されているかどうかが判ります。

http://www.dns-ok.jpcert.or.jp/

幽霊ドメイン名について : JPRS 坂口さん

近年注目されている猛威

  • プロトコルによる定義が明確でない部分を突いた攻撃 (幽霊ドメイン名)
  • プロトコルの脆弱性をついた攻撃 (キャッシュポイゾニング)

傾向と対策

  • 1980年代から利用されていた
  • 性善説から生まれた
  • 利用者用途が大きく変動
  • DNS の重要性は未だ変わっていない

DNS プロトコルを正しく理解が対策の第一歩!

幽霊ドメイン名について

  • 2012年2月8日 中国 Haixin Duan さんによる論文として発表
  • その前日にISC が緊急セキュリティアドバイザリを発表

幽霊ドメインが引き起こす問題

  • ドメインを管理していたものからそのドメインを引き剥がすことができる
  • 強制的にドメイン名を使用不可にしても使われ続ける
  • 強制的に移転させても使われ続ける

動作原理

キャッシュ -> Root -> JP DNS -> 権威 DNS

の場合、キャッシュ上の TTL が切れたレコードに対して権威 DNS に問い合わせするが、 TTL が切れていないレコードについても問い合わせる。その際に新しい情報が入ってき た場合上書きするか？破棄するか？は、実装次第。NS ホストを定期的に問い合わせす ることで TTL を巻き戻し、永遠にキャッシュを利用させる攻撃手法。悪意のあるサイ トのドメインを差し押さえても、使用され続ける可能性が出てくる。

対策

  • 幽霊ドメインが発生しない実装へ書き換え (bind9, unbound は実装済み)
  • 幽霊ドメイン名のキャッシュ情報をクリアする (ISC が推奨)

Unbound, Bind9 で取られた対策

権威 DNS に問い合わせはするが、TTL については上書きしない

問題の対策 : IIJ 山本さん

前提

  • ブラジルの事例についてはキャッシュサーバで対策しても無益。

従来

  • 従来のキャッシュ DNS への攻撃はキャッシュポイゾニング
  • ISP のキャッシュ DNS サーバが標的
  • 歴史的経緯でアクセスコントロールが緩い
  • プロトコル/実装の脆弱性を突き、偽のレコードをキャッシュさせる
  • 理論的には20年前から知られていたが、実際の攻撃が困難だった

近年

  • 2008, カミンスキー攻撃が発表される
  • キャッシュしたレコードは TTL が来るまで再度検索されないが、これを可能にした
  • 理論的な猛威から現実的なそれへ

対策

  • 問い合わせる際の Port 番号をランダム化 (queryID(16bit) x port (16bit))
  • 一部商用サーバでは攻撃を検知する機能がアリ (攻撃を検知したら問い合わせを tcp に切り替える)
  • ISP では ingress-filtering を可能な限り実施する
  • Open Recursive はやめる -> 攻撃の機会を大幅に低減できる
  • DNSSEC の導入をすすめる -> 中長期的な対策

DNSSEC が短期的対策にならない理由

  • 検証するキャッシュサーバがまだ少ない
  • DNSSEC で署名しているドメイン名がまだほとんど無い
  • 鶏と卵問題
  • DNSSEC そのものの複雑さ -> 理解しているエンジニアの数が少ない

DNS Changer への対策

  • CPE ベンダで対策するしか無い
  • DNS サーバでできることは無い

ISP がやるとしたら…

  • OP25B ならぬ OP53B 対策を行うか？
  • DNS トラフィックを見張る (Google Public DNS など例外はあるが、自社キャッシュ 以外への問い合わせは誤差の範囲のはず)

DNS の課題 : IIJ 松崎さま

  • 児童ポルノフィルタ : 問題のあるサイトのドメイン名を書き換える
  • DNS64 : A へ書き換える -> DNSSEC との併用が難しいことが取り上げられている < RFC

‘アクセス制御’・’書き換え’, これらは攻撃者が行うことと同じ!

所感, まとめ

以上簡単でしたが、レポートでした。こういったイベントに1年出席しないだけで、知 らないことが出てくる DNS 界隈。毎年大きな脆弱性の出る Bind。使えて当たり前、障 害が起こると大問題になる DNS。管理者にとってつらい状況だけど、ユーザにとって無 くてはならないシステムなので、運用・開発に携わっている人間は、近年の状況をウォッ チし続けていく必要がある。この講義を傍聴しているなかで、自社の環境の組み換えを ぼんやり考えていました。