Infrastructure-as-code templates are the source of many cloud infrastructure weaknesses

In the age of cloud computing where infrastructure needs to be extended or deployed rapidly to meet ever-changing organisational 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).

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 defences," the researchers said. "This high number explains why, in a previous report, we found that 65 per cent 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 per cent), Terraform by HashiCorp (37 per cent) and AWS CloudFormation (24 per cent).

Of these, 42 per cent of identified CloudFormation templates, 22 per cent of Terraform templates and nine per cent of Kubernetes YAML configuration files had a vulnerability.

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 per cent 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 unauthorised 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 per cent didn't have encryption enabled, and 45 per cent had no logging turned on.

Terraform templates, which support multiple cloud providers and technologies, did not fare any better. Around 66 per cent of Terraform-configured S3 buckets did not have logging enabled, 26 per cent of AWS EC2 instances had SSH (port 22) exposed to the internet and 17 per cent 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 per cent)
• Containers without CPU or memory resource limiting (64 per cent)
• Azure Network Security Groups (NSG) with exposed SSH (51 per cent)
• Google Cloud Platform Storage without logging enabled (58 per cent)
• Azure Storage without Secure Transfer enabled (97 per cent)

Kubernetes YAML files had the smallest incidence of insecure configurations, but those that did were significant. Of the insecure YAML files found, 26 per cent 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 per cent of organisations allow public access to port 22 (SSH)
• 69 per cent of organisations allow public access to port 3389 (RDP)
• 64 per cent fail to enable logging for their data storage
• 62 per cent do not enable encryption for the data storage
• 47 per cent of organisations 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.

Cyber criminal groups often target cloud infrastructure to deploy crypto-mining malware that takes advantage of the processing power paid for by the victims. However, some of these groups are also venturing beyond crypto-mining 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 organisation'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."