How I bypassed IDOR (Access Control) Protection

Note: This article was originally written by me on August 13, 2017, but re-posting this here because I deleted the other blog!

While pentesting a HackerOne's private program. I noticed that there was an option to create a team, it also had an option to invite other members using email. And on the same page, the emails (which were invited and which were already part of the team) were displayed. Since now, I’ve been calling it ‘team’, but the site represents it with the name ‘brand’.

The program being private on hackerone, we will scrutinize the site as: http://vulnsite.com!

So, while testing for race-conditions on the invite members option, I came upon this GET request:

GET /_ajax/profile/brands/BACawjzt-Xk/invitations? HTTP/1.1
Host: www.vulnsite.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-[sitename]-Analytics: AAMAA1dFQgA=
X-[sitename]-Brand: BACawjzt-Xk
X-[sitename]-Build-Name: vikachu
X-[sitename]-Build-Sha: 523fa138b0e9bf1142857fe3093fc196d7fae55f
Referer: https://www.vulnsite.com/brand/members
Cookie: __cfduid=d001041a315ddda7daf205bd739e3379c1499609824; ajs_user_id=%22UACawu1inbU%22; ajs_group_id=null; _ga=GA1.2.14298406.1499609833; _gid=GA1.2.283747709.1499609833; amplitude_idsite.com=eyJkZXZpY2VJZCI6IjEzODViZGNhLWU4MTEtNGYzMi1hNWQ4LTRkODM0NzZiNDZlMVIiLCJ1c2VySWQiOiJVQUNhd3UxaW5iVSIsIm9wdE91dCI6ZmFsc2UsInNlc3Npb25JZCI6MTQ5OTYwOTgzNDU5MCwibGFzdEV2ZW50VGltZSI6MTQ5OTYxMDcxNjgzOCwiZXZlbnRJZCI6MjIsImlkZW50aWZ5SWQiOjksInNlcXVlbmNlTnVtYmVyIjozMX0=; ajs_anonymous_id=%226b19b45b-a10f-4746-b51e-e80cb7857ebd%22; CB=BACawjzt-Xk; CID=qwnCP4SBWmwKK7G5TMHo_1i9fZkR--6jbAveJhXv0TtZSW9ZxFYo7_6hJbdClX222magRgndXFuELRSor_Y7rjpKG0d1Zw9ASs5iwBmCEHcehxkG; CAZ=Echg-KSowZ4_zul8qvTPkug0EPdfwBltvGYHLUozgSr6VheNLgSuxmdoQ7yxIdG90k2UlsCqBv_jjql2I34Sb52f251wkfqdur56KY_5N4Ww71sMGqQ_BTWBFHXjwzzSiPBagAS7g9oTefYK3aQsx-MB93YuCObXfoeFiqpJ-RGUy-qE1hoRftM7oixjuLNHz9zCmL3hqVZcMVwofELtI88z3chGhHWtuCvHVW6fRpore-YJ59DKkhOL_w_yi_XW8BcQG7CJti_eCXPZ6SW1Q_MCxzCvi_ITSCYRFgNbk4Mtbwu9; CL=en; CS=1; __vero_user=UACawu1inbU; __stripe_mid=7cfed837-f29b-41d1-9559-93c1707bdc1e; __stripe_sid=ae257182-0b7a-45b5-8d29-5296b81c4442; CC=PK; __veroc4=%5B%5D; __vero_visit=true
Connection: close

Repeating this request, in response I got all the emails which were invited to my brand (team). Now this is interesting, since there was a brand ID in the GET request. I quickly created a new account on vulnsite.com another machine (VM), invited some emails and grabbed the brand ID of the victim account (which was created on VM).

Back to the attackers machine, with full hope of getting an IDOR (missing access control). I changed the ID in the GET Request: /_ajax/profile/brands/[victim-brand-id]/invitations?=> Repeated the request, and all I got was a 403 Forbidden error! 

I decided to dig deeper, and found that the brand ID was *not* just in the GET data, but there were 3 values on the brand ID in the same request:

  • GET request /_ajax/profile/brands/BACawjzt-Xk/invitations?
  • X-[sitename]-Brand: BACawjzt-Xk (Header)
  • CB=BACawjzt-Xk (One of the cookie values)

Now this is really compelling, quickly changed the brand ID values in all three options: (The GET request, X-Site-Brand header, CB cookie value) to the victim (VM machine) account’s brand ID.
Replayed the request, and BOOM! ๐Ÿ˜‰ All the invited emails in the victim’s brand were displayed in front of me! ๐Ÿ˜€

I quickly wrote a report and submitted it via HackerOne to the private program. But since this doesn’t seem to be a big issue (only emails being disclosed), I started digging deeper and found that this was a site-wide vulnerability in the X-Site-Brand header and CB cookie value. Now, exploiting both of them to bypass the IDOR (Access Control) protection allowed me to do anything with the team just by knowing the brand ID: Disclosing sensitive information, removing members, adding members, and last but not the least: adding administrators which lead to complete takeover of the brand! I quickly sent all this information to the site’s security head (via email and told him about the report ID on HackerOne).

After 3 days of reporting, they fixed the issue, and since they mostly reward bounty under $256, and this was a critical one, so they rewarded a bit more:



Thanks for reading till here, I hope you learned something. Happy hacking!
Ahsan Tahir

[Write-Up] Open URL Redirection & Xss In Dato Capital



Hey guys, how are you going? I hope good!

Today, I am going to share the PoC of two vulnerabilities which I've found in Dato Capital.

So, the two bugs were following:

  1. Open URL Redirection
  2. Cross Site Scripting

Open URL Redirection:

First, I'll write about the Open URL Redirection, which I've found in Dato Capital.
The vulnerable pages was /isn/Login and the vulnerable parameter was u=
the final URL was https://en.datocapital.com/isn/Login?u=[Evil Site Here] 

After the victim login to his/here account, her/she will be redirected to attacker's site.

STEPS TO REPRODUCE:

  • Go to this URL: https://en.datocapital.com/isn/Login?u=https%3A%2F%2Fwww.google.com.pk%2F
  • Log in to your account
  • You will be redirected to Google.com.pk

Cross Site Scripting (XSS):

Now, I am going to write about the stored cross site scripting bug which I've found in Dato Capital, the vulnerable areas were [Name, VAT#, ADDRESS] and the type of xss was stored, so the site was defacealbe and whenever the user visits, pop-up will occur each time.

STEPS TO REPRODUCE:

  • Login to account
  • Go to menu
  • Click on Edit profile
  • Check mark on generate invoices
  • In all fields, enter this payload: "><img src="x" onerror=prompt(document.domain)>
  • Again click on edit profile, xss will pop-up!

And for reporting these two issues, Dato Capital listed my name in thier Hall of Fame, and wrote "2 contributions" as you can see in the screenshot:


Thanks for reading.

VIDEO PoCs:

OPEN URL REDIRECTION:



CROSS SITE SCRIPTING:


[Write-Up] Stored Cross Site Scripting in "World Beyblade Organization"

Hey, this is my first write-up on my blog, today I am going to share the PoC of Stored XSS (Cross Site Scripting) vulnerability, which I've found in WBO (World Beyblade Organizaion)

So, the bug existed in "Tumblr option for adding your tumblr blog to your profile on WBO!

It was not filtering the user input, and as a result we were able to execute JavaScript in your profile page! As you can see in the screenshot below.




STEPS TO REPRODUCE:
  • Go to your User control panel
  • Click on edit profile
  • And this code: "><img src="x" onerror=prompt(document.domain)>
  • Go to your profile, the xss will pop-up
Moreover, the input was stored, so the site was also defaceable, and everytime a user opens the page, the xss will pop-up!

Thanks for Reading!

VIDEO PoC:-