Azure DevOps
Following the lateral movement to the robisl user, further advancement proved challenging as the user’s home directory was devoid of any content. Additionally, the examining of user privileges of the robisl user did not yield a path for progression.
I will check back at the Azure DevOps server instance.
Given the user’s membership to the Production group, this may imply not only does the user possess access to the Azure DevOps instance, but also potentially wields higher privileges compared to the previous nathen user.
Successfully authenticated to the Azure DevOps instance as the robisl user
While the robisl user is also part of the ekenas collection, much like the nathen user, the project assigned to the user is different.
PartsUnlimited is the project
parts unlimited is also PartsUnlimited is a fictional project created by Microsoft, serving as a comprehensive example for showcasing various features and practices in software development. It encompasses a broad range of aspects, including application architecture, continuous integration, deployment pipelines, and the utilization of Azure DevOps services. The project is designed to illustrate real-world scenarios and best practices in a practical and accessible manner. Source code is available
Since this project is also just another dummy project with arbitrary data, I will only report the key findings
Administrator and restorer users are also part of this project, alongside the previous SmartHotel360 project
Repos
In contrast to the previous HotelSmart360 project, there is only a single repository, PartsUnlimited, containing many more branches
None of the files contain any considerable information
Pipelines
Interestingly, there is not a single pipeline configured for the PartsUnlimited application.
Given the source management appears to be actively maintained with many branches, this is rather strange
I might be able to create a new pipeline. I will check the permissions of the current user below
Permission and Access
Checking the Security section in the Project settings reveals the exact same scenario as the previous case.
The robisl user has a transitive group membership to the Contributors group via the PartUnlimited Team team
This grants the user to conduct the exact same build exploitation technique that was previously used to gain the initial foothold
Agent pools
However, checking the Agent pool reveals the significant difference
There is a single agent pool, Setup, that is owned by the administrator user
Given there are no additional service connections or service identities associated with the Setup agent pool in the PartsUnlimited project, and it’s owned by the administrator user, the build execution context is likely associated with the security context of the administrator user for the builds within this agent pool.
Although there is a small possibility of the difference between privileges of the administrator user set to the target system as a user account and privileges of the administrator user specifically assigned WITHIN the Azure DevOps server instance, it is highly unlikely
Setup.Agents
There are way more agents available within the Setup agent pool
Setup.Details
The Details section in the Setup agent pool indeed confirms the singular and exclusive ownership by the administrator user
Setup.Security
The Security section in the Setup agent pool shows that Pipeline permissions is enabled
This is critical difference because enabling Pipeline permissions grants the ability to create, edit, and execute pipelines within the context of this agent pool
It essentially means that I can leverage this configuration to escalate privilege by creating a pipeline itself. Build made using a newly created pipeline will then be executed under the security context of the administrator user as identified above
Moving on to the Privilege Escalation phase