AWS CDKの脆弱性が発覚したらしいので元レポートを読んでみた
「AWS CDKの脆弱性が発覚した」というニュース記事が流れてきたのですが、読んでも不安を煽るだけで何を言っているかよく分からない内容でした。
仕方がないので、脆弱性を報告したAqua Security社の記事を読んでみました。
非常に分かりやすくまとめてくれているので、マスコミのよく分からない記事で不安を感じている方は、原文を読むことをお勧めします。
超概要
見つかった脆弱性は、特定の手順を踏んでしまったCDK用のS3バケットを乗っ取れるという内容のようです。
脆弱性の影響の可能性があるアカウントには、2024/10/15 (日本時間だと2024/10/16かもしれない)にAWSから「Missing CDK bootstrap bucket」がタイトルに含まれるメールが送られています。
- メールが来てなければセーフです。(今回の脆弱性に対しては)安全です。安心してください。
- メールが来ていても攻撃を受けたり被害にあう可能性は限りなく低いので、冷静に対応しましょう。
メール来ていた場合の対処法はクラメソさんが即日まとめているので、そちらを参照するのが良いでしょう。
概要
攻撃を受ける流れをざっくり書くと以下のようになります。
- ユーザーが、CDKを使い始める。このタイミングでCDK用のS3バケットが作られる。
- ユーザーが、CDKがデフォルトで作成したS3バケットを手動で削除する。
- 攻撃者が、ユーザーが消したのと同じ名前のS3バケットを作って待ち構える。
- ユーザーが、CDKの利用を再開すると攻撃者が作ったS3バケットにファイルをアップロードしてしまう。
- 攻撃者が、アップロードされたファイルを書き換えることで悪さが出来る。
つまり、2のバケットの手動削除をしていなければ問題なしです。S3バケットを消した心当たりがある方には前述のメールが届いているのではないかと思います。
個人的な意見としては、脆弱性があったのは確かだと思いますが、ユーザーの行動に依存しまくる攻撃を仕掛ける暇な攻撃者なんているんですかね?素人目には何らかの方法でアクセスキーを奪取したほうが楽に攻撃できるのでは?と思ってしまいます。
なお、今回の問題はv2.149.0(7/13リリース)以降のCDKでは修正されていますので、古いCDKを使っている方はアップデートしておきましょう。
もうちょっと詳しく
攻撃の仕組みについて
この攻撃が成立するポイントとして、以下が挙げられます。
- S3のバケット名は、全世界で一意である。
- CDKをアカウント内で最初に使用する時(cdk bootstrap)にCDK用のS3バケットが作られるが、バケット名のデフォルト値は簡単に推測できる。
- 具体的なバケット名は
cdk-hnb659fds-assets-{account-ID}-{Region}
です。
- 具体的なバケット名は
2の理由により、攻撃者はターゲットのアカウントのCDKが自動生成するバケット名を推測できますので、ユーザーより先に該当のバケットを作ってしまう事が可能です。
1の理由により、攻撃者が先にバケットを作っている場合は同名のS3バケットを作ることが出来ません。通常はCDK利用開始時にS3バケットが作れないとエラーになりますので、CDKが使用するS3バケット名を変更すればそれで問題ありません。
ですが、概要に書いた手順を踏んだ場合、つまり「ユーザーが一度CDKで作成したS3バケットを手動で削除し、その後攻撃者が同名のS3バケットを作成した場合」は話が変わります。「CDKはユーザーが作ったS3バケットが存在していると勘違いしているので、攻撃者が作った同名のS3バケットを使用してしまう」という問題が発生します。
どのくらいのユーザーが影響を受けるの?
AWSの発表によると、CDKユーザーの1%が影響を受けるとのことです。
Aqua Security社の調査だと「38,560アカウントを調査した結果、782アカウント(2%)がCDKを使っていて、81アカウント(10%)が脆弱性が確認できた。」とのことです。つまり全体の0.21%のアカウントに脆弱性があったようです。
Aqua Security社の調査がCDKアカウントの10%が対象なのに対して、AWSの発表がCDKユーザーの1%が影響を受けるということで乖離があるのが気になるところではあります。
いずれにしても、超概要で書いたように該当者にはメールが届いていますので、不安な方はメールを確認しましょう。
今後のセキュリティ対策について
Aqua Security社は、今後はセキュリティ対策として以下の3点を推奨しているようです。
- 「AWSアカウントID」を秘密情報として扱う
- IAMポリシーでスコープを制限する
- 予測可能なS3バケット名を使用しない
個人的には2以外はあまり賛成できないです。理由は1や3は正規のユーザーの利便性や開発体験が低下する可能性が高いからです。「全てのものを隠して触れなくすれば安全です」というのは当然のことですが、それによって使いにくいサービスになったら本末転倒だと思います。一方でアクセス制限をすることで不正なユーザーを排除することは重要なので、2のIAMによる制限や管理は徹底するべきかと思いますし、少なくとも今回のような問題を防げます。
最後に
不安を煽る記事が出てるので気になって調べたけど、基本的には心配しなくてよいと思います。
ただ、レポートにはしれっと「調査したらついでに100以上のS3バケットで脆弱性を見つけたよ」的なことも書いてありました。今回の脆弱性以前の問題としてセキュリティ設定に不備があるケースも多いかと思います。この機会にAWSアカウントのセキュリティを見直してみるのもありかなと思いました。
また、繰り返しになりますがAqua Security社のレポートは分かりやすくて勉強になりましたので、セキュリティが気になる人やCDKを使っている人は読んでみることをお勧めします。
NCDC株式会社( ncdc.co.jp/ )のエンジニアチームです。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください! ※エンジニア以外も記事を投稿することがあります
Discussion