Palo Alto Networks: Botched Access Management an Easy Opening for Cloud Attacks

It is a truth universally acknowledged that a cloud in possession of an identity and access management (IAM) system, must be in want of security. OK, so that’s not exactly what Jane Austin wrote, but you get the idea. Unit 42, Palo Alto Networks‘ threat intelligence team, reports in its most recent Unit 42 Cloud Threat Report that cloud misconfigurations continue to plague thousands of organizations. Specifically, fouled up IAM configurations can lead to major cloud security problems, which, in turn, can cause serious crypto-jacking attacks.

How bad is it? In one Red Team exercise, a single simple IAM misconfiguration “allowed our Unit 42 researchers to compromise an entire, massively scaled cloud environment and bypass just about every security control.” Had this been a real attack it could have led to a multimillion-dollar data breach. Palo Alto Networks helped the customer remediate the issue.

Is this fun or what?

Access Issues Everywhere

The Unit 42 team then moved on to see if this kind of IAM problem was common. Bad news. It is.

They found several common identity-related flaws across thousands of cloud accounts. The root cause, wrote Matthew Chiodi, Palo Alto Networks’ public cloud chief security officer, “is a lack of IAM governance and standards.” This is further aggravated by “the sheer volume of user and machine roles combined with permissions and services that are created in each cloud account.”

What makes it even worse, Chiodi continued, “humans are good at many things, but understanding effective permissions and identifying risky policies across hundreds of roles and different cloud service providers are tasks best left to algorithms and automation.”

Adding insult to injury, IAM defects are difficult to detect. All too often they go unnoticed until it’s too late and an attack strikes home.

Further investigations of the intersection of the cloud and GitHub led to the discovery that developer accounts could be leveraged to expand a cloud’s attack surface. Usually, developer accounts are allowed a higher level of access to cloud environments than normal users. There’s nothing wrong with that per se, but some of the permissions that programmers are granted are downright dangerous.

Specifically, the security explorers found developer accounts had access to a custom organization-specific IAM role called flowlog*. This opened up all flow log subtypes, including the much too powerful flowlogs.role-admin role. Armed with this, an attacker could escape the developer area and get administrative access to the entire cloud environment. All of this came courtesy of an overly permissive admin IAM role.

The moral of the story: you must be particularly careful about setting up developer IAM rights.

So, how common are these problems? Too common. The reasoning is that searching misconfigured IAM roles isn’t that different from searching for databases, which allows anonymous logins. Unit 42 researchers scanned for account IDs for Amazon Web Services (AWS). These were then checked against a pre-generated list, created by crawling GitHub and aggregating the top 500 most-used IAM role names.

Their crawling through GitHub for AWS ID and role name matches found over 145,623 repositories, more than 175,000 EC2 snapshots, hundreds of S3 buckets, and many RDS snapshots and KMS keys. In short, “Make no mistake: If attackers had discovered what Unit 42 researchers found, they would have assuredly taken steps to ‘own’ these cloud accounts.” Along the way, researchers discovered misconfigured DevOps roles that had near-system admin permissions and misconfigured DBAccess roles that had access to database services, such as Amazon DynamoDB and Amazon Redshift.

Jay Chen, senior cloud researcher for Unit 42, added that this “misconfigured IAM trust policy is specific to AWS environments and usually exists in more sophisticated cloud environments that require cross-account access. Based on our research, we spotted this misconfiguration more often in larger accounts with hundreds or thousands of IAM roles.” In short, the more complex your cloud, the more likely it is you’ll open potentially serious IAM holes.

That said, Chen continued, Unit 42 believes that IAM misconfigurations, which can lead to elevation of privilege, are common across all CSPs. “With thousands of permissions across hundreds of cloud services that all interact with each other, there are many chances that one user may gain elevated privilege by abusing a set of granted permissions, as noted in our report. A similar type of misconfiguration has also been reported in Google Cloud.”

Now AWS tries it best to keep you from making these kinds of blunders. By default, when you create an AWS IAM trust policy, it’s limited to specific AWS services, accounts, or identity providers. Unfortunately, that obviously hasn’t stopped sysadmins who just want to get a job done and ignore security requirements along the way. When you manually edit IAM trust policies in the AWS consult, you must ignore multiple warnings — and that’s exactly what people do.

Unit 42 also found that just like people are always using passwords wrong, staffers are also blundering with Access Key IDs and their corresponding Secret Access Keys. In particular, organizations do a poor job of rotating out old keys. Globally, Unit 42 research found that 68% of organizations using AWS and 62% of organizations using Google Cloud have service account keys older than 90 days. Interestingly, Azure has hardly any gross user account policy violations, such as inactive user access or expired keys. That’s probably because Azure uses Azure Active Directory (AD) to control and manage user accounts.

Last, but by no means least, they found a staggering 57% of Japan and Asia-Pacific organizations don’t enable Multi-Factor Authentication (MFA) in AWS for their IAM user accounts. The Americas, 46%, and EMEA, 45%, are better about using MFA, but that’s still nothing to boast about. Making matters worse, all too many organizations don’t even use MFA for their IAM root accounts. This is just asking for trouble.

And, Unit 42 notes, trouble is looking for you. Unit 42 research shows that cryptojacking affects at least 23% of organizations using the cloud.

Happy Cryptojackers

Attackers typically use misconfigured cloud infrastructure, such as those described above, to compromise cloud instances. These misconfigurations can lead to the bypass of firewalls, AWS Security Groups, Amazon and Google Virtual Private Clouds (VPCs), or Azure Virtual Network (VNet) policies, and can expose an organization’s cloud environment.

That done, the attackers tend to use cloud resources for Kinsing crypto-mining operations targeting the popular Monero cryptocurrency.

So, what can you do about all this? Palo Alto would be happy if you were to use its Prisma Cloud cloud native security platform, it’s WildFire malware prevention cloud service, and Autofocus attack analysis software.

The company also has numerous general suggestions on how to protect yourself and your cloud. These include:

1. Minimize the use of administrator credentials.
2. Simplify user management by using assigning peoples to groups or roles.
3. Enable MFA.
4. Configure a strong password policy. Good passwords still matter even in these days of MFA.
5. Rotate access tokens regularly.
6. Monitor IAM APIs.
7. Grant least-privileged access
8. Auto-remediate excessive privileges.
9. Leverage cloud-native security platforms.
10. Harden IAM roles. Never grant anonymous access (e.g., “Principal” : { “AWS” : “*” }) to any IAM role.

If you do all these things, you’ll be a heck of a lot safer than you probably are today. You see, it’s not paranoia when they really are out to get you. And, I and Unit 42 assure you, they really are out there and they really are out to get you and your little cloud too.

Amazon Web Services and Palo Alto Networks are sponsors of The New Stack.

Feature image via Pixabay.

At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.