How I got into the PayPal server through a bug in downloading files and got access to remote code execution
Pentester (penetration tester) tells how he managed to find a bug in downloading files and penetrate the PayPal payment system server.
Hello to all!
')
Hope you are doing well. I am sure that the title surprised you a lot, and you rushed here to see if I really could get remote access not just anywhere, but to the PayPal server.
In fact, it was quite a simple hack aimed at checking vulnerability (the so-called POC). The only moment I was lucky with was finding and successfully defining a vulnerable domain.
Let's start with a little background. As you could see earlier in my previous post, I recently passed the OSCP certification exam . It really took me a lot of days and nights of hard work - almost 4 months of focused training and no search for bugs, that is, in fact, no earning of pocket money.
Normal people: a weekend full of booze, parties, fun, hangovers and other things. Questions like: “Did you watch the new Spider-Man?” Game of Thrones? ”
People like me:
So, one weekend, looking at some blogs and videos on YouTube, I came across the material on PayPal, thought to go to their page to promote the bug search promotion using Burp and found the following:
The screenshot shows the usual response from http://paypal.com/bugbounty/ . Looking closely, you can see a curious list of PayPal domains in the Content Security Policy response header. I was interested in https: //*.paypalcorp.com . This is a typical approach that I use to catch bugs. I am looking for as many working subdomains as possible for the final goal, since they are usually left without proper attention, and, like me, as a result, they find something there.
You can use Subbrute , Knockpy , enumall or other similar utilities. I usually do this, but on this weekend laziness got the better of it and I scanned them in VirusTotal. The final list can be found here .
I copied the list of subdomains to the local machine, launched dig -f paypal + noall + answer to get a convenient picture of where all the subdomains actually point to.
One of them, brandpermission.paypalcorp.com, pointed to https://www.paypal-brandcentral.com/ - a site for registering requests to PayPal’s online support service for vendors, suppliers and partners, through which they request permission to use the brand. The system is available to download the draft versions of logos and graphics at the time of the request.
The reaction of any bug hunter who saw the file upload form:
Smells catch
Therefore, for starters, I created a “ticket” by uploading a simple image called finished.jpg. It got to the server under the name finished_thumb.jpg along the path / content / helpdesk / 368/867 /. I quickly checked whether the file that we sent through the form named finished.jpg was loaded and yes, fortunately (this fact will play its role later) he was there.
Next, I learned a little about how the application works: how it loads files, where they go to, what name patterns for files and folders are accepted in it. It became clear that the catalog 368 was named so by the number of the ticket I created, and 867 - the identifier of the folder in which all the files associated with it are stored, that is, various graphic materials attached to the ticket.
I quickly repeated the same actions, created another appeal, from which it became clear that the ticket identifiers and folders are serially generated. Created another ticket, but this time uploaded a file with the .php extension, containing a simple single-line script for the command line:
The script returned 302 code (that is, in fact, 200 OK). This meant that the application did not do any checks on file types, content, and other things. There is! My face at this moment:
Come on...
After seeing the 302 code, I rushed to open a new ticket to copy the link as it was in the case of loading an image file. But when sending .php see the path of the downloaded file was impossible. The only thing you could know was the ticket number. What to do next?
And now ...
Having received the ticket number (366 in this case), we will know the name of the directory where our “graphic examples” were loaded. All that is missing is the folder identifier where the file falls into (since we cannot see the php file when viewing the source code of the page as it is possible with images).
But we know the name of the file - success.php (since we checked before that example.jpg was in the same folder as example_thumb.jpg).
So, despite the fact that when loading and processing success.php in success_thumb.php, the code of the first one was “eaten”, success.php, however, it still exists on the server and can be accessed. We also know the folder ID (867), obtained when loading a previously simple image. The ticket number for downloading the verification php is 366.
Why not just mess up the folder IDs where the downloaded file is stored?
You can not just take and zabrutass
Therefore, I quickly launched the following search with identifiers 500-1000 in Intruder:
https://www.paypal-brandcentral.com/content/_helpdesk/366/$(brutecent 500-1000) $ / success.php. As a result, 200 code was received on the identifier 865.
My reaction:
Cool! Now, when we found out the catalog directory with the file, let's try to execute the code: https://www.paypal-brandcentral.com/content/_helpdesk/366/865/success.php?cmd=uname-a;whoami
A little magic cat / etc / passwd to make sure that the possibility of remote code execution really is:
The server also had an authorization page for PayPal employees.
Hope you enjoyed this stuff! I would really appreciate feedback in the comments;)
Chronology of processing treatment:
~ July 8, 2017 18:03 - Report a bug to PayPal
~ July 11, 2017 18:03 - Bug fixed
~ July 25, 2017 3:30 - Received an award
But wait! The story does not end there. Here is some more seed material. I will tell about it in my blog on the following weekend:
I reported the same vulnerability at different points in the application. One of the messages was quite obvious, so they were combined into one message, and the second was marked as duplicate.
From the translator:
At the time of publication of the translation, the site www.paypal-brandcentral.com became unavailable, giving an HTTP 500 error. Probably the publication of the original article served as a source for detecting more serious vulnerabilities by other researchers.
Hello to all!
')
Hope you are doing well. I am sure that the title surprised you a lot, and you rushed here to see if I really could get remote access not just anywhere, but to the PayPal server.
In fact, it was quite a simple hack aimed at checking vulnerability (the so-called POC). The only moment I was lucky with was finding and successfully defining a vulnerable domain.
Let's start with a little background. As you could see earlier in my previous post, I recently passed the OSCP certification exam . It really took me a lot of days and nights of hard work - almost 4 months of focused training and no search for bugs, that is, in fact, no earning of pocket money.
Normal people: a weekend full of booze, parties, fun, hangovers and other things. Questions like: “Did you watch the new Spider-Man?” Game of Thrones? ”
People like me:
So, one weekend, looking at some blogs and videos on YouTube, I came across the material on PayPal, thought to go to their page to promote the bug search promotion using Burp and found the following:
The screenshot shows the usual response from http://paypal.com/bugbounty/ . Looking closely, you can see a curious list of PayPal domains in the Content Security Policy response header. I was interested in https: //*.paypalcorp.com . This is a typical approach that I use to catch bugs. I am looking for as many working subdomains as possible for the final goal, since they are usually left without proper attention, and, like me, as a result, they find something there.
You can use Subbrute , Knockpy , enumall or other similar utilities. I usually do this, but on this weekend laziness got the better of it and I scanned them in VirusTotal. The final list can be found here .
I copied the list of subdomains to the local machine, launched dig -f paypal + noall + answer to get a convenient picture of where all the subdomains actually point to.
One of them, brandpermission.paypalcorp.com, pointed to https://www.paypal-brandcentral.com/ - a site for registering requests to PayPal’s online support service for vendors, suppliers and partners, through which they request permission to use the brand. The system is available to download the draft versions of logos and graphics at the time of the request.
The reaction of any bug hunter who saw the file upload form:
Smells catch
Therefore, for starters, I created a “ticket” by uploading a simple image called finished.jpg. It got to the server under the name finished_thumb.jpg along the path / content / helpdesk / 368/867 /. I quickly checked whether the file that we sent through the form named finished.jpg was loaded and yes, fortunately (this fact will play its role later) he was there.
Next, I learned a little about how the application works: how it loads files, where they go to, what name patterns for files and folders are accepted in it. It became clear that the catalog 368 was named so by the number of the ticket I created, and 867 - the identifier of the folder in which all the files associated with it are stored, that is, various graphic materials attached to the ticket.
I quickly repeated the same actions, created another appeal, from which it became clear that the ticket identifiers and folders are serially generated. Created another ticket, but this time uploaded a file with the .php extension, containing a simple single-line script for the command line:
The script returned 302 code (that is, in fact, 200 OK). This meant that the application did not do any checks on file types, content, and other things. There is! My face at this moment:
Come on...
After seeing the 302 code, I rushed to open a new ticket to copy the link as it was in the case of loading an image file. But when sending .php see the path of the downloaded file was impossible. The only thing you could know was the ticket number. What to do next?
And now ...
Having received the ticket number (366 in this case), we will know the name of the directory where our “graphic examples” were loaded. All that is missing is the folder identifier where the file falls into (since we cannot see the php file when viewing the source code of the page as it is possible with images).
But we know the name of the file - success.php (since we checked before that example.jpg was in the same folder as example_thumb.jpg).
So, despite the fact that when loading and processing success.php in success_thumb.php, the code of the first one was “eaten”, success.php, however, it still exists on the server and can be accessed. We also know the folder ID (867), obtained when loading a previously simple image. The ticket number for downloading the verification php is 366.
Why not just mess up the folder IDs where the downloaded file is stored?
You can not just take and zabrutass
Therefore, I quickly launched the following search with identifiers 500-1000 in Intruder:
https://www.paypal-brandcentral.com/content/_helpdesk/366/$(brutecent 500-1000) $ / success.php. As a result, 200 code was received on the identifier 865.
My reaction:
Cool! Now, when we found out the catalog directory with the file, let's try to execute the code: https://www.paypal-brandcentral.com/content/_helpdesk/366/865/success.php?cmd=uname-a;whoami
A little magic cat / etc / passwd to make sure that the possibility of remote code execution really is:
The server also had an authorization page for PayPal employees.
Hope you enjoyed this stuff! I would really appreciate feedback in the comments;)
Chronology of processing treatment:
~ July 8, 2017 18:03 - Report a bug to PayPal
~ July 11, 2017 18:03 - Bug fixed
~ July 25, 2017 3:30 - Received an award
But wait! The story does not end there. Here is some more seed material. I will tell about it in my blog on the following weekend:
I reported the same vulnerability at different points in the application. One of the messages was quite obvious, so they were combined into one message, and the second was marked as duplicate.
From the translator:
At the time of publication of the translation, the site www.paypal-brandcentral.com became unavailable, giving an HTTP 500 error. Probably the publication of the original article served as a source for detecting more serious vulnerabilities by other researchers.
Source: https://habr.com/ru/post/322802/
All Articles