Nakaya / セキュリティ・キャンプ全国大会2024 脅威解析クラス課題晒し

Created Fri, 27 Dec 2024 03:51:00 +0900 Modified Fri, 10 Jan 2025 14:49:03 +0000
12530 Words
event security

セキュリティ・キャンプ全国大会2024 脅威解析クラスに応募し，合格したので応募した課題の内容を晒します．

問1

あなたがセキュリティ・キャンプ全国大会に応募する理由を教えてください。受講生や講師とのコミュニケーション、受講したい講義、なりたい自分など、何でも構いません。(2000文字以内)

全国大会に応募する理由

私がセキュリティ・キャンプ全国大会に応募する理由は、技術面で大きく成長したいからだ。 私は、セキュリティが社会に浸透していくためには、技術でセキュリティを担保するということとセキュリティ知識を広報して世の中に広めていくという2つの方法があると考えている。 これまでの大学生活では、主に後者の広報活動をやってきた。石川県警察から委嘱を受け、サイバー防犯ボランティア活動を1年から今まで続けている。サイバー防犯ボランティアでは、小学校への情報リテラシーの出前授業やランサムウェア・フィッシングメールの啓蒙動画作成、情報リテラシーや情報セキュリティを学ぶことができるゲーム作りなどを行ってきた。セキュリティに関する意識を、自分の周りの人たちから変えることができたと感じている。 よりセキュリティを社会に浸透させていくために、今の自分に足りていない部分は情報セキュリティに関する深い知識だと考えた。セキュリティを考慮したシステム設計や開発などを行うためには、技術的な成長が必要だ。そこで私は、セキュリティ・キャンプ全国大会をきっかけに、技術面で大きく成長したいと思い、応募することにした。

脅威解析クラスに応募する理由

脅威解析クラスを選んだ理由は、セキュリティ脅威に対して様々な視点から学ぶことができると思ったからだ。デジタルフォレンジックやコード実装、マルウェア解析などそれぞれ別の観点からセキュリティ脅威を学ぶことができる。また、講義内容を見て、深い技術を学びつつそれをインシデントレスポンスやフレームワークに落とし込み、より実務的な経験ができると感じた。

全国大会に期待すること

私は全国大会を通して、情報セキュリティに関して切磋琢磨できる仲間と出会いたいと考えている。 特にReverseの分野は、これまで独学のような形でCTFや書籍など学んできた。しかし、独学では知識の広がりや学ぶモチベーションの波など問題がある。そこで、全国大会では切磋琢磨できる仲間と出会い、セキュリティ・キャンプ全国大会の期間だけではなく、始まる前の期間や終わった後での交流を継続的に行いたいと思う。

問2

今までに解析したことのあるソフトウェアやハードウェアにはどのようなものがありますか？解析の目的や解析方法、結果として得られた知見などを含めて教えてください。(2000文字以内)

Crackmeの解析

Crackmeはリバースエンジニアリングの勉強目的で解析を行った。 Crackmeでは主にGhidra・IDAを用いて静的解析を行った。 その解析を行ったのは1,2年前であるため、正確な内容かどうかわからないが確か入力に対してパスワードを入力するものだった。 Ghidraで解析した際にはSymbol Treeのfunctionから怪しい関数名を探すことや逆アセンブル・逆コンパイルなどについて学ぶことができた。

BadUSBを用いたWindowsイベントログの解析

以前SECCON電脳会議に参加した際にHayabusaを用いたWindowsイベントログ解析を行った。 その解析が面白かったため自分でもWindowsイベントログの解析を行った。 自分で行った際には、BadUSBをArduino Microで自作し、BadUSBを差したときのイベントログとSSDなど正規のUSBを差したときのイベントログを比較して、BadUSB独自の挙動が見つけられるか実験した。 BadUSBは差すと特定のWebサイトに飛ぶというものを作った。 結果としては、BadUSBと正規のUSBの違いを見つけることはできなかった。 USB自体の抜き差しなどはログとして見ることはできたが、それがよくない正常ではない挙動をしているのかどうかは自分の調査では特定できなかった。

この応募課題を見てCTF以外の解析を行ったことがないと気付いたため、Udemyのファームウェア解析に取り組んだ。 解析方法は、Linuxのコマンドで行った。 やっていて面白かったところは、binwalkコマンドでメインファイルであるbinファイルを解析したところだ。 binwalkコマンドを使用して、ブートローダーのオフセットの位置やSquashFSというファイルシステムのオフセットの情報を得ることができた。 丁度この応募課題でファイルシステムについて勉強していたため、繋がっているように感じて面白かった。 また、このファイルシステムをマウントして中身を調べた。 busyboxをreadelfで見てアーキテクチャが判明したり、/etc/passwd.bakファイルをJohn The Ripperでパスワード解析を行ったりした。 新しい学びが多く、この応募課題をやり終えたら続きをやるつもりだ。

NTLMハッシュ解析

ペネトレーションテストの勉強をしていたときに、WindowsのNTLMハッシュの解析を行った。 Windowsはパスワードを保存する際にパスワードをそのまま保存するのではなく、パスワードをハッシュ化してそれを保存している。 パスワードハッシュはレジストリに保存してあり、この時は自分のWindows10のパスワードハッシュを取ってきてKali Linuxへ移した。 パスワードハッシュを解析するために、John The RipperとKali Linux内のrockyouを使用した。 自分のWindowsのパスワードはある程度強固な自信があったが、5秒程度で解析でき、解析したものも自分のパスワードで合っていた。 パスワードハッシュさえ手に入れれば、こんなに簡単にパスワード解析できるのかと感じた。 また、BadUSBと組み合わせたら大きな脅威になると感じた。

Azusawa’s Gacha World(Project SEKAI CTF 2023)

CTFのRev問題で一番印象に残っている問題だった。 Unityでビルドされた問題が渡され、実行するとスマホゲームのガチャのような画面が出てきた。 画面が本当のゲーム画面の様で、今までゲーム画面のようなRevの問題を解いたことがなかったため凄く驚いた。 内容はガチャのトップレアの排出率が絶対出ないような設定になっており、Reverseしてその絶対出ないようなガチャの排出率をいじってレアキャラを出すというものだった。 UnityのRevもやったことがなかったので、当時はこの問題を解くことができなかった。 Writeupを見て解くことができなかった理由がわかり、DnSpyというツールでdllを編集した際はDnSpyからそのファイルをRemoveする必要があったようだった。

問3

今までに作成したソフトウェアやハードウェアにはどのようなものがありますか？ どんな言語やライブラリ、パーツを使って作ったのか、どこにこだわって作ったのか、などたくさん自慢してください。(2000文字以内)

諸事情により(略)

問4

ここ数年に発表された、以下のキーワードに関連するニュースや記事や学術論文から1つ選び、それに関して調べた内容を記述してください。内容には、1.選んだ理由、2.技術的詳細、3.被害規模または影響範囲、4.対策、の4点を必ず含めてください。なお、対策は今ある技術のみに捕われず、将来的な技術や法律など、自由な発想で書いてください。 (2000文字以内)

キーワード：

  • 脆弱性
  • マルウェア
  • エクスプロイト
  • サプライチェーン
  • 国家支援型攻撃

2023年11月27日に発表された、LINEヤフー株式会社が受けたサプライチェーン攻撃

1.選んだ理由

キーワードを見たときに、あまり自分で調べたことのなかった「サプライチェーン」と「国歌支援型攻撃」が気になった。「サプライチェーン」の単語を見た際に、以前セキュリティニュースでLINEヤフーがサプライチェーン攻撃を受けたことを思い出したため、詳しく調べてみようと思ったから。

2.技術的詳細

LINEヤフーの関係会社である韓国企業のNAVER Cloud社の委託先企業の従業員の所有するPCがマルウェアに感染していた。 そして、NAVER Cloud社とLINEヤフー共同で扱っていた認証基盤で、社内システムへのネットワーク接続を許可していたことから、不正アクセスを受けた。

時系列(JST)

  • 2023年9月14日: LINEヤフーの社内システムへの不正アクセス開始
  • 2023年10月17日: 不正アクセスを検知し、調査開始
  • 2023年10月27日: 外部からの不正アクセスである蓋然性が高いと判断 不正アクセスかもしれない従業員のパスワードリセットし、アクセス経路と推測される関係会社からのアクセスを随時遮断
  • 2023年10月28日: 従業者の社内システムへの接続について再ログインを強制実施
  • 2023年11月27日: ユーザーおよび従業者等への通知

3.被害規模または影響範囲

ユーザーに関する情報

  • 個人データ: 302,980件(日本ユーザ: 130,192件)
    • 通信の秘密に該当する情報: 22,239件(日本ユーザ: 8,982件)

取引先等に関する情報

  • 個人データ: 86,211件
    • メールアドレス: 86,071件
    • 従業員の氏名,所属,メールアドレス等: 51件
    • 氏名,メールアドレス: 7件
    • Slackプロフィール情報: 82件

従業員等に関する情報

  • 個人データ: 130,315件
    • ドキュメント管理システム内の個人データ: 6件
    • 認証基盤システム内の個人データ: 51,347件
      • LINEヤフー,LINEヤフーグループ会社: 30,409件
      • NAVER社,NAVER社グループ会社: 20,938件
    • 社内コミュニケーションに係るサービスシステムの個人データ: 78,962件

4.対策

LINEヤフーの公表した対策

  • 社内システムで共通化しているNAVER Cloud社との従業者情報を扱う認証基盤環境の分離
  • ネットワークアクセス管理を強化
  • 委託先の安全管理措置の是正
  • 計画の妥当性・有効性・客観性の担保を目的として外部企業を交えた計画策定

自分が考えた対策

  • システムをゼロトラストにする 今回は認証基盤の社内アクセス権限を委託先に与えていたことが原因の一部である。LINEヤフーの対策として認証基盤の分離が挙げられていたが、ゼロトラストへ移行することによって委託先の人でも簡単にはアクセスできないようにすればいいのではないかと考えた。
  • グループ企業,委託企業に標的型攻撃メール訓練を行う 今回のインシデントが起きた理由に、関連会社の委託先従業員のPCにマルウェアが感染してしまったというものがある。 どのように感染したか、は不明であるが標的型メールでマルウェアをダウンロードしてしまったという形が一番可能性が高いのではないかと考えている。そのため、親会社・関連会社が定期的に標的型攻撃のメール訓練を行うことによって、実体験として記憶に残るため効果的ではないかと考えた。

問5

ポートスキャンに関して、次の各問に回答してください。

問5-1

TCPのポートに対するポートスキャンの方法には、TCP SYNスキャン、TCP Connectスキャンが知られています。それぞれの動作原理を説明してください。 また、これらの手法には互いに長所と短所が存在します。 TCP SYNスキャンとTCP Connectスキャンのそれぞれの長所/短所を動作速度や検知されやすいかという観点から述べてください。

TCP SYNスキャンの動作原理

TCP SYNスキャンでは、3ウェイハンドシェイクを利用して、ポートが開いているかを確認する。 TCP SYNスキャンの特徴は、3ウェイハンドシェイクを利用するがコネクションを確立せず、送信先からの返答によりポートの開閉を判断するところだ。 送信元と送信先とのやり取りは、以下のものになる。

  1. 送信元：接続したいポートにSYNパケットを送る
  2. 送信先：ポートが開いている場合にはSYN/ACKパケットを送信元に返し、ポートが閉じている場合にはRSTパケットを返す
  3. 送信元：送信先から返ってきた反応をもとにポートが開いているか判断する
  4. 送信元：送信先からSYN/ACKパケットが返ってきた場合はポートが開いており、RSTパケットや応答が無い場合はポートが閉じていると判断する

TCP Connectスキャンの動作原理

TCP ConnectスキャンもTCP SYNスキャンと同様、3ウェイハンドシェイクを利用して、ポートが開いているかを確認する。 TCP Connectスキャンの特徴は、3ウェイハンドシェイクでコネクションを確立して、送信先からの返答によりポートの開閉を判断するところだ。 送信元と送信先とのやり取りは、以下のものになる。

  1. 送信元：接続したいポートにSYNパケットを送る
  2. 送信先：ポートが開いている場合にはSYN/ACKパケットを送信元に返し、ポートが閉じている場合にはRSTパケットを返す
  3. 送信元：送信先からSYN/ACKパケットが返ってきた際には、送信先にACKパケットを送信する
  4. 送信元：送信先からSYN/ACKパケットが返ってきた場合はポートが開いており、RSTパケットや応答が無い場合はポートが閉じていると判断する

TCP SYNスキャンのメリット・デメリット

メリット

  • TCPコネクションを確立しないため、高速でスキャンをすることができる
  • TCPコネクションを確立しないため、匿名性が高い

デメリット

  • コネクションを確立しない明らかに怪しい通信を多く行うため、ファイアウォールやネットワーク型IDS/IPSなどに引っ掛かりやすい

TCP Connectスキャンのメリット・デメリット

メリット

  • TCPコネクションを確立するため、普通の通信との見分けが多少難しくなる

デメリット

  • TCPコネクションを確立するため、スキャンのスピードがSYNスキャンより遅くなる
  • TCPコネクションを確立するため、通信のログが残りやすくなる

TCP SYNスキャンとTCP Connectスキャンのスピード比較

この部分は課題に含まれていないが、単純に気になったので試してみた。 動作はNmapのScanMeを用いた。コマンドは以下のものを試した。

nmap -sS http://scanme.nmap.org/

nmap -sT scanme.nmap.org

SYNスキャンは1つのIPアドレスをスキャンするのに14.42秒、Connectスキャンは15.75秒掛かった。

問5-2

RustScanやMASSCANなど、Nmapより高速にスキャンを行えるポートスキャナが台頭しています。 しかし、ポートスキャンを高速に行うと問題が生じる場合（特に社内/学内などの内部ネットワークを対象とする場合）があります。 具体的な影響の例とともに考えられる問題点を述べてください。

高速なポートスキャンを行うと、ネットワークやサーバに負担が掛かることが予想される。 特に、内部ネットワークでは社内システムや実験環境など、大量アクセスによるネットワーク・サーバ負担は考慮されていない設計になっていることが多く、予期せぬサービス停止が起こる場合が考えられる。内部ネットワークは外部ネットワークと比べて、空いているポート数も多いと予想され、より大きな負担が掛かる。

MASSCANのGitHubのREADMEにも、高速ポートスキャンによってネットワークに負担が掛かる「Thus, your default behavior will overwhelm the target network. Networks often crash under the load that masscan can generate.」と記述されていた。

問6

配布したアーカイブファイル内のimage.ddはディスクをddコマンドでコピーしたイメージファイルです。これらを用いて以下の問題に簡潔に解答してください。

問6-1

イメージファイルimage.ddに存在するファイルシステムをmountコマンドまたは同等の機能を持つユーティリティでマウントできるようにしてください。 その過程でイメージファイル内のどの部分をどのように変更したのか、なぜそれでマウントできるようになるのかを簡潔に解答してください。

image.ddの0x100438バイト目を「00」から「53」へ、0x100439バイト目を「00」から「EF」へ変更した。

まず何をやればいいのかわからなかったため、FTK Imagerで見えていたGPTパーティションが怪しいのでないかと思い、調べた。 Filesystem MetadataであるBackup GPT HeaderやPrimary GPT Headerなどのバイナリを見て、違う箇所を探したりBackupでGPTパーティションを上書きなどしてみたがマウントできるようにならなかった。 その後、バイナリエディタで中身を見たり、Linuxコマンドのfileやfdisk、gdiskなどを片っ端から試したりなど手あたり次第できそうなことをやった。 fsckコマンドでimage.ddを調べていると「Bad magic number in super-block」や「Could this be a zero-length partition?」という文章が出てきて、スーパーブロックのマジックナンバーの部分が「0」で置き換わっているのではないかと考えた。
そしてextのファイルシステムについてWeb(https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout)で調べたところ、マジックナンバーが「0xEF53」で、オフセットが「0x38」だった。0x100400バイト目からスーパーブロックが記述されていたようだったため、マジックナンバーをリトルエンディアンの形に直した「0x53EF」を0x100400＋0x38した0x100438バイト目を上記のように書き換え、マウントすることができた。

問6-2

問6-1でマウントしたファイルシステム形式の名称（例:FAT16）と、そう判断した理由を簡潔に解答してください。

Autopsyを用いてimage.ddの中身を見た際に、削除されたファイルの中に「f0033864.ext」や「f0033872.ext」などのファイルが見つかった。 また、fsckコマンドでスーパーブロックのオフセットを計算して出てきたアドレスである「0x100000」バイト周辺のバイナリとextのファイルを解析した記事にでてきたバイナリが、似たような構造をしていたため、一旦ファイルシステムは「ext」ではないだろうかという仮説を立てた。 そこで、問6-1に記述した箇所を書き換えたことにより、FTK Imagerでは「ext4」として認識され、「NONAME」直下にrootディレクトリが表示された。root以下のディレクトリも確認することができ、txtファイルやHTMLファイルなども表示されたため、このファイルシステムは「ext4」だと判断した。 mountコマンドでもFTK Imagerと同じように認識させることができた。

問6-3

イメージファイルimage.ddに存在するファイルシステムをマウントしてもそのままでは通常の方法で中身を参照（マウントしたOS上でファイルをダブルクリックするなどして、ファイルのフォーマットに対応したアプリケーションで中身を表示）できないファイルが存在します。そのファイルを、マウントしたOSから通常の方法で参照できるようにしてください（※ファイルを抽出するのではなく、参照ができる状態に戻してください）。 その過程でイメージファイル内のどの部分をどのように変更したのか、なぜそれで参照できるようになるのかを簡潔に解答してください。

mountしたもので、中身を参照できなかったファイルが「jp-cr-deloitte-cyber-trends-and-intelligence-report-2023.pdf」というPDFファイルだったため、これを参照できるように目指した。しかし、求められた状態にすることができなかったため調べたこと、考えたことを記述する。

ext4では、ファイルやディレクトリを管理するためにinodeというものを用いている。 私はこのPDFデータが保存されているメモリとinodeがPDFデータを参照する際のメモリが違うため、上手く参照できていないのではないかと考えた。 mountできるようにしたimage.ddをFTK Imagerで読み込んだところ、ファイルシステムのメタデータで「inode bitmap」と「inode table」というものがあった。 ext4のドキュメントを読むと「inode bitmap」はinode tableのエントリ使用状況を表しているだけのようなので、「inode table」に焦点を当てた。 「jp-cr-deloitte-cyber-trends-and-intelligence-report-2023.pdf」と同じディレクトリにHTMLファイルが置かれており、そのinode番号を調べた。 「ls -li」コマンドで調べると「Cyber Intelligence Center_ Services_ Cyber Security _ Deloitte Japan _ Tohmatsu.html」はinode番号が18、「Deloitte Tohmatsu Cyber LLC _ Deloitte Japan.html」はinode番号が19だった。 以上からinode番号17 or 20のinode tableの部分のどこかしらを書き換えればいいのではないかと考えた。

問7

今後、より重要になる思われる技術（製品等でも可）の中で、あなたが攻撃の対象として興味深いと感じるものを1つ挙げ、次の設問に回答してください。すべての設問において技術的な回答を期待しています。

問7-1

選んだ技術はどんなものですか？

Bluetooth

Bluetoothの種類

Bluetoothとは近距離無線通信技術の一つだ。Bluetoothと言っても、2種類の通信方式がある。 1つ目は、Bluetooth Classicだ。Bluetooth Classicは、主にワイヤレスヘッドホンやワイヤレススピーカーなどのオーディオ分野でよく使われている。 2つ目は、Bluetooth Low Energy(BLE)だ。BLEは、主にウェアラブルデバイスやキーバードなどのバッテリー駆動のアクセサリでよく使われている。 この2種類の通信方式をまとめてBluetoothと呼んでおり、Bluetooth ClassicとBLEは通信方式が異なるため、互換性は無い。

周波数帯について

Bluetoothは、2.4GHz帯を使用している。そのため、2.4GHz帯を使用している無線通信規格(電子レンジ・無線LAN・RFIDなど)を同時に使用する場合には、電波干渉を起こす場合がある。 Bluetooth Classicでは2.4GHz帯の周波数を1MHzの幅で分割して80個のチャンネルとして使用する。一方、BLEは2MHzの幅で分割して40個のチャンネルとして使用する。

通信の仕組み

BLEでは親機のことを「セントラル」、子機のことを「ペリフェラル」と呼ぶ。 セントラルからの接続待ちの仕組みを「アドバタイズ」と呼び、アドバタイズはブロードキャスト通信を行う。 ペリフェラルがアドバタイズを発信し、セントラルがそのアドバタイズを受信することによって、機器の認識を行っている。 ペリフェラルはアドバタイズを発信した後に、セントラルからの接続要求が来ないか待機する。 セントラルからの接続要求が来た場合には、「GATT通信」と呼ばれる1対1の接続に切り替える。

ペアリングについて

Bluetooth使用時によく聞く「ペアリング」は必須のものではない。 ペアリングは、「お互いに共通の暗号化情報を保持すること」、「通信内容を暗号化すること」の2つの役割を持つ機能だ。 ペアリングの流れは以下のようになる。

  1. セントラルからペアリング要求を送信
  2. ペリフェラルがペアリング応答を返す
  3. 認証処理
  4. 暗号化情報を交換
  5. 暗号化された通信を行う

認証処理の際には、どのような認証方法を選択するか以下の中から選ぶことができる。

  • Just Works: ユーザーの操作なしに自動的に接続相手を認証

  • Passkey Entry: パスキー入力を求める

  • Numeric comparison: お互いに認証番号を表示してペアリングしようとしている相手が意図した相手か確認して認証

  • Out of Band: Bluetooth以外の通信方式を利用する認証

  • Bluetoothの脆弱性

    • BlueBorne
      • ペアリングせずにリモートで機器が乗っ取られる
    • KNOB攻撃(Key Negotiation Of Bluetooth Attack)
      • リンクキーをクラックする攻撃手法
    • BIAS攻撃(Bluetooth Impersonation AttackS)
      • リンクキー無しでペアリングされた機器になりすまし、ペアリングし、認証のマスターとスレーブを入れ替え、相手をスレーブとして動作させることが可能

問7-2

その技術が脆弱になり得るのはどんなときだと思いますか？

  • Bluetoothの暗号化について知らないとき Bluetoothはペアリングを行うことによって、通信内容を暗号化する。 しかし、このペアリングは必須のものではなく、ペアリングをしなくても通信を行うことができる。 このことを知らない人は、ペアリングをしなくても接続できるような設定で、機密情報をやり取りしてしまうかもしれない。

  • 暗号化をペアリング時のもののみにするとき ペアリングをすると、通信を行う際に暗号化されたものを送るようになる。 しかし、ペアリングを何らかの方法でバイパスされてしまうと平文のデータがそのまま見えてしまう。 そのため、ペアリングのみの暗号化に頼りすぎるのではなく、上位レイヤーでも暗号化を行う。

  • Bluetoothが受信されないことを前提にするとき ペリフェラルは基本的にずっとアドバタイズを発信しているため、機器を発見されないようにすることはできない。 そのため、知られたくない情報をやり取りする際は、第三者に接続される可能性があることを考えて、上位レイヤーで認証などを設けた方がよい。

  • IoT機器などでBluetooth自体をアップデートできない環境にあるとき Bluetooth自体にも脆弱性は見つかっており、そのたびにBluetoothのアップデートがかかる。 BluetoothがWi-Fiなどで更新できる環境にある場合はいいが、IoTでLPWAなどのローカルのネットワークのみで動作している場合、Bluetoothの更新を行うことができない。 アップデートしていなさそうなIoT機器にBluetoothの既知の脆弱性を狙われるということが考えられる。

  • 認証が甘いとき Just WorksやPasskey Entryなどの認証方式を利用していると、簡単に認証が突破される場合がある。 利用できるからと言って、セキュリティを甘くしない。

問7-3

その技術に対して攻撃することを考えたときに、思いつく障壁は何ですか？

  • ペアリング時の暗号化通信 通信を暗号化されると解析が難しくなる。 暗号化方式もBluetooth4.2以上では、楕円曲線暗号を用いた強力なものが使用されている。

  • 上位レイヤーでの暗号化や認証 Bluetooth自体の脆弱性を突いて攻撃できたとしても、それより上のレイヤーで対処されていれば情報を取得することができない。

  • 強固な認証方式 Numeric comparison認証を利用されると、お互いのデバイスで認証しなければならないため、攻撃成功までのハードルが上がる。

  • 得られそうな機密データの量・質 Bluetoothでやり取りされるデータで機密性の高いものは少ないと予想される。 得られるデータが大したことないということは、攻撃する上で障壁になり得ると考える。

  • Bluetoothの通信距離 Bluetoothの通信距離はモジュールにも依るが、10~300mほどとされている。 一般的に利用されているものはあまり通信距離は長くないだろう。 そのため、Bluetoothに攻撃を仕掛ける際はBluetoothの電波を拾える範囲にいなければならない。 物理的にBluetoothの周囲に近づけなければ攻撃することはできない。

問8

ELF ファイル “hack” について、以下の質問に解答してください。

ファイルを IDA 8 (Freeware version) でデコンパイルすると、このようなコードが出力されます。

int __fastcall main(int argc, const char **argv, const char **envp)
{
  if ( !strcmp("Reversing is cool.", "Reversing is fun.") )
  {
    if ( !strncmp("Reversing is cool.", "Reversing is fun.", (size_t)"Reversing is fun.") )
      puts("Nope.");
    else
      puts("Welcome to Security Camp!");
  }
  else
  {
    puts("What's wrong?");
  }
  return 0;
}

このコードを読むと、“What’s wrong?” という文字列が表示されることが予想されますが、このプログラムを実行すると、実際に出力される文字列は以下のように異なるメッセージが表示されます。

$ ./hack
Welcome to Security Camp!

この実行ファイルに用いられているトリックについて説明してください。
また、解答に至るまでの調査方法について記述してください。

方法を考えたが、確証のある方法が思い付かなかったため、考えた方法を記述する。

NULL終端文字

strcmp関数やstrncmp関数は、文字列をNULL文字(\0)があるかどうかを判別している。 そのため、strcmp関数の引数である文字列の途中でNULL文字を入れることによって、文字列の途中までの比較で終わらせることができる。 しかし、Ghidraでhackのアセンブリを見た際には、NULL文字が文字列に紛れ込んでいるのを確認することができなかった。 また、逆アセンブルされたコードを再現し、入力として途中にNULL文字を入れた文字列を渡すというものを行った。 最初の部分にNULL文字を入れることによって、Welcome to Security Camp!を表示させることには成功したが、その実行ファイルをGhidraで見たところ、hackとは違うアセンブリだったためこの手法は違うのではないかという結論に至った。

「MOV EDX ,0xd」によるstrncmp関数の文字列最大長設定

与えられたhackをGhidraで読み込んでアセンブリを見たところ、「MOV EDX ,0xd」というアセンブリがあった。 これはEDXに0xdが設定される命令だ。 ここで使用されたレジスタは、後に「MOV RDX ,s_Reversing_is_fun._00100907」という命令で「Reversing is fun.」という文字列が入った。 そしてそれをRSIにMOVしている。 このことから、文字列の13番目までstrncmpで比較されることになるのではないかと考えた。 その結果「Reversing is cool.」と「Reversing is fun.」は同じ文字列であるとみなされ、「Welcome to Security Camp!」が表示されると思われる。

strncmp関数の第三引数

strncmpの第三引数は、比較する文字列の最大文字数を指定する。 それが「(size_t)“Reversing is fun."」となっており、これはアドレスをサイズ型にキャストしたものになる。 そのため、本来は「Reversing is fun.」の文字数を第三引数に入れようとした操作だったが、間違えて大きい数字を引数としているためバッファオーバーフローなどが起きてしまったのではないかと考えられる。