「AWS Game Day Tokyo 2013」に行ってきたら、AWS界隈でMost EVILになってました。
先日「AWS Game Day Tokyo 2013」に行ってきました。
「AWS Game Day Tokyo 2013」とは？
アメリカ大統領選挙のオバマ陣営「Obama for America」が堅牢なシステムを作り上げるために、「Game Day」という手法を用いました。「Game Day」とは、敵味方に分かれてシステムを攻撃、防御/修復を行い、脆弱性の発見とその修復方法を考えるものです。
これを、日本で初めて行おうというのが「AWS Game Day Tokyo 2013」です。世界でも、「Obama for America」、南アメリカに続きまだ3回目で、これまでで最大規模で開催されました。
Game Start !
朝10時に、会場に着くとAWS界隈の濃いメンバーが集まっており、効果的な攻撃方法を話し合ってました。
- Reserved Instanceを大量購入する破産攻撃
- 使用するアカウントでEnterprise Support(最低$15,000！)に入ってしまう
- etc
等々、効果的な作戦が上がってましたよ。
皆が集まるとルール説明がありました。
- 全体参加者で3チームに分かれ、別の部屋で行う。
- チーム毎に。さらに2、3人でチームに分かれて、別の部屋のチームと対戦する。
- まずシステムを構築する。対戦相手のシステムを攻撃しあう。攻撃された自分のシステムを修復する。
- 単に消すような攻撃はつまらない。分からないように壊して下さい。
- お金がかかる攻撃はNG！
ルール説明の後、チーム分けがされました。チームが発表されると、参加者に国家公務員の所属とかセキュリティ企業の人がおり、ザワザワしました。
自分のチームは、AWSに慣れている方は少なめで、セキュリティ関連の方の割合が多かったです。組んだ方は、#自宅ラック勉強会の@seafayさんでした。
Prepare to Game !
最初に守るシステムを構築します。簡単に説明するとQueueに入っている複数URLの画像を取り出して、画像を結合し、S3へ出力するというシステムです。実際に処理をするサーバはAuto Scaling構成になっています。システムの内容はnginksさんのブログが詳しいです。
手順書に従ってシステムを構築するのですが、対象のリージョンが決まってたり、既定の時間が足らなくなってしまい、最終的には用意されていたCloudFormationで一発でStackを構築してしまいました。今思うと、自分で構築した方がカスタマイズできて、より面白かったかなと思います。
周りを見渡すと、自分のシステムを守るためにnmapの実施確認をされている方もいましたが、AWSでは事前申請が必要なのでNGとなり、ションボリされていました。
自分のチームでは、時間がなかったため防御のためにAuto Scaling Groupにに仕込みを入れておきました。
Let's Attack !
昼食後に、「いつ攻撃するの？」(玉川さん)「今でしょ！」(Miles Ward)の掛け声で、攻撃を開始しました。
攻撃の内容、基本的に以下の方針を考えていました。意地が悪い内容ですね！
- なるべく、AWS Management Consoleからは見えない部分を叩く。
- 直したつもりになっても戻らない。
- 一度直しても、いつの間にか元に戻る。
その結果、以下の攻撃を行いました。
- Auto Scaling GroupをScheduled Actionで毎分max size、min sizeを0台に上書きする！
- Auto ScalingのLaunch Configurationを別の物に変更して、マシンが上がっても動作しないようにする。
- Launch Configurationの元の設定を削除して、元の名前でダミーの設定を用意しておく。
- S3の権限を全て消しておく。
- S3のBucket Policyでアクセスを拒否しておく。
- SQSをダミーで大量に作成しておく。
Auto Scaling GroupをScheduled Actionは、実は防御の仕込でも使ってました。
攻撃中に他のチームは、課題のアプリケーションの脆弱性を付いてSQSにコマンドを投げ込むコマンドインジェクション(名付けて"SQS Injection"？)等の高度な攻撃をされていました。一番驚いたのが、相手のIAMのPower Userしかないのに、KeyPair無しでrootの奪取をしたチームが有りました。
SQS経由でコマンドインジェクションでどうにかしたんでしょうか？私の拙いスキルでは、あまり想像つきません。
Repair
攻撃の次は、修復を行います。このシステムで使用している以下の主要サービスを見ていきました。
- Auto Scaling Group
- S3
- SQS
- EC2
最初はAuto Scaling Groupです。Auto Scaling Groupを確認しましたが、台数やAMIは正常でした。また、Launch ConfigurationもIAM Roleが設定されているので正常と判断しました(Power UserではIAM Roleが設定できないのです)。また、Scheduled Actionも設定されていませんでした。
次に、S3ですが、ユーザのパーミッションもBucket Policyを問題ありませんでした。
そして、SQS。キューのパーミッションはDefault Policyの設定で、Queueもからの状態でした。
最後にEC2です。Auto Scaling構成なので、とりあえずインスタンスをTerminateして、勝手にインスタンスが上がってくるのを待ちました。その後、SSHでログインが正常にできました。
どこに攻撃がされているのか分からないまま、Queueに画像のURLを投入すると、結果の画像がS3へ正常に出力されました。
何所に攻撃されたの？？？
攻撃された箇所が分からず、動作に関係が無いSecurity Groupの設定や別リージョンを確認しましたが何もわからずに、時間が過ぎていきタイムアップとなりました。
Discussion
最後は、対戦相手と攻撃の修復の内容を話し合います。相手に何所を攻撃したのか聞くと、SQS経由でコマンドを投入し、サービスをいじったりや巨大ファイルを作成したりと大胆な攻撃をしたそうです。しかし、こちらの修復方法がEC2をTerminateすると勝手にインスタンスが立ち上がるという事なので、きょっとショックを受けていたような。
そして、こちらの攻撃の説明をした後に修復方法を聞くと、結局CloudFormationで修復したそうです。どんなに頑張っても、最強のCloudFormationで一発で直りますよね。正しい修復方です。
他のチームの攻撃を聞くと、SQSに巨大なファイルを突っ込んだ上でタイムアウトを短くし、次に投入するQueueを消してしまうという凄い攻撃や、出力先S3のLifecycle Ruleを変更して1日後にGlacierへ移動してしまうというお洒落な攻撃がありました。
Evaluation
Miles氏からの講評あり、なんと我チームが「Most EVIL break!賞」を受賞しました。正直、SQS関連への攻撃で皆高度な攻撃を仕掛けていたので無理かなと思っていたのですが、Management Consoleから見えない部分を突いたのが評価されたみたいです。Milesには、これで「Most EVLI！」覚えてもらったようです。
あと、最も優れた修復を行った「Most AWESOME fix!賞」は@ijinさんが受賞されました。
Miles氏が言っていたことで最も印象的だったのが、「RepairよりRebuildの方が簡単にできるようになる」、「あるべき状態の振る舞いを定義を保存しておき、現状と比較し、自己治癒し続けていくというのが最高のシステム」という２つです。
最近では、Chef、PuppetとServerSpecでServer Provisioningが普及し始めていますが、今度はCloudFormationやOpsWorksでSystem Provisioningが進んでいくと言う事なのでしょう。System as Code(Not Application)とでもいうのでしょうか？
最後に
システムを攻撃すると言う事はあまり経験できることではないので、今回のGame Dayは非常に勉強になりました。
今後の改善点かなと思うところは、
- 攻撃、修復のターンを複数回のが良い。
- VPC環境のシステムにする(ネットワーク系の設定ができるので)。
- 修復する時の手段を制限する(CloudFormationは強力すぎるので、作り直せば何でも直せてしまう)。
- 攻撃の前に防御策を行う時間をもう少し取った方が良い。
次のre:InventでもGame Dayを行うようなので、東京リージョン代表として是非参加したいと思います。問題は渡航費をどうやって捻出するかだなあ。
Milesを始め、AWSのSAの皆様有難うございました。
あと同じチームになった@seafayさん、有難うございました。
