Exploiting Devops -Leak Source codes
By: Shivbihari Pandey
Tags: Azure Devops, Shodan Recon, Vulnerability, Bug Bounty, Jenkins

Welcome!!

Today, I will share one of my findings, based on the DevOps process, which involves Applications like Azure DevOps, VSTS, Jenkins and GitHub, Shodan, etc.

Exploitation Steps Flow:[Summary ]

Recon[ASN] →Shodan Lookup →Found Logfile in Jenkins→got Azure DevOps Urls running Jenkins → found PAT of AZURE →Able to Download Source code →Found Tons of Hardcoded credentials

Now, if you Already understand the finding process, Leave here, OR Want to Read the Full Story →Continue

Also, this blog might Have Grammatical mistakes[Please Ignore, I am just a Lazy guy], Now if you are OK with that, Please continue 🤞

you might be wondering why DevOps as Title First, I am awful at naming [Lots of Disclaimers]. Second, this blog will give you some basic Ideas about DevOps &, once you find a security loophole, how you will exploit it.

So Lets Start With DEVOPS Definition

In DevOps, there are multiple stages and tools involve, and one is “Version Control,” there are many tools in the market that provide this facility like Git.

I am not getting into much details of the DevOps topic, but to introduce you, Now Most of the Development tools go through this automation phase once the developer submits code for testing/compiling and deployment using Automation tools.

In the software development field, the Continuous Delivery of software is supported by build and deployment automation, commonly called a Continuous Integration/Continuous Deployment (CICD) pipeline.

And one of the famous Tool is Jenkins.

Let's Jump directly into Vulnerability:

Recon Process:

I was testing one site which has a large domain, so stating with the Subdomain enumeration, I used to extract the ASN number for a particular organization.

after the multi-step Recon process, I start looking into the ASN number collected for the main domain and start looking it in shodan search engine and start filtering service using port and application running on it

suppose to filter result which running in port 8080, use this search method

asn:AS15967 port:”8080"

After looking into multiple URLs, I came up with one which running the Jenkins service in it.

However, it has login protection, but still, I start browsing the files and projects in the workspace

I came up with the folder which has the pipeline.log file in it, and it's accessible directly,

and in the pipeline .log file, I found windows local directory, computer name, and user name. I found the azure directory of that particular project, and I opened it, which gave me the Jenkins service running in azure cloud.

I started looking into the people assigned in Jenkins and selected the latest build application because if I found something like token or API keys, it might still be alive.

Select the user who completed the latest build and started looking into a particular user's “Build History” option.

After I select the latest build Application and start looking into its “Build History ” because it has a log of a compilation of the application, every time a new feature is added, that will go under the CI/CD pipeline for compiling, Testing, etc.

In the history section, I started viewing the “Console Output,” or you can say the Bash History of running Automation scripts used for compiling and building in the CI/CD automation process.

In Bash History, I found out a curl request has been executed in this process, and it also has the Token, which at that time I had no idea about it, So I start Googling about tokens in the Azure Active directory.

curl — user validuser:[TOKEN] -X POST — url https://dev.azure.com/xyz/xyz_child/_apis/build/builds?api-version=5.0 — data {“definition”:{“id”: 65}, “parameters”: “{\”xtyf\”:\”285\”}”} — header Content-Type: application/json

I found something about the token, but it didn’t help me, so I started exploring the other Folders, and I see there is something called “Pipeline Steps,” which I think is just the overview of steps run in the automation process.

Here again, I found the same token as in the previous one, but this time it saying something like VSTS.exe seems like some kind of CLI tool, so I start exploring it and came to know that,

VSTS CLI is a command line interface for Azure DevOps Services and Team Foundation Server (TFS). With the VSTS CLI, you can manage and work with resources including pull requests, work items, builds, and more.

so I quickly install it in my local system using this URL

Now I start reading the Documentation of the VSTS CLI tool from here: https://docs.microsoft.com/en-us/cli/vsts/get-started?view=vsts-cli-latest

And found out it needs the Personal Access token to interact with the Azure DevOps services.

To make full use of the VSTS CLI, you should check the All scopes option when creating the token. If you only need to interact with a specific Azure DevOps Services organization, limit your token to just this organization. Before you can run VSTS commands, you need to run the vsts login command to sign in or set up credentials. Running vsts login securely stores your PAT and establishes default credentials:

Now it starts making sense about the token we found out in “Console History.”

So I quickly Login using.

vsts login — token xxxxxxxxxx

VSTS CLI supports setting up defaults like instance, project, and output format for ease of use. e.g.

vsts configure — defaults instance=https://dev.azure.com/myorganization project=myproject

These values are dummy, but Replace the “MyOrganization” and “myproject” with the valid values.

in my case, it gave an error, so I found out this way to do the same stuff as above

run this into making your project instance URL:

C:\Users\Hack_Rider>vsts configure — defaults instance=https://dev.azure.com/[OrganizationName]/

Setup the project name:

C:\Users\Hack_Rider>vsts configure — defaults project=[ProjectName]

after connecting to instance its time to look into the Repo files

You can use the list command within the VSTS CLI to find and list the resources running in VSTS.

For example, vsts code pr list shows the list of all pull requests you have.

C:\Users\Hack_Rider>vsts code pr list — output table

It gave me all the Active user List, Email Addresses, and associated Repo manage by them.

Now TO GET ALL THE REPO codes available in the project.

C:\Users\Hack_Rider>vsts code repo list

Now to get the actual git repo inside the projects.

C:\Users\Hack_Rider>vsts code repo show — name [RepoName]

OK, now we have Sufficient information to Download the Remote Repo

For that these commands going to be used, run this command in Powershell

# replace “yourPAT” with your actual PAT

MY_PAT=yourPAT B64_PAT=$(printf “%s””:$MY_PAT” | base64) git -c http.extraHeader=”Authorization: Basic ${B64_PAT}” clone https://dev.azure.com/yourOrgName/yourProjectName/_git/yourRepoName

In Site these Project files, I have found Tons of Sensitive information, Like Multiple API keys, Tokens, Emails Credentials, Private Hosted Application Passwords, ThirdParty Services API Keys & Tokens like slacks, Bitly, Trello, etc. and many more.

So Moral Story:

1: [Devlopers] Making a single mistake can be disastrous sometimes

2: If you find something like this, instead of simply reporting the token, start exploring, give it time, start exploring more attack possibilities; in that process, you will learn a lot.

3: And after the bug gets patched, write a blog 😜[Kidding].

I have found multiple Vulnerabilities of this type; hopefully, I will share the story about it Next time, but For now, That's It,

If you found it interesting, Retweet it, Share it.🤞