2023年2月17日

NEC サイバーセキュリティ戦略統括部セキュリティ技術センターの榊です。昨年末のAWS re:Inventでは多数の新サービスが発表され、AWSファンの間では大変な盛り上がりだったかと思います。セキュリティ系のサービスもいくつか新たに発表、あるいは既存サービスのアップデートが発表されておりました。その中で私が注目したのは「Container runtime threat detection for GuardDuty」です。これは起動しているコンテナ、およびコンテナが実行されているEC2インスタンスのアクティビティを監視し、C&Cサーバーとの通信等、不審な挙動の可視化が期待されるもののようです。そこで本記事では、AWSにおけるコンテナを悪用したサイバー攻撃の検証結果を紹介します。

環境説明と攻撃の流れ

今回用意した検証環境のイメージと、攻撃の流れは以下の通りです。

ここでECR（Elastic Container Registry）とは、AWSが提供するフルマネージドなコンテナレジストリです。「フルマネージド」なので、本来コンテナレジストリを自前で作る際に必要な、OSやアプリケーションの構築・設定がほぼ不要なサービスです。大変便利ではありますが、アクセス権の設定を誤ると攻撃者に悪用される可能性があります。

検証結果

では早速検証をしていきます。まず、EC2（Victim）にてUbuntu ver.18.04をPullします。

次に、取得したUbuntuコンテナイメージをECRにPushします。

AWSマネジメントコンソールでECRを確認すると、PushしたUbuntuコンテナが格納されていることを確認できました。

続いてAttacker PCで上記のUbuntuコンテナをPullします。今回は簡単のため、Attacker PCとしてEC2インスタンスを使用しております。このEC2に対し、以下の通りECRに対するフルアクセスを許可するようなIAMポリシーを付与します。

この状態で、ECRに格納されているUbuntuコンテナをPullします。

続いて、このコンテナにリバースシェルを挿入します。今回はDocker Scan [*1]というOSSを使用しました。このツールはコンテナレジストリやコンテナイメージに対し、さまざまなタイプのスキャンや操作が可能なツールです。また、コンテナイメージにリバースシェルを挿入することも可能です。リバースシェルの挿入を実施する際は「trojanize」コマンドを使用します。

これで準備が完了しました。あとは、このコンテナイメージをECRにPushし、Netcatにてリバースシェルを待ち受けます。

EC2（Victim）にて、ECRからコンテナをPullして実行します。リバースシェルが成功しているかの確認のため、「flag」というファイルをコンテナ内に新規作成しておきます。

Attacker PCのターミナルを確認すると、EC2(Victim)とのコネクションが成立していることが確認できました。先ほど作成した「flag」というファイルも確認できることがわかります。

ちなみに以下のスナップショットにあるようなURLに対してアクセスすることで、このコンテナが起動しているEC2（Victim）のメタデータを抽出することが可能なケースもあります。場合によっては認証情報も窃取できてしまいますので、非常に危険です。

現状の対策

この攻撃の恐いところは、「誰が作ったかわからないコンテナイメージがEvilなコンテナだった」のではなく「自分たちが開発しているコンテナがEvilになっている」という点です。対策としては、主に以下の観点があると考えます。

まとめ

以上、Amazon ECR上の正規コンテナ改ざんに関するご紹介でした。クラウドやコンテナ等、比較的抽象度が高いサービスは、管理・監視のノウハウが不十分なケースも多くあるのではないかと想像します。「Container runtime threat detection for GuardDuty」に対する期待も抱きつつ、私自身もさらに色々な事例を検証し、今後も皆様に紹介してまいります。

参考情報

執筆者の他の記事を読む