Terraform Unleashed: Crafting custom
Provider exploits for Ultimate control
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 ??
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.
Terraform Enterprise Deployment Architecture
Terraform Workflow
â–ş - 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.
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.
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.
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.
Exploit ( System File Read)
Create a Terraform configuration file that uses the new data source to read the /etc/passwd file on the host.
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
â–ş 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.
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
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
Conclusions
â—Ź Provider Attack Types
â—‹ Third Party Providers
â—‹ Insider Threat
â—Ź Defense
â—‹ Updated Training
â—‹ Updated Detection Technology
â—‹ Updated Processes
Questions?
â–şrdash@axl.net
â–şafoley@axl.net

Terraform Unleashed - Crafting Custom Provider Exploits for Ultimate Control

  • 1.
    Terraform Unleashed: Craftingcustom Provider exploits for Ultimate control
  • 2.
    Rupali Dash bringsover 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 TheTalk 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.
  • 5.
  • 6.
    â–ş - In-orderto 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 provideris 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 executableswhich 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 providerwith 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 ( SystemFile 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 providerwith 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 Commandson 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 Providerand 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: Malevolenceof 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 AttackTypes â—‹ Third Party Providers â—‹ Insider Threat â—Ź Defense â—‹ Updated Training â—‹ Updated Detection Technology â—‹ Updated Processes
  • 18.