meowの覚え書き

meowの覚え書き

write to think, create to understand

rvctf2023復習: Wayback Machineの総当たり

公開情報と調査 OSINT CTF reconnaissance

これは心を抓む戦い!

目次

概要

2023年の DEF CON 31にて行われた Recon Village CTF(以下rvctf)で出題された問題の復習を今更ながら行う。復習というよりも別解探しというべきかもしれない。
具体的にはWayback Machineのページをいかに手番を抑えて総当たりするかを考える。最近のLLMベースの手段で解けないかも試験した。

問題の内容

“Challenge 1”1という問題名のものであり。第1問目、一番配点が低いパネルである。
問題文は以下。

We are hexapps. We build apps for others. We are quite new and do not have an old footprint. Visit our website for more info: https://hexapps.xyz

機械翻訳:

私たちはhexappsです。他人のためにアプリを作っています。我々は非常に新しく、古いフットプリントを持っていません。詳しくはウェブサイトをご覧ください： https://hexapps.xyz

問題文中のURLのページからフラグを探す問題である。
問題文に何がフラグになるのかは書かれていないものの、CTFのOSINTカテゴリを解いたことがあるプレイヤーならば、インターネットアーカイブにアタリをつけるのではないかと思う。
しかし、私が所属していたチームはこの問題を解けなかったし、記憶が正しければ140チーム以上が参加したにもかかわらずsolveが5or6程度しかなかったと思う。
それにはこの問題独特のヒネりがあるためだと考える。

問題の難しさ

実際正解となるフラグもWayback Machine内に存在した。
https://web.archive.org/web/20230805070205/https://hexapps.xyz/index.html

トグルの1つに”coupon code”という体で仕込まれている。なお、最新のページの方は”You can also 〜”の文章が消されている。

しかし、フラグの格納場所が恐ろしく見つかりづらい場所に設置されている。
具体的には、”https://hexapps.xyz/”のアーカイブではなく、”https://hexapps.xyz/index.html” のアーカイブの方に存在した。index.htmlの有無で別々にアーカイブがとられるようだ。
URLエントリーリストを見ると、index.htmlなし(フラグなし)のアーカイブはリストの一番上であるのに対し、index.htmlあり(フラグあり)のアーカイブは、URL下の88エントリーある内の後ろから2番めにあり、総当たりしなければ見つからないような隠され方がされている。

後ろから2番め

私は88エントリ全部見る根性は無く、「実はwayback machineではないんではないか。gitなどで別の手段でアーカイブされたものを見るんじゃないか」という風に探索空間を広げてしまい、綺麗にラビットホールに嵌まってしまった。

問題の想定解法

ここで運営から提供されるポイント消費で得られるヒントを紹介する。 CTFの時間が経つに連れ3つ追加された2。

hint1

Go back in time. Spot the difference.

機械翻訳:

過去に戻って、違いを見つけてください。

hint2:

We are not old, it should not take too much time going back in time looking for us.

機械翻訳:

私たちは古くないので、過去に戻って私たちを探すのにそれほど時間はかからないはずです。

hint3:

Been to Wayback machine? Did you see something different on the website. Check the whole page.

機械翻訳:

Wayback Machine にアクセスしましたか? ウェブサイトで何か違うものを見つけましたか? ページ全体を確認してください。

ヒントを伺うに、「Wayback Machineのアーカイブを全部見る」ことがこの問題の想定解と解釈できる。地獄ですね、、、3

一応、「総当たりしなくても効率的に見つけられるのでは」という指摘について回答しておく。

  • Q1. HTMLファイルだけに絞って見ればよいのでは?
    • A1. html上にあるとは限らない。rvctf2022でもWebページ調査の問題があったが、その時はjsファイル内にあった(参考)。 さらにrvctf2021はWordPressのCookie同意バナー内のプライバシーポリシー文章(txtファイル)内にフラグが仕込まれていた。どこに仕込まれているか予測できない。
  • Q2. フラグの文字列を正規表現などで検索すればすぐわかるのではないか?
    • A2. 必ずしもフォーマットで加工されているわけではない。rvctf2022の時もリート表記で人目ではフラグだとわかるもののテキスト検索ではヒットしない。

すなわち、rvctfのWebページ調査問題は、経験則的あるいは機械的にフラグを取得することが非常に難しく、言ってしまえば根性を試すような要素があるということである。

プレイヤーが最初に取り掛かるであろう第1問目にこれを出題した意図は色々と勘繰りたくなるが、この問題から学ぶところを見出すとすれば、index.html を明示的に指定した方のURLのアーカイブにはまだ見ぬ情報が残っているかもしれないということであろう。
この問題1つに7時間以上突っ込んだ身からすれば良い勉強代である。

Wayback Machineのアーカイブ閲覧の効率化を考える

さて、Wayback Machineのページをすべて見ればおそらく解けた問題であるが、それを行使できなかった背景にはWayback MachineのアーカイブをWebブラウザで確認することは手間なことにある。

アーカイブ1つ1つのファイルを確認するには次の工程で行う。

  1. URLエントリーリスト からファイル名のクリック
  2. カレンダーUIから日付をクリック
  3. その日付のhh:mm:ssをクリック
  4. ページが表示されるので見る
  5. (+αでソースの表示)

日付のパネルを逐一確認するのは面倒だし、アーカイブが完全に表示されるまでには時間がかかり、調査のオペミスも生じやすい。
(実際に https://web.archive.org/web//https://hexapps.xyz/ で1つほど試してみるとその負担を実感できるかもしれない。)

したがって、以下のことが可能になれば、この問題はもう少し労力を減らし、かつフラグを見つけられたのではないかと考える。

  • 工程1: Wayback Machine の指定したURLのリソースをすべて、かつ全時刻分ダウンロードする
  • 工程2: ダウンロードしたリソースをすべて目視で確認する

工程1の実施方法は割愛するが、ツールが見つかるかもしれない。

工程1で、1つのディレクトリ内に全タイムスタンプのファイルを用意したイメージがこちら。

これで、ローカル上で効率よくファイルを確認することができるようになった。

あとは工程2として、vscodeでペインを分け、ソースを左、ビューアーを右などにすることで、webブラウザ越しの総当たりよりも手間と時間が軽減できる。
この時、画像ファイルは別ディレクトリに分けて別にすると確認がなお捗る。

RAGベースの文書検索で総当たりを効率化できないか

アーカイブされたファイルを1つ1つ見ていけばいずれ答えにたどり着けることはわかったが、いくらリソース参照のステップを時短しても、工程2の目視総当たり確認することには変わりがない。これを効率化できないかを考えた。
そこで近年のトレンド技術、RAGベースの文書検索を用いて、LLMにキーワードを含むファイルを見つけてもらうことを検討した。

RAGベースの文書検索の概要図

RAG(Retrieval Augmented Generation;検索拡張生成)とはLLMに問い合わせる時、プロンプトに文書などのコンテキスト情報をセットで与えることでコンテキストを踏まえた回答をさせる技術である。
新しい情報やプライベートな情報など、LLMが学習したデータ以外の情報を踏まえて回答を行うbotを作成したい時に有効な手段となりうる。
特に文書検索への応用がさかん4であり、自然文で文書を検索するためのコア技術として期待されている。

自前でRAGベースの文書検索環境を組むのは多少手間がかかるので、何かいい方法がないかと思い私が目をつけたのがGithub Copilotである。
文書検索をさせることはGithub Copilotのユースケースから外れるだろうが、copilot自体はコードを理解することにチューニングされていると考えられるし、ちょうどダウンロードしたアーカイブをvscodeで閲覧していたこともあるし、最近は無期限の無料枠もあり始める敷居が低いことも後押しした。

やったことは、アーカイブを保存したディレクトリをワークスペースのルートになるようにした上で、ワークスペース全体を参照するようにして(メンション@workspaceをつけて)質問を投げるだけである。モデルはgpt4oを使用した。

問い合わせ文はこちら

@workspace I am participating in the CTF. There seems to be a hidden keyword in files in this folder. Can you help me find it?

結果はこちら、

駄目な模様。gpt4oも匙を投げてしまう。

一応、明示的に「探したいものはクーポンだ」と情報を与えた状態だとヒットする。

次に、検索範囲をvscode上で現在アクティブなペインに絞って、同様の質問をする。フラグを含むhtmlファイルに絞って同様の質問をした結果がこちら。

フラグを提案してくれた。
したがって、ファイルを一つ一つ開いて問い合わせれば、見つけてくれる期待はできることがわかった。

結局ファイルを開いて1つ1つ質問をするという総当たりの手間は省けていないが、前向きに評価するならば目視チェックしてくれる作業者が1人増えたと捉えれば良いだろう。

RAGベースの文書検索の考察

今回の問題には貢献しない結果ではあったが、個人的に、「公開情報をローカルにダンプ→RAGベースで文書検索」は化けそうな匂いがする。
今回は問題文が曖昧なために漠然としたプロンプトを与えてしまったが、例えば、氏名やユーザ名など、抽出したい情報を明示的に指定できれば機能するのではないかと思っている。これらは電話番号のように正規表現などでパターンを組むことができず知的なプロセスで抽出する必要があり、そこにLLMが役立つはずである。
また、CTFに限らず今後も膨大なオープンソースの文書を漁る場面に出くわすはずで、その時に適用できればいいと考える。

この手法が機能する場が現れることを期待して、調査手段の引き出しの1つとして持っておきたい。

まとめ

本記事では、DEF CON 31のRecon Village CTFの問題を振り返り、以下の点について検討した：

結論として：

  • アーカイブの一括ダウンロードとローカルでの確認により、作業効率を改善できる
  • RAGベースの検索は今回の問題には直接的な効果は限定的だったが、明確な検索対象がある実際の調査では有用な可能性がある
  • 調査手法の1つとして、RAGベースの文書検索は今後の活用が期待できる

技術が発展してもなお、調査において根性を試される場面は残念ながら無くなっていない。昔、海外のosint関係のフォーラムで「best toolは何か」というトピックに"brute force"というレスがついていたのを見かけたが、ネタではなくガチの意見だったのかもしれない。

参考文献

  1. rvctf2023は問題名が基本”Challenge <#>”という形式のナンバリングで、問題名からは内容が推察できない形となっている。↩
  2. 私のチームはヒントを閲覧していない。CTF終了後にヒントが閲覧可能な状態となっていたものをメモしていた。↩
  3. しかもヒントは3つとも同じことが書いてあるに等しい。このヒント3つをポイントを払って掴まされたチームは気の毒だと思う。余談だが、私が所属していたチームはヒント開示のためにポイントを消費することが敗因につながると知っており、絶対に見ないようにしていた(参考)。rvctfの戦い方を弁えている様を見て「長年やり慣れている、というか、やられ慣れているなぁ」と内心笑っていたものである。↩
  4. AI関連の展示会に行くと半数近くのブースがRAGベースの文書管理・検索ソリューションを宣伝している。↩