Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PenTesterが知っている危ないAWS環境の共通点

20,145 views

Published on

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

Published in: Technology

PenTesterが知っている危ないAWS環境の共通点

  1. 1. PenTesterが知っている 危ないAWS環境の共通点 ~攻撃者視点よりお届けする狙われやすいAWSの穴~ 2019/2/23 JAWS DAYS 2019
  2. 2. Shun Suzaki(洲崎 俊) Twitter:@tigerszk ITイベントの参加・開催や日々の脆弱性検証をライフワークと する「とあるセキュリティエンジニア」 Daiki Ichinose(一ノ瀬 太樹) Twitter:@mahoyaya Perlが好きなウィークデーバグハンター。 土日は家族サービスとコミュニティ活動に勤しんでいる。 Ken Kitahara(北原 憲) 博士(理学)。物理学で博士号を取得してから、2014年4 月から縁も所縁もない情報セキュリティ業界で働き始める。 ネットワーク系のサイバー攻撃技術が専門。
  3. 3. AWSのセキュリティは?  プラットフォームとしてのセキュリティは堅牢  強固な物理セキュリティ  自由に冗長化やスケーリングが可能  便利なマネージドサービスが用意されている
  4. 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. 5. 伝えたいこと  当たり前だが、AWSを使っていたとしても、 セキュリティインシデントは発生しうる  プラットフォームが堅牢でも、 最終的にはユーザの使い方次第  システムを運用していく中で、脆弱性が作り こまれる可能性もある  安全に使うには、ユーザ側にてセキュリティを意識 した対策が必要
  6. 6. 責任共有モデル  低レイヤーはAWSがカバーするが、高レイヤー部分は ユーザ―が対策しなければならない 責任共有モデル – アマゾン ウェブ サービス (AWS)より引用 https://aws.amazon.com/jp/compliance/shared-responsibility-model/
  7. 7. 安全にAWSを利用するためには 1. オンプレ環境などと同様の対策が必要 実装時や運用で作りこまれてしまう脆弱性などはオンプレなどと同じ EC2などで稼働するアプリケーションのセキュリティは大丈夫? 2. AWSサービスごとに個別の対策が必要 S3、IAM、セキュリティグループなどの設定は大丈夫? 3. 必要に応じて便利なマネージドサービスを利用 CloudTrail、AWS WAF、Guard Duty、Amazon Inspector etc…
  8. 8. ここら辺のことは 他のセキュリティセッションでも 沢山話があったかと思います。
  9. 9. ここからは攻撃者視点での AWSセキュリティについてのお話
  10. 10. AWS環境で狙うなら何? どうせ狙うのならやっぱり Credential(認証情報) ですよね?
  11. 11. AWSにおけるCredentialとは AWSサービスを利用するために必要な認証情報  AWSアカウント(ルートユーザ・IAMユーザ)  ID  パスワード  アクセスキー  アクセスキーID  シークレットアクセスキー
  12. 12. AWSアカウント  AWS マネジメントコンソールへのサインインに 必要となる AWS Management Console AWS Cloud ルートユーザ IAMユーザ ID パスワード ID パスワード
  13. 13. アクセスキー  AWS API、AWS CLI、AWS SDK、または Windows PowerShell 用 AWS ツールから AWS をプログラム で呼び出す場合に使用する ルートユーザ IAMユーザ アクセスキーID シークレットアクセスキー アクセスキーID シークレットアクセスキー AWS Cloud
  14. 14. Credentialがあれば何でもできる • Credentialがあれば、割り振られた権限に応じ てAWSのマネージドサービスを好きなように 操作できる • Credentialにルートユーザの権限があれば、 そのAWS環境においては、神になれる
  15. 15. つまりAWS環境では Credentialを悪用されてしまう状況が 最も危険
  16. 16. Credentialはどのように窃取される? 今回はCredentialを窃取されてしまう 良くある事例をご紹介
  17. 17. AWSアカウントの場合
  18. 18. マネジメントコンソール経由での 不正ログイン  MFA(多要素認証)が有効でなければ当然狙い所  何らかの方法でユーザID・パスワードを窃取もしくは推測 され、マネジメントコンソールなどから不正ログインされ てしまう  ありがちなのは、単純なパスワードの設定や 「パスワードの使い回し」問題  海外のペネトレーションテストでは、ソーシャルエンジニ アリングのテクニック利用したスピアフィッシングなどで、 ユーザID・パスワード情報を取得している
  19. 19. アクセスキーの場合
  20. 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. 21. AWSもスキャンしてくれてるけど…  AWSもGitを検索し、アクセスキーを公開している利用者の リポジトリに通知してくれているが、攻撃者も同じことを やっている  そのためAWSからの通知前に悪用される可能性がある 【参考】 • GitHub に AWS キーペアを上げると抜かれるってほんと???試してみよー! https://qiita.com/saitotak/items/813ac6c2057ac64d5fef
  22. 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. 23. アプリケーションの脆弱性を利用さ れるケースも  Webアプリケーションやミドルウェアの脆弱性を突かれるこ とによって、Credentialを窃取されてしまう可能性もある 【紹介する事例】 SSRFを利用したCredentialの窃取 サーバ内部に配置されたCredentialの窃取
  24. 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. 25. AWS APIを利用してCredentialを取得  IAMロールが紐づいた状態のインスタンスにて、AWS APIへ 一時的なCredentialを要求するリクエストを強制させられ、 EC2のIAMロールに紐づいたCredentialを窃取されてしまう。 AWS側のメタデータAPISSRFの脆弱性が存在するEC2攻撃者 脆弱性を悪用するリクエストを送信 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. 26. Credentialを取得した結果
  27. 27. サーバー内に配置されているCredential  サーバー内にアクセスキーが配置されていたり、設定ファイル などが残存しているケースがある  AWS CLIなどを利用している場合には、以下の場所か環境変 数に設定されていたりするが他の場所にあることも  Linux: /home/USERNAME/.aws/credentials  Windows: C:UsersUSERNAME.awscredentials  この場合、サーバー内に侵入された場合や、システム内部の ファイルを読み取ることができるような脆弱性(ディレクトリ トラバーサルなど)を利用されることなどによって、取得され てしまう可能性がある
  28. 28. 場合によっては これで終わりではない…
  29. 29. 権限昇格される可能性  窃取されたCredential付与されたIAMポリシーの種類や設 定状況などによっては、さらに高い権限へと権限昇格され てしまう可能性がある  場合によっては管理者権限を奪取されAWS環境を完全掌握 される可能性もありうる Privileges Escalation
  30. 30. 権限昇格されてしまう例~その1~  以下の権限のいずれかが割り当てられている場合には、ポリシーを勝 手に追加することにより、ポリシーの権限を奪取して、権限昇格可能  当然ながら他にも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. 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. 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. 33. AWS環境への攻撃デモ
  34. 34. 情報収集 権限昇格 バックドアの 設置 AWSサービス の悪用 デモのシナリオ  何らかの経路でAWS Credentialを入手した後、そのCredentialを 元に攻撃者がAWS環境に侵入するというデモです。  攻撃者は侵入後にAWS環境に対して以下の行為を行います。
  35. 35. Pacu  今回のデモで利用している AWS Exploitation Framework  Rhino Security Labsが公開  OSSであり、python3で開発されている  AWSのアクセスキーをセットして使用する https://github.com/RhinoSecurityLabs/pacu
  36. 36. Demo
  37. 37. 対策
  38. 38. 対策のアプローチは多く分けて三つ 1. Credentialの漏洩を防止 2. Credentialの悪用を抑制 3. Credentialを悪用されたことを検知
  39. 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. 40. 特にアクセスキーについては注意 アクセスキーの発行は最小限に 不要なものは削除を 不要な場所にアクセスキーのデータが存在 していないか調査を アクセスキーを取り扱うサーバに対するセ キュリティ対策も忘れずに 【参考】 • AWS アクセスキーを管理するためのベストプラクティス https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws -access-keys-best-practices.html
  41. 41. 現実的にすべての項目を定期的に確認す るのはかなりしんどい 各社が無料から有料までいろいろなツールを提供 しているので、「ツールでできる部分は」ツール に頼る  AWS Trusted Advisor  Classmethod insightwatch  Netflix Security Monkey
  42. 42. とはいえ、ツールも導入して実行して終 わりではない  ツールで出来ないことの把握  適時の見直し(そのツールはメンテナンスされ ていますか?)
  43. 43. git-secretsを使おう  Credentialを誤って git リポジトリにcommitして しまうことを防いでくれるAWSが公開しているtool awslabs/git-secrets https://github.com/awslabs/git-secrets
  44. 44. アクセス許可の境界(Permissions Boundary)を利用しよう  Permissions PolicyとPermissions Boundaryの2 つのポリシーで、できることできないことの細やか な制限が可能になる機能  主に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. 45. Conditionのaws:RequestedRegion を利用しよう  リージョンを制限して被害範囲を限定し、検知も容 易にする 【参考】 • 【待ってた】「東京リージョンだけでXXXの実行を許可する」を簡単に実現する IAMのアップデート https://dev.classmethod.jp/cloud/aws/iam-policy-global-condition-key- requested-region/
  46. 46. 悪用されたことを検知する  AWSアカウントのアクティビティは監視が必要  AWS CloudTrailを利用してアカウントアクティビティのログ を取得  Amazon CloudWatchなどでログをモニタリング  平常時のログを自分で分析しておき、異常な動きをし ているものがないかを監視
  47. 47. Amazon Guard Duty  機械学習を利用してトラフィックログ等から怪 しい通信を検知するマネージドサービス  アカウントの不正利用などの監視に有効 【参考】 • Amazon GuardDuty https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/what- is-guardduty.html
  48. 48. Thank you!

×