Flatt Security mini CTF #4 Writeups

WriteUp 10个月前 admin

56 0 0

Self 自我

Welcome to Mini CTF #3!
欢迎来到Mini CTF #3！
あなたは管理者になれますか？您可以成为管理员吗？

管理者になってGET /v1/flagを叩いてください!
成为管理员并点击 GET /v1/flag！

2nd blood。うれしい。第二滴血。快乐。

とりあえずBurpを開いて、もらったサイトを眺めてみる。
目前，我打开了 Burp 并查看了我收到的网站。
一方はwebサイトが立ち上がり、ログイン画面となる。もう一方はtokenが無いと動かないようでAPI用のエンドポイントのようだ。
另一方面，将启动一个网站并显示登录屏幕。另一个似乎没有令牌就无法工作，它似乎是 API 的端点。
adminでログインするんだろうとなーと思っているとヒントが与えられる。
如果您认为您将以管理员身份登录，您将得到提示。

操作方法がわからない？不知道如何操作？
2024-01-16 19:10:04
AWS の SDK や CLI は基本的に命名が一貫しているので、調べやすいかも?
AWS 开发工具包和 CLI 的命名基本上是一致的，因此查找它们可能更容易。
新規登録は sign-up 注册注册
ログインは initiate-auth 登录 initiate-auth
https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/#cli-aws-cognito-idp

Mini CTF #3!の反省でヒントが今回はたくさん出るらしい。
Mini CTF #3! 看来这次会有很多提示。
ありがたい。幸运。
もらったキーワードで検索してみる。尝试搜索您收到的关键字。

sign-upで検索するとREADME.mdで以下のような説明が出てくる。
如果您搜索注册，README.md 中会出现以下说明。

CLIENT_ID=<user-pool-client-id>
USERNAME=<username>
PASSWORD=<password>
aws cognito-idp sign-up \
  --region "ap-northeast-1" \
  --client-id $CLIENT_ID \
  --username  $USER_NAME \
  --password $PASSWORD \
  --no-sign-request

CLIENT_IDか…と思いながらBurpの履歴を見ていくと、cognito-idp.ap-northeast-1.amazonaws.comへのPOST /でClientIdが渡されていることに気が付く。
CLIENT_ID或者… 如果您查看 Burp 的历史记录， cognito-idp.ap-northeast-1.amazonaws.com 您会注意到 ClientId 被传递给 POST / .
ということで、上の説明を参考にユーザーを作ってみる。
因此，让我们参考上述说明创建一个用户。

aws cognito-idp sign-up --region "ap-northeast-1" --client-id "21[reducted]9t" --username "evilman" --password "fdsajkj3irfjkjfisadj4A!" --no-sign-request

すると、なんか作れてそうな応答が帰ってくる。然后，我得到的回应似乎能够有所作为。
これでevilman:fdsajkj3irfjkjfisadj4A!でログインしてみるとログインできるようにはなった。
现在，您可以在使用登录时登录 evilman:fdsajkj3irfjkjfisadj4A! 。
You are not Admin user.
ok.

adminで検索するとself/lib/api/functions/authorizer.tsに以下のような部分が見つかる。
如果使用 admin 进行搜索，您将 self/lib/api/functions/authorizer.ts 在中找到以下部分。

    if (payload["custom:role"] !== "admin") {
      return denyPolicy(event.methodArn, "not admin");
    }

ここですね。custom:roleとやらをadminにすればフラグがもらえそう。
这是对的。如果将 custom：role 设置为 admin，则会收到一个标志。
どうすればいいかなと思っているとちょうどヒントが降ってくる。
就在我思考该怎么做的时候，一个提示出现在我身上。

ユーザーの属性の特性、どないせい？用户属性的特征是什么？
2024-01-16 19:15:26

ユーザーの属性に対するアクセス制御のデフォルト値は？
用户属性的访问控制的默认值是多少？
ユーザーの作成や属性の変更は、アプリケーションクライアントや IAM の権限によって制御することが可能です。アプリケーションクライアントの属性の権限は、デフォルトでは全ての属性を許可しています。このため、アプリケーションクライアントの属性の制御は明示的に行う必要があります。
创建用户和修改其属性的能力可以通过应用程序客户端和 IAM 权限进行控制。缺省情况下，应用程序客户机的属性权限允许所有属性。因此，必须显式控制应用程序客户机的属性。

https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-attribute-permissions-and-scopes

カスタム属性はどうやって追加するの？如何添加自定义属性？
このドキュメントを参考にしてください。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes
使用此文档作为参考。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes

そう。それがやりたいことなんだけれど、やり方が分からない。
右。这就是我想做的，但我不知道该怎么做。
でも何とかして外部からカスタム属性をつけることができそうなのはヒントから分かる。
但是，我从提示中可以看出，似乎可以以某种方式从外部添加自定义属性。
aws cognito-idp sign-upで属性を追加できないか？というアイデアが出る。
aws cognito-idp sign-up 我不能在中添加属性吗？这个想法出来了。
aws cognito-idp sign-up helpを眺めてみる。 aws cognito-idp sign-up help 让我们来看看。

...
          [--user-attributes <value>]
          [--validation-data <value>]
          [--analytics-metadata <value>]
          [--user-context-data <value>]
          [--client-metadata <value>]
...

なんかそれっぽいオプションがたくさんありますね。有很多这样的选择。
ここから熱烈ググると以下の記述を見つける。如果你从这里热情地谷歌一下，你会发现以下描述。

aws cognito-idp update-user-attributes —access-token ACCESS_TOKEN –user-attributes Name=”nickname”,Value=”Dan” https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-attributes.html#:~:text=aws%20cognito%2Didp%20update%2Duser%2Dattributes%20%2D%2Daccess%2Dtoken%20ACCESS_TOKEN%20%2D%2Duser%2Dattributes%20Name%3D%22nickname%22%2CValue%3D%22Dan%22
aws cognito-idp update-user-attributes — access-token ACCESS_TOKEN –user-attributes Name=“nickname”， value=“dan” https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-attributes.html#:~:text=aws%20cognito%2Didp%20update%2Duser%2Dattributes%20%2D%2Daccess%2Dtoken%20ACCESS_TOKEN%20%2D%2Duser%2Dattributes%20Name%3D%22nickname%22%2CValue%3D%22Dan%22

まさに求めていたものがそこにあった。这正是我想要的。
update-user-attributesについてのものだが、--user-attributes自体の用法は同じだろうということで以下のようにやってみると成功する。
至于 update-user-attributes，这个词本身的用法 --user-attributes 可能是一样的，所以尝试以下操作，它会成功。

aws cognito-idp sign-up --region "ap-northeast-1" --client-id "21[reducted]9t" --username "evilman2" --password "fdsajkj3irfjkjfisadj4A!" --no-sign-request --user-attributes Name="custom:role",Value="admin"

これでevilman2:fdsajkj3irfjkjfisadj4A!でログインするとフラグが得られた。
现在，当您 evilman2:fdsajkj3irfjkjfisadj4A! 使用登录时，您会看到一个标志。

ちなみに、この後にも2つヒントが出ていた。顺便说一句，在此之后有两个提示。

認可？どこでやってるんだろう？批准？他们在哪里做？
2024-01-16 19:20:21
このアプリケーションでは、API Gateway のカスタムオーソライザーを利用しています。 https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
此应用程序利用 API Gateway 的自定义授权方。 https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
ファイルは、self/lib/api/functions/authorizer.js にあります。
该文件位于 self/lib/api/functions/authorizer.js 中。

それと和

必要な属性は？我需要什么属性？
2024-01-16 19:25:15
self/lib/api/functions/authorizer.js では、どのような処理をしていましたか？後ろで待ち構える Lambda Function には、context という引数が渡されます。
你在self/lib/api/functions/authorizer.js中做了什么？在您身后等待的 Lambda 函数将传递一个名为 context 的参数。

あと更なるヒントが口頭でも出ていた。口头上也有更多的暗示。

「Flatt Security Blogにあるかもな～」
“可能在Flatt安全博客上~”

この後解説も聞いたが、ソースコードをちゃんと読んでおらず、いかに雰囲気で問題を解いているかが分かる。
这之后我听了解释，但是我没有正确阅读源代码，我可以看到气氛是如何解决问题的。

Miss Box 解けなかった盒子小姐无法解决

令和最新版の画像共有サービス「File Box Advance」を使ってみました!
我尝试使用最新版本的令和图像共享服务“File Box Advance”！
とても便利!いっぱい使ってみてください! 非常方便！尝试经常使用它！
あと、もし何か面白い画像があったら管理者に教えてくださいね!
另外，如果您有任何有趣的图像，请告知管理员！
使い方は添付ファイルを見てください！有关如何使用它，请参阅附件！

解けなかったので以下感想です。我无法解决它，所以这是我的印象。
記憶を思い出せる限り書きだしただけなので、興味のある方のみどうぞ。
据我所知，我刚刚把它写下来了，所以只有你有兴趣的时候才请。

画像ファイルをアップロードできるサイトが与えられる。
您将获得一个可以上传图像文件的站点。
とりあえず、サイトを閲覧してみると、ReportができるのでXSS問題かなと考えていた。
目前，当我浏览该网站时，我以为这是一个XSS问题，因为我可以做一个报告。

既にヒントが出ているのでヒントを見てみる。已经有提示了，所以让我们来看看提示。

前回の続きと、その派生を考えよう让我们考虑上一篇文章及其衍生物的延续
2024-01-16 19:24:59
self と同じように属性に何か鍵があるかも？也许像 self 这样的属性有某种关键？

属性を変える必要がある。属性を同じように持ってきている部分を探してみるとmiss_box/infra/lib/api/functions/authorizer.tsにあった。
您需要更改属性。当我寻找以同样方式带来属性的部分时，我发现 miss_box/infra/lib/api/functions/authorizer.ts .

    return allowPolicy(event.methodArn, {
      tenant: payload["custom:tenant"],
    });

何に対するポリシーが許可されるのか分からないが、custom:tenantに入れ込んだテナントが許可されるっぽい。
我不知道该策略的允许用途是什么，但似乎允许将租户放入 custom：tenant。
テナントってなんだと思いながら巡回するがよく分からない。
我四处走动，想知道什么是租户，但我并不真正理解它。

まあ、気を取り直して、目玉機能のファイルアップロードの部分について読んでいこう。
好吧，让我们回到我们的轨道上，阅读有关特色功能的文件上传部分的信息。
miss_box/infra/lib/api/functions/signedUrlPut.tsを開いて中身を見てみると、拡張子、ファイルサイズ、Content-Typeのチェックをしている。
miss_box/infra/lib/api/functions/signedUrlPut.ts 当我打开它并查看内容时，我检查了扩展名、文件大小和 Content-Type。
突破できなさそうに見えるな…と思いながらも、これを何とかするんだろうなぁと思いを巡らすがアイデアは特に出ず。
看来你突破不了…… 我想知道我是否会为此做点什么，但我没有想出一个主意。

ヒントが出る。提示出来了。

アップロード用の署名付き URL はどこで作ってるんだろう？
在哪里创建用于上传的预签名 URL？
2024-01-16 19:34:49
miss_box/infra/lib/api/functions/signedUrlPut.ts を読んでみると、どうやら S3 の署名付き URL を作っている条件が書かれているようです。
如果您阅读 miss_box/infra/lib/api/functions/signedUrlPut.ts，它似乎描述了创建 S3 签名 URL 的条件。

Burpでの履歴を眺めてみると、アップロード時は
如果你在 Burp 中查看历史记录，你可以在上传时看到它

rp065n90h5.execute-api.ap-northeast-1.amazonaws.comのPOST /v1/box/signed-url/putにjson形式でメタデータを入れ込む
rp065n90h5.execute-api.ap-northeast-1.amazonaws.com POST /v1/box/signed-url/put 将元数据放入 JSON 格式
応答に署名付きURLが帰ってくる响应中返回预签名 URL
それを使ってmissbox-web-web-host-bucket.s3.ap-northeast-1.amazonaws.comにPOSTでファイルアップロード
使用它通过 POST missbox-web-web-host-bucket.s3.ap-northeast-1.amazonaws.com 将文件上传到

という流れになっている。これは着目すべきポイントになりそう。
事情就是这样。这似乎是一个需要关注的点。
しかも中身を見ると X-Amz-SignedHeaders=content-length%3Bhost というのが含まれていて、Content-Typeが含まれていない。
此外，如果您查看内容，它包含 X-Amz-SignedHeaders=content-length%3Bhost ，但不包括 Content-Type。
これは差し込めるのでは？这不是插电的吗？

…とさらっと書いているが、思考が行ったり来たりして時間内に考察できていたのはここまで。
… 我写得很轻，但我的思绪来回走动，我能够及时思考它。
ここまでの考察でContent-Typeを自由に変更する所までは成功している。
到目前为止，我们已经成功地自由地更改了 Content-Type。
次の問題はどうやって管理者にこのファイルを「元のサイトのドメインで」踏ませるかであり、ここにもう1つ超えるべき壁があった。
接下来的问题是如何让管理员“在原始站点的域中”踩到这个文件，还有一个障碍需要克服。

復習したらこの続きを追記するかもですが、st98さんの解説を見る方が遥かに良いです。
当我回顾它时，我可能会添加这个延续，但最好看看 st98 的解释。