taisho3日記

WriteUpなど。

MNCTF 2017 Writeup

7月6日にMacnica Networks DAY 2017 Day1(Day2は7月11日とのこと)に参加し、午前中に行われたMNCTF2017にもチャレンジしてきました。

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

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

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

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

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

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

MNCTF2017

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

f:id:taisho3_indo8:20170708085320p:plain

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

オンサイトの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 してキャッシュをクリアしたほうがいいかも。)

f:id:taisho3_indo8:20170708102640p:plain

 

 ■脅迫文書

 文書中に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その6

■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個目の到着時にあて先のポートが閉じている(一つ目がすでに到着するため)とみて無視する(2つのレスポンスはほとんど同時に送出されているが、まれに時間差が長いときにあて先が反応か?)

 

あとは毎回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その5

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

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

 

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

 

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

・mondai5.pcap(1パケットのみ記録されている)
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その4

■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その3

■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その2

■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だがほったらかしのミラーポートがたまたまり(または設定変更で作成!?)、そこと通常のアクセスポートの2つを利用して攻撃端末がつながれている(ミラー側で検知、アクセスポートで送信)
③クライアントDNS側またはキャッシュDNS側のケーブルにタップ装置やバカHUBなどをかませて、そこと通常のアクセスポートを利用して攻撃端末がつながれている。

 

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

 

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

 

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

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

2014年 9月27日(土)~28日(日)の2日間、信州大学工学部 SASTecにて実施されたSECCON2014長野大会DNS Security Challengeに参加してきました。
初日に配布されるpcapファイル(計6問分)を解析し、攻撃者のパケットや攻撃手法、そう考えた理由などを記述し、翌日に回収されて採点というものでした。
2日目はDNSカルトクイズ大会が実施され、パケット解析の結果とDNSカルトクイズ大会の総合得点で順位が決まるというものでした。
結果は総合2位でした。
(パケット解析は2位、DNSカルトクイズ大会は1位でした。)
以下パケット解析問題についてWriteUp

 

※パケットデータは配布用のものが別途用意されるというような情報がありましたため、念のためここでは要約だけの記載にとどめます。
※パケットデータの中身に触れる部分がありますが、そこは概要が分かる程度に加工して表現しています。
 (パケットNoは、実際に配布されたパケットデータのNoとあわせて表現しておきます。)

 

 

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

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

 

○パケットデータ概要
173個のDNS関連のパケットのやり取りが記録されている。
怪しいところは一箇所あり、権威DNSからの回答が重複しているパケットがある。
下記のような感じです。
(凡例)パケットNo ソースIP:ソースポート -> デスティネーションIP:デスティネーションポート Info

166  192.168.0.197:30828 -> 10.0.0.144:53       Standard query 0x1b89 A www.indo8.co.jp
167  10.0.0.144:53       -> 192.168.0.197:30828 Standard query response 0x5e25 A 172.16.0.129
168  10.0.0.144:53       -> 192.168.0.197:30828 Standard query response 0x1b89 A 172.16.0.129

 

○回答考察
166で出した問い合わせに対して、レスポンスが2つ帰ってきています。
トランザクションIDをみると、正しいペアとなるのは166と168(0x1b89のペア)であり、167のパケットはおかしいとわかります。
念のため、このトランザクションID(0x5e25)でフィルタかけてみましたが、pcapデータからは同じトランザクションIDを持つパケットは記録されていませんでした。
これで問1の答えは167のパケットと分かりました。これは正解しました。

 

問2について考察しました。
・中間者攻撃関連であればトランザクションIDを間違えるはずがないので違う。
・キャッシュポイゾニングを狙ったものだが、トランザクションID以外は絶妙なタイミングでポート番号も一発で一致させている。
結局、偶然に頼ったDNSキャッシュポイゾニングを試みたパケットがたまたま届いたという理解で一致し、答えをDNSキャッシュポイゾニングとしました。
が、答えはバースデイアタックでした。。トランザクションIDを合致させるレベルで実施されるものと思っていたので、送信元ポート番号まで含んで実施する(今回送信元ポート番号は53/udp固定ではありませんでした)ということまで発想がとどかず不正解。
この回答発表で一気にへこみ、寝不足の頭は真っ白になりました。。

 

問3はAレコードのレスポンスを偽造して、キャッシュポイゾニングを狙ったものと思われる、、というようなことを書きましたが、バースデイアタックについて記述していないので不正解。

 

○その他
本問題(このあとのmonndai1~3)は、答えのパケットのチェックサムがおかしいため、wiresharkが色つきで表現してくれます(最近のwiresharkはデフォルトで表示してくれず、設定をする必要があります)。
チェックサムをみるかぎり、この問題は168のパケットデータをコピーし、timeやトランザクションIDをバイナリエディタなどで編集して作成されたと思われます(167と168のチェックサムが同じのため)。

mondai1~3の攻撃パケットの特定作業は楽になり、それ以外を考える時間に当てることができました。

 

 

★追記

上記のパケット概要での表現ですみませんが、、、

問題ファイルではwww.indo8.co.jpのAレコードのレスポンスパケットを偽装している。

いくらバースデイアタックといえど、絶妙なタイミングでパケットをいれこんでいるのでトリガーとなる問い合わせを発行しているはずだが、見当たらない。。

www.indo8.co.jpのAレコードを問い合わせるパケットを攻撃者が送っているはずだが、MACアドレスで確認したところ、存在していなかった。

(www.indo8.co.jpのAレコードを問い合わせている送信元MACアドレスはすべてVMwareのベンダーコードであった。が、攻撃パケットの送信元MACはJuniperのベンダーコードである。よって、juniperのベンダーコードを持つMACを送信元としてwww.indo8.co.jpのAレコードを引いているパケットがなければ、攻撃者はトリガーを仕掛けていないと思われる)。

また、www.indo8.co.jpの権威DNSは、直前の委任パケットをみると2つあり、通常は2つ分の権威DNSのIPを装ってパケットを投げると思うが、攻撃パケットはひとつしかないため、わざわざ事前に確認できるのに、可能性を低くするやり方をしている。

トリガーもなく、権威DNSも2つ分パケット送ればいいところを1/2で当たる可能性に賭けて、送信元ポートとトランザクションIDをヒットさせるような攻撃は、バースデイアタックの範疇にいれてしまっていいのか??と疑問に思う。

 

 

mondai2へつづく。

(不慣れで書くのに時間がかかるため、分割して掲載していきます。。)