MoinQ:

/その後

キャッシュにあるレコードに対する問い合わせにはリゾルバーはキャッシュ内のレコードを返答する。 

キャッシュにないレコードを問い合わせることにより、外部への問い合わせを発生させ、
対する偽返答を受け取らせる。当時のBINDは問い合わせポートが53に固定されていた。

これがKamiskyの指摘した攻撃法である。(/2008年)

Muellerは同様の手法により、NSに毒を入れやすいことを示した。

Additional Sectionを使った毒盛を再検討する。-- ToshinoriMaeno 2018-12-29 23:49:30

/2020: https://twitter.com/securitytrails/status/1327015852718305280?s=20

1. DNS/毒盛/Kaminsky手法

Contents

  1. DNS/毒盛/Kaminsky手法
  2. 対策
  3. 攻撃例
  4. さらなる対策
  5. 2008
  6. なぜ説明がないのか
  7. 解説、 議論
  8. 毒盛できる対象とは
  9. 対策
  10. おまけ

リゾルバーにDNS問い合わせを送り出させ、それに対する(偽の)返答を受け取らせることにより

Kaminskyはリゾルバーに「次々と」問い合わせを送り出させる攻撃手法を示した。(2008年）

/TTL制約回避 ../雨だれ攻撃

しかし、Kaminskyは問い合わせ名を変えて問い合わせするということだけを指摘していて、 具体的にどのような問い合わせを送りつけ、どのような返答を送り込むかは説明しなかった。

Kaminskyはキャッシュにない名前を問い合わせることで、リゾルバーに問い合わせを発生させる例を示し、 それにより毒盛可能な脆弱性があることを指摘した。問い合わせ名を変えることしか提案していないと言ってもよい。

-- ToshinoriMaeno 2017-11-09 23:35:19

2. 対策

対策としては問い合わせポートのランダム化が提案されただけだった。(djbdnsでは2000年以前に実装されている）

3. 攻撃例

このため、攻撃者に利益のある毒がどのようなものであるかの憶測がなされた。 そして、 

　情報がキャッシュにあっても上書きされるという実装の不良と言ってもよい欠陥が暴露された。

攻撃手法のなかでも、Muellerの指摘(NS毒)は重要である。

DNSの仕組みに問題が潜んでいるという説には賛成できない。 

Kaminsky-Mueller流の攻撃手法には対抗できる防御がある。（実装はまだ見あたらない）

4. さらなる対策

/キャッシュNS上書き脆弱性

Mueller流攻撃でNSを狙う攻撃の危険性がはっきりした。

これらに対する対策も明らかにした。実装が進めば、脅威ではなくなる。 

なにを考えてきたかの記録の意味で残してある。

DNS/毒盛/Mueller手法

そして、簡単で効果的な対策を発見した。DNS/毒盛/Kaminsky手法/対策はある

リゾルバー作成者の説得を試みているが、成功していない。 -- ToshinoriMaeno 2016-03-18 00:26:07

Contents

  1. DNS/毒盛/Kaminsky手法
  2. 対策
  3. 攻撃例
  4. さらなる対策
  5. 2008
  6. なぜ説明がないのか
  7. 解説、 議論
  8. 毒盛できる対象とは
  9. 対策
  10. おまけ

5. 2008

2008年に Dan Kaminsky により報告されたキャッシュ毒盛攻撃手法　../Kaminsky講演 https://kb.isc.org/article/AA-00924/0/CVE-2008-1447%3A-DNS-Cache-Poisoning-Issue-Kaminsky-bug.html

リゾルバーに対して、 「キャッシュされていない名前(タイプ）を問い合わせる」ことにより、 問い合わせを発生させ、攻撃の機会を増やすものである。/TTL制約回避

具体的に毒が入れられるケースは説明しない、という立場のようです。（理由は不明）

/Vixie

2008年当時では 民田スライド が代表的説明だった。Additional Section のレコードが毒になっている。(これはBINDの不良だと思っている）

スライド 21 

Kaminsky型と他の方式の比較
 •  Kashpureff型との比較
–追加セクションを利用する点は同じ
– Kashpureff型は現在の実装では外部名のため無視されるが、
Kaminsky型は内部名となるため、キャッシュ対象となる

Kaminskyの示した例がまずいことから、導かれた誤解だろう。（あるいは分析不足か）

見直し中： http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

6. なぜ説明がないのか

https://www.unbound.net/documentation/DNS_cache_poisoning_vulnerability.html

BIND各バージョンへの毒入れ実験(2011)

6年たって、Kaminsky攻撃手法の意味するところを理解しました。

https://www.ietf.org/mail-archive/web/dnsop/current/pdf2jgx6rzxN4.pdf

http://users.auth.gr/basags/pubs/hase9.pdf Formal Analysis of the Kaminsky DNS Cache-Poisoning Attack Using Probabilistic Model Checking

http://www.sec-pro.net/spnseminar081025_shio.pdf

http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug

http://www.cs.berkeley.edu/~daw/teaching/cs261-f09/reading/matasano-kaminsky-dns-forgery.html /matasano

http://dnsops.jp/event/20130719/20130719-undocumented-DNS-orange-6.pdf

http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

http://www.caughq.org/exploits/CAU-EX-2008-0003.txt NS injection

http://resources.sei.cmu.edu/asset_files/Presentation/2008_017_101_51416.pdf

http://www.merit.edu/events/mjts/pdf/20081007/Blunk_DNSCachePoisoning.pdf

7. 解説、 議論

Kaminskyは 

  １. キャッシュされているデータのTTL制約を受けない攻撃手法

が存在することを示した。 しかし、間違った例を示している。（意図的だとおもわれる。）

slide 17 Enter The DNSRake より 

 3) Send rplies containig name server rediretions to www.foo.com
   --RANDOMwww.foo.com IN NS  www.foo.com
　　     www.foo.com IN A 6.6.6.6
  -- If this works, it works

ここのNS毒が入っても毒として使われることは考えづらい。 主目的はAレコードだと考えるのが妥当であるが、 このAレコードが毒入れできる機会は多くないだろう。　（glue なので）

実際に毒の入る例は示されていない。

その後、毒入れできる実例が見つかっているが、それはBINDの不良（脆弱性）を突いたものであった。

8. 毒盛できる対象とは

Kaminskyの示した例（対象）では毒盛できない。どういう対象を選べば毒盛できるのだろうか。　/毒の例

毒盛が成功する多くの例はKaminskyの例とは以下の点で違っている。

これらは「委譲返答」ではありません！ 

この違いに意味があるかは明らかではありませんが、成功した毒盛手法は容易に対策可能なものです。
  bindの動作不良だったようです。最新のbindではすでに対策されているようです。（説明はありません）

説明はbindの公開情報には見当たりません。　（非公開情報にはあるのかもしれませんが。）
　詳細を公開すると、攻撃に利用されるからという理由をいう人もいますが、これでは今後のためになりません。
きちんと追跡して、公開報告することはまだ行われていないようです。
　そのため、毒盛可能かどうかは個別に試して確認するしかありません。 手間もかかり容易ではありません。

-- ToshinoriMaeno <<DateTime(2011-08-20T15:23:42+0900)>>

委譲返答を使った毒盛も可能であり、非常に危険なため、詳細はここには書きません。

対策が進んだときに解説したいと思っています。 -- ToshinoriMaeno 2014-03-23 23:38:41

http://www.sec-pro.net/spnseminar081025_shio.pdf 30--31 にNS毒の話（検証ずみ）がある。

9. 対策

port randomization を行って、攻撃監視をしているなら、心配はいりません。 （注：2008年での話）

「キャッシュを上書きしない」なら安全かというと、そうではない。

キャッシュは一日一回クリアしましょう。

Paul Wouters: Defending your DNS in a post-Kaminsky world https://www.blackhat.com/presentations/bh-dc-09/Wouters/BlackHat-DC-09-Wouters-Post-Dan-Kaminsky-slides.pdf 

Before accepting glue records or additional data, 
 independently verify these with new queries.

DNS/毒盛/NS毒盛/対策はある

10. おまけ

権威サーバとキャッシュサーバは分離しましょう。兼用は危険です。

-- ToshinoriMaeno 2012-11-09 20:32:01

DNS/毒盛の脅威 DNS 名前空間の構造（運用）に関連する脆弱性

http://delab.csd.auth.gr/~katsaros/hase9.pdf Formal Analysis of the Kaminsky DNS Cache-Poisoning Attack Using Probabilistic Model Checking

https://samsclass.info/40/proj/p7-Kam.htm Performing the Kaminsky Attack

http://users.auth.gr/basags/pubs/hase9.pdf

MoinQ: DNS/毒盛/Kaminsky手法 (last edited 2024-11-08 13:03:57 by ToshinoriMaeno)