Jump Ahead: Enum – Initial Foothold – User – Root – Resources

TL;DR;

To solve this machine, we begin by enumerating open services – finding ports 80, 3690, and 5985 open. Checking out port 3690 we learn it is a subversion server. While enumerating it, we find a set of credentials as well as several subdomains. One subdomain we eventually learn of is http://devops.worker.htb, which after using the credentials we found to login, we are presented with Azure Devops. Through this, we are able to upload and execute a reverse shell on one of the previous subdomain we found. While enumerating the remote machine, we find another set of credentials, which we use to remotely connect as the robisl user – and gain user.txt. Using robisl‘s credentials to log into devops, we are able to exploit Azure Pipelines to execute system commands – gaining root.txt.

Enumeration

To solve this machine, we begin by enumerating open services – finding ports 80, 3690, and 5985 open.

To bruteforce files and directories on the webserver at port 80, we use gobuster, however, we do not get valuable results. Port 5985 is typically associated with WinRM, which we would need credentials to authenticate with, so we can’t do much with it right now. Port 3690 is something we have not seen before, so we do some researching and learn it is associated with subversion – the precursor to git. To enumerate the subversion server, we use the svn info command.

From the output, we learn of a potential user (nathen) and a potential subdomain (dimension.worker.htb).

• 

After adding the potential subdomain to our /etc/hosts file, we go to http://dimension.worker.htb and are presented with a website. After clicking the “Work” link, we are presented with more possible subdomains, which we also add to /etc/hosts. Checking these other subdomain do not appear to present us with additional information. Next, we checkout the subversion repository to look for any interesting information we can find.

Doing so, we obtain what appears to be the source code of http://dimension.worker.htb and also moved.txt. Looking at moved.txt we are told the latest version of the repo is at http://devops.worker.htb.

• 

After adding this new subdomain to our /etc/hosts file, we try to go to it, however, we are asked for credentials, which we do not have. Next, we decide to take a look at the log to see what changes have been committed. After running svn log, we see that a deployment script was added with revision 2 (r2). A deployment script may contain information disclosure, or potentially credentials, so we decide to checkout the r2 revision.

Doing so, we see moved.txt is deleted, and deploy.ps1 is added. Printing out deploy.ps1, we are given potential credentials for nathen.

• 

• 

Initial Foothold

Now that we have credentials, we go back to http://devops.worker.htb/ and log in. Doing so, we are presented with an Azure DevOps page with a project called “SmartHotel360”.

• 

Next, we navigate to “SmartHotel360->Repos”, and are presented with what looks like a GitHub repository that defaults to “Spectral”. Spectral is one of the subdomains we found, so this may potentially be the source code for it. Azure DevOps allows for CI/CD through Azure Pipelines, which means that if we are able to push code to the master branch, we may be able to access it from the webserver – such as for executing a reverse shell. To try to upload a reverse shell to the webserver, we start by creating a branch of the repository – I named mine “khaotic”. Next, we use msfvenom to generate the reverse shell, and use nc to start a reverse shell listener.

Once the reverse shell is generated, we upload it to the repository branch.

• 

• 

Next, we click the link to create a new pull request. We approve the request, and create a work item for it.

• 

Lastly, we click “Complete” and “Complete Merge”. Once the changes have been merged to the “Master” branch, we can navigate to http://spectral.worker.htb/shellme.aspx to execute the reverse shell. Doing so, we are given access to the machine as iis apppool\defaultapppool.

• 

Getting User

After we’ve gotten a shell as iis apppool\defaultapppool, we upload winPEAS to the machine and run it for our initial enumeration. After doing so, we see that the machine has a second drive attached – W:\. Looking around the drive, we find W:\svnrepos\www\conf\passwd, which contains about 40 possible account credentials.

• 

• 

Comparing it to C:\Users\, see what that only user robisl is a valid account. Using the credentials, we use evil-winrm to log into the machine – gaining access to user.txt.

• 

• 

Getting Root

After remoting into the machine as the robisl user, we again run winPEAS, however, we do not find anything of value. Next, we log into the Azure Devops with the credentials for robisl, and select the “PartsUnlimited” project. One thing we can do, is try to make use of CI/CD to potentially push a backdoor to the machine. To do this, we navigate to Pipelines->Azure Repos Git->PartsUnlimited->Starter pipeline->Save and run. On the “Save and run” page, we need to select to create a new branch for the pull request.

• 

• 

After we press the “Save and run” button, we receive an error because the pool is incorrect. To correct this issue, we check Project Settings->Agent Pools, and see there is a pool named “Setup”.

• 

Now that we know the correct name of the agent pool, we can go back to the branch we created in the repo, and edit “azure-pipelines.yml”. We change the pool from “Default” to “Setup”, and from additional research, we learn we can run powershell commands directly from the pipeline as a step. Rather than try to get a reverse shell, we attempt to add a user, and add it to the “administrator” and “remote management users” groups.

• 

• 

After we’ve committed the changes, we need to create a pull request to have them merged into the master branch. We are able to approve the pull request, however, it needs a work item. To create a work item, we click ‘+’->New work item next to the project name – type/name/etc doesn’t matter. Next, we add the work item to the pull request. To finish up the pull request, we select “Complete” and follow through with the merge.

• 

• 

• 

Once the merge is complete, the master branch should now have the backdoored pipeline. To execute the pipeline, we need to go to Pipelines->“New pipeline”->Azure Repos Git->PartsUnlimited->Click “Run”. Everything should run fine, and our new account should be created.

• 

Using evil-winrm, we should be able to log into the new account, and grab root.txt from C:\Users\Administrator\Desktop\.

• 

• 

Thank you for taking the time to read my write-up. I am interested in other ways this machine has been solved. Feel free to reach out to me and we can discuss it. Thanks!

Khaotic Pro Hacker

Rank: 886 2 47

hackthebox.com

Resources

• Using powershell to customize your build pipeline