ビーコンの創出

なんか作ったり報告したり。

DNSのセキュリティ問題を体験してきました(セキュリティ・キャンプWS)

前回に続いて2017年11月30日にセキュリティ・キャンプWS(ワークショップ)があったので行ってきた日記。

前回の記事はこちら souring.hatenablog.com

講師:金子 正人さん(IPAセキュリティ・キャンプグループ)

DNSのセキュリティ問題

  • ゾーン転送の設定不備による情報流出
  • DoS/DDoS 攻撃
  • キャッシュ・ポイズニング攻撃
  • 実装に対する脆弱性攻撃 ←今回体験する脆弱性はこちら
  • ドメイン名ハイジャック

CVE-2015-5477の脆弱性

DNS サーバ BIND の脆弱性対策について(CVE-2015-5477):IPA 独立行政法人 情報処理推進機構

脆弱性:TKEYに関する問い合わせの処理内のエラーがREQUIRE検証エラーを引き起こし、namedを異常終了させることができる

つまりは一発で(復旧するまで)永続的なDoS攻撃ができてしまう...。しかも簡単なコードで。

可用性に全面的な被害を与え、誰でも容易に攻撃が可能などと言った点を踏まえてCVSSスコアが7.8(深刻度:重要)と位置付けられている。

今回はこのとっても危ない脆弱性をついた攻撃コードを作成しました。

CVE-2015-5477に対する攻撃コードの作成と実行

攻撃成立条件を満たすDNSメッセージ形式を調査

攻撃成立条件

DNSのセクションが以下の条件を満たしたクエリを送信すると攻撃が成功する。

  • Headerセクション
    • フラグは標準問い合わせ(RDは任意)
  • Questionセクション
    • リソースレコードタイプ : TKEY
    • クラス : ANY
  • Additionalセクション
    • リソースレコードタイプ : A
    • クラス : ANY
    • TTL : 任意
    • リソースレコード値 : 任意

これら3つのセクションの具体的な値をいくつにしたら良いかを仕様を見たり、実際のパケットを見たりして調べました。 自分は適当な標準問い合わせ(standard query)のパケットのバイナリをWiresharkで見て参考にし、それで本当に正しいかを仕様書で確認しました。しかし、Additionalセクションがあるパケットは通常ではなかなか観測できないので以下のdigコマンドを使って発生させました。

dig @127.0.0.1 www.google.com IN A

調べるのに使った仕様書たち

Chapter 15 DNS Messages

Domain Name System (DNS) Parameters

Information on RFC 1035 » RFC Editor

条件を満たす攻撃用DNSメッセージを作成し、送信

単純な問い合わせをするpythonのコードを書き換えて攻撃コードを作成しました。

f:id:souring:20171130234654p:plain 攻撃条件を満たすコードを送ることができました。

f:id:souring:20171130234700p:plain このコードでクエリを送信しても、レスポンスが返って来なくなります。

それまでできていた通常の問い合わせをしても、いくら待っても返事が返ってくることはありませんでした......。(no server could be reached)

まとめ

攻撃者にとって

  • コストが低い(一発)
  • コードが簡単
  • 同時並行で攻撃可能

運営者にとって

  • 早急なパッチ対応とバージョンアップをする必要がある
  • 通常のDNS問い合わせと区別しにくい
  • キャッシュサーバと権威サーバの双方が対象で対策範囲が広い

感想

実装の不手際でここまで危険なことになるとは恐ろしい。こういう脆弱性はどうやって発見されるんだろう。