In the age of cloud computing where infrastructure needs to be extended or deployed rapidly to meet ever-changing organizational needs, the configuration of new servers and nodes is completely automated. This is done using machine-readable definition files, or templates, as part of a process known as infrastructure as code (IaC) or continuous configuration automation (CCA).
[ Follow these 5 tips for better cloud security. | Get the latest from CSO by signing up for our newsletters. ]
A new analysis by researchers from Palo Alto Networks of IaC templates collected from GitHub repositories and other places identified almost 200,000 such files that contained insecure configuration options. Using those templates can lead to serious vulnerabilities that put IaC-deployed cloud infrastructure and the data it holds at risk.
“Just as when you forget to lock your car or leave a window open, an attacker can use these misconfigurations to weave around defenses,” the researchers said. “This high number explains why, in a previous report, we found that 65% of cloud incidents were due to customer misconfigurations. Without secure IaC templates from the start, cloud environments are ripe for attack.”
Widespread IaC problems
There are multiple IaC frameworks and technologies, the most common based on Palo Alto’s collection effort being Kubernetes YAML (39%), Terraform by HashiCorp (37%) and AWS CloudFormation (24%). Of these, 42% of identified CloudFormation templates, 22% of Terraform templates and 9% of Kubernetes YAML configuration files had a vulnerability.The evolution of cloud security: Where it’s headed and tips to planhttps://imasdk.googleapis.com/js/core/bridge3.433.1_en.html#goog_2136437367Volume 0%
Palo Alto’s analysis suggests that half the infrastructure deployments using AWS CloudFormation templates will have an insecure configuration. The report breaks this down further by type of impacted AWS service — Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (RDS), Amazon Simple Storage Service (Amazon S3) or Amazon Elastic Container Service (Amazon ECS).
For example, over 10% of S3 storage buckets defined in templates were publicly exposed. Improperly secured S3 buckets has been the source of many publicly reported data breaches in the past.
The absence of database encryption and logging, which is important to protect data and investigate potential unauthorized access, was also a commonly observed issue in CloudFormation templates. Half of them did not enable S3 logging and another half did not enable S3 server-side encryption
A similar situation was observed with Amazon’s Redshift data warehouse service. Eleven percent of configuration files produced Redshift instances that were publicly exposed, 43% didn’t have encryption enabled, and 45% had no logging turned on.
Terraform templates, which support multiple cloud providers and technologies, did not fare any better. Around 66% of Terraform-configured S3 buckets did not have logging enabled, 26% of AWS EC2 instances had SSH (port 22) exposed to the internet and 17% template-defined AWS Security Groups allowed all inbound traffic by default.
Other common misconfigurations found in Terraform templates include:
- AWS Identity and Access Management (IAM) passwords that don’t meet industry minimum standards (40%)
- Containers without CPU or memory resource limiting (64%)
- Azure Network Security Groups (NSG) with exposed SSH (51%)
- Google Cloud Platform Storage without logging enabled (58%)
- Azure Storage without Secure Transfer enabled (97%).
Kubernetes YAML files had the smallest incidence of insecure configurations, but those that did were significant. Of the insecure YAML files found, 26% had Kubernetes configurations that ran as root or with privileged accounts.
“Configurations allowing containers as root provide attackers with an opportunity to own virtually any aspect of that container,” the Palo Alto researchers said. “This also makes the process of performing container escape attacks easier, thus opening the host system to other potential threats. Security and DevOps teams should ensure that containers do not run with root or privileged accounts.”
IaC misconfigurations reflected in real deployments
The types of IaC template misconfigurations and their prevalence — the absence of database encryption and logging or publicly exposed services — is in line with the type of issues detected by Palo Alto Networks in real-world cloud infrastructure deployments in and covered in past reports:
- 76% of organizations allow public access to port 22 (SSH)
- 69% of organizations allow public access to port 3389 (RDP)
- 64% fail to enable logging for their data storage
- 62% do not enable encryption for the data storage
- 47% of organizations do not use tracing functionality for serverless functions
This suggests that the use of IaC templates in automated infrastructure deployment processes without first checking them for insecure configurations or other vulnerabilities is a big contributing factor to the cloud weaknesses observed in the wild.
Cybercriminal groups often target cloud infrastructure to deploy cryptomining malware that takes advantage of the processing power paid for by the victims. However, some of these groups are also venturing beyond cryptomining and use hacked cloud nodes for other malicious purposes.
“It is readily apparent that attackers are using the default configuration mistakes implemented by weak or insecure IaC configuration templates, bypassing firewalls, security groups, or VPC policies and unnecessarily exposing an organization’s cloud environment to attackers,” the Palo Alto researchers said. “Shift-left security is about moving security to the earliest possible point in the development process. Organizations that consistently implement shift-left practices and procedures within cloud deployments can quickly outpace competitors. Work with DevOps teams to get your security standards embedded in IaC templates. This is a win-win for DevOps and security.”
