PHDays III CTF：内観（パート1）

2013年5月23日および24日に、実用的な情報セキュリティに関する年次国際フォーラムの一環として、Capture the Flag原則に基づいた最大の大会の1つであるPHDays III CTFが開催されました。 今年は、コンテストの開催に多くの努力が費やされ、その結果、参加者の誰もが無関心になりませんでした。 このイベントの後、私たちは競技の準備がどのように行われたかについて話し、カーテンの後ろからの眺めを提示することにしました。



CTFは、チームプレイに似た形式で情報セキュリティを提供するための競争です。 各チームには、脆弱なサービスが事前にインストールされた独自のネットワークインフラストラクチャが提供されます。 チームはサービスを研究し、それらの脆弱性を探し、それらを使用して、ライバルのサービスを攻撃する必要があります。 同時に、彼らはライバル攻撃から身を守るために、自身のサービスを稼働状態に維持し、エラーを修正する必要があります。



敵のサービスに対して攻撃を成功させると、チームは「フラグ」と呼ばれる秘密データを受け取ります。 フラグは、攻撃が成功したことの証拠です。 また、サービスに加えて、チームには追加のフラグをもたらすことができる事前に準備されたタスクのセットが与えられます。

準備開始

CTFコンテストへの参加と開催に豊富な経験があるため、コンテストの主な目的はタスクであることを理解しました。 しかし、優れた「ラッパー」-伝説、ゲームの世界、魅力的なルール、プレイヤーと観客の両方に没入感を与える視覚的なコンポーネントがなければ、競争は数学のオリンピアードよりも少し面白いでしょう。



まず、凡例とルールを作成し、それらをタスク自体の作成の開始点として使用することが決定されました。 焼きたてのゲームコンポーネントをリンクするために、ゲームの作成プロセスについてさらに学習することにしました。



伝説の概念を開発した後、ゲームの仕組みを経験しました。 まず、コンペの形式を決定しました。通常のタスク（Jeopardy CTF）、サービス（クラシックCTF）、イノベーションを備えた混合CTFでした。 。 この形式は、私たちに思われるように、参加者のスキルを広く評価し、ゲームにダイナミズムをもたらします。



次に、プレイヤーがタスクで実行できることと、そのために何をすべきかを理解する必要がありました。 ゲームの本質、プレーヤーの活動や関与などの用語が浮上しました。 ボード上にエンティティを描画し、それらのアクションを定義することにより、最終的にルールを修正することができました。 ゲームのバランス-プレイヤーのタスクと内部ゲームリソースのポイントの分布を決定するためだけに残ります。



まず、さまざまなタイプのタスク（サービスとタスク）を優先することから始めました。 すべての問題を解決したチーム、またはすべてのサービスを完全に分析し、それらのエクスプロイトを作成し、サービスの脆弱性を修正したチーム-私たちにとって誰が勝者かを決定する必要がありました。 また、タスクやサービスに対する部分的なソリューションを比較する必要がありました。 このランキングにより、私たちは割り当てスコアのバランスの取れたシステムを作成することができ、CTF全体を解決する際にチームが自由に戦術を選択できるようになりました。



CTFの開発における重要なポイントは、コンペティションが開催されるポジティブハックデイズフォーラムは、ハッカーの戦いにまったく限定されないという事実でした。つまり、ファンはもちろん、チーム。



誰も放置しないために、ゲームのコースを視覚的に反映するシステムが必要でした。さらに、私たちが発明した世界に没頭しているように感じました。 実際、このシステムは、ほぼリアルタイムでゲームイベントを視聴者に視覚化する必要があります。 また、これはゲームなので、システムはゲームのように見えるはずです。世界のカラフルな写真、スタイリッシュなヒーロー、美しい特殊効果、不均一な（可能な限り）イベントです。 1人のミューズが私たち全員を訪問しました。私たちは、このゲームを複数の世代に影響を与え、ヒーローズオブマイトアンドマジックのように見せたいと考えています。 そして、さまざまなモバイルプラットフォームで起動できれば理想的です！..



Maxim Korobtsev（ gametrek.ru ）には、ユニークなゲームデザインとCTFルールの開発に多大な貢献をしてくれたことに感謝します。

ルールとゲームの仕組み

伝説に加えて、ブレインストーミングの最初の数週間で、オリジナルのゲームの仕組みとゲームのルールが登場し、タスク解決プロセスに少しの戦略が追加されました。 プレイヤーが常にゲームを実行するためのいくつかの戦略を選択できるようにメカニクスを開発し、それぞれが勝利に導くことができるようにしました。

ゲームセットに含まれるもの：

• 10チーム:)、
• 5つのチームサービス（鉱山）、
• 3つの一般的なサービス（地雷を引く）、
• 25タスク
• 4人のボス（悪役）。

ゲームの目的：できるだけ多くのゴールドを獲得します。 最も「裕福な」チームが勝利します。





ゲームの仕組みの概略図（オプション1）



ゲームの本質：

1. ラウンド-プレイ時間の5分間隔。 各ラウンドの終わりに、発生したゲームイベントが誤って計算され、フラグがサービスで更新されます。
2. フラグは、サービス、タスク、またはボスに見られる秘密情報です。
3. 金は、D。I.メンデレーエフの原子番号79の周期系の第6周期の最初のグループのサブグループの要素です。また、ランキングでのチームの位置を決定するゲームポイントのタイプ。
4. リソース-チームサービスでのアクションの実行から受け取るゲームポイントのタイプ。 各サービスは、独自の種類のリソースをもたらします。

リソースの種類（コストの増加順）：

• 木
• 石炭
• 鉄
• 油
• 結晶。

リソースアクション：

• 金のリソースの購入/販売（リソースは金の購入/販売が可能で、リソースの購入コストは販売コストよりも大きい）;
• タスクの購入（タスクに対するアクションを参照）;
• サービスを健全な状態に維持するためのリソースを取得する（チームサービスのアクションを参照）。
• 競合他社のサービスに対する攻撃のためのリソースの取得（チームサービスのアクションを参照）。

1.サービス -ラウンドごとに1回更新されるフラグを持つ脆弱なアプリケーションで、チームの1つに属します。

チームサービスのアクション：

• サービスを健全な状態に維持する：サービスが健全な状態にある場合、ラウンドごとに所有者に対して一定量のリソースが生成されます。
• ライバルサービスに対する攻撃。 チームは、サービスの脆弱性を悪用することにより、ライバルのサービスを攻撃できます。 さらに、攻撃を成功させるために、攻撃チームはラウンドのために被害者チームのリソースの一部を取ります。 したがって、チームが攻撃する敵が多いほど、より多くのリソースを受け取ります。
• サービスの保護（パッチ）：敵がチームのサービスを攻撃するほど、ラウンド終了時に受け取るリソースが少なくなるため、脆弱性を閉じて地雷を保護する必要があります。

チームがサービスに対して受け取るポイントの数は、次の式を使用して計算されます。

• チームが他の誰かのフラグを盗んだ場合、そのチームは0.4 * C / Nを受け取ります。ここで、 Cはラウンドごとにサービスによってもたらされるリソースの合計数であり、 Nはサービスオーナーチームを含むサービスは動作可能であると認識されます。
• チームがサービスの所有者であり、ラウンド全体で作業状態にある場合、チームは残りのリソース全体から盗難を差し引いたものを受け取ります。

2.共有サービスは、どのチームにも属さないフラグがラウンドごとに1回更新される脆弱なアプリケーションです。



共有サービスでのアクション：

• 共有サービスに対する攻撃。 チームは、サービスの脆弱性を悪用して一般的なサービスを攻撃できます。 さらに、攻撃が成功すると、攻撃チームは一定量の金を受け取ります。

3.タスク -これは、フラグを1つ持つ事前に準備されたタスクであり、それを解決するには特定のスキルが必要です。



タスクのアクション：

• オープニング（購入）タスク。 最初は、すべてのタスクはチームに対して閉じられています。 タスクのコスト、報酬とそれを解決するために必要なスキルに関する情報が利用可能です。 タスクの解決を開始するには、チームはタスクに一定量のリソースを費やしてタスクを購入する必要があります。
• ソリューションはタスクであり、チームがタスクを解決した場合、タスクの複雑さに応じて、彼女は一定量のゴールドを受け取ります。 また、タスクを解決するために必要なスキルの値が、チームの対応するスキルに追加されます。

4.ボスは、1つのフラグを備えた事前に準備されたタスクであり、制限付きライフタイム（3時間）、可変報酬、およびそれを解決するために特定のスキルが必要です。



すべてのチームからの各ラウンドでは、一定量の金（税）が集められ、それが上司に貯金箱に入れられます。



ボスに対するアクション：

• 上司の決定。 チームがボスを決定した場合、残りのボスの寿命は30分に短縮され、税金の徴収が停止されます。 割り当てられた時間内にボスを決定したすべてのチームは、彼の貯金を均等に分割し、それを解決するために必要なスキルをプラスします。

5.スキル（スキル） -表示されるゲームポイントのタイプ：

• 特定のタスクを解決するためにプレイヤーに必要なスキル;
• チームプレーヤーは、解決するタスクに基づいてどのようなスキルを持っていますか。

スキルの種類：

• Web-Webを扱うスキル。
• リバース-リバース分析のスキル。
• Pwn-脆弱性のスキル活用。
• 法医学-法医学検査の知識;
• Ucucuga-非標準/非自明のタスクを解決するスキル。
• 暗号-暗号の知識;
• ネットワーク-ネットワークインフラストラクチャとプロトコルの知識。
• その他-以前のタイプのいずれにも属さないさまざまなスキル。

スキルに対するアクション：

• タスクを解決するためのスキルを獲得する（タスクのアクションを参照）;
• 上司の決定のためのスキルを取得する（上司の行動を参照）。

6.アチーブメント（報酬） -特定の要件を満たしたチームに対して発行される報酬。 合計すると、ゲームでは42種類の賞を獲得できます。





ゲームの仕組みの概略図（オプション2）

ネットワークインフラ

ゲームのルールが整い、競争がどのように行われるか、そして技術的な観点から何が必要かということについて誰もがすでに考えていたとき、ネットワークインフラストラクチャの設計が始まりました。

設計

このジャンルのすべての規範によれば、設計はルール、ゲームの仕組み、常識に基づいた要件の仕様から始まり、その後、ネットワークの設計に直接進むことができました。



各チームには独自のサブネットが必要であり、IPアドレスに基づいてプレーヤーがopponent審システムの要求から敵の攻撃を区別できないように、1つのサブネットから別のサブネットへの要求をNATの背後に隠す必要があります。



コマンドサブネットに加えて、対話型タスクと共有サービスをホストするための個別のセグメントが必要です。 さらに、チームを識別するために、サービスがリクエストの送信元のサブネットに関する情報を取得できることが必要です。



デフォルトでは、すべてのタスクへのプレイヤーのアクセスは制限されるべきですが、チームが特定のタスクを購入した直後に、サブネット全体がそれにアクセスできる必要があります。



ゲームインフラストラクチャには、ju審部門も含める必要があります。 これには、審査システム、ユーザーインターフェイスを備えたWebサーバー、ビジュアライザーのサーバー部分、およびゲームプロセス全体を構成および監視するコンピューターが含まれます。 このサブネットから、すべてのタスク、サービス、およびコマンドへのアクセスが開かれている必要があります。 そして、もちろん、すべてのサブネットに対してインターネットへの無料アクセスが必要です。

実装

サーバールームにあるCisco Catalyst 3750X 24スイッチがネットワークコアとして選択されました。 Cisco ASA 5510ファイアウォールはそれに接続され、CTFネットワークのすべてのセグメント（チーム、タスク、サービス、審査員）のデフォルトゲートウェイとしても機能しました。 ネットワーク上のすべてのコンピューターにIPアドレス（DHCP）を配布し、IPアドレス変換（NAT）、タスクへのアクセス制限、およびインターネットアクセスを提供しました。



Cisco Catalyst 3750G 24スイッチはネットワークコアに接続され、10のチームとジュリーのD-Link DES-1008Eスイッチが接続され、それぞれが独自のセグメント（VLAN）に属していました。



また、対話型タスク、共通サービス、および審査員システム用の2つの強力なサーバーがメインルーターに接続されました。



1.2プロセッサー、4コア、64Gb RAM、1Tb HDD。

2台の仮想マシンを備えたVMware ESXiがその上で発生しました。 Ubuntu 13.04の最初のサーバーバージョンは、一連のju審サービスで機能しました。

• 審査員制度
• ユーザーインターフェース
• サービスの機能に必要なすべて。

2番目は、Windows 7を実行するビジュアライザーサービスを実行しました。



2.2プロセッサ、6コア、128Gb RAM、1Tb HDD。

VMware ESXiも実行し、36台の仮想マシンを実行しました。

• 対話型タスクの場合は20
• 3一般サービスの場合、
• ボスの下に13。

ゲームネットワーク図

一般的なプロジェクトアーキテクチャ

凡例とルールの準備ができたら、システムの全体的なアーキテクチャの設計を開始する必要がありました。 次に、デバイスプラットフォーム全体と個々のコンポーネントについて説明します。





プロジェクトの全体的なアーキテクチャの概略図



主な要素は、すべてのゲームロジックを処理するシステムであるJury Systemです。 彼女のタスクには、ゲームイベントの処理とチームのスコアリングが含まれます。 他のすべての部分は、独立したサブシステムではなく、外部インターフェースです。



Flag Acceptor Interface-フラグ受け入れインターフェース。 これは、審査員システムのサブシステムです。 この図に示されているのは、共通のサービスと敵のサービスの両方から盗まれたフラグを渡すチームの能力を表示するためです。



MongoDBはゲームの状態データベースです。 ゲームの現在の状態はすべてここに保存され、更新されます：チームによって得点されたポイント、タスクステータス（チームごとにオープンまたはクローズ）、タスクとボス自身の完全な説明、ゲームの期間など



ユーザーインターフェイス（UI） -Webアプリケーションとして実装されたコマンドのユーザーインターフェイス。 ゲームのルールに従って、チームはタスクを開いたり、リソースを売買したり、タスクを解決したり、現在の評価に関する情報を受け取ったりすることができます。UIはこの機能を担当します。 表示の初期データとして、MongoDBからデータを取得します。 ユーザーからのリクエストの処理は、RPCを介して実装され、AMQP上に順番に構築されます。



Visualizerは、ゲームイベントを蓄積して表示するゲーム視覚化システムです。 すべての情報がイベントを介して送信できるわけではないため、システムはMongoDBのシステムの状態から一部のデータを取得します。



ネットワークアクセスインターフェイス -タスクアクセス制御インターフェイス。 ゲームの開始時には、すべてのタスクがチームで利用できるわけではありません。 チームがタスクを開くとすぐに、このインターフェイスを使用してタスクが開かれます。

審査員制度

前述のように、審査システムはゲームロジックのレンダリングを担当します。 それを設計するとき、次の目標を達成しようとしました。

1. ゲームのルールの正しい実装 。 参加者にチートを与えることはできません。 私たちにとって最も重要なことは、ゲームのルールに従うことでした。
2. 仕事の安定性。 ゲーム中、参加者はju審員システムでの作業に苦労するべきではありません。 突然の転倒はゲーム全体の不均衡につながる可能性があります。チャンスは等しくなく、競争は客観的ではありません。 このため、安定した動作を実現するために、テストに多大な労力を費やしました。
   
   
   
   安全上の理由から、ju審制度の崩壊後にゲームの状態を復元する特別なシステムを作成しました。
3. 仕事のスピード。 CTFゲームをプレイした経験から、特にタスクが最後に解決された場合、システムからの応答を遅らせることはチームにとって致命的であることがわかっていました。 システムがユーザーからの要求をより速く処理するほど、チームは次のタスクをより早く開始できます。
4. 安全性 ルールの正しい遵守に加えて、重要な側面はシステム全体のセキュリティでもありました。 単純なプログラマではなく、本物のハッカーがゲームに参加しました。 違法なポイントや不正アクセスを許可することは不可能でした:)

目標が示されたので、now審員システムのタスクをペイントできます。

1. ラウンドの処理

• ルールに従って、各ラウンドの新しいチームの「フラグ」にはチームのサービスを入力する必要があり、ラウンドの最後に、チームから受け取ったすべてのフラグにリソースを追加する必要があります。 現在のラウンドのフラグは削除されます。
• ラウンドの終わりに、アクティブなボスがいる場合、チームから税金を「撤回」します。

2. ユーザーリクエストの処理

• リソースの購入/販売の実装。
• 開始/解決タスクの処理。
• ボスソリューションの処理。

3. チームからのサービスからのフラグの受信

• このタスクには、現在のラウンドのフラグの有効性と、フラグを渡したチームのチェックが含まれます（フラグを渡すことはできません）。 フラグがチェックに合格した場合、通行人は特別なリストに配置され、ラウンドの終了時にそのリソースを受け取ります。
• 同じフラグは、同じチームが1回だけ渡すことができます。

4. ボスのロジックの処理

• ボスは無視され、時間通りに殺されなければなりません。 ボスのキルタイムは動的です。 最初のチームの決定後、ボスは30分間生きなければなりません。 上司の最大寿命は3時間であることを思い出してください。

5. チームに実績を授与する

• チームにマークを付けることができる42の異なる成果を考え出しました。 それらはすべて、さまざまな種類のタスクの参加者による順次実行に基づいているため、ある意味でチームの戦術を特徴づけています。 このロジックを実装するには、ほとんどすべてのデータベースクエリが必要でしたが、少なくとも楽しいです:)

審査員システムのアーキテクチャ



外部コンポーネントを操作するためのインターフェース：

• Mongo Interface -MongoDBを操作するためのインターフェース。 当初は、UIがチームの評価に関する関連データを迅速に受信できるように、現在のアカウントをMongoDBに保存することが計画されていました。 この目標に基づいて、MongoDBが選択された理由は、読み取りが速いためです。 ゲームの全期間にわたってデータベースに書き込むことは非常にまれであり、外部イベント（チーム、タスクによるフラグの配信）またはラウンドの終わり（次の始まり）に一致するタイミングです。
• AMQPインターフェイス-AMQPを操作するためのインターフェイス。 AMQPがメッセージングプロトコルとして選択されました。 このインターフェイスに基づいて、RPCはVisualizerおよびUIの一部のUIおよびイベントマネージャーによって実装されました。

ゲームの本質：

• チーム-コマンドの説明の抽象化、
• サービス-サービスの説明、
• ボス-ボスの説明、
• リソース-リソースの説明、
• タスク-タスクの説明。

ゲームエンティティ上のロジックの処理は、「ゲームマネージャー」によって行われます。 それらの実装機能のいくつかに注目したいと思います。

• Flag Acceptorは、チームからサービスからフラグを受け取ることに完全に責任を持つエンティティです。 実際、それは特定のポートでリッスンしている通常のTCPサーバーであり、コマンドからの接続の数が制限されている各コマンドのストリームを持っています。 チームのスレッドを分離することは、少数のチーム（合計10チーム）と負荷分散によって正当化されます：あるチームが他のチームよりも積極的にフラグを渡す場合、これは一般的なケースで他のチームの作業を遅くしません-スレッドスケジューリングはOSに任されます。
• Boss Manager-エンティティは、ボスのロジックを処理します。 上司が働く期間が重複するようなゲーム以外の状況でも、仕事のロジックを正確に描くために多くのエネルギーを費やす必要がありました。 ただし、このロジックはデバッグ中に成果を上げました。
• イベントマネージャ -すべてのゲームイベントの処理を担当するエンティティ。 このエッセンスに基づいて、ゲームイベントを記録するロジックが構築され、ゲーム後に収集された統計を処理できるようになりました。 絶対にすべてのゲームイベントがログに記録されたため、ある意味でゲームのリプレイを行うことは可能ですが、これまでのところこのアイデアは計画されていません。 ゲームのログは後でアップロードできます。
• サービスチェッカーマネージャー -コマンドサービスの正常性を検証するエンティティ。 おそらく、詳細に立ち止まって、このチェックがどのように行われているのかを説明する価値があるでしょう。

サービスの保守性を確認するために、CTFオーガナイザーは特別なプログラム、チェッカーを事前に作成します。 通常、サービスは完全に抽象的であり、競合ごとに異なります。したがって、チェッカーと連携するためのユニバーサルインターフェイスを備えています。 チェッカーは、次のコマンドラインパラメーターを使用して個別のプロセスで起動されます：実行するアクションを決定する{GETまたはPUT}コマンド-サービスにフラグを付けるか、その存在、フラグを持つサービスがチェックされるサーバーのIPアドレス、フラグ自体を確認します。 完了すると、チェッカーは完了ステータスを返す必要があります。

• 0-サービスは正常に機能しています。
• 1-サービスは実行されていますが、プロトコルは実行されていません（フラグがありません）。
• 2-サービスは機能していません（接続は拒否されました）。

1ラウンドのチェッカーには2つのアクション（GETとPUT）があるため、それらはすべてのチームに対してラウンドごとに2回起動されます：PUT-四半期のランダムな遅延を伴うラウンドの第1四半期に、GET-四半期のランダムな遅延を伴うラウンドの第3四半期に。 チェッカーを開始してPUTコマンドを実行した時点で、その時間までに作業する時間がなかったすべてのチェッカーの完了も完了しました。 この場合のサービスのステータスには、チェッカー操作エラーが表示されます。



アーキテクチャ上、チェッカーはすべてのサービスとすべてのチームですぐに起動されるため、サービスのチェックはシステム全体で最もリソースを消費するタスクです。 したがって、チェッカーの作成には特別な注意を払う必要があります。チェッカーはできるだけ早く解決し、できるだけ少ないリソースを使用する必要があります。 一般に、プログラミングの観点から見ると、すべてがいつものようになります:)



残りのコンポーネントは特に重要ではありません。 私が注意したい唯一のことは、落下後にゲームを復元するシステムです。 この機能を実装するには、多くのゲーム変数を外部データベースに保存する必要がありました。 ほとんどのデータはすでにMongoDBに保存されているため、残りを保存してデータベースから復元する機能を追加することにしました。



最後に、ju審制度の実施に関するいくつかの言葉は注目に値します。 システム開発チームの中で最も人気のある言語だったため、システム全体がC ++で記述されました。 さらに、著者は、Pythonで記述された同じコードの動作が遅くなることを確信しています。 開発フレームワークとして、Qtはプロジェクト専用の開発者にとって最も便利なものとして選ばれました。



継続



作成者： slim_d0g blackzert muodov ki11obyte Asperka



PSゲームプレイの分析に関する興味深い記事がPHDays Webサイトに公開されました。