Azure DevOps
Despite of the trials and errors with some trouble shootings, credential reuse for the nathen user has been confirmed.
An instance of Azure DevOps is identified to be hosted in the devops.worker.htb virtual host / sub-domain
azure devops, Microsoft’s comprehensive DevOps platform, provides a suite of tools and services for software development and delivery. Similar to Jenkins in its role as an automation server, Azure DevOps offers version control, build automation, release management, and collaboration tools. Notable distinctions include Azure DevOps’ centralized, cloud-based approach and its integration with Microsoft’s cloud services. Unlike Jenkins, which is widely known for automation, Azure DevOps provides an integrated platform designed to streamline the entire software development lifecycle.
from an adversary’s standpoint, azure devops represents a valuable target for exploiting vulnerabilities in code repositories, build pipelines, and release processes. Adversarial activities may include unauthorized access, manipulation of development workflows, or compromise of sensitive information within the Azure DevOps environment.
After navigating to the webroot, I was automatically redirected to the ekenas directory, seemingly generated with the default configuration for a collection name. Additionally, the collection seems to contain a project named, SmartHotel360
smarthotel360 a fictitious company and project created by Microsoft, serving as a sample application to showcase various Microsoft technologies and best practices for building modern applications.
It’s very much likely a dummy project
hovering over the project, it reveals the integrated services
namely, those are boards, Repos, Pipelines, Test Plans, and Artifacts
Overview.Summary
Clicking into the project, SmartHotel360, opens up the Summary under the Overview
The Summary under the Overview in Azure DevOps offers a condensed view of the project’s current state, displaying recent activities, build and release statuses, and essential metrics for quick project assessment.
While the main section of the Summary contains a dummy data, The Members section at the bottom-right indicates 3 assigned members to the project. While the nathen user can easily be identified due to the matching profile image, the rest cannot be identified.
Those 2 other members are administartor and restorer users
They are very much likely system users as well
Dashboards
The Dashboards under the Overview in Azure DevOps serve as customizable visual displays, allowing users to aggregate and visualize key project information, metrics, and charts in a personalized layout for efficient monitoring and decision-making.
It contains an interesting set of data that appears to represent those demo websites shown in the dimension.worker.htb virtual host / sub-domain. This may suggests that the nathen user is responsible for deployment and maintenance of them as they appear to be particularly “assigned” to the user
Additionally, the Work assigned to Nathalie Henley section contains dummy data
Wiki
The Wiki under the Overview in Azure DevOps acts as a collaborative documentation platform, enabling teams to create, edit, and share project-related content. It serves as a central knowledge hub for storing and organizing information within the Azure DevOps environment.
However, it is empty
Boards.Work Items
the work items under the boards in azure devops represent tasks, issues, or user stories that teams can track and manage throughout the development process. It serves as a centralized hub for planning, organizing, and monitoring work within a project.
Some of them were listed in the Dashboards of the nathen user
Boards
The Boards under the Boards in Azure DevOps provide a collaborative space for teams to plan, track, and manage their work using agile or Scrum methodologies. It includes features for creating and prioritizing backlogs, managing sprints, and visualizing work progress on a virtual board.
However, it doesn’t appear to contain any considerable information
Backlogs
the backlogs under the boards in azure devops serve as a dynamic list of work items prioritized by teams. It enables effective planning and organization of tasks, issues, or user stories, ensuring a clear understanding of the work to be undertaken in a project.
However, it contains dummy data
Sprints
The Sprints under the Boards in Azure DevOps facilitate the iterative development process by allowing teams to plan, execute, and track work within specific time frames. It provides a structured approach to managing tasks and achieving project goals during each sprint cycle.
It’s empty
Queries
the queries under the boards in azure devops offer a powerful way for teams to retrieve and analyze specific sets of work items based on customizable criteria. This feature enhances project visibility and enables efficient tracking and reporting of relevant information.
It’s empty
Repos.Files
The Files under the Repos in Azure DevOps provide a centralized location for managing and versioning source code files within a project. This section allows teams to collaborate on code development, track changes, and maintain a history of the project’s source code.
It shows the repository of the alpha application, which is hosted in the alpha.woker.htb virtual host / sub-domain
Repositories of other applications can be access through the dropdown menu
I went through all of them and I have confirmed the relevance
Commits
the commits under the repos in azure devops showcase a chronological record of changes made to the source code repository. It offers transparency into the development process by displaying details of each commit, including the author, timestamp, and associated changes to the codebase.
Commit history can be accessed through here
Commit history of other applications can also be access through the same dropdown menu
Navigating to the dimension application, it shows 5 commits although these don’t appear to be the same as those 5 revisions seen in the Subversion server earlier. These 5 are web-app specific changes.
Pushes
The Pushes under the Repos in Azure DevOps represent instances where changes made to the local repository are propagated to the central repository. This section provides visibility into the history of pushes, including details such as the contributor, timestamp, and the changes pushed to the repository.
However, It doesn’t appear to contain any considerable information Same goes for all the other applications
Branches
The Branches under the Repos doesn’t appear to contain any considerable information
Only master branches are present for all the applications
Tags
The Tags under the Repos in Azure DevOps enable teams to mark specific points in the source code history as significant versions. This feature aids in organizing and referencing important milestones, releases, or stable points within the repository.
It’s empty
Pull Requests
the pull requests under the repos in azure devops provide a collaborative mechanism for proposing and reviewing changes before merging them into the main codebase. This section facilitates code review, discussion, and ensures the quality of code modifications before they are incorporated into the project.
However, it doesn’t appear to contain any considerable information
Pipelines.Builds
The Builds under the Pipelines in Azure DevOps manage the automated compilation and validation of source code, ensuring that the application or software is built successfully and meets defined criteria. This section plays a crucial role in continuous integration(CI), allowing teams to detect and address issues early in the development process.
It contains 7 pre-configured pipelines for all the applications that is assigned to the current user as suspected earlier
This also explains the note, an internal deployment pipeline, in the dimension.worker.htb virtual host / sub-domain
Create A New Pipeline (Failed)
Attempting to build a new Pipeline fails due to lack of the permissions that the nathen user has
This means that I would need to make use of either of those 7 pre-configured pipelines
Releases
The Releases under the Pipelines in Azure DevOps facilitate the management and deployment of software versions to different environments. This section streamlines the release process, ensuring smooth transitions from development to production with controlled and orchestrated release pipelines.
It’s empty
Library
the library under the pipelines in azure devops serves as a centralized repository for storing and managing reusable elements such as variables, templates, and secure credentials. This resource enables efficient configuration and enhances consistency across various pipelines, contributing to streamlined and maintainable build and release processes.
No resource found
Task groups
The Task groups under the Pipelines in Azure DevOps offer a way to encapsulate and reuse sets of tasks, promoting modularity and efficiency in pipeline design. By creating task groups, teams can standardize common procedures, simplify pipeline configuration, and enhance maintainability across different projects.
It’s empty
Deployment groups
the deployment groups under the pipelines in azure devops provide a mechanism for organizing and managing target environments for deployments. This feature enables teams to define and control sets of machines or Kubernetes clusters, streamlining the deployment of applications to diverse environments in a controlled and scalable manner.
It’s empty
Test Plans.Test Plans
The Test Plans under the Test Plans in Azure DevOps serve as a comprehensive solution for planning, tracking, and managing testing efforts. This section allows teams to create test suites, define test cases, and execute tests, providing insights into application quality and helping ensure robust software releases.
While it doesn’t appear to have been configured, it reveals that the current user has basic access level basic access level in the current context refers to the plan
Runs
the runs under test plans in azure devops display the execution results of test cases, providing a detailed overview of testing outcomes. This section allows teams to track and analyze test runs, facilitating the identification and resolution of issues during the testing phase of the development lifecycle.
It’s empty
Artifacts
The Artifacts in Azure DevOps function as a centralized repository for managing and versioning binary packages, enabling efficient package management and artifact sharing across the development pipeline. This service supports various package types, promoting collaboration and consistency in software development and deployment processes.
It’s empty again
Permissions and Access
in azure devops, permission and access control are pivotal components that regulate user interactions with project resources. They ensure a secure and organized collaborative environment, allowing to manage who can view, modify, build, release, and administer various aspects of a project. This granular control is essential for maintaining data integrity, protecting sensitive information, and fostering efficient collaboration among team members. Properly configured permissions contribute to streamlined workflows, compliance with organizational policies, and overall project success within the Azure DevOps ecosystem.
Understanding and manipulating permission structures becomes crucial for adversaries aiming to navigate and exploit Azure DevOps environments. This knowledge provides insights into potential actions within the system, enabling adversaries to assess and exploit opportunities.
Clicking into the Project setting button and the Security section, it reveals 2 top-level groups; Teams and Azure DevOps group
teams:- teams are more flexible and can be customized to match your project’s structure.
- Teams represent groups of people who collaborate on specific areas or features.
- You can create multiple teams within a project, each with its own set of members.
- It could be compared to OU of Active Directory
- Teams have their own backlogs, boards, and other planning tools as its implementation is tied to project management and collaboration aspect of software development.
azure devops groups:- these are predefined security groups that come with Azure DevOps installation.
- Examples include “Project Administrators,” “Contributors,” and “Readers.”
- They provide default access levels and permissions.
- You can add users to these groups to grant them specific access.
In the current security context, the nathen user is part of all 3 teams
Contributors
Additionally, the SmartHotel360 Team team has the inherited security configurations from the Contributors group that allows the current user, nathen, to perform the following actions;
- Create branch permission:
Bypass rules on work item updates:Not setChange process of team project:Not setMove work items out of this project:Not setWhy? - The absence of restrictions on work item updates and project processes allows the user to create branches.
- Build pipeline permissions:
Define releases and manage deployments:Allow (inherited)Delete test runs:Allow (inherited)Manage test configurations:Allow (inherited)Manage test environments:Allow (inherited)Why? - Inherited permissions for creating and managing test runs, configurations, and environments grant the necessary access to initiate build pipelines.
This essentially means that the current user, nathen, is able to modify any LIVE web application by building a pipeline
Moving on to Exploitation phase
Agent
the agent pool section under the pipeline in the project settings in azure devops dictates the execution context for builds and releases. It involves configuring a pool of agents responsible for carrying out tasks in the CI/CD processes.
It shows Default with Azure Pipelines, which appears to be the default configuration for the agent pool
Agents
Clicking into the Agents section in the Default agent pool reveals 2 active agents; Hamilton01 and Hamilton02
The names, Hamilton01 and Hamilton02, likely refer to distinct instances of executing agents handling build requests.
Details
The Details section in the Default agent pool shows the owner; “Azure Pipelines”
Given the likely association of Azure Pipelines with the built-in system identity or service connection linked to the pipeline, determining the system-wide security context of the execution becomes challenging at this stage. Because this Default Agent pool could be configured to be running by any accounts or users
Security
The Security section in the Default agent pool shows an option, Pipeline permissions, to grant access permission to all pipelines
This option restrict a repository to specific pipelines helps prevent unauthorized access to YAML pipelines.