DNS 毒入れの真実

Oct 24, 2015 @DNS温泉補講
(注:本スライドはDNS温泉(1,2,3)参加者のレベルを前提としています)

鈴木常彦 @ E-ONTAP.COM

DNS毒入れの真実　目次

BlackHat 2008 で世間を騒がせた Kaminsky の誤り

B.Müller 論文

BlackHat 2009 での Kaminsky の再発表

委任の弱点 (委任インジェクション)

NS を持たないノード(サブドメイン名)、あるいはゾーンの世代間同居などにより直接検索される機会の少ないゾーンが、偽の委任情報を毒入れされる脆弱性を持つ。

NS を持たないノードの偽委任による毒入れ(FQDN)

NS を持たないノードの偽委任による毒入れ (ac.jp など)

世代間同居 (親子ゾーンの同居)

世代間同居 (親子ゾーンの同居)

世代間同居 (親子ゾーンの同居)

RFC2181の弱点

  • RFC1034,1035 には説明はないが、RFC2181 には権威ある応答に付随する NS が委任側で得られた NS に優先し、キャッシュを上書きするルールが定められている
  • Paul Vixie によれば委任元と委任先では NS RRset がしばしば異なっているので、委任先の NS RRset をより正しいものとすることにしたとのこと
  • RFC2181 5.4 Receiving RRSets
    The challenge for the server is to determine which of the data sets is correct, if one is, and retain that, while ignoring the other. Note that if a server receives an answer containing an RRSet that is identical to that in its cache, with the possible exception of the TTL value, it may, optionally, update the TTL in its cache with the TTL of the received answer. It should do this if the received answer would be considered more authoritative (as discussed in the next section) than the previously cached answer.

    • RFC2181の弱点

    RFC2181 5.4.1. Ranking data

Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

    権威サーバからの NS は委任元からの NS に優先する

    RFC2181の弱点 (移転インジェクション)

    以上より RFC2181 に準拠した実装では以下のような攻撃が可能となる。

    移転インジェクション - 委任側 NS キャッシュの上書き

    移転インジェクション - 権威側 NS キャッシュの上書き

    ルートゾーンへの毒入れ (移転インジェクションの応用)

    PRIMING

    再度 ルートゾーンへの毒入れ

    再度 ルートゾーンへの毒入れ (移転インジェクションの応用)

  • 前提: root-servers.net への委任の NS は攻撃中にキャッシュされる
  • 前提: root-servers.net からの権威ある応答に付随する NS がキャッシュにあってもよい
  • 攻撃パターン
    問い合わせ
   $random.root-servers.net.  IN  A
本物の応答
   NXDOMAIN (SOA)
偽応答
   AA flag: 1
   Answer Section: $random.root-servers.net. IN A 192.0.2.1
   Authority Section:  root-servers.net.    IN NS ns.poison.nom.
  • 以下のように毒が入る (キャッシュダンプ)
    ; Auth Authority
    .                        1111  NS  [a-m].root-servers.net.
; Auth Authority
    root-servers.net.       86383  NS  ns.poison.nom. (偽権威)
    root-servers.net.        2222  NS [a-m].root-servers.net. (↑上書きされる)
; glue
    [a-m].root-servers.net.  2222  A  192.0.2.1
  • この状態で [a-m].root-servers.net の A を問い合わせると偽権威からの応答が glue キャッシュを authanswer で上書きする。ルート乗っ取り完了。

    • その他の攻撃

  • RFC2181 5.4.1. Ranking data では CNAME の A は再検索することになっているが、、、
    Note that the answer section of an authoritative answer normally contains only authoritative data. However when the name sought is an alias (see section 10.1.1) only the record describing that alias is necessarily authoritative. Clients should assume that other records may have come from the server's cache. Where authoritative answers are required, the client should query again, using the canonical name associated with the alias.
  • 世の中には CNAME とともに Answer に含まれる A を再検索することなく受け入れる実装が存在する
    (Unbound や最近の BIND は大丈夫)
  • 攻撃パターン
    問い合わせ
   $random.example.jp.  IN  A
本物の応答
   NXDOMAIN (SOA)
偽応答
   AA flag: 1
   Answer Section: $random.example.jp. IN CNAME www.example.jp.
   Answer Section: www.example.jp.     IN A     192.0.2.1
  • もちろん NS への毒入れも狙われる
  • $random.example.jp のネガティブキャッシュは攻撃の邪魔にならない

    • DNSSEC の弱点

    Breaking DNSSEC, D.J.Bernstein, 2009

    Easiest, most powerful attack:
  Can ignore signatures.
  Suppose an attacker forges a DNS packet from .org, 
  including exactly the same DNSSEC signatures
  but changing the NS+A records to point to the attacker’s servers.

Fact: DNSSEC “verification”
  won’t notice the change.
  The signatures say nothing about the NS+A records.
  The forgery will be accepted.

    対策

    質疑、議論