The dark side of domain-specific languages: Tenable uncovers new attack techniques in open source software
Tenable has disclosed that its Tenable Cloud Security Research team has uncovered new attack techniques in Domain-Specific Languages (DSLs) of popular policy-as-code (PaC) and infrastructure-as-code (IaC) platforms. These can lead to compromised cloud identities, lateral movement, and data exfiltration.
Infrastructure-as-Code (IaC) has become the backbone of modern cloud DevOps practices, with policy engines and Policy-as-Code tools critical for governing sensitive and complex deployments. DSL’s are hardened languages with limited capabilities, which are supposed to be more secure than standard programming languages. However, these frameworks are often assumed secure by default—leaving an open door for attackers to exploit.
This announcement follows a recently discovered SMB force-authentication vulnerability in OPA.
Why it matters:
While DSLs like those in Open Policy Agent (OPA) and HashiCorp’s Terraform are designed to be secure, Tenable’s findings reveal specific overlooked misconfigurations that adversaries can manipulate through third-party components. This highlights the importance of rethinking security strategies around PaC and IaC deployments.
Attack scenario – Open Policy Agent (OPA)
OPA is a widely used policy engine with applications ranging from microservice authorisation to infrastructure policies. Policies in OPA are written using Rego, a high-level, declarative DSL with built-in functions that, when misused, can become tools for malicious activity. Tenable research discovered how an attacker who compromises the policy supply chain can insert malicious Rego policies that will be executed during policy evaluation, to achieve malicious objectives like credentials exfiltration or data leaking.
Attack scenario – Terraform
Terraform has long been a highly adopted IaC tool due to its declarative, platform-agnostic nature, community support and shareable components. Its configurations use HashiCorp Configuration Language (HCL), another DSL. Terraform has two kinds of third-party components that can be shared through the Terraform Registry or other (public or private) registries: Modules and Providers. These are commonly used for efficiency, and even for enhanced security when used right. However, if used carelessly, they can introduce a serious supply chain risk.
Tenable found that when Terraform Plan is configured to run on a pull request trigger in CI/CD pipelines, attackers can achieve code execution of unreviewed code, opening stealthy paths for malicious insiders or external attackers.
Tenable research recommendations for mitigation
- Implement a granular role-based access control (RBAC) and follow the principle of least privilege. This should be applied to the local user running the IaC or PaC framework, the users that can access it via API, and the associated cloud roles. Separate roles may be used for the Terraform Plan and Apply stages, to prevent unreviewed modifications of IaC resulting in cloud infrastructure changes.
- Only use third-party components from trusted sources: modules and providers in Terraform, and policies in OPA (These are some examples for components that, when used from third parties, should be sourced cautiously). Verify their integrity to ensure no unauthorised changes were made prior to their execution.
- Set up application-level and cloud-level logging for monitoring and analysis.
- Limit the network and data access of the applications and the underlying machines. To prevent communication with other internal servers through OPA policies, as discussed in the attack techniques section, you may use OPA’s capabilities.json file to restrict outbound network connections (using the allow_net field to restrict the hosts that can be contacted by the http.send and net.lookup_ip_addr functions).
- Scan before you plan! Prevent automatic execution of unreviewed and potentially malicious code in your CI/CD pipeline by placing your scanner before the terraform plan stage.
