Terraform Unleashed - Crafting Custom Provider Exploits for Ultimate Control
0 likes90 views
The document discusses the expertise of Rupali Dash and Alex Foley in cybersecurity, specifically focusing on Terraform and custom provider exploits in cloud environments. It elaborates on the mechanisms of Terraform workflows, potential attack vectors using custom providers with filesystem access or code execution features, and the associated risks. Additionally, it emphasizes the importance of security measures to mitigate threats from malicious Terraform providers and insider attacks.
Terraform Unleashed - Crafting Custom Provider Exploits for Ultimate Control
- 1. Terraform Unleashed: Crafting custom Provider exploits for Ultimate control
- 2. Rupali Dash brings over 8 years of cybersecurity experience, specializing in penetration testing and red teaming. Currently a Lead Security Architect at Axl.net Security, she oversees cloud security and penetration testing engagements. Her credentials include notable certifications like OSCP, OSWE, AWS Security Specialist, and GCPN. She has presented at prominent conferences like Black Hat Asia, DevSecCon, and CoCon. Alex Foley is a broadly experienced security professional with over 25 years of experience in IT and cybersecurity. He is the founder and CEO of Axl.net Security. He has operated and continues to operate as the vCISO of multiple startup companies with the support of the team from Axl.net Security. Throughout his career, he's had the opportunity to wear many hats and do "all the things" within product development, operations, and security. This broad experience has enabled Alex to bring this depth of understanding to the CISO roles. Alex's skill set focuses on blue team operations, which complements Rupali's expertise in red team activities. Who Are We ??
- 3. Who Does The Talk Cater To Pen testers and Red-teamers who will be testing an cloud infrastructure. Security Architects managing the security posture of the cloud infrastructure.
- 4. Terraform Enterprise Deployment Architecture
- 6. ► - In-order to provision this code the user logs in to the terraform enterprise first and provides the AWS Credentials of the account for the resource provisioning . ► Upon Terraform Init the TFE Spins up the worker container in the TFE AWS account and Downloads the required provides specified in the provider block. ► During Terraform Plan, The Terraform API zips the IAC code and the Provided authentication credentials along with the terraform binary and stores it over the worker container. ► It also performs a state lock using dynamo DB for that specific workspace so that no two TFE plan can run simultaneously for a specific workspace and it ques the job. ► It also downloads the Sentinel policies associated with the workspace on to the worker container. ► During the Terraform plan once the sentinel policies are validated against the TFE plan out out, Terraform generates a newer set of credentials using the provided AWS credentials in the terraform file which will be used to provision the resource in the clients AWS account. ► Once the Apply is completed the worker container stores the generated terraform state file over the s3 bucket and destroyes the container.
- 7. Terraform Provider ►A terraform provider is a binary written in go that interacts with terraform binary over RPC & enables interaction with the provider API. This includes Cloud providers and Software-as-a-service providers. The providers are specified in the Terraform configuration code. They tell Terraform which services it needs to interact with.
- 8. Key-RISK Terraform binaries are executables which will be downloaded into the emphiral container during terraform init. Terraform Provider runs with the highest privilege on the worker container and hence have access to all the mounted file system as well as the AWS STS credentials. The TFE worker container needs to have the read access to the s3 and RDS instance where the TFE state file gets stored as a part of application. In a scenario where multiple providers are invoked for a specific Terraform Plan, Both the providers will have access to the TFE environment variables and the host file system.
- 9. Attack-1: Custom provider with filesystem access to gain access to the host file system ● In Golang Import os/exec and import syscall modules enables the binary to interact with the host file system. ● Create the data source to read an environment variable & register this new data source in your provider.go file. ● Use “go build” command to build the provider.
- 10. Exploit ( System File Read) Create a Terraform configuration file that uses the new data source to read the /etc/passwd file on the host.
- 11. Attack-2: Custom provider with Code Execution feature Terraform-provider-cmdexec is a custom built provider that provides command execution capability through Terraform Configuration. Below is the example of the main.tf file used to leverage the provider to execute the command. https://github.com/rung/terraform-provider-cmdexec https://alex.kaskaso.li/post/terraform-plan-rce
- 12. ► Execute Commands on the Terraform container ► Provision highly privileged roles / resources by Bypassing sentinel policies to gain persistence. ► Exfiltrate Vaulted secrets from the TFE container. ► Manipulate state files resulting in deleting resources in the existing cloud accounts. ► Gain access to PII data in Production accounts. ► Supply chain threats to organizations using the malicious providers.
- 13. Why the Terraform Provider and not the Provisioners ? ►Terraform Provisioner has local_exec() and remote_exec() capability which helps to execute commands on the TFE infrastructure as a part of terraform apply. ►Terraform Provisioners are called only after a successful plan and prior to the Terraform Apply. Hence usage of sentinel policy can be leveraged to block those attacks. ►Terraform Provider block executes during the terraform plan and hence It cannot be blocked/restricted through Sentinel
- 14. Provider Security Risks ►1: Malevolence of the Binary: This is to ensure that the provider binary doesn’t contain any malware , packers or custom exploits. ►2: Impact on the TFE infrastructure: This will provide insight on the different functionalities and access level of the provider in the TFE infrastructure. ►3: Out bound Network communication: This will provide insight on the different end points/APIs embedded into the binary
- 17. Conclusions ● Provider Attack Types ○ Third Party Providers ○ Insider Threat ● Defense ○ Updated Training ○ Updated Detection Technology ○ Updated Processes