What Lurks Beyond Leaky Storage Buckets and Reduced Visibility

By Anne Saita

In 2020, a large SaaS provider with hundreds of thousands of users asked Palo Alto Networks to run a red team exercise against the customer’s cloud infrastructure. Though the cybersecurity company normally doesn’t conduct pen tests, it accepted the challenge.

“The bottom line: We were able to quickly own their environment,” said Matthew Chiodi, Palo Alto Networks’ Chief Security Officer, Public Cloud, during an RSA Conference presentation in mid-May.

Prime suspect: Identity and access management
The red team took advantage of the complexity that currently surrounds cloud-based identity and access management. It set up a completely separate cloud account with limited information from the customer and no remote access or login credentials. Acting like an attacker, the team searched for publicly available information on Google and GitHub to basically test different configurations and different role names.

Several days into the enumeration exercise, the team obtained a temporary access token into the customer’s cloud environment due to a misconfigured IAM role via a role trust policy. Had the target been an on-premises data center using common software like Active Directory, access failures would have shown up in audit logs. Instead, security teams had no visibility because the red team attacked the cloud service provider’s IAM system—not the customer’s cloud account, Chiodi explained.

The temporary access token was then leveraged to view EC2 (Elastic Compute Cloud) instances used by AWS subscribers to provision a virtual server and read the metadata attached to them. The previously discovered misconfigured IAM roles allowed an external account to read internal-only files within S3 buckets, including an exploitable source code repository and a set of encrypted credentials.

If the encryption was done correctly and private keys maintained properly, the attack would have ended there. But in this instance, the aforementioned misconfigured IAM role allowed pen testers to call the key management service and ultimately gain a set of plaintext credentials to access other areas.

“As you can imagine, this would have been a great way to do a supply chain–style attack,” the CSO added.

Another culprit: Infrastructure as code
One reason the Palo Alto Networks team could penetrate the customer’s cloud-based environments was because the compromised company actually followed a best practice: it replicated Infrastructure-as-Code templates. Unfortunately, that also replicated the IAM misconfiguration.

“This is something you need to be extremely mindful of as you build and mature in the cloud,” Chiodi warned.

This red team exercise might sound unique, but other Palo Alto Networks research supports the prevalence of “unknown” misconfigurations in both cloud-based IAM and infrastructure as code, which is now the norm for most developer-led organizations.

In early 2020, Palo Alto Networks released research in which it had gathered almost 300,000 files and 145,623 source code repositories—all publicly available. A team extracted nearly 70,000 role names and almost 33,000 cloud accounts that were tested via an API for validity. Researchers then plucked the 500 most common role names within those confirmed cloud accounts and ran different enumerations and cloud config combinations. The study showed that researchers could access thousands of EC2 snapshots, hundreds of S3 buckets, as well as numerous key management service keys and relational database service snapshots.

The same group surveyed infrastructure as code templates scraped from GitHub and found:

• Insecure configurations. Some 42% of AWS CloudFormation templates had one or more insecure misconfigurations, particularly around encryption, eventing or logging. With Terraform, the most popular alternative, 22% of all configuration files had at least one insecure configuration, particularly around access logging and object versioning—a real issue should a user come under a ransomware attack.
• Permissive access. About 76% of cloud workloads exposed SSH port 22.
• Difficult attribution. Some 60% of cloud storage had logging disabled.
• Compliance and privacy risks. Approximately 43% of cloud databases were not encrypted.

“When you have a compromised cloud account due to one of these types of misconfigurations, it is almost always much worse than a compromised cloud host,” Chiodi concluded.

How to avoid such mistakes
So, what can organizations do to better manage risks within IAM and infrastructure as code? Chiodi recommended the following mitigations:

• First and foremost, gain a holistic view of your cloud infrastructure and the entire software development cycle. This way you can embed security at the earliest point in the software development pipeline.
• During the build phase of DevOps, enable development teams to develop secure code with secure plug-ins they can use at the earliest possible point in the software lifecycle.
• During deployment, scan registries for common misconfigurations, CI/CD plugins, vulnerability scans, etc.
• Continue to focus security resources on runtime as is currently done in most organizations.
• Gain visibility into your infrastructure to make sure everything, such as containers, is behaving as expected. This can be done by leveraging some kind of agent running at the workload level.

Once you’ve built a solid foundation for flagging misconfigurations earlier in the development cycle, you can go deeper into understanding real-time cloud activity—users, processes and technology—using a dashboard for easier tracking. After you have better situational awareness, put automated guardrails in place that will hunt and remediate misconfigurations before they can do damage.

Chiodi also suggested greater code movement transparency by mapping the entire lifecycle of code, starting with workflows. This often takes months to produce, but it goes a long way toward fully understanding how to embed security tools and processes as early as possible. That also goes for establishing and following standards in the cloud. When such standardization occurs, security becomes another component of product quality that ultimately leads to cloud-optimized cybersecurity.

Anne Saita is editor-in-chief of InfoSecurity Professional magazine.