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.

flaws.cloudに挑戦しよう!

2019/11/17に開催した「とある診断員とSecurity-JAWS#01」で行ったflaws.cloudワークショップの資料です。

  • Login to see the comments

flaws.cloudに挑戦しよう!

  1. 1. に挑戦しよう! 2019/11/17 @tigerszk FLAWS
  2. 2. 自己紹介 Shun Suzaki(洲崎 俊) 三井物産セキュアディレクション株式会社に所属して、 ペネトレーションテストなどを中心としたセキュリティサービス提供に従事 Twitter: とある診断員@tigerszk I‘M A CERTAIN PENTESTER! 公開スライド:http://www.slideshare.net/zaki4649/ Blog:http://tigerszk.hatenablog.com/ ⚫ ISOG-J WG1 ⚫ Burp Suite Japan User Group ⚫ OWASP JAPAN Promotion Team ⚫ IT勉強会「#ssmjp」運営メンバー ⚫ MINI Hardening Project 運営メンバー 2
  3. 3. flaws.cloudとは? ⚫ Scott Piper氏(@0xdabbad00)が公開されているCTF形式で AWS固有のセキュリティトピックに関して学べる素晴らしい サイト! http://flaws.cloud/ ⚫ Level1~Level6の問題が出題されている
  4. 4. 本イベントの趣旨 ⚫ flaws.cloudを皆でいっしょに解いて、楽しみながら AWSセキュリティの基礎を学びましょう!
  5. 5. 全問題にヒントが用意されています! ⚫ flaws.cloudは公開サイトなので、家に帰ってからも復習でき ます。 ⚫ 学習目的のサイトであるため、全問題にヒントが用意されて います。 ⚫ ヒントはかなり具体的で、ほとんどWrite UPみたいな感じな ので、基本的にはそれを読めば必ず解けます。 ⚫ ヒントを見すぎるとすぐ解けてしまうので、今回はなるべく 見ないようにして、考えながら一緒に進めてみましょう! ⚫ もちろん出来る方はバシバシ先に進んでいただいてOKです。 ⚫ 私の方でもオリジナルの追加ヒントを出したり、徐々に解説 していこうと思います。
  6. 6. 事前準備 1. AWS CLIを実行する環境が必要です AWS CLI とは、コマンドラインからAWS サービスを制御するための ツールです。flaws.cloudでは、問題を解くにあたってこちらのコマンド を多用するため動作環境が必要です。 AWS CLI のインストールと設定 https://docs.aws.amazon.com/ja_jp/streams/latest/dev/kinesis- tutorial-cli-installation.html 2. AWSアカウントが必要です 途中の問題で、ご自身のAWSアカウントが必要となる問題があるためア カウントの作成をお願いいたします。また、EBSボリュームとEC2を一時 的に作成する必要があるため微量ですが課金が発生する可能性があります。 AWS無料利用枠を利用すれば料金は発生いたしませんので、無料枠を利 用できるアカウントのご用意を推奨します。
  7. 7. Level1 次の問題へとつながるサブドメインを探そう!
  8. 8. ココがポイントです! ⚫ このサイトはAWSのあるサービスを利用して作られています。 ⚫ ドメインを色々調べてみると色々わかるかもしれません。 flaws.cloud ⚫ ポートスキャンなどを行う必要はありません。
  9. 9. 途中まで解説
  10. 10. ドメインを調査した結果 ⚫ DNSルックアップの結果から、 Amazon S3を利用して いることがわかります。 ⚫ また、ホストされているリージョンが us-west-2だとい うことも分かります。
  11. 11. Amazon S3とは ⚫ Amazon S3(Amazon Simple Storage Service) インターネット経由で利用できるAWSのストレージサービス https://aws.amazon.com/jp/s3/ ⚫ AWSは従量課金なので使った分だけ料金は発生するが、容量 無制限で利用できます。 ⚫ バケットとはS3におけるデータを格納するための領域です。 複数作成可能でありアクセス制御もできます。 ⚫ Webサイトの静的コンテンツ(htmlファイル、画像ファイル、 JavaScriptファイルなど)を直接クライアントに配信すること ができるため、Webサーバーとしても利用できます。
  12. 12. Level1解説
  13. 13. S3の仕様について ⚫ Amazon S3のバケット名はグローバルに一意であり、名前 空間はすべての AWS アカウントにて共有されています。 ⚫ S3バケットを利用して独自ドメインを利用して、静的なサ イトをホスティングする場合には、前提としてバケット名と ドメイン名が一致する必要があります。 ⚫ そのためドメイン名がflaws.cloudであるため、バケット名 もflaws.cloudであることが推測できます。 【参考】 独自ドメインを使用して静的ウェブサイトをセットアップする https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/website- hosting-custom-domain-walkthrough.html
  14. 14. S3バケットのURL ⚫ S3バケットは、リソースを一意に識別するURLを持ちます。 ⚫ URLは以下2種類のタイプが存在します。 ◆ 仮想ホスト形式 1. http://バケット名.s3-リージョン名.amazonaws.com/ 2. http://バケット名.s3.amazonaws.com/ ※2019 年 3 月 20 日より後に開始されたリージョンで作成されたバケットでは2の形式では到達できないようです。 ◆ パス形式 1. http://s3-リージョン名.amazonaws.com/バケット名 2. http://s3.amazonaws.com/バケット名 ※米国東部 (バージニア北部) リージョンは1の形式で、他のリージョンは2の形式となります。 2020年9月30日以降、パス形式での S3 API リクエストは受け付けられなくなるとのことです(既存に作成済みのものは除く) 【参考】Amazon S3 バケットの使用 バケットへのアクセス https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingBucket.html#access-bucket- intro
  15. 15. 目的のS3バケットのURLは? ⚫ というわけで、このWebサイトを公開しているS3バケット のURLは以下と分かります。 ◆ 仮想ホスト形式 http://flaws.cloud.s3.amazonaws.com/ http://flaws.cloud.s3-us-west-2.amazonaws.com/ ◆ パス形式 http://s3-us-west-2.amazonaws.com/flaws.cloud/ ⚫ ちなみにこのS3バケット利用しているWebサイトへは以下 のURLでもアクセスができます。 http://flaws.cloud.s3-website-us-west-2.amazonaws.com/
  16. 16. ⚫ S3バケットを示すURLにアクセスするとSバケット内の ファイル一覧が表示されます。 アクセスすると
  17. 17. 怪しげなファイルを発見 ⚫ それっぽいファイルがあるのでアクセスすればクリア! http://flaws.cloud.s3-us-west-2.amazonaws.com/secret-dd02c7c.html
  18. 18. ⚫ AWS CLIを使う場合にはこんな感じ S3バケットの内容を一覧表示 aws s3 ls s3://バケット名 ※実行結果では、認証情報を読み込まないように--no-sign-requestオプション を設定しているのと--regionオプションにてリージョン情報を設定しています。 AWS CLIを使う場合には 【参考】AWS CLI での高レベル (s3) コマンドの使用 https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-services-s3- commands.html
  19. 19. この問題から学べること ⚫ 過去度々問題となっていますが、S3バケットに誤った設定を してしまうことで、情報が漏洩してしまう危険性があります。 【参考】Amazon S3バケットのアクセス設定に関する注意喚起メールにつきまして https://aws.amazon.com/jp/blogs/news/securing_amazon_s3_buckets/ ⚫ デフォルトのS3バケットはセキュアに作成されますが、Web サイトとして設定している場合には、オブジェクトを読み取 り可能とするために全ての利用者に対して“s3:GetObject”の アクセス許可を付与しているケースがあります。 【参考】静的ウェブサイトホスティング用に S3 バケットを設定する方法 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/user-guide/static-website-hosting.html ⚫ さらにEveryone対してオブジェクトの一覧許可すると、この ようにディレクトリリスティングが有効となってしまいます。
  20. 20. Level2 先ほどの問題と非常に似ているとのことです。 また、「AWSアカウントが必要」と書いてあります。
  21. 21. ⚫ Level1と同じようにS3バケットのURLに、アクセスしても AccessDeniedとなります。 http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud.s3-us-west-2.amazonaws.com/ 普通にアクセスしてみてもダメ
  22. 22. AWSのクレデンシャルについて説明 AWSサービスを利用するために必要なクレデンシャル(認証情報) ⚫ AWSマネジメントコンソール ⚫ ID ⚫ パスワード ⚫ アクセスキー ⚫ アクセスキーID ⚫ シークレットアクセスキー
  23. 23. AWSマネジメントコンソール ⚫ AWSの管理用Webインタフェースを利用してAWSサービスを 利用する AWS Management Console AWS Cloud ルートユーザー IAMユーザー ID パスワード ID パスワード
  24. 24. アクセスキー ⚫ AWS API、AWS CLI、AWS SDK、または Windows PowerShell 用 AWS ツールから AWS をプログラムで呼び出す場合に使用する ルートユーザー IAMユーザー アクセスキーID シークレットアクセスキー アクセスキーID シークレットアクセスキー AWS Cloud
  25. 25. IAMユーザーのアクセスキーを作成 ⚫ ハンズオン用にIAMユーザーを発行して、アクセスキーを発行してください。 発行の仕方は以下のサイトなどをご参照ください。 【参考】AWSアクセスキー作成 - Qiita https://qiita.com/miwato/items/291c7a8c557908de5833 【参考】 AWS アクセスキーの作成 https://aws.amazon.com/jp/premiumsupport/knowledge-center/create- access-key/ ⚫ 今回のハンズオンでアクセスキーを発行するユーザーはS3の読み取りと、 EC2関連の操作ができれば大丈夫ですので以下の既存ポリシーがアタッチさ れていれば問題ありません。 AmazonS3ReadOnlyAccess AmazonEC2FullAccess ⚫ ハンズオン終了時には、必ず不要なユーザー及びアクセスキーは削除するよ うにお願いいたします。
  26. 26. AWS CLIにおけるクレデンシャルの設定 ⚫ aws configureコマンドを実行することでAWS CLI で利用するクレデン シャルを簡単にセットすることができます。 ⚫ コマンドを実行すると4 種類の情報の入力が求められます。 ⚫ 引数なしで実行した場合には、defaultという名前のプロファイルに保存さ れます。使用するプロファイルを明示的に指定しない場合は常にこの認証 情報が使用されます。 ⚫ --profileオプションを利用するとプロファイル名を指定して認証情報を登 録することができます。 アクセスキー シークレットアクセスキー AWSリージョン 出力形式 【参考】AWS CLI の設定 - AWS Command Line Interface https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap- configure.html
  27. 27. クレデンシャルの保存場所 ⚫ aws configure で指定された認証情報は、ホームディレクトリの .aws フォルダにある credentialsファイルに保存されます。 ⚫ その他の設定オプションも.aws フォルダのconfigファイルに保存されま す。 ⚫ aws configureコマンドを使わなくても、こちらのファイルを直接編集す ることで、クレデンシャルの追加や設定オプションの変更などが可能です。
  28. 28. Level2解説
  29. 29. ⚫ アクセスキーを設定した状態で、以下のコマンドを利用して、 S3バケットにアクセスすると中身が見えます。 ⚫ secret-e4443fc.htmlにアクセスすればクリアです。 認証設定を行ってS3にアクセスするだけ aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
  30. 30. この問題から学べること ⚫ Level1と同じようにS3の権限設定の不備に関する問題です。 ⚫ 「Any Authenticated AWS User」という権限設定がされて いた場合には、自分のアカウントに所属していないAWSアカ ウントでもアクセスできる状態となり、 AWSのアカウントさ えあれば誰でもアクセス可能になってしまいます。
  31. 31. Level3 さっきの問題と非常に似ている問題らしい 「AWSアクセスキーを見つけてね!」と書いてある
  32. 32. 途中まで解説
  33. 33. ⚫ AWS CLIを実行してS3バケットの中身を見てみると.git ファイルが存在することが分かります。 とりあえず、S3バケットを見てみると…
  34. 34. ⚫ 以下のAWS CLIを実行するとS3バケットの中身をダウン ロードできます(指定したディレクトリにS3バケットの全 内容が展開されるので実行する前に注意!!)。 ⚫ ダウンロードした.gitファイルを解析してみましょう! S3バケットからダウンロードしてみる syncコマンドでローカルのディレクトリを同期させる aws s3 sync <S3バケットのPath> <Localダウンロード先のPath> aws s3 sync cp://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud . cpコマンドでファイルをダウンロード aws s3 cp <S3バケットのPath> <Localダウンロード先のPath> ※ --recursiveオプションをつけることでディレクトリを再帰的にコピーできます。 aws s3 cp s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud . --recursive
  35. 35. Level3解説
  36. 36. ⚫ git logコマンドでコミットログを見ると変更されているのが 分かります。 ⚫ 誤って追加してはいけないものを追加した的なコメントが… コミットログを見てみると
  37. 37. ⚫ git checkoutコマンドを利用して、first commitの状態に 戻すと「access_key.txt」がでてきます。 ⚫ 名前の通り中にはクレデンシャル(アクセスキーの情報) が書かれています。 git checkoutで戻してみよう
  38. 38. 出てきたクレデンシャルを設定 ⚫ 再びaws configureコマンドを利用して、出てきたクレデン シャルをAWS CLIで利用できるようにしましょう。 ⚫ --profileオプションを利用するとプロファイル名を指定してご 自分の好きなプロファイル名を設定してください。 ⚫ リージョンはus-west-2に設定することを推奨します。
  39. 39. ⚫ 以下コマンドにて、設定したクレデンシャルの権限で確認で きるS3のバケットの一覧を参照してみましょう。 aws s3 ls --profile 設定したプロファイル名 ⚫ Level4のサブドメインにアクセスしたらクリアです。 S3バケットの一覧を見てみると
  40. 40. この問題から学べること ⚫ このようになんらかの経路でAWSキーが漏洩してしまった場 合には、不正利用されてしまう可能性があります。不要なも のは削除するなどアクセスキーは適切に管理しましょう。 【参考】AWS アクセスキーを管理するためのベストプラクティス https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-access- keys-best-practices.html ⚫ git経由で認証情報などが漏洩してしまうケースは現実世界で もよくあるため注意が必要です。 git-secretsなどを利用して、認証情報をgitリポジトリに commitしないようしましょう。 git-secrets https://github.com/awslabs/git-secrets
  41. 41. Level4 今回の問題にはS3は関係ありません。 URLにアクセスするとBasic認証を要求されます。 クリアするのはどうにかしてBasic認証を突破する必要が あります。 正しこの問題はWebアプリの脆弱性を突くような問題では ありません。 先ほどの問題で取得したクレデンシャルを利用します。
  42. 42. 問題文にヒントが隠れています nginxがセットアップされた直後に、そのEC2からスナップ ショットが作成されたことを知っていると役に立ちますよ! どうにかしてそのスナップショットを取得することはできな いだろうか? It'll be useful to know that a snapshot was made of that EC2 shortly after nginx was setup on it.自分の言葉で書く
  43. 43. 途中まで解説
  44. 44. この問題を解くためのアプローチ flawsの環境 問題のEC2 EBSのスナップショット 自分のAWS環境 EBSとはEC2 にアタッチ可能なブロックレベルのストレージサービスです。 EC2のデータはEBSに保存する構成が基本となります。 今回のスナップショットとはこのEBSのスナップショットを指します。 このスナップショットをどうにか自分の環境に持ってきて、自分のEC2に アタッチさせ中身を見ることができないか?というのがこの問題を解くた めのアプローチとなります。 自分のEC2 ①自分の環境に持ってくる ②自分のEC2にアタッチして中身を解析
  45. 45. 利用できるスナップショットの情報を取 得するには 【参考】describe-snapshots — AWS CLI 1.16.205 Command Reference https://docs.aws.amazon.com/cli/latest/reference/ec2/describe- snapshots.html ⚫ aws ec2 describe-snapshotsコマンドを利用することで、 利用可能なスナップショットの情報を取得できます。 aws ec2 describe-snapshots ⚫ ただそのまま実行した場合には、自分の所有するスナップ ショットとパブリックな全てのスナップショットの情報が 出力されるため、なんらかのフィルタが必要です。
  46. 46. ⚫ 以下のコマンドで、利用しているAWSアカウントやユーザ の情報を確認できます ⚫ Level3で取得したクレデンシャルに紐づくプロファイル名 を指定して実行してみましょう。 クレデンシャルに紐づく情報を調べてみよう aws sts get-caller-identity -–profile 設定したプロファイル名 AWSアカウントID AWSリソースネーム (ARN) ユーザID ユーザIDにはアクセスキーIDが表示されます。 ARNとはAWSのサービスリソースを一意に識別するための記述形式です。 AWS アカウント ID は、ARN を構築するのに使用する 12 桁の数字です。
  47. 47. ⚫ 以下のようにowner-idにAWS アカウント ID を指定してフィルタす ると、このAWSアカウントが公開しているスナップショットの情報 を取得できます。 aws ec2 describe-snapshots --owner-id 975426262029 --profile 設定したプロ ファイル名 ⚫ スナップショットの情報はパブリックに公開されているためどの認証 情報からでも取得できますが、regionをus-west-2に指定する必要が あります。 フィルタを指定して検索してみよう
  48. 48. パーミッションを確認してみると ⚫ 以下で取得したsnapshot-idを指定してスナップショットの パーミッションを確認することができます。 aws ec2 describe-snapshot-attribute --snapshot-id snap-0b49342abd1bdcb89 --attribute createVolumePermission --profile 設定したプロファイル名 ⚫ CreateVolumePermissonのGroupキーの値がallとなってい るため誰でもスナップショットが作成可能なことが確認でき ます。
  49. 49. ⚫ aws ec2 create-volumeコマンドで、先ほど取得した snapshot-idを指定して、自分のアカウントに、該当のスナップ ショットからEBSボリュームを作成してみましょう。 ⚫ 作成にはregionをus-west-2に指定する必要があります。またア ベイラビリティゾーンも指定する必要があるためus-west-2bと 設定してみてください。 aws ec2 create-volume --availability-zone us-west-2b --region us-west- 2 --snapshot-id snap-0b49342abd1bdcb89 自分のアカウントにスナップショットか らEBSボリュームを作成してみましょう
  50. 50. EBSボリュームの作成が成功
  51. 51. ⚫ マネジメントコンソールから確認すると自分のアカウントに EBSボリュームが作成されているはずです。 ⚫ Regionは米国西部 (オレゴン) : us-west-2となります。 マネジメントコンソールで確認すると
  52. 52. ⚫ 適当にEC2を作成します(Ubuntuが推奨されています)。 ⚫ 作成したEC2にEBSボリュームアタッチしてみてください。 EC2にEBSボリュームをアタッチする
  53. 53. ⚫ 作成したEC2インスタンスにSSHログインし、アタッチし たボリュームをマウントしてみてください ⚫ マウントした領域中から、そもそもの目的であるBasic認 証のID/PASSを探しだすことができればゴールです! 次にやることは?
  54. 54. Level4解説
  55. 55. ⚫ SSHでログイン後、mountコマンドを利用して、EC2にア タッチしたEBSボリュームをマウントします。 EBSボリュームをマウント
  56. 56. ⚫ 調査すると/home/ubuntuに.htpasswdファイルを生成す るスクリプトファイルがあり、ID/PASSが記載されている ことが分かります。 ⚫ この情報で最初のBasic認証にログインすればクリアとなり ます。 Basic認証のID・パスワードを取得
  57. 57. この問題から学べること ⚫ AWSではEC2とRDSのスナップショットを取得することがで きます。 ⚫ AWSでは通常バックアップ目的で、EC2のスナップショット を取得しますが、このように攻撃者に悪用されてしまう可能 性があることを覚えていてください。 ⚫ ただし、デフォルトではスナップショットは自分のアカウン トからのアクセスに限定されます。スナップショットを適切 に管理することが重要です。
  58. 58. Level5 EC2のProxyサービスを利用してlevel6のS3バケット に存在する隠しディレクトリを見つけてください!
  59. 59. ⚫ URLパスの一部にURLを指定するとProxyとして動作するように なっています。 http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/example.com Proxyとなっている
  60. 60. 途中まで解説
  61. 61. SSRFを利用したクレデンシャルの窃取 ⚫ 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
  62. 62. AWS APIを利用してクレデンシャルを取得 ⚫ IAMロールが紐づいた状態のインスタンスにて、AWS APIへ 一時的なクレデンシャルを要求するリクエストを強制させられ、 EC2のIAMロールに紐づいたクレデンシャルを窃取されてしまう。 AWS側のメタデータAPISSRFの脆弱性が存在するEC2攻撃者 脆弱性を悪用するリクエストを送信 AWSのメタデータAPIに対して 一時的な認証情報を勝手に要求 認証情報を含んだ結果が返る認証情報を窃取 【参考】インスタンスメタデータとユーザーデータ https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec 2-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/…
  63. 63. ⚫ 実際にこの脆弱性を利用してクレデンシャルを窃取 してみてください。 ⚫ 窃取したクレデンシャルを利用して、 level6のS3 バケットの一覧を取得しましょう。 ということでやることは?
  64. 64. Level5解説
  65. 65. ⚫ 以下のURLにアクセスすると認証情報を取得できます。 http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/ 169.254.169.254/latest/meta-data/iam/security-credentials/flaws SSRFを利用して認証情報を取得
  66. 66. 認証情報をセットします ⚫ 取得したクレデンシャル情報をAWS CLIで利用できるように 設定します。 ⚫ token情報(aws_session_token)も設定する必要があります。
  67. 67. S3バケットを確認すると ⚫ AWS CLIにてS3バケットを読みに行けば隠しディレクトリが分か り、判明したディレクトリにアクセスすればクリアです。 ⚫ cpコマンドと同様に--recursiveオプションで配下にあるディレク トリの内容も表示されます。 aws s3 ls s3://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud -- recursive --profile 認証情報のプロファイル名
  68. 68. ここから学べること ⚫ この問題と同じような手口で実際に攻撃された事案が話題となりま した。 SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog https://piyolog.hatenadiary.jp/entry/2019/08/06/062154 ⚫ AWSでは169.254.169.254は特別なIPとして利用されています。 ⚫ メタデータを利用するためのAPIを悪用してクレデンシャル情報を 取得するテクニックがあるということを覚えておいてください。 ⚫ また、このテクニックはAWSだけではなく、他のクラウドサービス においても悪用される危険性があるため注意が必要です。
  69. 69. Level6 いよいよ最後の問題です! SecurityAuditポリシーが付与されたユーザーのアクセスキー を取得したとのことです。 このAWSアカウントではこの権限以外でも何かできるらしい です。 このアカウントが一体何をすることができるのかを調査して みてください!
  70. 70. SecurityAuditのポリシーとは? ⚫ ユースケース: ユーザーはセキュリティ要件の遵守についてアカウントをモニタリン グします。このユーザーは、潜在的なセキュリティ侵害や悪意のある 行為を調査するためのログおよびイベントにアクセスできます。 ⚫ ポリシーの詳細: このポリシーでは、AWS の多数のサービスの設定データを表示し、 それらのログを確認するアクセス許可を付与します。 「職務機能の AWS 管理ポリシー」より引用 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_job- functions.html
  71. 71. 途中まで解説
  72. 72. まずは、アカウント情報を調査 ⚫ いままでと同様にクレデンシャルを設定してまずは、aws sts get-caller- identityコマンドを利用して、アカウント情報を調査してみます。 aws sts get-caller-identity –profile 設定したプロファイル名 AWSアカウントID AWSリソースネーム (ARN) ユーザID
  73. 73. アタッチされているIAMポリシーを見てみる ⚫ 以下コマンドを利用し、先ほど取得したユーザ名を指定するとアタッチされ ているポリシーが判明します。 aws iam list-attached-user-policies --profile 設定したプロファイル名 --user-name Level6 ⚫ SecurityAuditと思われるポリシー以外にどうやら他にlist_apigatewasysと いうポリシーがアタッチされていることがわかります。 【参考】list-attached-role-policies — AWS CLI 1.16.205 Command Reference https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-role- policies.html
  74. 74. list_apigatewaysについて調べてみる ⚫ list_apigatewaysは独自に作成したポリシーのようです。 ⚫ get-policyコマンドを利用して、先ほど取得したARNを指定し、さら にポリシーを調査してみましょう。 aws iam get-policy --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --profile 設定したプロファイル名 【参考】get-policy — AWS CLI 1.16.205 Command Reference https://docs.aws.amazon.com/cli/latest/reference/iam/get-policy.html
  75. 75. さらにポリシーの詳細を調査 ⚫ get-policyコマンドを実行して取得した、DefaultVersionIdキーの値から管理 ポリシーのバージョンIDが分かります。 ⚫ さらにget-policy-versionコマンドを利用して、バージョンIDとARNを指定 し、list_apigatewaysポリシーの、より詳細な情報を取得してみます。 aws iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --version-id v4 --profile 設定したプロファイル名 【参考】get-policy-version — AWS CLI 1.16.205 Command Reference https://docs.aws.amazon.com/cli/latest/reference/iam/get-policy- version.html
  76. 76. ⚫ get-policy-versionコマンドの結果より、このAWSアカウント上にて AmazonApiGatewayサービス(REST および WebSocket APIを簡単に利 用できるマネージドサービス)を使用していることが推測されます。 ⚫ ポリシーの内容からは、ユーザー:Level6は以下のARNのリソースに 対してAPI Gateway の GET アクションを許可されていることが分か ります。 arn:aws:apigateway:us-west-2::/restapis/* ⚫ もう一つのMySecurityAuditポリシーの内容も同様の手法で詳細情報 を確認することができます。 ⚫ その結果、 API Gateway と非常に親和性の高いあるサービスを利用 している可能性が推測されます。 ここまでの調査結果から分かること 【参考】API を管理するためのアクセスの制御 - Amazon API Gateway https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api- gateway-control-access-using-iam-policies-to-create-and-manage-api.html
  77. 77. MySecurityAuditポリシーを調査すると ⚫ MySecurityAuditポリシーがアタッチされたユーザーには全てのリソース に対してLambda関数におけるListFunctions、GetAccountSettings、 GetPolicyの権限が与えられていることが分かります。 aws iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/MySecurityAudit --version-id v1 --profile 認証情報のプロファイル名
  78. 78. AWS Lambda ⚫ AWSに関するなにかしらのイベントをトリガとして、事前 に設定しておいた処理を自動的に実行させる環境を提供し てくれるサービス ⚫ 実行したいプログラム( Node.js, Java, C#, Python, Ruby, Go, PowerShell をサポート)をLambda関数として 定義します。 ⚫ 近年ではAWSにおけるいわゆるサーバレスアーキテク チャー(サーバーを必要としないアプリケーション実行環 境)に利用されています。
  79. 79. ⚫ APIGatewayを使用する場合はLambdaを連携させるパ ターンは多いです。 ⚫ もしかしたらLambda関数を利用してAPIを叩いたりして いるのでないだろうかと推測されます。 ⚫ ということで次のアプローチはLambda関数関連について 調査してみましょう! Lambda関数使っているのでは?
  80. 80. 途中まで解説
  81. 81. Lambda関数の一覧を取得 ⚫ list-functionsコマンドを利用してLambda関数の一覧を取得してみます。 aws lambda list-functions --profile 設定したプロファイル名 ⚫ Level6というLambda関数が存在することが分かります。 【参考】list-functions — AWS CLI 1.16.205 Command Reference https://docs.aws.amazon.com/cli/latest/reference/lambda/list- functions.html
  82. 82. Lambda関数のポリシーを確認 ⚫ 該当のAPI ARNが取得でき、rest-api-idが「s33ppypa75」で あることが分かります。 【参考】 get-policy — AWS CLI 1.16.205 Command Reference https://docs.aws.amazon.com/cli/latest/reference/lambda/get-policy.html ⚫ 関数名level6を使用してポリシー情報を取得してみます。 aws lambda get-policy --function-name Level6 --profile 設定したプロファイル名 ⚫ ポリシーを見ると API Gateway APIからLambda関数が呼び 出されていることが推測されます。
  83. 83. 【参考】Amazon API Gateway で REST API を呼び出す https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how- to-call-api.html このREST APIを叩くにはどうすれば? ⚫ このAPIは非常に怪しい。どうすればアクセスすることができるのか? ⚫ 後はステージ名がわかればAPIを叩けるかもしれない
  84. 84. ステージ名を取得する ⚫ get-stagesコマンドを用いて、API IDを指定し、調査すると ステージ名が判明します。 aws apigateway get-stages --rest-api-id “s33ppypa75“ --profile 設定した プロファイル名 ⚫ ステージ名は「Prod」です。これで最後のパーツがそろいま した! 【参考】get-stages — AWS CLI 1.16.205 Command Reference https://docs.aws.amazon.com/cli/latest/reference/apigateway/get-stages.html
  85. 85. Level6解説
  86. 86. ⚫ 得られた情報を元にするとAPIのURLが以下だと分かります。 https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6 ⚫ アクセスしに行くとゴールURLが表示されます。 得られた情報を元に判明したURLにアクセス
  87. 87. この問題から学べること ⚫ このようになんらかの方法にてアクセスキーを入手されてし まった場合に、設定されているIAMポリシーなどによっては、 色々環境について情報を収集され、セキュリティ不備などを 攻撃されてしまう可能性があることをお分かりいただけたか と思います。
  88. 88. Congratulations!!
  89. 89. 【参考】こんなスライドも公開しています ⚫ 今回皆さんが手を動かして体験したような、クレデンシャ ルの漏洩に関するAWS環境への攻撃と対策についてまとめ たJAWS DAYS 2019のスライドです。 https://www.slideshare.net/zaki4649/pentesteraws
  90. 90. 最後に ⚫ いかがでしたでしょうか?最初にお伝えしましたが、 flaws.cloudは公開サイトなので、気になる所があれば、後 でゆっくり復習してみてください。 ⚫ またハンズオンで作成したEC2・EBSボリュームなどは課 金されてしまうので削除をお願いします。作成したユー ザーなども不要であれば削除をお願いいたします。 ⚫ また、実は続編のflaws2.cloudも公開されているので、 そちらも是非チャレンジしてみてください! http://flaws2.cloud/ flaws2.cloudのWriteupを書いたよ! - とある診断員の備忘録 http://tigerszk.hatenablog.com/entry/2019/08/09/150927

×