AWSへの不正アクセスを防ぐために気をつけておいた方が良いことを紹介します
まずはIAMのベストプラクティスに則ることが最も大切ですが、この記事では実際にどのような攻撃手法で不正アクセスを試みるのかを紹介しつつ、その対策方法も記載していこうと思います。
IAMベストプラクティス
S3セキュリティベストプラクティス
1. アクセスキーの漏洩によるAWSの不正利用
どうやっているか
AWSを利用している人にとってはお馴染みの攻撃手法だと思います。
実際にGithubに上げてみたところ13分で抜き取られるというQiitaの記事もあるぐらいですので、仕事/プライベート関らず対策が必要です。
GitHub に AWS キーペアを上げると抜かれるってほんと???試してみよー!
ちなみに大体のアクセスキーを抜いてくる方々は、抜いたあとに
新しいIAMユーザー発行をする > 新しいユーザーでお高いインスタンス建てる > マイニング
のパターンが多い印象です。
対策方法
- そもそもアクセスキーを使わずにIAMロールを使用する。
- けどローカル開発どうすんの?っていう場合にはaws-mfaを使って個人のMFAを利用して毎回一時キーを発行するようにする。
- この構成の場合だとアクセスキーは残りますが、MFA認証が通らない限り権限の発行が制限されます。
-
~/.aws/credentials
以下に一時キーは残るので、duration-seconds
は短めに設定するのがオススメです。
- いやいやそんなすぐにキーを使わなくするのは無理だよ、っていう場合にはgit-secretsを使用するのがオススメです。
- 最小権限を付与する
- 権限管理の基本ですね。すべての項目でこれは守る必要があります。
- IAMベストプラクティス
2. RDP/SSHプロトコルのインターネット公開によるEC2への不正アクセス
以下の資料を参考にしています。
https://www.lac.co.jp/lacwatch/pdf/20200130_cecreport_vol8.pdf
どうやっているか
上記でIAMロールを使用した方が良いと書きましたが、このパターンはEC2インスタンスにIAMロールを付与していることを逆手にとった攻撃手法になります。
またこの攻撃はインスタンス内部にマルウェアを仕込むなどやりたい放題できるので、注意が必要です。
以下のように攻撃が進むと思われます。
- 対象のインスタンスにIAMロールを付与している状態
- 対象のインスタンスへインターネット経由で接続可能(
0.0.0.0/0
でオープン)な状態 -
admin/admin
のような簡単なパスワートを設定しているな状態 - 攻撃者がパブリックなインスタンスを調査
-
admin/admin
のようなパスワードでインスタンスに不正アクセス
対策方法
- インターネット経由でアクセスをする場合はIP制御を入れる
-
0.0.0.0/0
でアクセスできるセキュリティグループを検知できるようにするのも良いかと思います。
-
- 簡単なパスワードを設定しない
- sshであれば公開鍵暗号が推奨だと思います。
- windowsの場合は
aws workspace
+MFA
で二段階認証にする - 最小権限を付与する
- また出てきました。大事なことだと思います。
- IAMベストプラクティス
3. パブリックS3への不正アクセス
以下の資料を参考にしています。
https://recruit-tech.co.jp/blog/2019/05/10/cardstealer/
どうやっているか
AWS S3のbucketポリシーの設定不備を狙った攻撃になります。
以下のように攻撃が進みます。
- 攻撃者は、AWS S3のPublic Bucketsを調査
- 攻撃者は、見つかったAWS S3に対し、バケットポリシーをチェック
- 攻撃者は、PUT権限がついていると分かると、正規のJavaScriptにマルウェアを混入してアップロード
- マルウェアは、改ざんされた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/
対策方法
-
SSRF
を発生させないような実装。使用するプラグインなども考慮が必要そうです。 - 最小権限を付与する
- やっぱり大事なことだと思います。面倒くさがらず必要な分だけ付与しましょう。
- IAMベストプラクティス
まとめ
攻撃方法が多くて嫌になってしまいますね。。AWSを利用するときは便利な部分ばかりフォーカスされがちですが、使い方によってはマイナスな面も存在することを頭に置いておきましょう。
あとベストプラクティス読みましょう!!!!
IAMベストプラクティス
S3セキュリティベストプラクティス
Author And Source
この問題について(AWSへの不正アクセスを防ぐために気をつけておいた方が良いことを紹介します), 我々は、より多くの情報をここで見つけました https://qiita.com/picapica/items/3bdd9fa956bb9937bb9c著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .