DARK MATTER

CDI Engineer's Technical Blog

OTネットワークセキュリティ監視の資産管理と振る舞い検知が手軽に試せた - 元有償のパッシブ型監視ツールを適用した模擬制御システムを攻撃 -


OTセキュリティ業界ではネットワーク監視製品が賑わっています。特に、運用中の制御システムに影響を与えずに、通信パケットから学習を行い、資産(アセット)情報を自動抽出するとともに正常状態からの変化をアラートする製品を各社提供している様子がうかがえます。そんな中、無償のツールを探し回り比較したところ、商用並みのすごいツールに出会えたので紹介します。ちなみに上図のようにインターネットとの通信の様子をリアルタイム表示する機能もあるのでOTに限らずIT環境に適用しても面白いと思います。

はじめに

サイバーディフェンス研究所の安井です。長年制御システムを開発してきた経験から制御システムセキュリティ向上に取り組んでいます。
先に開催された2022年の重要インフラサイバーセキュリティコンファレンスでは、セキュリティベンダ各社より、通信パケットをキャプチャして解析し異常を検知しアラートする類の製品が紹介されていました。運用している環境に影響を与えたく無いというユーザへの現実解であり、この種のツールが普及してほしいと思っています。どのように有用なのか、試したい方も多いのではないでしょうか?
とはいえ、予算を確保し自組織の環境で製品比較しようとしても試用品が無い場合があったり、デモを見て比較しようにも短時間では比較ポイントがよくわからない事もあると思います。また、関心があっても予算的に手が届かないと感じている方もいるのではないでしょうか。

対象読者

OTネットワーク監視に関心があり、無償で試して基礎知識を得たい方。
OTネットワーク監視に関心があるが、予算がなく困っている方。
OT/IT問わず、ネットワークトポロジ作成や自動学習するネットワーク監視ツールに興味がある方。

できること

無償のOTネットワーク監視ツール入手先を知れる。
一般的なOTネットワーク監視の基本機能について、実例をもとにイメージできる。

本稿で紹介すること

1. OTネットワーク監視ツールの以下基本機能を有する無償ツールの紹介

  • 運用への影響を与えないため、Passiveなパケットキャプチャから監視ができる
  • アセット一覧とネットワークトポロジを自動生成できる
  • 一定期間の自動学習と、学習後の変化を参照できる

2. 適用事例として、工場制御システムを用いた、アセット把握と、攻撃試行時のアラート結果の紹介

youtu.be
適用事例紹介に用いる工場制御システム

言及しない付加価値的な機能

本稿では触れませんが、各社の商用の製品は、以下に列挙したような様々な付加機能を持っているものがほとんどだと思います。

  • OTに特化したプロトコルの対応
  • SignatureベースのIDS機能
  • 各種ノードにアクセスして情報収集するActiveな監視機能
  • FWなどの防護製品とのインシデント対応連携機能

自組織において、これらの機能が必要か判断するためにも、まずは今回紹介するツール等を使って基本機能を把握してみる事から始めると良いのではないかと思います。

有償ツールの比較は行いません。

有償のツールは各社から販売されており、これらのツール使用比較レビューを求められている方もいると思います。私自身、ある製品の検証をした事もあり、各社の製品を自社のサイバー攻撃検証用の環境に適用したいとも思っているのですが、予算的に複数ツールの購入には踏み切れず、じっくり比較した経験はありません。限られた経験における偏った情報を提供することは避けたいため、今回は有償ツールについては言及しません。
なお、上記のとおり筆者は個別製品の専門家ではありません。本稿を読んで、うちの製品は、こんな実用的な素晴らしい機能があるという事など教えていただけると助かります。また、更に、製品を貸してもいいよというベンダ様がいましたら声をかけていただけると幸いです。

無償ツールを探してみる

ここからは、無償で手に入るツールを比較します。とはいえ、この手のツールで無償のものはあまり見当たりません。そのような中、ICSサイバーコミュニティにて入手した情報から、NSA(National Security Agency:アメリカ国家安全保証局)のGRASSMARLINと、Dragos社のCYBERLENSおよびSOPHIAを紹介します。なお、その他にも各社商用ツールの試用版など制約の元利用できるツールもあるとは思いますが、それらについては取り上げていません。

GRASSMARLIN

github.com
GRASSMARLINはNSAが提供しているツールであり、自動学習機能は無いですが、OTセキュリティの世界では草分け的な存在なので参考として紹介します。興味ない方は読み飛ばしてください。
2017年前後に開発されていたものであり、キャプチャしたパケットからアセットの情報を表示するツールです。代表的な機能としてはIPv4アドレスでのネットワークトポロジを表示することができます。現在世の中で流通している多機能なツールと比較すると機能が限定されている感は否めません。しかし、2017年当時を振り返ってみると、セキュリティ対策への関心が今ほど高いとは言えなかった当時のOT業界の方達へツールを無償で提供し、世界中の多くの方へ、OTセキュリティ対策の第一歩である「アセット把握」を後押しした意義あるツールだったのではないかと想像します。

今でもIPv4での野良サーバの発見程度の目的であれば十分使えると思うので、手軽に利用できますし興味ある方は使ってみると良いと思います。Linuxをインストールしたことがある方であれば、2時間もあればインストールして、マニュアルを軽く読みながら使えるようになると思います。一定時間パケットキャプチャしたPCAPファイルを読み込ませれば、自動でネットワークトポロジを作成してくれます。試しに、工場制御システムのネットワークに適用した例を下図に示します。

工場制御システムのネットワークトポロジ

自動で生成されたネットワークトポロジに対し、見やすいようにノードの位置を手動で配置し直したものです。
左から、SCADA HMI(192.168.100.205)、SCADA Server(192.168.100.204)、Soft PLC(192.168.100.202)、仮想工場(192.168.100.112)の4つのIPアドレスが抽出され表示されているのがわかります。残り2つの224.0.0.251,239.255.255.250はマルチキャストの宛先IPアドレスです。224.0.0.251はホスト名解決に使用するMDNS(multicast DNS), 239.255.255.250はプリンタなどを識別するSSDP(Simple Service Discovery Protocol)であり、OSのデフォルトインストール状態では有効となっていますが工場制御システムには不要なものです。この事から、このシステムでは必要な通信だけに限定するセキュリティ対策までは行っていないのだなぁという事が読み取れます。

Dragos のICS Cybersecurity Community向けツール


www.dragos.com

Dragos社は、OT/ICS向けのサイバーセキュリティに特化した会社であり、2019年に競合のNexDefense社を買収した際に、もともと商用であったDragos社のCYBERLENSとNexDefense社のSOPHIAを無償公開しました。なお、現在Dragos社はこれとは別に有償製品を販売しているので、今回紹介するCYBERLENSとSOPHIAは最新の有償製品と同等のツールというわけではないことは承知おきください。

Dragos CYBERLENS

CYBERLENSで工場制御システムのネットワークトポロジを表示したものを下図に示します。見やすいようにノードの位置を手動で配置し直してあります。

工場制御システム

IPv4アドレスだけでなくMACアドレスも表示していることがわかります。学習した内容をスナップショットとして保存しておき、その後の変化を表示する機能もあります。下図は、スナップショットを保存した後、IPアドレスを振っていない不正な端末をネットワークに接続し、スナップショット採取時との変化を表示したものです。

不正な端末接続後

MACアドレス(08:00:27:3c:bc:93)が新たに登場したことがわかります。
商用だっただけありインストールは簡単で使い方も直感的にわかりやすいので、さくっと試して見てください。次に紹介するSOPHIAの方が機能豊富であるため、CYBERLENSの紹介はここまでにします。

Dragos SOPHIA

これはすごい!! もともとNexDefense社の商用製品であり、機能はもとより見た目や使い勝手も含めしっかり作り込まれている感があります。
アセット把握だけでなく、学習後の変化を容易にわかりやすく表示する機能があります。具体的には以下がDashboard画面ですが、上部のベルマークのAlertsの中に、「Baseline Deviation」という項目があり、ある時点までの通信状況を凍結したBaselineを作成しておき、Baseline作成時点からの変化発生数を表示することができます。

ダッシュボード画面

もちろんネットワークトポロジも表示できます。以下は工場制御システムのネットワークトポロジです。見やすいようにノードの位置を手動で配置し直してあります。

ネットワークトポロジ

ちなみに、一番右端のノードがIPアドレスでなく(04-ab-18-3b-74-6e)とMACアドレスが表示されているのは、学習開始してから十分時間経過していないときに表示したためであり、この後1日放置した後に確認したところIPアドレス192.168.100.112に変わっていた事を補足しておきます。

本稿では触れませんがFreeのIDSとして有名なsnortやsuricataのルールを取り込んで異常検出する機能もあります。

余談ですが、これだけの物をICSのCommunityに無償で提供してしまうところに、Dragos社の心の広さと現在の自社製品への自信をうかがわせます。このように古い世代の製品を無償提供して業界や社会に貢献するとともに、自社の評判を高めるというのは、スタートアップ企業にとってもユーザにとっても両者WinWinの面白い戦略だなぁと思います。

不正な端末をネットワークに接続して攻撃試行したときの検出結果

ここからは、学習後の変化を表示する機能がどのように有益かイメージしてもらうために、代表的な攻撃シナリオとして、Dragos SOPHIAで監視しているネットワークのスイッチの空きポートに不正な端末(以降、攻撃者端末とも表記)を接続してネットワーク上を探索したときの結果を紹介します。
以下、時系列シナリオ風に攻撃側[Red]と防御側[Blue]のそれぞれの人物の思考と行動イメージで記載します。

不正な端末を接続して攻撃試行

[Red]攻撃者端末をネットワークのスイッチの空きポートに接続します。まずは、当該ネットワークの情報はわからないので、IPアドレスは割り当てずに流れてくるパケットを盗聴します。下図の左下のように、攻撃者端末をスイッチの空きポートに接続したイメージです。

工場制御システムに不正な端末を接続した図

[Blue]SOPHIAのDashBoardをみると、Alertsが増えている事がわかります。

ダッシュボードにアラートが発生

[Blue]Alertsの詳細を見ると新たなMAC addressが出現しています。

Alertsの詳細に新たなMACアドレスが出現

[Blue]ネットワークトポロジで、正常時との変化を差分表示して見ると、やはり新たなMACアドレスが出現しています。

あらたなMACアドレスの端末が出現している

[Blue]たぶん、また誰かが勝手に野良端末をつなげたんだろうな?でも、もしかしたらサイバー攻撃かも?

[Red]スイッチの空きポートに攻撃者端末をつなげてキャプチャしただけなのでユニキャストのパケットは採取できません。ユニキャスト以外のパケットはキャプチャできているので、採取したパケットキャプチャを解析し、マルチキャストやブロードキャストのパケットの送信元IPアドレスからネットワークセグメントが(192.168.100.0/24)であると予想できます。
[Red]ネットワークにつながる機器を見つけたいので、攻撃者端末に適当に空いていそうなIPアドレス(192.168.100.106)を割り当て、ポートスキャンツールのnmapを使ってarpプロトコルで当該セグメント(192.168.100.0/24)に存在するホストを探索してみます。

[Blue]SOPHIAのDashBoardをみると、500以上のAlertsが増えている事がわかります。

ダッシュボードのAlertsが更に500以上増えている

[Blue]Alertsの詳細を見ると、先ほどのMAC addressの端末から多量の宛先に対してarp通信が発信されていることがわかります。

Alerts詳細では多量のarp通信が発生している

[Blue]ネットワークトポロジで正常時との差分を見ると、緑の枠で表示された192.168.100.106の端末が出現しており、そこから4つの装置に対して緑の線で示した新たな通信が発生していることがわかります。

ネットワークトポロジに新たな端末が出現し新たな通信が行われている。

[Blue]これは、サイバー攻撃を意図した偵察が行われていそうだ!!

[Red]この後も様々な攻撃を施行しましたが、詳細は割愛します。
[Blue]その後、様々なAlertsを検出していました。ここまでAlertsが発生しているということは、不正な端末はサイバー攻撃を意図して接続されていることが間違いなさそうです。

その後の攻撃後のDashboard


いかがでしょうか? 学習後の異なる振る舞いを検知するツールでどのような事象が検知できるかの一端をイメージいただけたのではないでしょうか?
インターネットと直接接続しないOTのネットワークにおいては、特定の宛先との特定のプロトコルでの通信しか流れておらず精度の高い学習ができる環境の場合が多いのではないでしょうか?そうであれば、この手のツールが、サイバー攻撃の兆候を発見するのに大きな役割を果たせそうなことがイメージできると思います。

補足 必ず検出できるのか?

攻撃シナリオの最初に攻撃者端末を接続したときにSOPHIAのアラートが検出されたのは、攻撃者端末から何かしらのパケットが発信されたためです。また、その後、500件ものアラートを検出したのは、攻撃者が、ネットワーク監視製品がある事を知らず、派手に探索を行ったためです。
もし攻撃者が、ネットワーク監視製品での検出を逃れるために、Baselineに登録された通信だけを使って高度な攻撃をしかけたら、発見できなかったかもしれません。

とはいえ、攻撃者がBaselineに登録済みの通信を全て推測することは、頻度も含めた詳細な通信設計情報を事前に入手しておくか、どこかしらのサーバ内に侵入して通信パケットを解析しておくなど、非常に難易度の高いハードルをクリアしておかないことには困難でしょう。

この補足は、あくまで、このツールを入れればどのような攻撃でも発見できるという訳ではない事を知ってもらうために書いたものです。

SOPHIAのリアルタイム表示機能

SOPHIAには、リアルタイムにパケットの流れをアニメーション表示する機能があります。以下は、工場制御システムで不正な端末によるネットワーク探索が行われた後の状況を示したものです。

リアルタイムにパケットの流れをアニメーション表示

中央の濃い赤の箱で示した192.168.100.0/24のセグメントの4つの装置間で通信している様子が表示されています。とくに密度が高い緑で表された部分が、PLCと仮想工場間の通信であり、ここで非常に頻繁な通信がおこなわれていることがわかります。
なお、ここでは、多量の透明の箱が表示されていますが、これは、右上隅の濃い赤の箱の攻撃者端末からnmapで当該セグメントの全アドレスあてに探索を行なったため、セグメントのすべてのIPが透明の箱で表示されてしまったものです。正常状態であれば、透明な箱は出現しないので、このような多量の透明の箱が出現する事が異常という認識さえあれば、この画面からも異常に気づくかもしれません。

参考
今回の工場制御システムはインターネットと接続がない環境でしたが、インターネットと接続する環境に適用すれば、インターネット上の相手とのやりとりもリアルタイムで表示します。
下図は、インターネットと接続したネットワークにSOPHIAを適用し、日本のあるサイトから巨大なファイルをダウンロードしているときの様子です。

インターネットとの通信を表示している様子

実際に運用するまでに必要な事

今回Dragos SOPHIAを使って、OTネットワーク監視の基本機能を紹介しましたが、パケットキャプチャによる通信監視をしたことがない方へ、この手のツールを使うときに考慮しなければならない事を簡単に列挙しておきます。

  • パケットキャプチャする箇所の決定
  • パケットキャプチャする方法の決定
  • ツールのインストールと設定
  • ツールが検出したアラートの解釈
  • 対処体制の整備(マネジメント系の話題で重要ですが本稿の範囲外なので割愛します)

これらのうち、実運用する上では、最後の「ツールが検出したアラートの解釈」が最もハードルが高いかと思います。ここについて、頑張ってサイバー攻撃の技術について学習するか、内外で相談できる専門家とのつながりを確保するか、そもそも問い合わせ窓口を持つ有償製品を適用するかなどの検討が必要と思います。
例えば、サイバー攻撃でなくとも機器の故障での交換時や、不注意の保守員の行動などで、通常と異なるパケットが送信されることはよくあることです。結局は、運用する方がある程度の正常・異常判断をしなければならなくなります。これがどれだけの難易度なのかは実際使ってみた方でないとわからないと思います。自分達にとってどれだけ大変か簡単かを見極める意味でも、この手のツールをまずは使ってみる事をお勧めします。

ある程度の予算がある組織の方は、それなりのコストを払って製品適用と運用を行う事が無難と思います。予算が少ない組織の方は、今回紹介したツールだけでも適用しておき、アラートがでるようならどこかに相談するという方針とするだけでも何もしないよりは断然安心できると思います。

無償・有償に関わらず、各種ツールを提供している方達もコストが掛かっていることは間違いないですし、アラート内容の分析にもコストはかかる物ですので、世の中を安全にするためにもそれぞれがある程度のコストは負担して、制御システム業界に関わる皆がハッピーになってほしいと思っています。
とはいえ、使った事がない方にとってはどの程度のコストがかかるのか、自分達に見合った運用ができるのか想像もつかない方も多いのではないでしょうか?そういう意味でも、今回紹介したような無償ツールが提供されている事は、制御システム業界の方達にとって非常に有意義だろうなぁと思います。

なお、「ツールのインストールと設定」に関しては、製品毎に事情も異なると思いますし高度な事を実現しようと思えば難しくなるのが一般的とは思います。一例としてDrago SOPHIAを例にとると、Linuxをインストールすることができる方であれば、マニュアルに従えばインストールできますし、設定についても1,2日試行錯誤すれば、今回紹介した最低限の機能は使えるようになると思います。英語が苦手な方も翻訳ツールでなんとかなると思います。

まとめ

OTネットワーク監視ツールがどのような事ができるものか、元商用品が無償公開されたDragos SOPHIAを使って紹介しました。

一度、どこかのネットワークに適用し気軽に試してみると、自分達に、あと何が必要なのかがみえてくるかもしれません。
興味をお持ちの方は、ぜひ一歩踏み出してみてください。思ったほどハードルは高くなかったと思うのではないでしょうか。

注:本稿は、特定の製品を推奨するものではありません。

国際地域対抗CTFのICC2022に参加しました

こんにちは、技術部の前田です。

ICC2022というCTFの地域対抗の国際大会にCTFプレイヤーとして参加したのでその一部始終や簡易Writeupを報告します。

はじめに

International Cybersecurity Challenge (ICC)はICC委員会が主催するCTF大会です。 ICC委員会は世界の各地域を統括する団体から構成され、2022年度はアフリカ、アジア、カナダ、ヨーロッパ、ラテンアメリカ、オセアニア、アメリカの7地域の団体が参加しました。 開催されたCTFへもこれらの7つの地域から1チームずつが参加しています。

このICC2022は今年度が初開催のイベントで、ギリシャのアテネで開催されました。 ヨーロッパでの開催なので、ICCの他にヨーロッパチームをバックアップするENISAもICC2022の主催として参加しています。 なお2023年も開催されることが決まっていて、既に次の予選が目前に迫っている地域もあります。

アジアチームについて

アジアチームはAsian Cyber Security Challenge (ACSC)という団体がCTFによる予選会を開催し、その中の成績優秀者8カ国15名から構成されています。 出場可能な選手には年齢制限が設けられており、1995年1月1日以降の生まれの人が参加できます。

  • インド: 2名
  • 日本: 3名
  • マレーシア: 1名
  • シンガポール: 2名
  • 韓国: 2名
  • 台湾: 1名
  • タイ: 1名
  • ベトナム: 3名

他の地域、特にヨーロッパやアメリカは15人以上のメンバーを集めて2次選抜を行ったり、メンバーが決まった後にCTFの練習などをしたそうですが、アジアチームでは特にそのようなイベントはありませんでした。 アジアチームの特徴としてメンバーの分布範囲が広く、集まって何かをするのは難しかったのと、更にはコロナ禍の状況も相まって気づいたら本戦が目の前にあったという印象でした。

というわけで、アジアチームは現地アテネで初顔合わせとなりました。 時差ボケ対策やメンバー間の交流を深めるため、ICC2022自体の開始と比べると丸2日ほど早く現地入りしました。 その空きスケジュールを利用してギリシャ入り初日はアジアチーム全員集合して顔合わせ兼食事会、翌日は日本勢と台湾・タイ勢と共にアテナイのアクロポリスへ観光に行きました。 私は大勢の人を一気に覚えるのは苦手なのですが、この期間のおかげで徐々にメンバーを覚えられたので助かりました。

Jeopady (1日目)

JeopardyはオンラインCTFなどでもよく採用されるルールで、十数問〜数十問の問題が用意され、解いて得られるフラグを提出すると1問ごとに得点を入手できます。 この日は朝9時から夜18時までの9時間で競技が行われました。

昼食休憩等は特になく、代わりに常時ビュッフェスタイルで軽食が提供され、好きなときに取りに行って食べる形式でした。 トイレ等で離席する帰りに取って来られるのはとても便利で、さらに串に刺さっている料理や一口大のトルティーヤが食べやすかったため、競技中はそればっかり食べていました。 また、飲み物もカウンターで注文するとすぐに受け取れるようになっていました。

ビュッフェではクッキーやフルーツも提供されていました

CTFでは基本の5ジャンル(Forensic, Reversing, Pwnable, Crypto, Web)から35問の問題が出題され、更にハードウェアで7問、脱出ゲーム形式のESCAPE ROOMチャレンジも出題されました。 これらの内容は事前に告知されており、特に基本5ジャンルについてはそれぞれの出題割合も公開されていました。

得点形式にはDynamicScoringが採用されていました。 DynamicScoringでは問題を解いたチーム数が多いほどその問題は簡単だったとみなして得点を低くします。 この得点の計算式がかなり厄介で、4チーム解くだけで点数が元の半分以下になってしまうため、どれだけ単独に近い状況で問題を解けるかが鍵になっていました。

私が主に担当したCryptoジャンルでは、暗号の学習プラットフォームであるCryptoHackの運営陣が作問に入っており、高難易度の問題が多数出題されました。 Cryptoジャンルの問題は7問出題されましたが、そのうち解かれた問題が2問しかなかったことがその難しさを物語っていると思います。

私はその中でもUnbalancedという「p,qのビット数が異なるRSAに対するSmall private exponent attackを行え」という問題にチャレンジしました。 この手の問題は既に論文が発表されていて、それを実装すると解けるというタイプの問題です。 すぐに攻撃を行う論文を見つけ実装してみましたが、理解力の甘さやミスが重なり、最終的に解くことはできませんでした。

Hardware Challenge

前述のUnbalancedが行き詰まってしまったため、代わりにハードウェアの問題に取り組み3問を解きました。

ハードウェアとは言っていますが、実際にはESP32上で動作するMicroPythonからハードウェア上に隠されたフラグを探し出すという形式で、真にハードウェア的なハックは要求されませんでした。

1つ目の問題は下のようなコードが提供された上で、「EFUSE_BLK2からデータを読みだせ」という問題でした。

def secure_read_efuse_block(block, start_offset, length):
    if block == efuse.EFUSE_BLK2 and length > 0:
        print('No access allowed to secure efuse region!')
    else:
        length = length if length > 0 else 256

最初はそもそもこの関数を使わずにeFuseからデータを読み出せばいいと思い試行錯誤していましたが、よく見るとlengthに負数を入れるとif文をバイパスできることに気づき、フラグを入手できました。 ちなみにハードウェア要素は全くありません。

2つ目の問題は「AES-CBCを使ったログインシステムでrootというユーザ名でログインしろ」という問題でした。 これもCBCに対するビットフリップ攻撃をすればよく、どちらかといえば暗号の問題でハードウェア的な要素はありませんでした。

3つ目の問題は「ESP32のRTC_FASTメモリ領域(0x3FF80000)からフラグを読みだせ」という問題で、その領域を読み出す関数read_rtc_memory(addr, size)は提供されているものの、実際にフラグがある領域を読み出そうとすると関数内の処理でブロックされるようになっていました。

ESP32のデータシートを見ると、メモリマップのRTC_FASTとして8KB*2の領域が定義されているのに実際は8KBとして扱われていることから、2つとも同じ物理領域を指していると予想しました。 そこでアドレスとして0x400C0000を与えて関数を呼び出すことでフラグが表示されました。

ハードウェア問題が出ると聞いて身構えていましたが、ハードウェア上でCTFの問題が出題されるというような形式でした。 他のメンバーが解いた1問もBrainf**kで足し算をするプログラムを書けという問題だったらしく、こちらもハードウェア要素はなさそうでした。 ただ、解けなかった問題の中には不正にFlashの中身を書き換えることを要求する問題も含まれていたため、解法が気になるところです。 Jeopardyは今後問題が公開されるそうなのでそのときに確認してみたいと思います。

ESCAPE ROOM Challenge

ESCAPE ROOM Challengeは、日本の脱出ゲームに着想を得た(本当に係の人が日本のやつって言ってました)チャレンジで、謎を解き明かしつつ爆弾を止めるという設定がありました。 もう少し踏み込んだことも言っていましたが、私のリスニング能力の低さから大部分をスルーしてしまいました。

このチャレンジにはチームから5~7人の代表者を選出して挑戦します。 制限時間は45分で、その間に車内を捜索しダイヤル錠や金庫の番号を見つけて開けるのを繰り返すと爆弾解除コードのヒントが揃っていき、最後に解除コードを入力すると爆弾が停止するという内容でした。

CTFの一環で出題された問題ですが、情報セキュリティ的な要素はほぼ必要なく、一般の人も参加できそうな形式の脱出ゲームでした。 後で調べたところ、モノとしてはこれをそのまま呼んでいたようです。 https://escaperoommobiel.nl/en/professional/cyber-security/

アジアチームからは6人が参加し、約16分を残して脱出に成功しました。 他のチームのクリアタイムは不明ですが、スコアボード上では4チームが脱出に成功していたようです。

Attack & Defense (2日目)

Attack & Defense (A&D)は、各チームに複数のサービスが動作するサーバが渡され、互いに攻撃して相手のサーバからフラグを奪う形式のルールです。 サービス内の脆弱性を探し、見つかれば攻撃コードを書きつつ脆弱性を修正し(パッチ)、さらに未知の脆弱性で点数を奪われればパケットも凝視して脆弱性を探すという大変忙しい形式でもあります。

今回のA&Dでは、大きく4つのサービスが用意され、その中の8ヶ所に運営からのフラグが書き込まれるという形式でした。 A&Dの各問題や競技結果はGitHub上で公開されています。

github.com

それぞれの問題の概要は次の通りです。

  • ClosedSea (Web, Crypto)
    • NFTの売買ができる(という体の)Webサービス
  • CyberUni (Crypto, Web)
    • 1つのシングルサインオン基盤と3つの小サービスからなるサービス群
  • RPN (Pwn)
    • 数値や文字列を保存可能なスタックマシン
  • Trademark (Crypto, Web)
    • データを登録してライセンスキーを持っている人がそれを閲覧できるサービス

ICC2022ではroot権限のあるVMがチームに1つ与えられました。 VMの上には4つのサービスのDocker環境が用意されていて、場合に応じてソースコードやバイナリファイルをパッチしてビルドし直すことができます。 また競技時間はJeopardy同様9時から18時で、開始から1時間は各チーム間のネットワークは閉鎖され互いに攻撃できないようになっています。

ネットワークがオープンされると、運営チームは1ラウンドごとに各チームのサービスの動作確認をし、その後フラグを書き込む処理を行います(SLAチェック)。 この書き込まれたフラグを他チームから奪って運営に提出することで点数をそのチームから奪い取ることができます。 なお、古すぎるフラグは受け付けないようになっているため、後から攻撃を成功させて一気にフラグを奪い取るようなことはできません。

A&D全体の総括をすると、かなりバランス良くできていて競技性が高かったと感じました。 ただA&Dの1ラウンドが2分と短めに設定されていたため、攻撃が遅いとフラグを取りこぼす可能性があったのは、暗号系で計算量が多い問題セットに対してはやや大変でした。

Trademark (1)

Trademarkは私が主に取り組んだサービスで、ライセンスキーの発行・管理を行うサービスになっています。 また、このサービスはC#で書かれていて、.NETを経由してLinux上で動作します。 競技終了後に運営に聞いたところ一番簡単なサービスだったらしく、実際に時間内に問題の脆弱性がほぼ全部発掘された上にA&Dらしい攻防も発生するなど、非常に楽しめた問題でした。

最初に見つけた脆弱性は AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA というライセンスキーが必ず妥当なものとして判定されるという脆弱性でした。 チェックアルゴリズムはn個のライセンスキーLnを使って表される、f(x)=A(x-L1)(x-L2)...(x-Ln) mod p という多項式のxにライセンスキーを数値化したものを入れて、値が0になればOKというものでした。 (x-Ln) という形の掛け算のうち1個でも0になれば式全体が0になることを利用した認証アルゴリズムです。 この多項式の実装を読んでいると、定数項の扱いが存在しない(定数項は必ず0)ことがわかったため、x=0を入力すると結果は0になることが予想できました。

この脆弱性に気づいたのは10:14頃で、既にネットワークがオープンになっている状況でした。 取り急ぎチームメンバーと情報を共有し、私は攻撃コード、チームメンバーがそのパッチを担当することになりました。

caronte が重すぎる問題

アジアチームではパケットの解析のため、caronteをVM上に導入していました。 caronteはA&D用のパケット解析OSSツールで、チームリーダーがセットアップしてくれたものです。 事前に行われたA&D環境のデモ会である程度の使い方は知っていましたが、実戦で使うといろいろトラブルが起きるものです。

caronteはDocker上で動作しており、VM側でキャプチャしたパケットファイルをボリュームマウントするように設定されていました。 caronteではキャプチャしたpcapファイルを適宜手動で読み込ませる必要があるのですが、これを実行しても10:06以降のデータが読み込まれないという問題が発生します。 また、読み込み動作をするとVMに相当な負荷が掛かっている様子も見受けられました。

原因が不明なので最初はそのまま放置してパケットを見ないでいたのですが、ある時チームのサービスすべてで一気にSLAチェックが失敗する現象が発生し始めました。 ここでやっとcaronteが重く、それによりサービスの動作が停止しSLAチェックに影響を及ぼしているであろうことに気が付きます。

すぐにリーダーに相談し、caronteを外部サーバへ移動させて事なきを得ました。 恐らくパケットが10:06までしか読み込まれなかったのはファイルが大きすぎてタイムアウトしたからだと考えられます。 開始から2時間ほどパケット解析ができなかったのはA&Dにおいてはかなり痛手でしたが、序盤は思っていたよりも攻撃が飛んでこなかったのでなんとか助かりました。

Trademark (2)

1つ目のパッチ後しばらく経ってもフラグの流出は止まりませんでした。 多くのチームが他の攻撃に着手していると考え、パケットキャプチャを読むことを考えます。 ちなみに自分の環境ではなぜかcarnoteへのパケットアップロードが機能しなかったので結局はWiresharkで読んでいます。 すると次のようなリクエストを発見しました。

POST /api/products/41/download?/api/login HTTP/1.1
...

このリクエストはユーザ認証なしでいきなりフラグを抜き取るものでした。 事前にこの辺りの挙動はコードリーディングでディレクトリトラバーサル的なことが起きるんじゃないか?と予想してメンバー内で確認していた場所でもあったため、すぐに確認しに行くと次のようなコード片を発見しました。

    public async Task InvokeAsync(HttpContext context, ApplicationDbContext db)
    {
        if (_blacklist.Any(context.Request.FullPath().Contains))
        {
            await _next(context);
            return;
        }
        //...
        //ユーザ認証処理
    }

_blacklist はリクエストに認証を必要としないURLが羅列される配列です。 要はAPIリクエストでログインや登録の部分は認証の処理をスキップするというコードになっています。 問題なのはContainsメソッドを使ってチェックしているという点です。 FullPathメソッドは他のファイルでURLのパス部分とクエリ文字列を結合するように定義されていたため、Containsを使ってしまうとクエリ文字列部分に /api/login のような_blacklistの文字列が紛れ込んだ場合に認証をスルーしてしまいます。

ContainsEqualsに変えるだけで直せる脆弱性ですが、パスの処理を書き換えてしまうため入念にローカルチェックをした後にデプロイしました。 ちなみに結果は動いたのでよかったですが、StartsWithメソッドを使うほうが適切だったかもしれません。

この脆弱性は11:30頃に発見し、約30分後にはパッチや攻撃スクリプトを完成させることができました。

Trademark (v.s. ヨーロッパチーム)

Trademarkの3つ目の脆弱性は、多項式を直接解くことでライセンスキーを復元するというものでした。 これについてはチームメンバーが発見し、パッチや攻撃スクリプトの用意が完了しています。

しかし問題はこの後で、ヨーロッパチームからのフラグが途絶えます。 この時間帯ではヨーロッパチームがフラグ出力のSLAに失敗しており、実際にアジアチームから提出したフラグは無効として扱われていました。

その後しばらくするとSLAが下がることを危惧したのかヨーロッパチームのサービスが復活し、また少しフラグが盗めるようになります。 しかし、またすぐにフラグが入手できなくなりました。 ここからはTrademarkに関わった全員でヨーロッパの挙動をチェックするようになります。

結論から言うと、ヨーロッパチームはアジアチームのスクリプトのパスワード長が一定なことを利用して、特定の長さのパスワードのときに登録が失敗するようにサービスを書き換えていました。 ユーザ名とパスワードの長さをランダムにするようにスクリプトを変更し、引き続きヨーロッパからフラグを盗めるようになりました。

その後もアジアチームの些細なスクリプトの挙動を察知してヨーロッパチームがフィルタを作成し、それをアジアチームが回避するということが数回続いて競技が終了しました。 簡易的なフィルタを書いて攻撃スクリプトを弾くのは攻撃側のリソースを削る効果もあり、実際にTrademarkチームは他の問題にあまり集中できませんでした。

ちなみに競技最後の1時間はスコアボードの点数が変動しなくなる(フリーズする)ようになっていたのですが、その間にアジアチームのパッチはオセアニアチームに破られていたようです。 完全にパッチしきったと思っても油断は禁物ですね。

競技結果

競技の結果はA&D部門で優勝、総合では準優勝でした。

Jeopardy部門でも2位は取れていましたが、1位のヨーロッパチームとその時点で2600点差付けられていたため、A&Dで逆転しきることができなかった形になります。 Jeopardyの2~4位では点差が1000点しか開いていないことからも、ヨーロッパチームのJeopardyでの活躍が凄まじかったことがわかります*1

ガラス楯と表彰発表時のレター

おわりに

ICC2022の様子は伝わったでしょうか。 JeopardyとA&Dの2形式で開催されたこともあり、内容がかなり盛りだくさんになりました。

CTF以外にも国際交流という観点でも多くの経験が得られました。 私は以前DEF CON CTFの本戦に出場した経験がありますが、その時は日本人チームでの出場だったため、チーム内言語は日本語でした。 一方アジアという枠では英語でコミュニケーションを取らざるを得ません。 私は英語に自信はありませんが、メンバー全員がトッププレイヤーなこともあってニュアンスが通じれば理解してもらえたので、とりあえず何か話してみるという精神を持てました。

私は95年生まれなので代表選手になれませんが次回もアジアチームはICCに参加すると思うので、96年以降生まれの腕に自信のあるCTFプレイヤーはぜひ予選に参加してみてください。

最後に、一般社団法人セキュリティ・キャンプ協議会様からはACSCの予選の運営を始め、日本人プレイヤーの渡航費・宿泊費・食費等まで、多大なご支援を賜りました。 この場をお借りして感謝申し上げます。

*1:現在公開されているJeopardyスコア表はないため内部の情報です

株式会社サイバーディフェンス研究所 / Cyber Defense Institute Inc.