Hello World, Hope you'll are doing well & i know you are reading this post after reading the post title , RCE in PayPal's server ? dafaq ? seriously ?
Trust me the POC is piece of cake , Only thing is I was lucky enough to enumerate & find the domain vulnerable to this attack.
Lets start with the story :
If you may have seen my last post I recently cracked OSCP which did require a lot of hard work days & nights - approx 4 months focus & away from bug hunting that means away from pocket money ;) .
Normal people: Weekends are full of drinks , parties ,fun , hangouts etc. Hey did you watch Spider-Man: Homecoming ? Game of Thrones ?
People like me :
So,as usual one weekend i was going through some blogs , youtube stuff, I came across some write up of paypal & thought of visiting the PayPal's Bug Bounty page with our Interceptor off in Burp and came across some thing below :
The snapshot above is just a simple response of opening http://paypal.com/bugbounty/ ,Having a closer look there's a cool list of PayPal's domains mentioned in "Content Security Policy:" Response Header. One of which was "https://*.paypalcorp.com" & looked interesting to me,as always one of my basic methodology during Bug Hunting is to find as much possible valid sub domains of the target as these are the places which are normally overlooked waiting for us ;).
You can use (Subbrute , Knockpy , enumall etc.) these are the tools which i normally use , but being lazy on the weekend i made use of VirusTotal this time to enumerate the sub domains you can get the list here :
Copied the subdomain's list locally & ran "dig -f paypal +noall +answer" to checkout where all the subdomains are actually pointing to in a neat way :
One of which was "brandpermission.paypalcorp.com" pointing to "https://www.paypal-brandcentral.com/",this site is actually a Online Support Ticket System for PayPal Vendors ,Suppliers & Partners where they request for PayPal Brand Permissions & had the feature of uploading Mockups of the Logos,Graphics related to the brand along with the ticket.
Every Bug Hunter's reaction after seeing file upload functionality :
So, I first created a ticket by uploading a simple image file named "finished.jpg" which got stored as " finished__thumb.jpg " in directory :
"/content/helpdesk/368/867/finished__thumb.jpg" "finished _thumb.jpg" was the new file created in the directory "/867/" i quickly checked whether the actual file which we uploaded exists in the directory or not,luckily (You'll know why later in the post ) "finished.jpg" also existed in the same directory. Cool stuff ;)
I further researched on the Actual Work Flow of the application how is it uploading where are the files uploaded , what are the file / folder naming conventions etc & understood that "368" directory in the above link is actually the ticket number we created & "867" is the folder's id where all the files related to the tickets are stored which includes the Mockup files.
I quickly created another ticket with same steps noticed that the ticket id & file id numbers are generated in serial manner. Created another ticket ,but this time uploaded a ".php" extension file which had a simple one liner command execution script :
which gave = 302 Response ( Which means 200 OK ;) according to the behavior of the application ,that means there were no controls in place to validate file type, content etc. Oh Yes ! I was like :
As soon as i saw 302 Response , i ran towards opening the ticket & doing a simple right click copy link shit like i was able to do when uploading a image file . But,here in this case if you upload a php file as mock up you can't see the path of the php file uploaded only thing which is visible is the ticket number.
So what's next ?
As i got the ticket id as "/366/" now we know what's the directory where our mock up files has been uploaded but we actually don't know what's the folder id where our file is stored ? (Because,we are not able to see the location of the php file like we are able to see for a image file by source code view ).
But, We do know the file name which is "success.php" ( Because we verified before that uploading " example.jpg "gets stored in same directory where the "example_thumb.jpg" is stored )
Same way assuming success.php as actual file as the success_thumb.php was eating away our one liner php code ( I hope you got why i said "Lucky" before )& we are also aware with the most recent folder id where the files are stored by uploading an simple image before. Therefore, as the recent file id i knew was "867" & the ticket id for our POC php Command Execution code is "/366/ "
Why not brute force the folder id for files ?
So i quickly fired my intruder to brute force the below request starting with the file ids 500-1000 : https://www.paypal-brandcentral.com/content/_helpdesk/366/$(bruteforced 500-1000)$/success.php & got a 200 response on "865" folder id.
I was like :
Cool ! Lets try executing code now :) with the ticket id & the file id we got above : https://www.paypal-brandcentral.com/content/_helpdesk/366/865/success.php?cmd=uname-a;whoami
Some cat+/etc/passwd magic to make myself beleive that i have actually found a RCE ;)
The server actually had an Login page for the PayPal Employees too.
I hope you liked the write up , I would appreciate your feedback in the comments down below ;)
Responsible Disclosure Time line :
~ Jul 08, 2017 18:03 - Submitted
~ Jul 11, 2017 18:03 - Fixed
~ Jul 25, 2017 3:30 - Rewarded
Wait ! The game doesn't end here check out the list of findings below which i will be writing soon on the blog in another weekends, I reported the same vulnerability in different endpoints in the application one was straight forward so both has been merged in ticket & marking one as duplicate .
Make sure to subscribe / bookmark my blog if you don't wanna miss my post updates ;).
Thank you ! Happy Hacking ! Be Positive & Keep Hustling !
Shoot me an email say Hi at email@example.com .