SECCON 2014 長野大会 DNS Security Challenge Writeupその４
■mondai4
○問題文
mondai4.pcapを見て、以下の問いに答えて下さい。
問1：用いられた攻撃手法は何か
答え：
問2：その攻撃手法だと考えた理由は何か
答え：
○パケットデータ概要
このパケットデータはmondai1～3までと作り方が違うようで、チェックサムのエラーがない。
しかし、内容がとってもファンキーであるので、がんばって全部表現してみる。
関係ないパケットを無視して、注目するのは下記。
（凡例）パケットNo ソースIP:ソースポート -> デスティネーションIP:デスティネーションポート Info (補足)
1 10.210.222.194:63137 -> 10.210.222.197:53 Standard query 0x2d5c A 00000001.www.indo8.co.jp
2 10.210.222.197:63137 -> 192.168.40.1:53 Standard query 0xb223 A 00000001.www.indo8.co.jp
3 192.168.40.1:53 -> 10.210.222.197:47771 Standard query 0xb223 (グルーとしてindo8.co.jpの権威DNSである172.16.191.1を得ている)
4 10.210.222.197:63137 -> 172.16.191.1:53 Standard query 0x49cb A 00000001.www.indo8.co.jp
5 172.16.191.1:53 -> 10.210.222.197:63137 Standard query response 0x9b44 NS ns1.example.jp
6 172.16.191.1:53 -> 10.210.222.197:63137 Standard query response 0x1f3d NS ns1.example.jp
7 172.16.191.1:53 -> 10.210.222.197:63137 Standard query response 0x401e NS ns1.example.jp
8 172.16.191.1:53 -> 10.210.222.197:63137 Standard query response 0x9aec NS ns1.example.jp
9 172.16.191.1:53 -> 10.210.222.197:63137 Standard query response 0x520c NS ns1.example.jp
10 172.16.191.1:53 -> 10.210.222.197:63137 Standard query response 0x2c89 NS ns1.example.jp
11 172.16.191.1:53 -> 10.210.222.197:63137 Standard query response 0x49cb No such name
12 172.16.191.1:53 -> 10.210.222.197:63137 Standard query response 0x3a0f NS ns1.example.jp
13 10.210.222.197:53 -> 10.210.222.194:63137 Standard query response 0x2d5c No such name
これは【一見】カミンスキー型でキャッシュポイゾニングを実施しているように見える。
No1にて、攻撃者（10.210.222.194）から攻撃対象のキャッシュDNS(10.210.222.197)に00000001.www.indo8.co.jpを名前解決させるトリガーを引いている。
No2とNo3で、攻撃対象のキャッシュDNS(10.210.222.197)がindo8.co.jpの権威DNSのIPをグルーレコードとしてゲット。
No4でindo8.co.jpの権威DNSである172.16.191.1へ問い合わせ開始。
No5～No10で自身を172.16.191.1と偽装した攻撃者からのパケット（毒入れ狙い）が届く（MACアドレスをみれば判別できます）。また、AA=0のため、移転インジェクションではない。委任インジェクションか？
No11は正しい権威DNSからの正規のレスポンス。
No12は攻撃者からのパケットのおこぼれ（正規のパケットを受け取った瞬間を、攻撃者は検知できないため。瞬間が検知できないだけで、問い合わせで確認は可能）
No13はNo1の問い合わせに対するレスポンス。
○回答考察
。。。まだチェックサムがおかしい方がよかったかも。。
まず、L4レベルで通信がなりたっていない。。No2のクエリに対してのレスポンスであるNo3ですが、このあて先ポート番号(47771)いったいどこから。。
ポート番号63137が不自然に利用されすぎ。。
次に上記には現れていないが、No3とNo4でMACアドレスに変化がなかった。No3の送信元の192.168.40.1と、No4の送信元の10.210.222.197が同じMACアドレス同士です。さらにNo3のあて先の10.210.2222.197と、No4のあて先の172.16.191.1も同じMAC同士です。。L2レベルで通信がなりたたない。。（または偽装された？！）
No2でrd=1をセットしているのに、No3ではrd=0にされてレスポンスがもどっている。。偽造されたのか？通常はレスポンスではクリアされないと思ったが。。
No5～No10およびNo12では、AA=0なので委任インジェクションしているかと思いきや、なぜかNSレコードをアンサーとして返している。。No4でAレコードを引いているのに？？これではインジェクションできない。。
上記のようなカオスな状態ではいろんな可能性がありすぎて、めちゃくちゃ混乱しました。
（知らない攻撃手法があるのかとも考えました。）
しかしなんとかつじつまを合わせようといろいろ考えぬいた結果、下記に到達しました。
「問題を作成した人が、実際のパケットフローを理解しておらず、それらしく作成した。」
または、
「具体的な攻撃手法は伏せておきたいため、わざと間違えたものを作成した。」
仕方がなく、回答では上記のおかしいところを指摘した上で、回答者が求めているであろう攻撃名を書きました。
（委任インジェクション）
さすがにこの問題は解説のときにJPRSの方からフォロー入っていました（これでは毒は入らない）。
