Skip to content

Latest commit

 

History

History
74 lines (58 loc) · 7.25 KB

threat-modeling.md

File metadata and controls

74 lines (58 loc) · 7.25 KB

Threat Model Analysis for puppetlabs/puppet

Threat: Master Compromise via Malicious Certificate Request

  • Threat: Master Compromise via Malicious Certificate Request

    • Description: An attacker crafts a malicious certificate signing request (CSR) that, when signed by the Puppet CA, grants the attacker elevated privileges or allows them to impersonate a legitimate node. This exploits vulnerabilities in the CSR parsing or signing process within the Puppet Master itself.
    • Impact: Complete control over the Puppet infrastructure; ability to deploy malicious configurations to all managed nodes; data exfiltration.
    • Affected Component: Puppet Master (CA, certificate handling logic specifically).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Strict CSR Validation: Implement robust validation of all CSRs before signing. This includes checks on the requested hostname, extensions, and other attributes, going beyond simple hostname matching. Specifically target Puppet's CSR handling.
      • Manual CSR Approval: Require manual approval for all CSRs, especially for nodes with sensitive roles.
      • Automated CSR Analysis: Use tools to automatically analyze CSRs for suspicious patterns or anomalies, focusing on Puppet-specific attributes.
      • Short-Lived Certificates: Use short-lived certificates to limit the impact of a compromised certificate.
      • Certificate Revocation: Have a well-defined and tested process for revoking compromised certificates.

Threat: Code Injection in Custom Facts

  • Threat: Code Injection in Custom Facts

    • Description: An attacker compromises a system and modifies a Puppet custom fact (written in Ruby, shell, or another language supported by Facter) to execute arbitrary code when the fact is evaluated by the Puppet agent. This leverages the fact execution mechanism within Puppet.
    • Impact: Execution of arbitrary code on the Puppet agent with the agent's privileges (often root); potential for lateral movement; data exfiltration.
    • Affected Component: Puppet Agent (Facter, custom fact execution specifically).
    • Risk Severity: High
    • Mitigation Strategies:
      • Secure Fact Development: Follow secure coding practices when developing custom facts for Puppet. Avoid using eval or similar constructs. Sanitize all input within the context of Facter.
      • Principle of Least Privilege: Run the Puppet agent with the minimum necessary privileges.
      • File Integrity Monitoring (FIM): Monitor the integrity of custom fact files to detect unauthorized modifications.
      • Code Review: Review all custom fact code for security vulnerabilities, focusing on how they interact with Facter.
      • Sandboxing (if feasible): Explore options for sandboxing the execution of custom facts within the Puppet agent to limit their impact.

Threat: Unauthorized Module Installation from Forge (Typosquatting)

  • Threat: Unauthorized Module Installation from Forge (Typosquatting)

    • Description: An attacker publishes a malicious Puppet module to the Puppet Forge with a name similar to a popular, legitimate module. An administrator unknowingly installs the malicious module using Puppet's module tooling.
    • Impact: Execution of arbitrary code on managed nodes via the malicious Puppet module; data exfiltration; system compromise.
    • Affected Component: Puppet Master (module installation via puppet module install), Puppet Agent (module execution). This is a direct threat because it involves Puppet's module management system.
    • Risk Severity: High
    • Mitigation Strategies:
      • Careful Module Selection: Double-check the module name, author, and download count before installing a module from the Puppet Forge using Puppet tools.
      • Module Verification: Verify the checksum of downloaded modules against the checksum provided by the Puppet Forge before installation with Puppet.
      • Code Review: Review the code of third-party Puppet modules before deploying them.
      • Internal Module Repository: Use an internal module repository to host trusted Puppet modules and prevent accidental installation from the public Forge.
      • Module Signing (if supported): Use Puppet's module signing capabilities to verify authenticity.

Threat: Hiera Data Leakage via Unencrypted Puppet Transport

  • Threat: Hiera Data Leakage via Unencrypted Puppet Transport

    • Description: Hiera data, which may contain sensitive information, is transmitted between the Puppet Master and agents in plain text over Puppet's communication channel. An attacker performs a Man-in-the-Middle (MitM) attack to intercept this Puppet-specific traffic.
    • Impact: Exposure of sensitive information (passwords, API keys, etc.) stored within Hiera.
    • Affected Component: Puppet Master (Hiera data serving), Puppet Agent (Hiera data retrieval), Puppet's communication channel.
    • Risk Severity: High
    • Mitigation Strategies:
      • TLS Encryption: Ensure that all communication between the Puppet Master and agents is encrypted using TLS. This is a core Puppet configuration requirement.
      • Hiera-Eyaml (or similar): Encrypt sensitive data within Hiera itself using hiera-eyaml or a comparable solution. This protects data even if the Puppet transport is compromised or Hiera files are accessed directly.
      • Network Segmentation: Isolate Puppet traffic on a secure network segment.

Threat: Exec Resource Abuse (within Puppet)

  • Threat: Exec Resource Abuse (within Puppet)

    • Description: An attacker leverages the Puppet exec resource to run arbitrary commands on a managed node. This is a direct Puppet threat because it involves the misuse of a core Puppet resource type. The vulnerability arises when the command attribute is constructed using untrusted input without proper sanitization within a Puppet manifest.
    • Impact: Arbitrary command execution on the target node, potentially with elevated privileges, initiated by Puppet.
    • Affected Component: Puppet Agent (exec resource specifically).
    • Risk Severity: High
    • Mitigation Strategies:
      • Avoid exec When Possible: Use more specific Puppet resource types (e.g., package, service, file) whenever possible.
      • Strict Input Validation: If you must use exec within Puppet, thoroughly validate and sanitize all input used to construct the command. Use whitelisting.
      • Parameterization: Use the onlyif, unless, creates, and path attributes of the Puppet exec resource to limit its execution.
      • Least Privilege: Run exec commands within Puppet with the minimum necessary privileges.