JAWS DAYS 2019に登壇した時の資料です。 セッション中の攻撃デモの動画は以下となります。 https://youtu.be/AyzrYEM601w

1. PenTesterが知っている
危ないAWS環境の共通点
~攻撃者視点よりお届けする狙われやすいAWSの穴~
2019/2/23
JAWS DAYS 2019

2. Shun Suzaki(洲崎 俊)
Twitter:@tigerszk
ITイベントの参加・開催や日々の脆弱性検証をライフワークと
する「とあるセキュリティエンジニア」
Daiki Ichinose(一ノ瀬 太樹)
Twitter:@mahoyaya
Perlが好きなウィークデーバグハンター。
土日は家族サービスとコミュニティ活動に勤しんでいる。
Ken Kitahara(北原 憲)
博士（理学）。物理学で博士号を取得してから、2014年4
月から縁も所縁もない情報セキュリティ業界で働き始める。
ネットワーク系のサイバー攻撃技術が専門。

3. AWSのセキュリティは？
 プラットフォームとしてのセキュリティは堅牢
 強固な物理セキュリティ
 自由に冗長化やスケーリングが可能
 便利なマネージドサービスが用意されている

4. じゃあ安心安全？
 仮想通貨盗掘？ ベーシック、AWSで不正アクセス被害
https://www.nikkei.com/article/DGXMZO39233590R21C18A2000000/
 AWS営業担当者の設定ミスでGoDaddyの機密情報が公開状態に
https://japan.zdnet.com/article/35123924/
 ホンダの海外法人が5万人分を超える顧客情報をクラウド上で公開していた
https://gigazine.net/news/20180609-honda-app-leaked-personal-
information/

5. 伝えたいこと
 当たり前だが、AWSを使っていたとしても、
セキュリティインシデントは発生しうる
 プラットフォームが堅牢でも、
最終的にはユーザの使い方次第
 システムを運用していく中で、脆弱性が作り
こまれる可能性もある
 安全に使うには、ユーザ側にてセキュリティを意識
した対策が必要

6. 責任共有モデル
 低レイヤーはAWSがカバーするが、高レイヤー部分は
ユーザ―が対策しなければならない
責任共有モデル – アマゾン ウェブ サービス (AWS)より引用
https://aws.amazon.com/jp/compliance/shared-responsibility-model/

7. 安全にAWSを利用するためには
1. オンプレ環境などと同様の対策が必要
実装時や運用で作りこまれてしまう脆弱性などはオンプレなどと同じ
EC2などで稼働するアプリケーションのセキュリティは大丈夫？
2. AWSサービスごとに個別の対策が必要
S3、IAM、セキュリティグループなどの設定は大丈夫？
3. 必要に応じて便利なマネージドサービスを利用
CloudTrail、AWS WAF、Guard Duty、Amazon Inspector etc…

8. ここら辺のことは
他のセキュリティセッションでも
沢山話があったかと思います。

9. ここからは攻撃者視点での
AWSセキュリティについてのお話

10. AWS環境で狙うなら何？
どうせ狙うのならやっぱり
Credential（認証情報）
ですよね？

11. AWSにおけるCredentialとは
AWSサービスを利用するために必要な認証情報
 AWSアカウント（ルートユーザ・IAMユーザ）
 ID
 パスワード
 アクセスキー
 アクセスキーID
 シークレットアクセスキー

12. AWSアカウント
 AWS マネジメントコンソールへのサインインに
必要となる
AWS Management
Console
AWS Cloud
ルートユーザ
IAMユーザ
ID
パスワード
ID
パスワード

13. アクセスキー
 AWS API、AWS CLI、AWS SDK、または Windows
PowerShell 用 AWS ツールから AWS をプログラム
で呼び出す場合に使用する
ルートユーザ
IAMユーザ
アクセスキーID
シークレットアクセスキー
アクセスキーID
シークレットアクセスキー
AWS Cloud

14. Credentialがあれば何でもできる
• Credentialがあれば、割り振られた権限に応じ
てAWSのマネージドサービスを好きなように
操作できる
• Credentialにルートユーザの権限があれば、
そのAWS環境においては、神になれる

15. つまりAWS環境では
Credentialを悪用されてしまう状況が
最も危険

16. Credentialはどのように窃取される？
今回はCredentialを窃取されてしまう
良くある事例をご紹介

17. AWSアカウントの場合

18. マネジメントコンソール経由での
不正ログイン
 MFA（多要素認証）が有効でなければ当然狙い所
 何らかの方法でユーザID・パスワードを窃取もしくは推測
され、マネジメントコンソールなどから不正ログインされ
てしまう
 ありがちなのは、単純なパスワードの設定や
「パスワードの使い回し」問題
 海外のペネトレーションテストでは、ソーシャルエンジニ
アリングのテクニック利用したスピアフィッシングなどで、
ユーザID・パスワード情報を取得している

19. アクセスキーの場合

20. Gitリポジトリ経由での漏洩
 Github上にAWSのアクセスキーが公開されたことに
より、漏洩するケースは多い
【事例】
• AWSで不正利用され80000ドルの請求が来た話
https://qiita.com/koyama9876/items/add70cba3cccdb7fa995
• 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。
https://qiita.com/mochizukikotaro/items/a0e98ff0063a77e7b694
• AWSが不正利用され300万円の請求が届いてから免除までの一部始終
https://qiita.com/AkiyoshiOkano/items/72002409e3be9215ae7e

21. AWSもスキャンしてくれてるけど…
 AWSもGitを検索し、アクセスキーを公開している利用者の
リポジトリに通知してくれているが、攻撃者も同じことを
やっている
 そのためAWSからの通知前に悪用される可能性がある
【参考】
• GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！
https://qiita.com/saitotak/items/813ac6c2057ac64d5fef

22. 公開されているものだけがターゲット
というわけでもない
 Uber社の情報漏洩では、非公開部分のGitHubよりアクセスキー
を奪取されてしまった
 標的型攻撃など、別経路で侵入された場合には、内部環境に配
置してあるファイルからCredentialを奪取されてしまう可能性
もありえる
【参考】
• Uber Paid Hackers to Delete Stolen Data on 57 Million People
https://www.bloomberg.com/news/articles/2017-11-21/uber-
concealed-cyberattack-that-exposed-57-million-people-s-data

23. アプリケーションの脆弱性を利用さ
れるケースも
 Webアプリケーションやミドルウェアの脆弱性を突かれるこ
とによって、Credentialを窃取されてしまう可能性もある
【紹介する事例】
SSRFを利用したCredentialの窃取
サーバ内部に配置されたCredentialの窃取

24. SSRFを利用したCredentialの窃取
 SSRF (Server Side Request Forgery)とは？
【参考】
• SSRF(Server Side Request Forgery)徹底入門
https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html
攻撃者から直接到達できないサーバーに対する攻撃手法の一種
内部NWのサーバー公開サーバー
攻撃者
脆弱性を悪用するリクエストを送信
本来はアクセスできない内部NWサーバ
に任意のリクエストを送信し、結果を受
け取れてしまう
内部NWに直接アクセスできない
xxx/?URL= http://192.168.1.1
xxx/?URL=http://www.example.com
http://192.168.1.1

25. AWS APIを利用してCredentialを取得
 IAMロールが紐づいた状態のインスタンスにて、AWS APIへ
一時的なCredentialを要求するリクエストを強制させられ、
EC２のIAMロールに紐づいたCredentialを窃取されてしまう。
AWS側のメタデータAPISSRFの脆弱性が存在するEC２攻撃者
脆弱性を悪用するリクエストを送信 AWSのメタデータAPIに対して
一時的なCredentialを勝手に要求
Credentialを含んだ結果が返るCredentialを窃取
【参考】
• インスタンスメタデータとユーザーデータ
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-
metadata.html
xxx/?URL=http://169.254.169.254/latest/meta-data/…
xxx/?URL=http://www.example.com
http://169.254.169.254/latest/meta-data/…

26. Credentialを取得した結果

27. サーバー内に配置されているCredential
 サーバー内にアクセスキーが配置されていたり、設定ファイル
などが残存しているケースがある
 AWS CLIなどを利用している場合には、以下の場所か環境変
数に設定されていたりするが他の場所にあることも
 Linux:
/home/USERNAME/.aws/credentials
 Windows:
C:UsersUSERNAME.awscredentials
 この場合、サーバー内に侵入された場合や、システム内部の
ファイルを読み取ることができるような脆弱性（ディレクトリ
トラバーサルなど）を利用されることなどによって、取得され
てしまう可能性がある

28. 場合によっては
これで終わりではない…

29. 権限昇格される可能性
 窃取されたCredential付与されたIAMポリシーの種類や設
定状況などによっては、さらに高い権限へと権限昇格され
てしまう可能性がある
 場合によっては管理者権限を奪取されAWS環境を完全掌握
される可能性もありうる
Privileges Escalation

30. 権限昇格されてしまう例～その１～
 以下の権限のいずれかが割り当てられている場合には、ポリシーを勝
手に追加することにより、ポリシーの権限を奪取して、権限昇格可能
 当然ながら他にもIAMポリシーを作成、追加、更新などできる権限が
割り振られている場合にも、同様の手法で権限昇格が可能
IAMポリシー 用途
iam:AttachUserPolicy ユーザのポリシーを追加
iam:AttachGroupPolicy グループのポリシーを追加
iam:AttachRolePolicy ロールのポリシーを追加
AWS CLIの実行例
//ポリシーの追加
$ awd iam attach-user-policy –-user-name <対象のユーザアカウント>
--policy-arn <権限が高いポリシーのARN>
$ awd iam attach-group-policy –-group-name <対象のグループ>
--policy-arn <権限が高いポリシーのARN>
$ awd iam attach-role-policy –-role-name <対象のロール> --policy-arn <権限が高いポリシーのARN>

31. 権限昇格されてしまう例～その2～
IAMポリシー 用途
iam:PassRole 存在するロールを資源に割り当て
lambda:CreateFunction 新たなLambda関数を作成
lambda:InvokeFunction Lambda関数を実行
AWS CLIの実行例
//Lambda関数の作成
$ aws lambda create-function --function-name <作成する関数名> --runtime python3.6
--role <割り当てるロールのARN> --handler <作成する関数名>.<スクリプト内で定義した関数名>
--zip-file <Lambda関数を定義したPythonスクリプトをzip化したファイル>
//Lambda関数の実行
$ aws lambda invoke --function-name <作成した関数> <実行結果出力先ファイルパス>
 以下の三つの権限が割り当てられており、 権限の高いLambda関数の
IAMロールが存在する場合には、任意のロールを割り当てた新たな
Lambda関数を作成し、呼び出すことによって、権限昇格が可能となる
 Lambda以外のマネージドサービスでも同様の手法で権限昇格が可能

32. 作成するLambda関数のpythonスクリプトの例
 指定したユーザを管理者権限グループに追加するスクリプト
 もし権限の高いLambda関数のIAMロールが存在する場合などには、
権限を割り振られて実行されてしまう可能性がある
import boto3
def lambda_handler(event, context):
client = boto3.client(‘iam’)
response = client.attach_user_policy(
UserName = ‘my_username’,
PolicyArn = ‘arn:aws:iam::aws:policy/AdministratorAccess’
)
return response

33. AWS環境への攻撃デモ

34. 情報収集 権限昇格
バックドアの
設置
AWSサービス
の悪用
デモのシナリオ
 何らかの経路でAWS Credentialを入手した後、そのCredentialを
元に攻撃者がAWS環境に侵入するというデモです。
 攻撃者は侵入後にAWS環境に対して以下の行為を行います。

35. Pacu
 今回のデモで利用している
AWS Exploitation Framework
 Rhino Security Labsが公開
 OSSであり、python3で開発されている
 AWSのアクセスキーをセットして使用する
https://github.com/RhinoSecurityLabs/pacu

36. Demo

37. 対策

38. 対策のアプローチは多く分けて三つ
1. Credentialの漏洩を防止
2. Credentialの悪用を抑制
3. Credentialを悪用されたことを検知

39. IAMのベストプラクティスに従おう！
【参考】
• AWS IAM ベストプラクティスのご紹介 – AWSアカウントの不正利用を防ぐために
https://aws.amazon.com/jp/blogs/news/aws-iam-best-practice/
• AWS を安全に使うために（IAM のベストプラクティス）
https://dev.classmethod.jp/cloud/sugano-042-iam-best-practices/
IAM のベストプラクティス
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html
AWS アカウントのルートユーザー アクセス
キーをロックする
悪用を抑制
個々の IAM ユーザーの作成 悪用を抑制
IAM ユーザーへのアクセス許可を割り当てる
ためにグループを使用する
悪用を抑制
最小権限を付与する 悪用を抑制
アクセスレベルを使用して、IAM 権限を確認
する
悪用を抑制
ユーザーの強力なパスワードポリシーを設定 漏洩を防止
特権ユーザーに対して MFA を有効化する 悪用を抑制
Amazon EC2 インスタンスで実行するアプ
リケーションに対し、ロールを使用する
漏洩を防止
ロールを使用したアクセス許可の委任 悪用を抑制
アクセスキーを共有しない 漏洩を防止
認証情報を定期的にローテーションする 漏洩を防止
不要な認証情報を削除する 漏洩を防止
追加セキュリティに対するポリシー条件を使
用する
悪用を抑制
AWS アカウントのアクティビティの監視 悪用を検知

40. 特にアクセスキーについては注意
アクセスキーの発行は最小限に
不要なものは削除を
不要な場所にアクセスキーのデータが存在
していないか調査を
アクセスキーを取り扱うサーバに対するセ
キュリティ対策も忘れずに
【参考】
• AWS アクセスキーを管理するためのベストプラクティス
https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws
-access-keys-best-practices.html

41. 現実的にすべての項目を定期的に確認す
るのはかなりしんどい
各社が無料から有料までいろいろなツールを提供
しているので、「ツールでできる部分は」ツール
に頼る
 AWS Trusted Advisor
 Classmethod insightwatch
 Netflix Security Monkey

42. とはいえ、ツールも導入して実行して終
わりではない
 ツールで出来ないことの把握
 適時の見直し（そのツールはメンテナンスされ
ていますか？）

43. git-secretsを使おう
 Credentialを誤って git リポジトリにcommitして
しまうことを防いでくれるAWSが公開しているtool
awslabs/git-secrets
https://github.com/awslabs/git-secrets

44. アクセス許可の境界（Permissions
Boundary）を利用しよう
 Permissions PolicyとPermissions Boundaryの２
つのポリシーで、できることできないことの細やか
な制限が可能になる機能
 主にattach* 系のiamへの攻撃を防ぐことができる
【参考】
• IAM エンティティのアクセス許可の境界
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_pol
icies_boundaries.html
• [新機能]IAMの委譲権限を制限可能なPermissions Boundaryが登場したので
試してみた
https://dev.classmethod.jp/cloud/aws/iam-permissions-boundary/

45. Conditionのaws:RequestedRegion
を利用しよう
 リージョンを制限して被害範囲を限定し、検知も容
易にする
【参考】
• 【待ってた】「東京リージョンだけでXXXの実行を許可する」を簡単に実現する
IAMのアップデート
https://dev.classmethod.jp/cloud/aws/iam-policy-global-condition-key-
requested-region/

46. 悪用されたことを検知する
 AWSアカウントのアクティビティは監視が必要
 AWS CloudTrailを利用してアカウントアクティビティのログ
を取得
 Amazon CloudWatchなどでログをモニタリング
 平常時のログを自分で分析しておき、異常な動きをし
ているものがないかを監視

47. Amazon Guard Duty
 機械学習を利用してトラフィックログ等から怪
しい通信を検知するマネージドサービス
 アカウントの不正利用などの監視に有効
【参考】
• Amazon GuardDuty
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/what-
is-guardduty.html

48. Thank you!