AWSへの不正アクセスを防ぐために気をつけておいた方が良いことを紹介します

まずはIAMのベストプラクティスに則ることが最も大切ですが、この記事では実際にどのような攻撃手法で不正アクセスを試みるのかを紹介しつつ、その対策方法も記載していこうと思います。

IAMベストプラクティス
S３セキュリティベストプラクティス

1. アクセスキーの漏洩によるAWSの不正利用

どうやっているか

AWSを利用している人にとってはお馴染みの攻撃手法だと思います。
実際にGithubに上げてみたところ13分で抜き取られるというQiitaの記事もあるぐらいですので、仕事/プライベート関らず対策が必要です。

GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！

ちなみに大体のアクセスキーを抜いてくる方々は、抜いたあとに
新しいIAMユーザー発行をする > 新しいユーザーでお高いインスタンス建てる > マイニング

のパターンが多い印象です。

対策方法

1. そもそもアクセスキーを使わずにIAMロールを使用する。
   • IAMロールの委任
2. けどローカル開発どうすんの？っていう場合にはaws-mfaを使って個人のMFAを利用して毎回一時キーを発行するようにする。
   • この構成の場合だとアクセスキーは残りますが、MFA認証が通らない限り権限の発行が制限されます。
   • ~/.aws/credentials以下に一時キーは残るので、duration-secondsは短めに設定するのがオススメです。
3. いやいやそんなすぐにキーを使わなくするのは無理だよ、っていう場合にはgit-secretsを使用するのがオススメです。
4. 最小権限を付与する
   • 権限管理の基本ですね。すべての項目でこれは守る必要があります。
   • IAMベストプラクティス

2. RDP/SSHプロトコルのインターネット公開によるEC2への不正アクセス

以下の資料を参考にしています。
https://www.lac.co.jp/lacwatch/pdf/20200130_cecreport_vol8.pdf

どうやっているか

上記でIAMロールを使用した方が良いと書きましたが、このパターンはEC2インスタンスにIAMロールを付与していることを逆手にとった攻撃手法になります。
またこの攻撃はインスタンス内部にマルウェアを仕込むなどやりたい放題できるので、注意が必要です。

以下のように攻撃が進むと思われます。

1. 対象のインスタンスにIAMロールを付与している状態
2. 対象のインスタンスへインターネット経由で接続可能(0.0.0.0/0でオープン)な状態
3. admin/adminのような簡単なパスワートを設定しているな状態
4. 攻撃者がパブリックなインスタンスを調査
5. admin/adminのようなパスワードでインスタンスに不正アクセス

対策方法

1. インターネット経由でアクセスをする場合はIP制御を入れる
   • 0.0.0.0/0でアクセスできるセキュリティグループを検知できるようにするのも良いかと思います。
2. 簡単なパスワードを設定しない
   • sshであれば公開鍵暗号が推奨だと思います。
3. windowsの場合はaws workspace + MFAで二段階認証にする
4. 最小権限を付与する
   • また出てきました。大事なことだと思います。
   • IAMベストプラクティス

3. パブリックS3への不正アクセス

以下の資料を参考にしています。
https://recruit-tech.co.jp/blog/2019/05/10/cardstealer/

どうやっているか

AWS S3のbucketポリシーの設定不備を狙った攻撃になります。

以下のように攻撃が進みます。

1. 攻撃者は、AWS S3のPublic Bucketsを調査
2. 攻撃者は、見つかったAWS S3に対し、バケットポリシーをチェック
3. 攻撃者は、PUT権限がついていると分かると、正規のJavaScriptにマルウェアを混入してアップロード
4. マルウェアは、改ざんされたJavaScriptがロードされる全てのページにおいて、クレジットカード情報の入力があるとその情報を取得し、データを送信

また昨今のサーバーレス構成の場合静的ファイルをPublic Bucketsでおく場合が多いですが、こちらに機密情報を入れておくと簡単に抜きとられるリスクがあるので、これも注意が必要です。

対策方法

これに関しては対策すべきことが多いのですが、基本はS3のセキュリティベストプラクティスに則りましょう。
基本的には 限られたリソースを公開すると最小限の権限しか許可しないが大切です。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/security-best-practices.html

4. SSRFを介したインスタンスプロファイルへのアクセス

以下の資料を参考にしています。
https://piyolog.hatenadiary.jp/entry/2019/08/06/062154

IMDSv2のアップデートによってX-Forwarded-Forヘッダーが付与されている時にアクセストークンを発行しないなどの改善がされていますが、ほとんどのEC2が依然v1を使っている状態だと思いますのでこちらもあげさせてもらいました。
https://aws.amazon.com/jp/blogs/news/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

どうやっているのか

まずこの攻撃方法を理解するにはSSRFとインスタンスプロファイルを理解する方法があります。
SSRFとは公開サーバーを通して内部サーバーへのアクセスが可能な状態なことを言います。

例えば以下のような公開サーバーへのhttpアクセスで内部サーバー 169.254.169.254へ自由にアクセス可能な状態を指します。

http://{FQDN}/dispatch?ip=169.254.169.254/latest/meta-data/iam/security-credentials/

次にインスタンスプロファイルとはインスタンス内部からのみ一時キーをhttpリクエストで取得する機能です。

SSRFとインスタンスプロファイルが組み合わさると以下のようにアクセスキーの不正取得が可能です。

イメージ

wordpressにもSSRFの脆弱性があったりするので、複雑ですが意外と攻撃しやすい手法なのかもしれません。
https://wordpress.org/support/topic/ssrf-vulnerability-server-side-request-forgery/

対策方法

1. SSRFを発生させないような実装。使用するプラグインなども考慮が必要そうです。
2. 最小権限を付与する
   • やっぱり大事なことだと思います。面倒くさがらず必要な分だけ付与しましょう。
   • IAMベストプラクティス

まとめ

攻撃方法が多くて嫌になってしまいますね。。AWSを利用するときは便利な部分ばかりフォーカスされがちですが、使い方によってはマイナスな面も存在することを頭に置いておきましょう。

あとベストプラクティス読みましょう！！！！
IAMベストプラクティス
S３セキュリティベストプラクティス