## page was renamed from DNS/毒盛/Kaminsky講演
## page was renamed from DNS/キャッシュサーバ毒盛/Kaminsky講演
## page was renamed from DNS/キャッシュサーバ毒盛/Kaminsky型攻撃
## page was renamed from DNS/キャッシュサーバ/Kaminsky型攻撃
## page was copied from DNS/Kaminskyの攻撃手法
## page was renamed from DNS/攻撃手法の説明/Kaminskyの攻撃手法

<<Navigation(children,1)>>
議論： [[/wiki]]



http://www.topology.org/linux/bind_bigbug.html

== DNS/Kaminskyの攻撃手法 ==
2008 年のBlackhat の講演videoを発掘してきました。
http://www.vimeo.com/17247507   [[http://www.slideshare.net/dakami/dmk-bo2-k8|スライド]]

ターゲットが referral だから毒盛できるとするのは単純すぎます。
 * Black Hat [[/講演のスライド(18)]]の攻撃法は手元の環境では成功しません。
 * http://fanf.livejournal.com/91801.html Tony Finch blogでの [[/Tony Finch の疑問]]を分析してみます。

こういう意見もあります。(port 固定の危険性はずっと以前に指摘されていたのに、BINDは対応しなかっただけ。）
　http://marc.info/?l=djbdns&m=123455915911196&w=2

=== Kaminsky の手法の要点 ===
Kaminskyの発見とはキャッシュサーバに「多数の問い合わせを送らせる」ことができるという事実の発見です。
　問い合わせ名がキャッシュにあると、キャッシュサーバは外部に問い合わせることなく、返事を送り出します。
　　これでは偽返答(毒)は受け取ってもらえないので、毒入れできません。
　TTL の制約をうけない攻撃(query と 偽 response)だと解説されているが、TTLに関係しない攻撃という方がましでしょう。

一方で、送られた偽返答をキャッシュされた内容によって防御できるというBINDキャッシュのハックが役にたたないことも示されました。

しかし、BINDキャッシュは「問い合わせportが固定されている」ことの方が深刻な問題であり、
ずっと以前から指摘されていたにもかかわらず放置されていたことはあまり取り上げられていません。

また、referral への毒盛手法は以前から存在しています。Kaminsky の発見により、「実用的な攻撃」になりました。

=== Kaminsky の主張 ===
http://www.doxpara.com/?p=1237 Towards The Next DNS Fix によれば、
 * TTL の制約を回避する方法はいくつもある。(本当か？）
   http://marc.info/?l=namedroppers&m=121963095700960&w=2 Paul Vixie は
     『特定の攻略が成立するかどうかは重要ではない。』と。[これはBINDにはもっと重大な欠陥があることを示唆している。]
 * 個別の DNS 攻撃を防御することよりも、包括的な防御を目指すべき。
 * port randomization は対策の第一歩である。
   まず port random 化ををやらなくては、(危なくて)攻撃対策の議論もできない。

たしかに、10 年近く前にDJBがdjbdnsで実装した”port randomization” をBINDにも採用させたのはすごいことです。
しかし、公表まで半年も必要だったのか。その間に悪用される心配があったのに。

== Kaminskyのスライドの攻略が成立するか: No ==
実際に確認するのは非常に困難です。

http://www.kb.cert.org/vuls/id/800113 Multiple DNS implementations vulnerable to cache poisoning では
  * Microsoft Windows DNS Server
  * ISC BIND  (query ID の暗号化に弱点)
  * BIND 8  (query ID の暗号化に弱点)
とありますが、実は不十分な port randomization などが最大の脆弱性らしいのです。

さらに、毒盛が成功するためには、
DNS データとしてキャッシュに受入れられる必要があります。
この理由で、実際に毒盛を確認するのは非常に困難です。
  * 本物のサーバを偽サーバに見たてて、テストしていますが、
  有効な毒盛に成功するところまで到達していません。
  

=== 成立しなかったケース ===
 * port random 化が実装ずみのキャシュでは事実上攻略は困難です。
 
さらに、
 * djbdns では in-bailiwick 検査がきちんと行われていて、
 Kaminsky のスライドにある例ではキャッシュされません。
 
 * BIND 9.3 以降でも djbdns と同様の状況だと推測できます。
 しかし、対策版が公表されていることは別の攻撃法が成立すると推測できます。

[[DNS/キャッシュサーバの動作/データとして受入れられる条件]]とはなにか。

=== 次の段階へ ===
どんな毒盛なら成立するかが気になります。 [[DNS/キャッシュサーバ毒盛/Kaminskyの攻撃手法]]

port random 化が十分実施されたら、DNS の攻撃法の議論をしましょう。
 Kaminsky がつぎになにを提案するのか、楽しみです。(結局、 DNSSECが出てきたが)

== 間違った説明が氾濫している ==
ウェッブ上にはきちんと正しい説明をしているものがほとんどない。なぜか。
 bindの不良が毒盛を許しているのに、そのの説明がないために、起きていると思います。

Kaminsky の説明には誤りがあるにもかかわらず、誤りを指摘できるはずの人達が黙っている。
　そのことがDNSの問題の深刻さを示していると考える。
    http://www.nic.ad.jp/ja/newsletter/No40/0800.html にある毒の入れ方も正しくない。

 * 多くのものはリンクと引用に過ぎない。これらは当然ながら、無視する。

 * BIND が毒盛される弱点をもっていることは事実であった。
　　ただし、どういう状況でどういう毒盛が可能であったかが書かれたものはほとんどない。
   (確認の手段が公開されていない。危険すぎるからか）
 * どういう弱点であるかは、BIND開発者側から説明されていないし、今後もない。
　　これではまともなソフトウェア開発とはいえないし、セキュリティに責任ある態度でもない。
 * DNSSECを押し付けるいい機会だと思っているふしがある。
 * セキュリティ関係者ですら、DNS の構造的欠陥には目を背けているようだ。あるいは理解していないのか。
　　後者だとすると、非常に危険な状態にあると言える。

この後の議論は[[DNS/wiki]]にあります。
アカウントを作成し、DNS/wiki に参加してください。
----
前野年紀