MNCTF 2018 Writeup

今年も参加してきました。

８位でした、ミーティー！！

エスカレータ上がったところで案内している方は勅使川原君かな？とか、

会場内に「たしかこの方は山崎君。。」とか思いながら着席しました。

凌さんではなく、山崎君のカウントダウンで競技開始でした。

今年は去年にもまして調査系というか、インシデント対応に使えそうな問題が多く、

また、勉強できたことも多く、楽しめました。

問題もシリーズ形式で、前の問題から内容が続いていく感じがメインで構成されています。

この路線で続けてほしいです！

もう問題サーバが公開されました。

MNCTF2018

　※本当に危険なものはないですが、実際の攻撃パターンを再現したりする問題ファイルがあったり、Shinobotを仕込まれる問題等あるため、会社内で実施すると、いろいろアラート上がる可能性が高いですのでお気を付けを。

■新人奮闘Ⅰ（マルウェア解析）

「AD_OptimizationTool.exe」をダウンロードし、SHA-256を答えるだけ。

何かしらのツールか、下記にアップロードして解答。

■新人奮闘Ⅱ（マルウェア解析）

「AD_OptimizationTool.exe」表層解析レポートを埋めよとのこと。

（MD5、SHA1、SHA256、ファイルサイズ、コンパイル日付、Import関数）

すべての要素は下記に投げれば得られます。

（途中までStub_PEでやってました。）

■新人奮闘Ⅲ（マルウェア解析）

「AD_OptimizationTool.exe」を実行すると、発行されるコマンドを答える問題。

stringsした。

でも、下記でもとける。

ここまでの新人奮闘はすべてVirusTotalで解けるという感じ。

■新人奮闘Ⅳ（フォレンジック）

与えられたログから、不正ログインされている時刻を答える。

先ほどの答え「cmd /c net user /add /domain vpnadmin P@ssw0rD1!」を利用する。

vpnadminでログを検索し、その時刻が答え。

■新人奮闘Ⅴ（その他）

先ほどのログで、送信元IPがある。

2018/07/13 15:01,vpnadmin,27.117.128.1

そこから送信元の国を調べる問題。

下記つかった。

答えは韓国。

■大量不正

ファイルをマルウェアの断片と見立て、似ているファイルを探す問題。

ファジーハッシュというものを利用するらしい。

回答できず。

あとで知ったが、virustotalで「ssdeep」という値がそれらしい。

これの値が近いものを探してもOKだが、数が多いのでコマンドがベスト。

コマンドだと下記とのこと。

C:\temp\ctf\malwares\malware>ls
sample1.bin sample20.bin sample32.bin sample44.bin sample56.bin sample68.bin sample8.bin sample91.bin
sample10.bin sample21.bin sample33.bin sample45.bin sample57.bin sample69.bin sample80.bin sample92.bin
sample100.bin sample22.bin sample34.bin sample46.bin sample58.bin sample7.bin sample81.bin sample93.bin
sample11.bin sample23.bin sample35.bin sample47.bin sample59.bin sample70.bin sample82.bin sample94.bin
sample12.bin sample24.bin sample36.bin sample48.bin sample6.bin sample71.bin sample83.bin sample95.bin
sample13.bin sample25.bin sample37.bin sample49.bin sample60.bin sample72.bin sample84.bin sample96.bin
sample14.bin sample26.bin sample38.bin sample5.bin sample61.bin sample73.bin sample85.bin sample97.bin
sample15.bin sample27.bin sample39.bin sample50.bin sample62.bin sample74.bin sample86.bin sample98.bin
sample16.bin sample28.bin sample4.bin sample51.bin sample63.bin sample75.bin sample87.bin sample99.bin
sample17.bin sample29.bin sample40.bin sample52.bin sample64.bin sample76.bin sample88.bin
sample18.bin sample3.bin sample41.bin sample53.bin sample65.bin sample77.bin sample89.bin
sample19.bin sample30.bin sample42.bin sample54.bin sample66.bin sample78.bin sample9.bin
sample2.bin sample31.bin sample43.bin sample55.bin sample67.bin sample79.bin sample90.bin

C:\temp\ctf\malwares\malware>ssdeep -bcdr *
"sample68.bin","sample1.bin",99

■種類特定（ネットワーク）

pcapをゲットして、マルウェアの名前を特定する問題。

去年の教訓で最新シグネチャにしたsnortにかけて、普通にでた（最新のシグネチャにて）。

[**] [1:42894:3] MALWARE-CNC Win.Trojan.Ursnif variant outbound connection [**]
[Classification: A Network Trojan was Detected] [Priority: 1]
07/04-19:28:54.497629 10.0.0.66:49202 -> 199.16.199.6:80
TCP TTL:255 TOS:0x0 ID:26 IpLen:20 DgmLen:451
***A**** Seq: 0x51B897A5 Ack: 0x19A3 Win: 0x3E65 TcpLen: 20
[Xref => http[:]//virustotal.com/en/file/d137ee63561a123edc51a1d23ce74a18ee094a872b0b9151606934ad12701c05/analysis/]

Ursnifを答えとして入力したがNGだったので、別名調べて「Gozi」で正解した。

（Ursnifは答えチェックミスだったそうで、正解のようです。）

答え合わせの時間にて、どなたかがvirustotalに投げて出たとのことだったのでやってみた。

えー、ナニコレ。。こんな機能あったの？

Snortでチェックしてるやん。。

virustotal、すごいな。。

■標的攻撃Ⅰ（マルウェア解析）

エクセルファイルが渡されて、マクロが稼働する実行条件となる「ユーザ名」を答えろとのこと。

エクセルがない。。

仕方ないのでとりあえずのstringsで、ユーザ名らしき数名をメボシをつけ、入力して正解（答え複数のため、そのどれかでOKだったらしい）。

■標的攻撃Ⅱ（マルウェア解析）

先ほどのエクセルがうまく稼働するとhttpsの通信が発生するとのこと。

エクセルがない。。

stringsで探す。。

C:\temp\ctf\attachment>strings 製品価格一覧20180711.xls |grep https
https[:]//gist.githubusercontent.com/Sh1n0g1/3a240ce15fe7f26263ddf1877e5acc38/raw/d1d74601e5f4c94c958130accb16add9bb16e33d/cert
https[:]//gist.githubusercontent.com/Sh1n0g1/3a240ce15fe7f26263ddf1877e5acc38/raw/d1d74601e5f4c94c958130accb16add9bb16e33d/cert

あった。。

■標的攻撃Ⅲ（マルウェア解析）

「製品価格一覧20180711.xls」の動作を終えると、別のファイルが生成され、そこから2次検体が生成されます。2次検体のSHA256ハッシュ値を調べてください。

とのこと。。

多分上記でダウンロードされるファイルだよね？と思い、ダウンロードした。

中身は下記。

ここで、予習の成果がでた。

下記を読んでいたため、同じ手口の問題だと予測できた。

blog.macnica.net

紹介されていた下記コマンドの要領で二次検体を手に入れた。

certutil -decode %temp%\\HnftK.pHFj %temp%\\ThnjFY.cab

そのSHA256で答え。

予習大事。。

■標的攻撃Ⅳ（ネットワーク）

2次検体を実行すると、HTTPSの通信が発生します。最初の通信のURLを調べてください。

とのこと。

実行させてみたがhttpsなのでFQDNだけでURLが確認できない。

はてさて、で行き詰っていたら、ここまで助けてくれたvirustotalを思い出して、ダメ元で先ほど作成した二次検体をなげてみた。

あるやん。。

これを入力し、正解した。

ミーティー!

■穴埋防御（マルウェア解析）

定義途中のYaraルールを完成させよとの問題。

さっぱりピーマンで解答できず。

Base64をでコードし、PowerShellということは分かったが、

mainの部分がさらにBase64されていた模様。

そこをデコードして、IDAなどにいれるとMutex名がわかるとのこと。

（やってみたが、なぜかフリー版のIDAでは、解答例のようにうまくでませんでした。よくわからず。。）

（2018/7/14修正） フリー版のIDAでもできてました。。デコード失敗してただけだったかも。

■盗難情報（暗号）

下記されたものを復号する問題。

XOR（シングルバイトキー）→ Base64 → ROT13

時間なく焦っており、そのままXORブルートから開始し、わけのわからないことになったまま終了しました。。

あとから復習で解きました。

a='aRIoHutsQk8ISEHLKS1EEkHIS4RISEFfUEpISEJdLvLYSEHISTMUHypIh9fW/

・・・省略・・・

ZKj86hwX6tdr0RzJmVGx1OHISEIpHSgEh1q1yj=='
dst=open('out.dat','wb')

b=a.decode('rot13').decode('base64')

dst.write(''.join(chr(ord(x)^0x15) for (x) in b))

dst.close()

これで、png画像がでて、答えがのってます。

（XORの部分はブルートフォースして探した。）

解答コーナーでは、下記が紹介されていた。

自作のpythonでブルートフォースするのはやめ、今後こちら有効に利用させてもらいます。。

デコードなどを何段も、いろんな種類でかませれるのが素晴らしいです。。

昼はつけめんTETSUにて。。うまし。

身になること多く、有意義な時間でした！

また来年もチャレンジしたいです。

ミーティー！！

MNCTF 2017 Writeup

７月６日にMacnica Networks DAY 2017 Day1（Day2は７月１１日とのこと）に参加し、午前中に行われたMNCTF2017にもチャレンジしてきました。

結果は11位ぐらい（今は問題も公開されて、当日のランキングは崩れていて分からず）。

正直もっといけるかと、はりきっていました。。。

会場も広く、90人以上いた感じです。

（会場には運営として、問題に登場する「やまざき君」や、「てしがわら君」がいました。ちなみに問題にでてくるような所業は一切していないとの弁明がありました。。）

しおりにWriteUp書くまでがCTFとあったので、書きます。。

公開されたサイトは下記。

MNCTF2017

　※これからやる人はネタばれになるので見ないでくださいませ。。

制限時間が１時間３０分なため、効率も考えてとかないとすぐ時間なくなりそう。。

オンサイトのCTFなんて、数年ぶり？で緊張した。

得点は1問100点スタートで、回答者が多くなると点数が低くなっていく方式でした。

■練習問題

入力テスト。これは競技時間前に入力可能。

よくわからない予習の成果で「MNCTF2017」と予想していたが、「MNCTF」だった。

■通信記録

最初に公開された問題。

これは解けなかったうえ、かなり時間をとられてしまった。。

pcapファイルが与えられて、突かれた脆弱性の名前を答えるというもの。

通信も大量に記録されていて、適当にぶち込んだNetworkMinerが戻ってくるまでだいぶ時間かかったような。。

SMBの通信も大量に記録されており、これは直近で話題のWannaCryでは？と気づいた。

が、脆弱性の名前とあったので、CVE識別番号などをうっていたが当たらず。。

stringsなどの結果でも何もビットはたたず。。

昔使ったオンラインのpcap分析サービスの試用版を思い出そうとしていたが、思い出せず（ARBORだったような）。

正解は「EternalBlue」とのこと。それは攻撃ツールの名前では？？

しかし、一回ぐらい答えとしてダメもとで入力はしておくべきだったかと。。

解き方としては、pcapをsnortなどに解析させて、検知ログを見ればOKとのこと。

windows版があるとのことでやってみた。

（インストールしてからちゃんと動くまでなんかいろいろはまった。。基本的にはsnort -v -c snort.confを実行してエラーで怒られた行番号のところを調べたり修正したりした。）

〇pcap読み込ませて分析。

snort -r pcap.pcap -c snort.conf

〇下記検知ログ抜粋。同時に投入されるバックドア「Doublepulsar」の検知ログもあった。なるほどです。

[**] [1:41978:4] OS-WINDOWS Microsoft Windows SMB remote code execution attempt [**]
[Classification: Attempted Administrator Privilege Gain] [Priority: 1]
05/16-15:27:09.267824 10.211.55.32:49348 -> 10.211.55.34:445
TCP TTL:128 TOS:0x0 ID:8740 IpLen:20 DgmLen:1500 DF
***AP*** Seq: 0x1250A1DC  Ack: 0x1411471A  Win: 0xFE  TcpLen: 20
[Xref => http://technet.microsoft.com/en-us/security/bulletin/MS17-010][Xref => http://isc.sans.edu/forums/diary/ETERNALBLUE+Possible+Window+SMB+Buffer+Overflow+0Day/22304/][Xref => http://blog.talosintelligence.com/2017/05/wannacry.html][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-0146][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-0144]

[**] [1:42329:1] MALWARE-CNC Win.Trojan.Doublepulsar variant successful ping response [**]
[Classification: A Network Trojan was Detected] [Priority: 1]
05/16-15:27:22.498716 10.211.55.34:445 -> 10.211.55.32:49676
TCP TTL:128 TOS:0x0 ID:7806 IpLen:20 DgmLen:79 DF
***AP*** Seq: 0x8CC329A5  Ack: 0xD56435DC  Win: 0xF9B2  TcpLen: 20
[Xref => http://www.virustotal.com/file/15ffbb8d382cd2ff7b0bd4c87a7c0bffd1541c2fe86865af445123bc0b770d13/analysis/][Xref => http://countercept.com/our-thinking/analyzing-the-doublepulsar-kernel-dll-injection-technique/]

 ■昇進試験

Linuxコマンドの クロスワードパズル。

「factor」と「column」は思い浮かばず、Linuxコマンド一覧をカンニングしながらといた。。

詳細省略。

■不審起動

不審なスクリプトが実行される。そのスクリプトの通信先のFQDNを答えてくださいとのこと。

pastbinのサイトからスクリプト本体を持ってきて実行する感じのもの。

JScriptで記載され、難読化されている。。

難読化解除のサイトは調べ済さ、ということでみたらJScriptは対応してなかった。。

時間がなくなってきていたので、マクニカネットワークスさんを信じて実行することにする。

JScriptの部分を抜き出し、hoge.jsとしてファイルに保存。クリックして実行した。

wiresharkでクエリーを捕まえた。

（うまく捕まらない場合は、 ipconfig /flushdns してキャッシュをクリアしたほうがいいかも。）

 ■脅迫文書

 文書中にURLとパスワードが書かれている。

Tor上にサイトがある模様。URLをよくみればわかる問題だったが、本番ではよく見ず、スルーしてしまった。。

Tor2Web などのプロキシサーバを使用すればよかったらしい。
（例：hogehoge.onionならば、hogehoge.onion.toとしてアクセスすると、専用ブラウザなくてもみれるらしい。勉強になったです。）。

■宛先暗号

不審な実行ファイルが検出されたとのこと。下記を分析して、通信先を特定せよとのこと。

解けなかった。
・svchost.exe(マルウェア本体)
・vm.dat(マルウェアと同じディレクトリにあったファイル)
・EDR_log.csv(エンドポイント対策のログ)

下記に投げて宛先を分析しようとしたが、これを防止するためか、vm.datがないと動かないようになっている模様。

https://malwr.com/

上記のみであきらめてしまったが、EDRのログを検索すれば実行時のコマンドパラメータが判明する。。冷静にみればよかった。。

これもマクニカネットワークスさんを信じて、EDRのログのとおりに実行することで、WireSharkで宛先を捕まえることができる。

■攻撃痕跡

これも先ほどの宛先暗号と同じような感じで、EDRのログと、攻撃者が残したファイルが与えられる。

解けなかった。

 EDRのログをよくみて、各ファイルを調べていく感じ。

実際の調査で行われた事例とのことで、勉強になりました。

マクニカネットワークスさん、EDR推しですね。。

（実際役に立ちそう。）

■情報照合

ハッシュ値のリストが与えられるので、とあるサイトのAPIを利用して、「RAT.A.aa74e」と判定されるハッシュを見つけるというもの。

やるだけ問題のようだが、手を付けれなかった。

■賭博遊戯

解けなかった。

Web問。JavaScriptが難読化されている。これを解除せずに指定の金額になるまで

勝ち進めなければならない。

Chromeのデベロッパーツールにて、解析する。

うまく解析できないような作りになっているようだが、diceArrayという配列の中身がConsoleで確認できるらしく、次にでる目がわかる（勉強になりました）。

掛け金も改ざんしないと、規定回数で目標金額に達さないらしい。

（それもデベロッパーツールでできる。）

■脆弱会話

下記が与えられる。

・Feuder.exe （Feuder本体)
・Feuder.cpp (Feuderのソースコード)
・exploit.py (脆弱性を突くためのPython)
・hint.png　(PoCと一緒に入手したヒント)
・send_pattern.py　(番地を調べるためのPython)

hint.pngがスタックバッファーオーバーフローの存在を示している。

その中で、攻撃成功時に利用した領域のサイズが答えとのこと（バッファの先頭アドレスから、リターンアドレス直前までの大きさ）。

 ソースもあるので、すぐに下記の部分が危ないとわかる（strcpy）。

void pr( char *str)
{
   char buf[1015];
   strcpy(buf,str);
}

アライメントの関係で、バッファは1016ぐらいで確保されるかなと考え、あとはsaved ebpを考慮して+4する。答えは、1020。

と、できたらよかったが、実際はアライメントを考慮せず計算したり、

デバッガも使っていろいろやっていた。。

send_pattern.pyをうちこんで、計測するのが想定解とのこと。

なんとか時間内に正解できた。

まとめ

仕事でも使えそうなものがちりばめられており、大変勉強になりました。

懇親会の料理が結構豪華（！）で満たされました。

SECCON 2014 長野大会 DNS Security Challenge Writeupその６

■mondai6
○問題文
mondai6.pcapを見て以下の問いに答えて下さい。

問1：攻撃成功している回数は何回か？
答え：

○パケットデータ概要
下記のようなパケットがずっと繰り返し続く。

（凡例）パケットNo ソースIP:ソースポート -> デスティネーションIP:デスティネーションポート Info (補足)

70  192.168.1.100:45143  -> 192.168.1.1:53       Standard query 0x0e0b A www.example.com
71  192.168.1.1:53       -> 192.168.1.100:45143  Standard query response 0x0e0b A 192.168.0.10
72  192.168.1.1:53       -> 192.168.1.100:45143  Standard query response 0x0e0b A 192.168.1.2
73  192.168.1.100:45143  -> 192.168.1.1:53       Standard query 0xfb76 A www.example.com
74  192.168.1.1:53       -> 192.168.1.100:48119  Standard query response 0xfb76 A 192.168.0.10
75  192.168.1.1:53       -> 192.168.1.100:48119  Standard query response 0xfb76 A 192.168.1.2
76  192.168.1.100:53     -> 192.168.1.1:48119    Destination unreachable(port unreachable)

○回答考察
この問題はコードを書かせたいらしいと皆で意見が一致した。。

下記に気をつけてカウントしていく。
・AレコードのクエリーのトランザクションIDを記録し、その後同じトランザクションIDを持つ最初のレスポンスをカウントしていく。
・量が多いため、トランザクションIDが後半で重複する可能性を考慮する
・Destination unreachableがたまに見えるが、レスポンスの2個目の到着時にあて先のポートが閉じている（一つ目がすでに到着するため）とみて無視する（２つのレスポンスはほとんど同時に送出されているが、まれに時間差が長いときにあて先が反応か？）

あとは毎回２つくるレスポンスのうち、どちらが攻撃者のパケットであるか議論した。
（チェックサムが0のものという回答があったが、0だとチェックサムはまだ計算されていないという意味となり、wiresharkでチェックサムが不正なときにつく色にならず、気づいていなかった。。）
192.168.1.2を回答としてもつレスポンスは、問題ファイル中、レコードのTTLが微妙に変化していた（カウントダウンされていた）。
192.168.0.10を回答としてもつレスポンスは、問題ファイル中、レコードのTTLが変化していなかった（固定）。
かつ、フラグの状態から、192.168.1.1はキャッシュDNSと思われる。

よって、後者はキャッシュDNS内で行われるはずのTTLのカウントダウンがされていないため、こちらが不正に偽造されたパケットである可能性がある。
よって、先ほど計算したそれぞれの合計値のうち、192.168.0.10の合計値が回答となる。

答え：1111

コードは主に下記を参考にさせていただきました。
http://stackoverflow.com/questions/13223879/dns-rdata-parsing-with-python

・コード
#!/usr/bin/env python

import dpkt ,socket, sys

if len(sys.argv) < 2 or len(sys.argv) > 2:
 print "Usage:\n", sys.argv[0], "filename.pcap"
 sys.exit()

f = open(sys.argv[1])
pcap = dpkt.pcap.Reader(f)

id={}
taihi={}
packet_count=0

for ts, buf in pcap:
 packet_count += 1

 #ether
 try: eth = dpkt.ethernet.Ethernet(buf)
 except: continue
 if eth.type != 2048: continue

 #ip
 try: ip = eth.data
 except: continue
 if ip.p != 17: continue

 #udp
 try: udp = ip.data
 except: continue

 #dns packet
 if udp.sport != 53 and udp.dport != 53: continue
 try: dns = dpkt.dns.DNS(udp.data)
 except: continue

 ### dns flag
 if dns.qr == dpkt.dns.DNS_Q:
   if len(dns.qd) != 0:
     for qr in dns.qd:
        if qr.name == 'www.example.com':
          if dns.id not in id:
             id[dns.id]=' '

 if dns.qr == dpkt.dns.DNS_R:
   if len(dns.an) != 0:
     for an in dns.an:
       if an.type == dpkt.dns.DNS_A:
          if an.name == 'www.example.com':
             if dns.id in id:
                taihi[packet_count]=socket.inet_ntoa(an.ip)
                del id[dns.id]

count=0
count2=0
for k,v in taihi.items():
  if v == '192.168.1.2':
    count=count+1
  if v == '192.168.0.10':
    count2=count2+1
print '#count'
print '192.168.1.2  : ' + str(count)
print '192.168.0.10 : ' + str(count2)

・実行結果
#count
192.168.1.2  : 89
192.168.0.10 : 1111

SECCON 2014 長野大会 DNS Security Challenge Writeupその５

■mondai5
○問題文
mondai5.pcapを見て以下の問いに答えて下さい。

問1：どのIPアドレスに対して何の攻撃をしむけようとしているか？
normal.pcapと見比べて，攻撃先のアドレスと攻撃名を示せ．
答え：

○パケットデータ概要
この問題のパケットデータはこれまでの問題とは明らかに品質が違っている。
きちんとした美しいデータにみえる。
ファイルは２つある。全部記載してみる。
（このデータだけは、公開されてもいいような気を使ったアドレスが最初から使われている。）

（凡例）パケットNo ソースIP:ソースポート -> デスティネーションIP:デスティネーションポート Info (補足)

・mondai5.pcap（１パケットのみ記録されている）
1   192.168.1.111:55862  -> 192.168.1.1:53  Standard query 0xd55f A www.example.com

・mondai5-normal.pcap
1   192.168.1.100:55862  -> 192.168.1.1:53       Standard query 0xd55f A www.example.com
2   192.168.1.100:50779  -> 192.168.1.1:53       Standard query 0xd196 NS <Root>
3   192.168.1.1:53       -> 192.168.1.100:55862  Standard query response 0xd55f A 192.168.1.2
4   192.168.1.1:53       -> 192.168.1.100:50779  Standard query response 0xd196 Server failure
5   192.168.1.100:49274  -> 192.168.1.1:53       Standard query 0xd431 NS <Root>
6   192.168.1.1:53       -> 192.168.1.100:49274  Standard query response 0xd431 Server failure
7   192.168.1.100:64480  -> 192.168.1.1:53       Standard query 0x5539 AAAA A.ROOT-SERVERS.NET
8   192.168.1.1:53       -> 192.168.1.100:64480  Standard query response 0x5539 Server failure
9   192.168.1.100:8228   -> 192.168.1.1:53       Standard query 0x82c7 AAAA A.ROOT-SERVERS.NET
10  192.168.1.1:53       -> 192.168.1.100:8228   Standard query response 0x82c7 Server failure

DNSクライアントである192.168.1.100が、192.168.1.1のキャッシュDNSへ対していくつか再帰問い合わせ（要求）を実施している。
ファイル名がnormalなので、キャッシュDNSサーバの今の状態を表現していると思われる。
・No1でwww.example.comのAレコードの再帰問い合わせ（要求）を出しているのに対し、No3でレスポンスがきている。
・その他のパケットはすべて、このキャッシュDNS（192.168.1.1）がルートサーバへアクセスができない状態を表していると思われる。

○回答考察
ルートサーバへアクセスできないキャッシュDNSがレスポンスを返すということは、現在キャッシュされている情報を利用しているということである。
mondai5-normal.pcapをみると、www.example.comについては、192.168.1.2という回答を返答できている。
よって、www.example.comのAレコードはキャッシュされている。

次にmondai5.pcapを見る。
キャッシュDNSにキャッシュされているAレコードをリクエストしているだけ。
問題文によると、これは攻撃パケットであるという。

これはおそらく192.168.1.1のキャッシュDNSが保持しているwww.example.comのAレコードのTTL切れを延命しようとしている攻撃ではないかと推測した。
（実際はおなじくキャッシュされているであろうexample.comのNSレコードを延命している。）
よって答えは下記のように記述した。

答え：192.168.1.1 に対し www.example.com の間違った 192.168.1.2 をキャッシュさせ続けさせるため、
すでにキャッシュされていると思われるwww.example.comの権威サーバのNSのTTL切れを防止している。
（最終的な攻撃先は、キャッシュサーバとして 192.168.1.1を使っている192.168.1.100等のDNSクライアント）
攻撃名はghost domain names（幽霊ドメイン名）脆弱性攻撃

しかし、公開された回答は、、、
DNSamp(lifier)攻撃、DNS Reflector Attack(Reflection Attack)でした。。
再度頭真っ白。。疲れ感マックス。。
寝不足とクイズ大会でくたばっている脳で、どこを間違えたか考えていた。。
そうしているうちに、回答公開終了。。

休憩時間にも落ち着いて考えてみたが、どうしても納得できず、まずはJPRSの方に聞いてみた。
サイズの大きいパケットや、いくつかパケットが記録されていればDNSampかもとのこと。
（問題は作成していないので詳細は不明とのこと）。

サイズ、、、Aレコードだし小さいし。。ANYでクエリーしていれば多少は、、、でも。。
運営の方の一人にもどうしてDNSampかどうしても理解できないので教えてほしいと聞いてみたが、問題作成者に聞いてみるとの回答をもらった。

う～ん、、何か見落としている？。。ほんとにDNSampなの？？？？

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の方からフォロー入っていました（これでは毒は入らない）。

SECCON 2014 長野大会 DNS Security Challenge Writeupその３

■mondai3
○問題文
mondai3.pcapを見て、以下の問いに答えて下さい。

問1：どのパケットが攻撃者の発信したものか（Seconds from Epochで答えてください）
答え：
問2：用いられた攻撃手法は何か
答え：
問3：その攻撃手法だと考えた理由は何
答え：

○パケットデータ概要
キャッシュDNSがクライアントDNSからのリクエストを受けて、一生懸命動くさまが記録されている。

関係ないパケットを無視して、注目するのは下記。
（凡例）パケットNo ソースIP:ソースポート -> デスティネーションIP:デスティネーションポート Info

1    10.210.222.194:45796 -> 10.210.222.197:53    Standard query 0x5683 A www.indo8.co.jp
（省略）
8    10.210.222.197:37886 -> 10.232.86.3:53       Standard query 0x5cb4 A www.indo8.co.jp
9    10.232.86.3:53       -> 10.210.222.197:37886 Standard query response 0x5cb4 A 10.32.158.139
10   10.232.86.3:53       -> 10.210.222.197:37886 Standard query response 0x5cb4 A 10.32.211.139
（省略）
19   10.210.222.197:53    -> 10.210.222.194:45796 Standard query 0x5683 A 10.32.158.139

○回答考察
DNSフラグの様子から、10.210.222.194がDNSクライアント側、10.210.222.197がキャッシュDNSと判明する。
No1にて、10.210.222.194からの再帰（要求）問い合わせを10.210.222.197が受ける。
省略部分で10.210.222.197による反復問い合わせ（非再帰要求を再帰的に行う）をへて、No8にて到達した権威DNS（10.232.86.3）へ問い合わせ（非再帰）を実施。
No9とNo10にて、権威DNSからの回答を受け取っているが、重複している。
No19で、DNSクライアントへ受け取った回答をレスポンスして終了。

No9が偽装されたパケットで、No10は正式なパケットと思われる。
（チェックサムでもNo10のパケットが編集されてNo9が作成されたことが分かる。）
（ちなみにNo19もチェックサムがおかしかった。正しいレスポンスが帰っているキャプチャを編集し、No9で編集したIPがもどっているようにNo19を編集したためとおもわれる。）
（　※No19をバイナリエディタで編集（10.32.158.139を10.32.211.139と修正）すると、チェックサムは正常になるため。）
ということで問1の回答は確定。

問2と問3について考察。
公開された回答は、権威DNS側での中間者攻撃でした。

これも、mondai2と同じ疑問をいだき、中間者攻撃という単語は利用しませんでした。不正解。。
（権威DNSを偽装したDNSキャッシュポイズニングと表現）

正規のパケットがあとから送られてこなければ迷わなかったのですが。。

SECCON 2014 長野大会 DNS Security Challenge Writeupその２

■mondai2
○問題文
mondai2-client.pcapとmondai2-server.pcapを見て、以下の問いに答えて下さい。

問1：どのパケットが攻撃者の発信したものか（ファイル名およびSeconds from Epochで答えてください）
答え：
問2：用いられた攻撃手法は何か
答え：
問3：その攻撃手法だと考えた理由は何か
答え：

○パケットデータ概要
簡略構成は下記。
キャッシュDNSが同一セグメントのDNSクライアントからの再帰（要求）問い合わせを受付、権威DNS群への非再帰問い合わせを再帰的に行う。

                        権威DNS群
                  　　　 　|
               　　　   [router]
                　　　　   |
DNSクライアント--[L2]--キャッシュDNS

mondai2-client.pcapがクライアント側の動きを記録したもの、mondai2-server.pcapがキャッシュDNS側の動きをキャプチャしたものにみえる。

関係ないパケットを無視して、注目するのは下記。
（凡例）パケットNo ソースIP:ソースポート -> デスティネーションIP:デスティネーションポート Info

・mondai2-server.pcap
1    192.168.0.197:46905 -> 10.0.0.244:53       Standard query 0xefd6 A www.indo8.co.jp
2    10.0.0.244:53       -> 192.168.0.197:46905 Standard query response 0xefd6
3    192.168.0.197:61593 -> 10.10.10.10:53      Standard query 0xa4f5 A www.indo8.co.jp
4    10.10.10.10:53      -> 192.168.0.197:61593 Standard query response 0xa4f5 A 10.194.126.191 A 10.194.126.175 A 10.194.126.183 A 10.194.126.184

・mondai2-client.pcap
1    192.168.0.194:53028 -> 192.168.0.197:53    Standard query 0x9b16 A www.indo8.co.jp
2    192.168.0.197:53    -> 192.168.0.194:53028  Standard query response 0x9b16 A 10.195.126.191 A 10.194.126.175 A 10.194.126.183 A 10.194.126.184
3    192.168.0.197:53    -> 192.168.0.194:53028  Standard query response 0x9b16 A 10.194.126.191 A 10.194.126.175 A 10.194.126.183 A 10.194.126.184

○回答考察
mondai2-client.pcapのNo2とNo3にて、キャッシュDNSからのレスポンスが重複している。
mondai2-server.pcapより、偽造されたパケットはmondai2-client.pcapのNo2のパケットであると分かる。
Aレコードの回答が10.194.126.191のところを、10.195.126.191と偽装している。
（ちなみにチェックサムをみてもおかしいのはmondai2-client.pcapのNo2であった。バイナリ編集などでmondai2-client.pcapのNo3をコピーして作成されている模様。）
ということで問1の回答は確定。

問2と問3について考察。
mondai2-server.pcap側には怪しい動きはみられないところから、クライアントDNSとキャッシュDNSの間でおかしなパケットが偽造されたらしいことが分かる。
ARPポイゾニング等での中間者攻撃などを考察したが、サーバからの正常なレスポンスもあとから到着していた。
よって、中継するようなやり方では、わざわざ正常なパケットをご丁寧に流してあげることはないはずなので、違うと思いました。
（ettercap NG-0.7.4.2にてARPポイゾニングしながら、DNSクエリーに偽応答を返すテストしてみましたが、わざわざあとから正しいパケットをクライアントに返すような動きはみられませんでした。）
よって、なんらかの方法で偽造しているが、中間者攻撃かどうか確信がもてなかったため、回答は「キャッシュDNSを装ったレスポンスパケット偽造」という抽象的な回答に収めました。

しかし、正式な回答はキャッシュDNS側での中間者攻撃でした。。。

うーん、、確かに下記のようなケースであれば、mondai2-client.pcapのNo3も戻ってしまってもしょうがないかなというケースはあるかと思います。
・攻撃者はすべてを中継することはできない環境（正しいパケットを阻止できない環境）にいるが、自分のパケットを正しいパケットより先に到達させることができる。
　※おそらくクライアントDNSとキャッシュDNS間のどこかにいて、mondai2-client.pcapのNo1を検知して、すぐに用意している偽造パケットを送信する。正しい回答のNo3はあとから到着する。

どこで・・・、DNSクライアントとキャッシュDNS間のL2空間のどこかとなると思われる。

　※ちなみにclient.pcapのNo2とNo3のソースMACおよびデスティネーションMACの構成に違いはありませんでしたので、ルータ等の外側から偽装パケットだけ戻っていることはなさそうです。
①DNSクライアントとキャッシュDNS間のL2がバカHUBで、そこに攻撃端末つながれた（通信は傍受できるし、送信もひとつのポートで可能）
②L2SWだがほったらかしのミラーポートがたまたまり（または設定変更で作成！？）、そこと通常のアクセスポートの２つを利用して攻撃端末がつながれている（ミラー側で検知、アクセスポートで送信）
③クライアントDNS側またはキャッシュDNS側のケーブルにタップ装置やバカHUBなどをかませて、そこと通常のアクセスポートを利用して攻撃端末がつながれている。

その他にも同一セグメントのどれかの端末がのっとられており、実行しているようなことも考えられますが、通常はバカHUBでないL2SWで接続されているため、結局ARPポイゾニングしないとクライアントDNSとキャッシュDNS間の通信を傍受できないと思われます。ARPポイゾニングするのであれば中間に入ることが可能なため、わざわざ正しいパケットをあとから送信することはないと思われます。
（キャッシュDNSやクライアント自身、またはルータ等がのっとられている場合でも、正しいパケットをわざわざ通過させることはないと思われます。）

①は最近ではほとんどない構成。
②は偶然あいていることを期待する、また、設定変更は敷居が高く（通常パスワードを突破しなければならない）、可能性低め。
③は通信断が発生するため、気づかれやすく、可能性低め。

問題の作成者の方は、上記のような可能性の低い構成をイメージして問題を作成したのでしょうか。。。
または、まだ別のやり方があるとか？、、、うーん。。