First bug on VDP program

6 months ago 31

BOOK THIS SPACE FOR AD

ARTICLE AD

بسم الله الرحمن الرحيم

hey there in this write up I'll talk about how I discover my first 3 bugs on a VDP program which i ‘ll mention it as target.com let’s get start

old methodology
in my old methodology i didn’t test the main domain, think about it will be secured, what i was doing is go throw jhaddix methodology by start to find domain acquisitions, then subdomains ,do some fuzzing by dirsearch, try to find some parameters using arjun, find some urls from waybackmachine or follow some GitHub methodologies. this approach is great but most of the time leads to duplicates.which change help me out to find this vulns ?
by talking my friend advice “take note for every request and response”, and what i did is “take one function at a time, use it as normal user, and write notes for every request and it’s response, try to understand the process and then test every request individually”, open my bugbounty notes a side and ask my self does vuln X could be exist in request Y, and discover the answer.

let’s start

what’s CSRF
Cross-Site Request Forgery (CSRF) occurs when requests to the application are submitted on behalf of an authenticated user without their knowledge via crafted, malicious code which can be in the form of a link the user clicks.

using above methodology i first open target.com witch was like static pages so i create an account and take notes of the process and test it with no luck, next i try test some XSW attacks on login because of SSO implementation by SAML with no luck,.. testing the functions one at time take notes about the requests and response headers, cookies and it’s flags noted that almost all cookies have “samesite=lax”
by testing update value of “get email notifications” check button, where a POST request send with tow params “form=random_id&update=true” i found that if “form” sent with empty value the function still work, i make POC for it but it’s not work
back to my cookie notes found that my highlighted words “samesite=lax” witch means that the cookie sends with only user action such click link,… back to my bugbounty notes search about “samesite=lax” bypass, and found that send GET request with parameter “_method=post” can by pass it.

but why all this work on a function have 0 severity, cuz if developer implement it that way here then it’s implemented same way on every form

and this’s right by testing security question form i found that same bypass works so i craft my POC to select first security question and set it’s answer to “secretanswer123”

<html> <body onload=document.getElementById(‘csrf’).submit()>
<form id=’csrf’ action=”https://store.target.com/account/updateQuestion/" method=”GET” >
<input value=”reg.form.secret.question1" type=”text” name=”question” hidden>
<input value=”secretanswer123” type=”email” name=”answer” hidden>
<input value=”” type=”email” name=”form_key” hidden>
<input required name=”_method” type=”text” value=”POST” hidden>
<button class=”button” type=”submit” hidden> Update email </button>
</form>
</body> </html>

host it on tiiny.host, open the link on same browser that i used to login,
then open new browser navigate to “store.target.com/customer/account/” follow the redirection to SSO subdomain, and click forget password, submit my email, and use my answer “secretanswer123” , got redirect to reset password page, set my new password

and POOOOM i can use the new password to open my account

in the next write up i’ll talk about the other 2bugs

Read Entire Article