Listen to this Post
Introduction:
In the sprawling landscape of modern DevOps, configuration management databases are the silent backbone of enterprise infrastructure. A recent discovery by security researchers highlights a critical reconnaissance opportunity: an often-overlooked PuppetDB endpoint that can expose a treasure trove of sensitive system data, providing attackers with a complete blueprint of an organization’s digital environment.
Learning Objectives:
- Understand the function and security implications of the PuppetDB `/pdb/query/v4/resources` endpoint.
- Learn how to ethically query this endpoint to identify exposed sensitive information.
- Implement hardening measures to secure PuppetDB instances from unauthorized access.
You Should Know:
1. Querying the PuppetDB Resources Endpoint
The `/pdb/query/v4/resources` API endpoint is a powerful interface that returns a comprehensive list of all resources managed by Puppet across the entire infrastructure. This can include user accounts, SSH keys, software versions, network configurations, and sensitive data stored in manifests.
Step-by-Step Guide:
To query this endpoint, a simple `curl` command can be used if the instance is exposed and lacks authentication:
curl -s "http://target-domain:8080/pdb/query/v4/resources" | jq .
What this does: This command sends an HTTP GET request to the PuppetDB service running on port 8080. The `-s` flag silences curl’s progress output. The response, typically a large JSON object, is piped into `jq ‘.’` to be pretty-printed for easy analysis.
How to use it: During authorized penetration tests or bug bounty assessments, replace `target-domain` with the hostname or IP of the discovered PuppetDB instance. Analyze the output for secrets, internal hostnames, IP addresses, and system configurations.
2. Filtering for Specific Resource Types
The raw output from the resources endpoint can be massive. Using PuppetDB’s query language, you can filter results to pinpoint exactly the data an attacker would find most valuable, such as user accounts or file resources.
Step-by-Step Guide:
A more targeted query using the `query` parameter can extract specific resource types:
curl -s -G "http://target-domain:8080/pdb/query/v4/resources" --data-urlencode 'query=["=","type","User"]' | jq .
What this does: The `-G` flag tells curl to use the subsequent `–data-urlencode` data as a URL query parameter. The query `[“=”,”type”,”User”]` instructs PuppetDB to return only resources where the `type` field equals User.
How to use it: This command is crucial for efficiently finding all user accounts created by Puppet, which can help map out privileged accounts or default system users. Other valuable types to query for include File, Package, and Service.
3. Extracting File Resources with Sensitive Content
Files managed by Puppet often contain application secrets, API keys, or configuration files with internal data. Querying for `File` resources and then inspecting their `content` or `source` parameters is a primary attack vector.
Step-by-Step Guide:
To find file resources and display their content:
curl -s -G "http://target-domain:8080/pdb/query/v4/resources" --data-urlencode 'query=["=","type","File"]' | jq '.[] | select(.parameters.content != null) | {title: .title, content: .parameters.content}'
What this does: This command queries for `File` resources and then uses `jq` to parse the JSON output. It selects only those files with a `parameters.content` attribute and prints a structured object containing the file title and its full content.
How to use it: Run this query and meticulously review the output. Look for keywords like password, key, secret, token, or `config` in the file titles and content. Any discovered credentials should be immediately reported.
4. Harvesting SSH Authorized Keys
User resources often contain `ssh_authorized_key` data. Compromising these keys can provide direct SSH access to systems within the infrastructure.
Step-by-Step Guide:
To extract all authorized SSH keys for users:
curl -s -G "http://target-domain:8080/pdb/query/v4/resources" --data-urlencode 'query=["=","type","User"]' | jq '.[] | select(.parameters.ssh_authorized_keys != null) | {user: .title, keys: .parameters.ssh_authorized_keys}'
What this does: This filters `User` resources for those that have the `ssh_authorized_keys` parameter defined. It then outputs the username and their associated public SSH keys.
How to use it: An attacker can take these public keys and attempt to find corresponding private keys in other breaches or through brute-force attacks. Defenders should use this command to audit what keys are being deployed globally.
5. Discovering Internal Network Information
Puppet configurations define networking and host information. Querying for network interface or hostname data can map the internal network.
Step-by-Step Guide:
Search for network-related resources or facts:
Look for network interface resources
curl -s -G "http://target-domain:8080/pdb/query/v4/resources" --data-urlencode 'query=["=","type","Network_interface"]' | jq .
Alternatively, query the facts endpoint for host networking
curl -s "http://target-domain:8080/pdb/query/v4/facts" | jq '.[] | select(.name | contains("ipaddress"))'
What this does: The first command looks for specific network interface resources. The second, more powerful command queries the `/facts` endpoint, which contains gathered system facts from all Puppet nodes, and filters for those related to IP addresses.
How to use it: The output will reveal internal IP addresses, hostnames, and network roles. This information is invaluable for pivoting and targeting critical systems in a multi-stage attack.
6. Identifying Software Packages and Versions
Knowing the exact software and versions running across an estate allows attackers to launch precise attacks using known vulnerabilities.
Step-by-Step Guide:
Query for `Package` resources to audit installed software:
curl -s -G "http://target-domain:8080/pdb/query/v4/resources" --data-urlencode 'query=["=","type","Package"]' | jq '.[] | {title: .title, version: .parameters.ensure}'
What this does: This command retrieves all resources of type `Package` and extracts the package name (title) and its installed version (parameters.ensure).
How to use it: Cross-reference the discovered software versions with public vulnerability databases like NVD or Exploit-DB. This quickly identifies low-hanging fruit for exploitation, such as outdated web servers or database software.
7. Securing Exposed PuppetDB Instances (Mitigation)
The core issue is unauthorized access. PuppetDB must be configured to reject unauthenticated queries. This is typically done by configuring Puppet Enterprise to enforce authentication and placing PuppetDB behind a firewall.
Step-by-Step Guide:
Edit the PuppetDB configuration file (/etc/puppetlabs/puppetdb/conf.d/jetty.ini) to enforce HTTPS and client authentication.
[bash] ssl-host = 0.0.0.0 ssl-port = 8081 ssl-key = /etc/puppetlabs/puppetdb/ssl/private.pem ssl-cert = /etc/puppetlabs/puppetdb/ssl/cert.pem ssl-ca-cert = /etc/puppetlabs/puppetdb/ssl/ca.pem client-auth = want
What this does: This configuration forces SSL/TLS encryption (ssl-port = 8081) and sets `client-auth` to want, meaning clients are strongly encouraged to present a certificate for mutual authentication.
How to use it: This is a defensive configuration step. System administrators should never expose PuppetDB’s ports (8080/8081) to the public internet. Access should be restricted via firewall rules (e.g., AWS Security Groups, Azure NSGs) to only allow connections from trusted management subnets or the Puppet masters themselves.
What Undercode Say:
- Reconnaissance Goldmine: An exposed PuppetDB endpoint is not a vulnerability in itself but a critical misconfiguration that escalates to an information disclosure flaw of the highest order. It provides a single, API-driven point to harvest data that would otherwise require breaching multiple systems.
- The Automation Double-Edged Sword: Infrastructure-as-Code (IaC) and DevOps automation provide immense efficiency but also create centralized points of failure. This finding exemplifies how automation tools, if not properly secured, can automate the attacker’s reconnaissance phase for them.
The discovery of this technique signifies a maturation of attacks against the software supply chain and DevOps tooling. Attackers are no longer just targeting end applications; they are systematically targeting the systems that build, manage, and deploy those applications. This approach offers a higher ROI, as compromising a single management system can reveal the secrets of an entire infrastructure. Defenders must expand their perimeter awareness to include these critical backend systems, treating them with the same security rigor as a public-facing database containing user PII.
Prediction:
The exploitation of misconfigured DevOps and infrastructure management tools like PuppetDB, Ansible Towers, and Jenkins instances will become a primary initial access vector for large-scale enterprise breaches. As attackers continue to weaponize this technique, we will see a rise in automated bots scanning the internet for these specific endpoints. This will lead to more targeted ransomware attacks where threat actors have intimate knowledge of the environment before deploying payloads, maximizing their impact and probability of payment. The industry will respond by pushing for default-secure configurations and greater adoption of zero-trust principles within internal network segments, not just at the perimeter.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Gokul Sudhakar – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
