Hardening 10 ValueChain 体験記

Hardening Project という競技をご存知ですか。

技術用語として Hardening（ハードニング）とは、「脆弱性を減らすことでシステムのセキュリティ堅牢にすること」（Wikipedia）を指します。サービスを提供するエンジニアであれば誰でもやっている当たり前のことですね。この Hardening──すなわち「守る技術」を競うため、WASForum¹が2012年から実施しているセキュリティ・イベントが Hardening Project です。

以前から Hardening Project の存在は知っていたのですが、某ゆるふわ勉強会²の人たちに誘われて、今年2015年11月に行われた Hardening 10 ValueChain（以下「h10v」）で初参加してきました。結果としては最下位という惨敗でしたが、とても価値のある経験を得られたので少しでもそれが伝わればと思います。

どんなイベント？

ざっくりと言えば、各チームは「株式会社はーどにんぐ」の一員となり、脆弱性のある EC サイト環境を競技時間のあいだにできる限り堅牢にして外部からの攻撃に耐え、最終的に競技終了時点での売り上げを競うという競技形式のイベントです。ただ、こんな感じのふわっとした理解のまま参加すると、あっさり負けます（ソースは自分）。

今回の h10v の公式サイトには以下のように書かれています。

防御技術力のみならず、サイトの運営を維持する総合力、つまり攻撃に対する堅牢化、それと同時に売り上げの確保、ダウンタイムの最小化、そのためのコミュニケーションスキルのすべてを加味して勝者が決まる³

このような評価軸を実現するため、ここに書かれた様々な「総合力」が無ければ「売上」というスコアが上がらないように、競技全体が設計されています。

競技そのものが「Hardening Day」として丸一日掛けて行われますが、さらにその振り返りとして「Softening Day」が翌日にあります。各チームの取り組みを発表し、攻撃側からの答え合わせを経て表彰式が行われます。Softening Day の内容は YouTube にて公開されています⁴。

それでは、実際の h10v における競技の詳細を紹介します。

全体像

h10v では、10人が1チームとなり、全6チームで競います。チームごとに用意されたテーブルに集まって8時間を戦い抜きます。人数や競技時間は、各回のテーマに応じて変わることがあるようです。前回（Hardening 10 MarketPlace）では1チーム5-6人だったようです。

各チームには、複数の仮想サーバで構成される競技環境が用意されます。各テーブルに用意された有線 LAN を経由して競技時間中のみ競技環境に接続できます。詳しくは後ほど詳しく紹介しますが、EC サイトをはじめとするいくつかのシステムが用意されています。この EC サイトに対して、運営側の用意したクローラーが「お客様」として定期的に訪問して商品を買っていきます。この「お客様」による売上金額こそが、スコアとして順位付けの対象となります。あくまで競技としては、システムの堅牢化はあくまで手段に過ぎず、購入数を上げることが目的となります。

この購入数を決めるのが「繁盛レベル」です。繁盛レベルは、運営側（後に紹介する kuromame6）が規定のルールに従って操作しているパラメータで、リアルタイムで会場前面のスクリーンに映し出されます。この繁盛レベルは「評判」を模しているため、たとえば情報漏洩事件があると一気に叩き落とされ、適切な対応をすれば回復してきます。また、事件そのものを未然に防ぐことに成功すれば上がるようです。上手く社長や顧客などへの技術アピールに成功すればさらなる向上が見込めます。これが「システムの堅牢化と安定運用」を「売上」として評価するための枠組みの肝です。

堅牢化したはずのシステムに対して「外部からの攻撃」を行うのが、運営側の「kuromame6」と呼ばれる技術チームです。彼らは8時間という競技時間の間、あの手この手でシステムの脆弱性を突いてきます。実際に行われた攻撃について後ほど紹介します。kuromame6は攻撃だけでなく、競技環境の構築・運用や評価なども担当します。

「段取り八分」という言葉があるように事前準備も重要です。今回は「参加者配付資料」が前日の夕方に配布されました。それだけでなく、そもそも h10v の開催告知からも、前回（Hardening 10 Marketplace）の発展であることが読み取れるため、競技環境の大枠そのものは大きく変わっていないだろうということが予想できます。したがって、これらの事前情報を基にした準備をすることで、8時間という短い時間を何十何百時間にも拡張することができます。

今回は10人という大きなチーム（前回は5-6人）ですので、チームの体制作りやタスクマネジメントも重要です。募集要項⁵においても明言されています。

すべてのチームは「やることが多すぎて手がでなかった」ということは激減し、むしろ「チームワークで乗り越えられた！」という経験ができる可能性が飛躍的に向上することでしょう。

人数が多いだけでなく、自分のチームに足りない部分を補うための「マーケットプレイス」もまた用意されています。マーケットプレイスにお金を落とすことで、カスペルスキーや NEC の WAF などのソフトウェアを購入したり、プロのセキュリティエンジニアを時間で契約したりといったことができます。

これが h10v という競技の全体像です。上手く機能するチームを組み立てて事前準備を進め、攻撃側の kuromame6に先んじて渡されたシステムを素早く堅牢化し、もし脆弱性を突かれたなら適切に対応するというだけでなく、繁盛レベルの増減条件を見極めて積極的に EC サイトの価値を上げていく──ここまでやって始めて勝利できる、そんな感じの総合競技です。

サーバ環境

以下が h10v で各チームに提供される競技環境です⁶。

各チームは大きく分けて4つのネットワークのサーバ・クライアントを管理します。これらはグローバルエリアのルータを介して、仮想的な「インターネット」に接続されています。kuromame6からの攻撃や、EC サイトへのクローラーはグローバルエリアを介して「インターネット」側からやってきます。

「社長」や「お客様」などと、「インターネット」を介してメールをやりとりすることも可能です。ただし、現実のインターネットへの接続は制限されているため、外部サイトから直接ファイルを持ってくることができないことには注意が必要です。

公開サーバエリア

公開サーバエリアには、EC サイト本体や「株式会社はーどにんぐ」のコーポレートサイトなどを提供するサーバ群が設置されています。また、外部との連絡を行うための DNS 兼メールサーバもあります。

「社長」などへの適切な報告がされないと繁盛レベルは上がらないため、EC サイトなどのウェブサーバだけを守っていれば良いわけでは無く、実際にこの DNS サーバに対しても攻撃が行われました。

社内サーバエリア

データベースサーバや、Active Directory サーバなどが置かれています。DB サーバが落とされれば当然ながら公開サーバエリアで提供している様々なサービも停止しますし、Active Directoryサーバが被害を受けると、この後に紹介する踏み台クライアントにも影響します。

踏み台クライアントエリア

公開サーバと並んで重要なのが、ここに設置されたサポート端末です。h10v では参加者の端末から直接接続して良いのはサポート端末のみというルールがあります。したがって、サポート端末が被害を受けてしまうと公開サーバなどに対して操作ができなくなってしまいます。

唯一 SSH が可能で事実上の作業機点となる CentOS 端末は1台しかありませんし、5台のWindows 端末にはそれぞれメールが設定され、ここでしかメールの送受信ができません。しつこいようですが h10v では報告こそが評価の根幹ですので、CentOS 端末だけでなく Windows 端末もまた、EC サイトと同じかそれ以上に死ぬ気で守る必要があります。

さくらのクラウドエリア

ファイアウォールの外から「インターネット」を介して外部から自チームの環境を動作するために、「確認用サーバ」が設置されています。ごく普通の CentOS 環境のサーバが用意されているようなのですが、今回うまく活かすことができませんでしたので詳細は不明です。

実際の攻撃

h10v で実際に行われた代表的な攻撃が以下の通りです。

時刻	攻撃内容
11時	標的型攻撃
12時	業務アプリからの情報漏洩
13時	DD4BC（DDoS for Bitcoin、30分間のNW遮断）
14時	Malvertising（広告からのマルウェア感染）
15時	潜んでいたマルウェアの再活動
16時	応募フォームのWebアプリからの情報漏洩

どれも現実において最近に目立っている攻撃手法です。

これからそれぞれの攻撃について紹介していきます。具体的な攻撃方法の詳細は明かされていないため正確である保証はありませんが、自チームで把握していた内容や、Softening Day などで公表されている内容からの推測をベースにしたものです。

標的型攻撃

前回はメールによる標的型攻撃があったものの誰も「踏んで」くれなかったため、今回は「誰かが踏んだ体でそこからすでに起動していた」というマルウェア感染後という攻撃シナリオになりました。

時間になると「マルウェアに感染して外部に攻撃しているからなんとかしろ」という連絡が外部の組織からやってきます。それと同時に一気に繁盛レベルも引き下げられ、適切な対応が進めば繁盛レベルが回復するという仕組みになっています。

開始から1時間での発動ということもあり、これを事前に対策して予防できたチームは無かったように思います。私たちも含めて、カスペルスキーの導入で予防するつもりが間に合わなかったというチームが多いようです。

標的型攻撃で送り込まれたマルウェアは、後ほど再び大活躍します。

業務アプリからの情報漏洩

社長の売上把握や、在庫追加などのバックヤード業務を行うためのウェブアプリが用意されていますが、これがインターネットに全公開されており、そこに表示されていた「最近の購入者情報」に含まれる個人情報が漏洩します。この情報漏洩も「外部からの連絡」として発覚します。

漏洩した情報は以下の組み合わせです。

1. 受注日
2. 購入者の氏名
3. 商品名および単価、数量、金額

参加者配付資料の「社内システム運用ルール」に「情報漏えい発生時の対応」というそのままの項目があるので、基本的にはそれにしたがって対応することになります。

現実でも同じですが、重要なことは、「いつから情報が漏れているか？」をいち早く特定することです。そのためには、この EC サイトのアプリケーションとしての構造を素早く把握しなくてはいけません。また、ユーザへの通知を行うためには、漏えい対象のユーザのメールアドレスを取得してお詫びメールを送るといった運用作業も必要となってきます。だんだんと、総合的なサービスの運用能力が問われるという Hardening Project の本質とが見えてきます。

DD4BC（DDoS for Bitcoin、30分間のNW遮断）

13時に競技環境のネットワークに突然アクセスができなくなります。

DD4BC と呼ばれる「DDoS 止めて欲しければ Bitcoin ちょーだい♡」という攻撃（を模した意図的なネットワーク遮断）です。ネットワークが遮断されてすぐ、kuromame6から DDoS を受けた旨の共有と、30分という復旧見込み時間がアナウンスされます。

この30分という「何もできない時間」を有効活用し、これまで3時間の振り返りと残り5時間に向けた体制作りが各チームに求められています。休み時間と思ってカレーをのんびり食べている場合ではありません。

Malvertising（広告からのマルウェア感染）

2015年後半で最も話題になったマルウェア感染手法である Malvertising（Web 広告からの感染手法）ですが、h10v でも当然のように仕掛けられました。コーポレートサイトに貼られた広告で3回に1回だけマルウェアが落ちてくるようになっていました（ブラウザ側の脆弱性による drive-by-download 攻撃）。発生時間までに対応ができていなければ、ユーザからの問い合わせという形で発覚します。

教科書的な対応は、広告の管理者に連絡をして、不正な広告が表示されない新しいリンク先 URL を受け取るというものでした。参加者配付資料に「広告サーバ管理者」としてメールアドレスが掲載されていることから、深読みできたチームもあったかも知れません。

ユーザへの対応だけで無く、あわてて状況を確認しようとソフトウェア更新が不十分なサポート端末などでコーポレートサイトを開いてマルウェアに感染してしまえば、その端末が標的型攻撃の経路になりかねません。したがって、発覚後のサーバ側の対応だけでなく、サポート端末側のソフトウェアアップデートや、ウイルス対策ソフト等での防御もまた重要となります。

潜んでいたマルウェアの再活動

標的型攻撃で仕込まれたマルウェアが再び活動を始め、管理者パスワードが Pepper ちゃんにより突然読み上げられたり、Windows 端末を使っていたらマルウェア経由で話しかけられたりなど、潜んでいたマルウェアによる心温まる⁷攻撃がありました。

実際には、Windows 7／Windows 8サポート端末では脆弱なパスワード・キャッシュから平文パスワードを奪取する攻撃が行われたようです。CentOS 端末ではシェルにキーロガーが仕込まれており、キーロガーの除去もしくは通信の遮断を行わない限り、root パスワード変更などを含むあらゆる操作が kuromame6に筒抜けになっていたようです。

実際のビジネスが組織で行われることを考えれば、これはとても恐ろしいことです。誰か一人が標的型攻撃の実行ファイルを踏んでさえしまえば、そこを足がかりに最終的には管理権限が完全に奪取されてしまいます。その末路が日本年金機構であったりソニー・ピクチャーズだったりするわけです。強制アクセス制御や、操作端末の制限などの「ぱっと見面倒そう」な最小権限の原則も、こういった実例を目の当たりにすると必要性が実感できました。

正直、もうこのあたりから切羽詰まりすぎて記憶が飛んでいます。つらい。

応募フォームのWebアプリからの情報漏洩

「ありがち」なウェブアプリの SQL インジェクションが最後にやって来ました。Java で組まれたウェブアプリで入力値をバリデーションもエスケープも無く SQL にぶっ込んでしまう素敵フォームです。

このフォーム脆弱性への対応は、かなり各チームで対応が別れたのが面白いところです。ソースコードもサーバ内に同梱されていたので、そもそもの脆弱性自体を直したチームもあれば、フォーム自体を1から書き直してデータベースを利用しないメール送信フォームにしてしまったチーム、WAF を入れて対応を保留したチームと様々です。

どれが正解ということはなく、それぞれのチームが持つスキルに合わせた「最適な対応」の判断が求められます。

結果と反省

我らが Team4「セキュ子の部屋」は残念ながら圧倒的最下位という結果に終わりました。全体の結果は以下の通りです。

順位	見込み販売力	技術点	顧客点	対応点	経済点
1位：現地集合検知改ざん	31,142,860	2,450	3,140[1位]	3,540[1位]	7,300[1位]
2位：ちゃんぷるー	28,799,800	2,150	2,570	2,880	1,300[3位]
3位：SUNSUNSUN	28,367,320	3,200[1位]	2,570	2,770	1,100
4位：ちゅーばしんか	25,991,372	2,750[3位]	2,950[3位]	3,210	1,600[2位]
5位：秘密結社にんじんしりしり	25,145,656	2,900[2位]	2,570	3,320[2位]	1,100
6位：セキュ子の部屋	14,841,380	2,300	3,140[1位]	3,320[2位]	500

「見込み販売力」はいわゆるクローラーによる売上金額です。あくまで見込み販売力によって順位は決まりますが、それ以外の4つの評価点は以下のように設けられています。

評価項目	内容
技術点	脆弱性への対応、マルウェアの対応など
対応点	インシデント復旧時間、サイト全体の稼働率など
顧客点	サポート能力、ユーザ保護の取り組み
経済点	サービスや製品をたくさん使って市場を活性化したかなど

私たちのチームは売上では最下位だったものの、外部対応を担当した方の圧倒的努力のおかげで、顧客点・対応点では高い評価を得ることができています。その一方で、結果発表でもかなり突っ込まれていましたが、売上2位のチームが実は技術点では最下位だったりするのも、競技であるが故というところでしょうか。

優勝したチームは、マネージャはホワイトボードと付箋紙でタスク管理に注力して一切 PC を開かない、初動でマーケットプレイスからセキュリティエンジニア2名を競技時間まるまる買い占めて1チーム12名に増員⁸するなどという徹底したマネジメントとチームビルディングで勝利を掴みました。また、前日資料を元に、各サーバで起こりうる問題と対策の洗い出しなども行っていたようです。

脆弱なままのサービスは提供しないという選択

私たちのチームは「危険だとわかっているシステムは、まず安全性を確認してからオープンするのがお客様のためだ」という立場から、競技開始からまず初動作戦としてサービスを止め緊急メンテナンス画面を出して脆弱性の対策に振り切るという選択をしました。脆弱性を塞ぎ未然に防ぐことで繁盛レベルを稼ぎ、最終的な売上で他を引き離すという作戦です。負け惜しみでは無いですが、この選択そのものは間違っていなかったもののメリットを活かせませんでした。

まず事前準備の不足から脆弱性の対策に時間が掛かり、ずるずると「メンテナンス時間」が伸びてしまうという最悪なパターンに陥りました。まれに良く聞く話ですが、大変よろしくないです。これは「いつまでに・何ができなかったら・どうする」という復旧判断ができないから起こります。あらかじめ所持スキルにより担当システムの分担はしていましたが、こういった判断を最終決定する「責任者」を一人きちんと決めていなかったのが原因です。これもまれに良く聞く話ですね。恐ろしいことです。

マルウェアによる攻撃も絶対あるだろうという予想から、まずは Windows 端末にカスペルスキーを導入して守るという方針を立てたにもかかわらず、そもそもソフトウェアパッケージが大きくダウンロードに時間が掛かったり、Windows 10に入れようとして対応 OS の都合で入らなかったりなど問題が多く発生しました。Windows 端末が使えなくなるとメール送受信ができなくなると言う焦りの空回りから結局カスペルスキー一つに16時ぐらいまで引っ張っています。

さらに、最初に「正しい動作」を確認せずにいきなり Wordpress のバージョンアップに特攻した結果、EC サイトの本体である Wordpress のショッピングカートプラグインの不具合を踏み抜き、正しい在庫数が表示されないという問題が起きました。Softening Day の答え合わせまで原因が全くわからず、kuromame6による情報改ざん攻撃だと思い込み調査をしていました。在庫数がわからないため、適切なマーケットプレイスからの「仕入れ」もできず、結果として最後に一気に売上が落ちるというダメージを食らいました。無駄な調査に人員も取られました。

結果として、端末のマルウェアや業務アプリといったサービス停止で防げなかったインシデントの対応に追われたあげく、競技開始後から3時間もサービスを止めたにもかかわらず脆弱性への対応が不完全なままのサービス再開を余儀なくされました。そして、一時的に他のチームより繁盛レベルを高く維持できた時間帯がありつつも、売っているのに仕入れていないという問題でまったく売上を得ることができませんでした。

次回勝つために

負けたら悔しいのが人間です。ならば次にどうするかを具体的に考えます。

kuromame6からの講評では、技術点が最も高かったチームですら評価ポイントの1/3もクリアできていないようです。評価で重きを置かれるポイントは毎回変わるとはいえ、純粋に堅牢化の技術的そのものにもまだまだ根本的にひっくり返す余地がありそうです。

優勝チームを見習ったチームビルディング・マネジメントと、万全の事前準備による瞬発力のある堅牢化技術が合わさることで最強になれそうです。

何も考えずに脆弱性診断

全ての意志決定には十分な情報が必要となります。脆弱性診断に長けたメンバーが居るチームが今回の技術点1位を取っているとおり、やはり適切な脆弱性診断による現状把握が大事です。競技環境の構成がある程度わかっている以上、ツールでできるような脆弱性診断はなかば機械的に競技開始時点で開始すべきでしょう。

Softening Day での発表によれば、今回は EC サイトやコーポレートサイトが Wordpress ベースだったため専用の脆弱性スキャンツールである WPScan が有用だったようです。またサポート端末については一般的な脆弱性スキャナである Nessus だけでも色々発見できていたそうで、自分のチームに脆弱性診断の専門家が居なかった場合でもツールの使い方を予習しておくだけでかなりの成果が見込めそうです。

今回もそうだったように、Hardening Project ではその趣旨から「最近注目されている脆弱性」を取り上げる方向がありますので、それを発見できるような脆弱性診断方法を逆算して自動化して持って行ければ、さらに一歩先へ行けそうです。

あらかじめ仕込まれたマルウェアへの対応

今回のように、競技開始時点で脆弱性だけで無くマルウェア本体までが仕掛けられていた場合、本質的には「何も信じられない」という状態から始めることになります。たとえば既設のバックドアでリアルタイムに介入されることまで想定すると何もできなくなってしまいます。ですが、物理的に新しいサーバを追加できない競技環境では、競技を成立させるために「現実的なゆるさ」があり上手くそこに乗っかっていく必要があります。

何も信頼できない環境に安全な橋頭堡を築いていくのはある種のパズル的な要素がありますが、例えばシェルや SSH を信頼できる静的リンクバイナリとして持ち込んだり、脆弱性診断でなんとかしたりといった手が考えられます。Windows であれば、ひとまず機械的にオープンソースのアンチウイルスソフトを導入すると言った手もありそうです。

「なにかされても被害を出さない」という封じ込めも有効そうです。全ての通信が通るルータは VyOSで手が出せるので、マルウェア自身への対策と合わせて実施するのが良さそうです。

作業環境の改善

競技環境はとにかくサーバの種類が多いため、ただ単純に SSH やリモートデスクトップで一台ずつログインして手作業でコマンドを売って回るといくらあっても時間が足りません。1台2分の作業でも13台の CentOS サーバに一台ずつ廻るだけで30分近くも掛かってしまいます。

せっかく SSH が使えるのであれば、漏れたら最後また変えるしかないパスワードでは無く、参加者PC から出さなければ絶対に漏れない公開鍵認証を利用することで、パスワードのコピペという手間からも解放され大幅に作業効率が向上します。例えば競技用の SSH プライベート鍵を共有しておけばよいでしょう。

こういった作業環境の改善は、かなり属人性が強く個人のノウハウが詰まっていることが多いのですが、そういったテクニックをあらかじめチーム内で共有することで作業の初速が上がります。初速を上げることは、最初の攻撃シナリオの実施までの時間が稼げることにもなり、何倍にも効いてきます。

Wordpress の管理画面などはブラウザからのアクセスが必要ですが、CentOS で VNC サーバを利用するなど Windows 端末に頼りすぎない作業環境を作り込むことも効果が大きそうです。

自らのサービスの正しい把握

サービスを正しく運用するためには、それを実現するシステムの正しい把握が必要不可欠です。今回の EC サイトであれば、Wordpress のどういったプラグインでどのように実現されているか、売り上げ管理システムとの関係はどのようなものか、売上と仕入れの関係はどうなっているのか、そういったことを専門で面倒を見る「サービス担当者」が必要です。

事前の作り込み

こういったことを考えながら、事前に公開されている情報をもとに、競技環境を予測してそれに対する事前準備を作り込むことが勝利への第一歩です。

1. 更新ファイルの用意 Wordpress であれば最新版の ZIP パッケージや、競技環境のディストリビューションのアップデート RPM パッケージを持ち込むことで、素早いソフトウェア更新ができます。
2. ファイアウォールのルール 通すべき通信を予測して iptables や VyOS の ACL 案を作り込んでおき、素早く不必要な通信を記録・遮断することで、マルウェアの被害を防ぐことができます。
3. 認証情報の共有 パスワードの再設定、ユーザの整理は行うとして、変更後のパスワード一覧をあらかじめ乱数で作っておき、競技に使う SSH プライベート鍵をチームメンバーで共有しておくことで、これらの再設定を全て前もって自動化することができます。
4. 脆弱性診断の準備 競技環境に即した脆弱性診断ツールを用意しておきます。細かいことですが、存在しているシステムの全体がわかっているのであれば、例えば診断先 URL などもあらかじめ設定しておくと貴重な時間を有効活用できます。
5. 開幕ぶっぱなしスクリプト これら用意した道具を全てのサーバに流し込む作業をスクリプト化しておきます。SSH が使える環境であれば Fabric が有用ではないかと感じています。

感想

長々と今回の h10v という Hardening Project の紹介をしましたが、いかがだったでしょうか。楽しさと悔しさが伝われば幸いです。

次回は2016年6月に沖縄で開催されそうな雰囲気です。

是非一緒に参加して優勝を勝ち取りましょう！

Footnotes

1. Web Application Security Forum http://wasforum.jp/ ↩

2. #ssmjp http://ssm.pkan.org/ ↩

3. http://wasforum.jp/hardening-project/ ↩

4. https://youtu.be/I1Um1l_9Vw0 https://youtu.be/nWPwbCbktIY ↩

5. http://wasforum.jp/hardening-project/h10v-application/ ↩

6. http://www.iij.ad.jp/company/development/tech/techweek/pdf/151112_2.pdf ↩

7. 黙って悪用されて死体すら残らず殺されるよりは余程マシ ↩

8. その後「ガチャ」景品で10分間だけもう一人追加され、一瞬だけ13人体制でした。 ↩