危ないAWS環境の共通点はここ！ペンテスターが攻撃者視点で指摘する

2019年04月24日 10時00分更新

　JAWS DAYSのようなカンファレンスでは、システムを開発し、運用し、守る側の視点からの取り組みが紹介されることが多い。これに対し「PenTesterが知っている危ないAWS環境の共通点攻撃者視点よりお届けする狙われやすいAWSの穴」では、普段、攻撃者と同じ手法を用いてシステムの脆弱性を洗い出す「ペネトレーションテスター」（ペンテスター）として活躍しているメンバーが、攻撃者の視点でAWSのどこに留意すべきかを、デモを交えながら解説した。

三井物産セキュアディレクションの洲崎俊さん

いくらプラットフォームが堅牢でも、ユーザーの使い方次第

　トップバッターの洲崎俊さんは、「皆さんご存知の通り、AWSはプラットフォームとしてはかなり堅牢。じゃあ安心安全かというと、実際にはS3バケットの中身を見られたり、侵害され仮想通貨の採掘に悪用されたりという事例も起きている。いくらプラットフォームが堅牢でも、ユーザーの使い方次第だ」と述べ、責任共有モデルを踏まえ、ユーザー側でもきちんと対策を講じることが重要だとした。

　では、攻撃者はAWSのどこを狙ってくるのだろうか。「やっぱり狙うなら『本丸』、つまりクレデンシャルの認証を取るのが一番効果的だと攻撃者は考える」（洲崎さん）

　AWSのクレデンシャルは、マネジメントコンソールにサインインする際に必要なIDとパスワード、つまり「アカウント」と、プログラムからAPIやAWS CLIを呼び出す際に必要な「アクセスキー」の2つに大別できる。どちらも、「クレデンシャルさえあれば、割り当てられた権限に応じてAWSサービスを好きなように操作できる。特にrootユーザーがとれれば『神』になれるため、攻撃者にとってはもっとも狙い目」だと洲崎さんは指摘する。

　AWSのベストプラクティスでは、アカウントについては多要素認証（MFA）を利用することを推奨している。これによって、総当たりや推測による不正ログインを防ぐ狙いだが、「残念ながら、全員が利用しているかというとそうではないため、どうしてもこういう問題は残る」（洲崎さん）のが実情だ。

　もう1つのクレデンシャルであるアクセスキーが漏れる経路としてもっとも多いのは「GitHub」だ。中には、わざとキーペアをGithubで公開してみたら、AWSよりも早く、たった15分で攻撃者がアクセスしにきたという一連の経緯をブログにまとめたエンジニアもいる。こうした検証ならばいいが、実際にはGitHub経由でアクセスキーが第三者に知られ、多額の料金請求を受けたケースも報告されている。

「じゃあGitHubを使わなければいいかというとそうではない。公開されているものだけがターゲットではないからだ。UberはGitHubのプライベートリポジトリを使っていたが、別のところでその認証情報が奪われ、プライベートリポジトリ経由でクレデンシャルが漏れて攻撃された。今の時代、ローカル環境が安全とは断言できない。標的型攻撃や別経路で侵入され、そこからクレデンシャル情報が奪われ、結果としてAWSが侵害されるケースは十分にあり得る」（洲崎さん）

　洲崎さんによると他に、Webアプリケーションの脆弱性が突かれ、AWSのクレデンシャルを奪われるケースもあるという。1つは、サーバサイドリクエストフォージェリ（SSRF）の脆弱性を付く手法だ。URLパラメータに細工を施すことで、ローカルサーバなど、通常ならばアクセスできない内部のリソースに外部からアクセスできてしまう。AWSに限らず、SSRFの脆弱性を突いてクラウドインスタンスのクレデンシャルを奪うテクニックは「バグバウンティ界隈では有名だし、インターネット上で情報が公開されている」（洲崎さん）

奪われるだけでも大事のクレデンシャル、さらに権限昇格の恐れも

　また、古典的だが、サーバ内に残存しているクレデンシャル情報を奪われてしまうこともあるそうだ。AWS CLIを普通に利用すると、サーバ内の特定の場所にクレデンシャルファイルが作成されることは周知の通りだ。攻撃者が何らかの方法でサーバに侵入した後に、このようにしてサーバ内に残ったままのクレデンシャル情報を奪っていくケースがあるため、注意が必要だ。

　クレデンシャルが奪われればそれだけでも大事だ。だが洲崎さんによると「場合によっては、問題はそれだけに終わらないのが問題視すべきところ」だという。

　「窃取されたクレデンシャルに付与されているIAMポリシーの種類や設定によってはさらに高い権限へと昇格されてしまう危険性がある。場合によってはルートを取られ、AWS環境を完全に掌握されてしまう恐れがある」（洲崎さん）

　たとえば、攻撃者が奪ったクレデンシャルに「ユーザーグループを追加する」「ポリシーを追加する」といったIAMポリシーが付与されていると、攻撃者はそれを用いて管理者に「繰り上がる」ことができる。IAMパスロールについても、Lambdaなどの関数実行権限が付与されていると、権限昇格の引き金になる可能性がある。

　洲崎さんは「環境にもよるが、クレデンシャルはただ取られて終わりではなく、設定やポリシーの状況によってはさらに昇格し、管理者権限を取られてしまう恐れがあることを覚えておいてほしい」とし、クレデンシャルに不用意にさまざまな権限を割り振らないよう留意すべきとした。

　続けて北原憲さんが、Rhino Security Labsが開発した「pacu」を用いて、洲崎さんが解説した攻撃者がAWSに侵入した後に権限昇格を果たすまでの一連の手口をデモンストレーションした。

ラックの北原憲さん

　デモでは、攻撃者が入手したアクセスキーに紐付けられているユーザーとIAMポリシーを確認し、権限昇格に利用できるIAMポリシーが含まれていることが分かると、IAMパスロールと実行可能なLambda関数（デモの例ではInvokeファンクションとCreateファンクション）を組み合わせ、Administrator Accessという権限が付いた別のロールをアタッチさせて管理者権限に昇格するまでを紹介した。

　こうしてひとたび管理者権限を入手すれば、あとはバックドアの作成だろうと、AWS Systems Managerを介してインスタンスに侵入しようと、何だって可能になる。北原さんはまた、侵入に利用されたアクセスキーが削除されたとしても、攻撃者にとっては永続的にアクセスするために新しいアクセスキーを作成してアタッチすることも容易なことを示し、非常に危険性が高いと説明した。

「ベストプラクティス」の徹底に尽きる対策、ツールの活用で少しでも負荷軽減を

　クレデンシャルが攻撃者にとって「狙い目」であり、万一入手された場合のリスクが非常に高いことも分かった。では、こうした攻撃手法から自社のAWSをどうやって守っていけばいいのだろうか。

　最後に登壇した一ノ瀬太樹さんは「基本的なことだが、『クレデンシャル自体の漏洩を防止する』『クレデンシャルの悪用を抑制する』『悪用されたことを検知する』という3つのアプローチがある」と述べた。いずれも当たり前といえば当たり前のことだが、「やはり一番大事なのは、IAMベストプラクティスをきちんと守ること」に尽きるという。

三井物産セキュアディレクション一ノ瀬太樹さん

　「特に、アクセスキーの扱いには注意が必要だ。必要以上に発行しないようにするとともに、不要なものは削除する。退職者が出たらその際にきちんと棚卸しをしたり、開発・運用ルールを定めてきっちり管理するなどして、運用をしっかりやっていく必要がある」（一ノ瀬さん）。さらに、このアクセスキーを取り扱うサーバ自体のセキュリティもチェックしなければならないとした。

　ただ、AWSのベストプラクティスに従って設定・運用をきっちり行おうとすると、やるべき事柄は多い。その負荷を減らす工夫の1つとして「いろいろな会社が、IAMポリシーやAWSのベストプラクティスを監査できるさまざまなツールを有償・無償で提供している。今できることとしては、こういったツールを活用して運用を容易にしていくことが挙げられるだろう。ただ、ツールも万能の神様ではない。定期的に見直しを行い、ツールでできることとできないことをしっかり把握して利用することが非常に大事だ」（一ノ瀬さん）。

　そもそもAWS自体日々進歩しており、気がつくと新たな機能が追加されている。「こうした新しい機能は、最も悪用されやすい部分になる可能性がある。新機能にそれらツールが追従しているか、メンテナンスされているかを考慮して使っていく必要がある」と一ノ瀬さんは述べた。

　一ノ瀬さんはほかにも、