CyberWire Daily - Misconfigured identity and access management (IAM) is much more widespread. [Research Saturday]

Episode Date: November 21, 2020

Identity and access are intrinsically connected when providing security to cloud platforms. But security is only effective when environments are properly configured and maintained. In the 2H 2020 edition of the biannual Unit 42 Cloud Threat Report, researchers conducted Red Team exercises, scanned public cloud data and pulled proprietary Palo Alto Networks data to explore the threat landscape of identity and access management (IAM) and identify where organizations can improve their IAM configurations. During a Red Team exercise, Unit 42 researchers were able to discover and leverage IAM misconfigurations to obtain admin access to a customer’s entire Amazon Web Services (AWS) cloud environment – a potentially multi-million dollar data breach in the real-world. These examples highlight just how serious the failure to secure IAM can be for an organization. Joining us in this week's Research Saturday to discuss the report for Palo Alto Networks' Unit 42 is CSO of Public Cloud, Matt Chiodi. The research can be found here: Highlights from the Unit 42 Cloud Threat Report, 2H 2020 Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

What we found was that this problem that we had found in this one customer was actually much more widespread. This is something that is likely affecting thousands of cloud accounts worldwide. That's Matt Chiodi. He's Chief Security Officer for Public Cloud at Palo Alto Networks. The research we're discussing today is their second half 2020 edition of their biannual Unit 42 cloud threat report. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware

attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, Thank you. Learn more at zscaler.com slash security. We wanted to really understand the impact of cloud misconfigurations. So we were actually approached by one of our customers

to do a red team exercise on their AWS environment. And as part of that red team exercise, one thing I'll say there is at Unit 42, we don't typically carry out offensive operations. We are strictly a research organization. But in this case here, we made an exception because of the sheer scale and size of this customer. So we carried out a red team exercise,

and in doing that, we very quickly discovered two critical AWS misconfigurations in less than a week that could have led to a multi-million dollar data breach. Well, can you give us some insights here? Because I think all of us are aware of the kind of endless chain of stories that we hear about people just sort of leaving their AWS buckets out there, hanging wide open inadvertently through misconfigurations. But I suspect there's some nuance there that we might be missing with the bigger picture. Sure. That's a great question, Dave.

And you're right. This wasn't a case of a customer having a misconfigured bucket or anything like that. This was something, I would say, slightly more complex. So this had to do, at the core of it, this was not an AWS misconfiguration. It had nothing to do with anything that AWS did. This had to do with exactly how the customer had an IAM role misconfigured, right? So this had to do specifically with identity. And again, our researchers in just about a week

were able to find this misconfigured role and then they were able to exploit it to the end where they were able to get complete and total control over this customer's AWS environment. So this one wasn't an S3 bucket up front, but they were able to use this misconfigured identity, this misconfigured role, and then from that, they were able to get to everything that was supposed to be

inside this environment. So yes, they were able to get to S3 buckets, they were able to get to encryption keys, and eventually they were able to own the entire environment. So yes, they were able to get to S3 buckets. They were able to get to encryption keys, and eventually they were able to own the entire environment. Can you give us some insights as to what happened on the client side? What did they overlook? What caused the error on their end that you all were able to uncover? That's a good question as well. Our assumption going in was, this is a massive, massive customer. They themselves ran a SaaS platform

that they then turned around and offered to their customers. Our assumption going in was that they were going to have absolutely stellar security across the board and that we probably wouldn't really find anything. In this case here, where this customer had not done a good job, it didn't have anything to do with patching. Their systems, as far as we could tell, were very well patched, things like that.

They didn't have any kind of application misconfigurations or application patches that were missing. In this case here, it had to do with the fact that they did not have strong identity and access management governance. And all that means is that, you know, in the cloud, and this, I would say, this is an area that is very different from the on-premise world. So in the on-premise world, when you're talking about identity, you're dealing with usernames, passwords, groups, and permissions. You have those four key elements. In the cloud, you have all four of those,

but then on top of it, you have this new thing, which is a role, right? And typically, there's just not one role in a cloud account. You could have hundreds in a single cloud account. And that was the case with this customer. So all we happened to find was just one of those roles that was misconfigured, right? In this case, it had a wild card.

It had that asterisk in there. And that simply meant that once we were able to find this misconfigured role, all we had to do was figure out, okay, what else does this give us access to? And that's how we were able to get in and then start to jump around and be able to eventually own the entire environment. And to be clear here, this is a well-resourced company we're talking about here.

These are not folks who are scraping for every dollar to try to do things right. It wasn't a matter of them not having the team and the resources to get it right the first time. Absolutely. This customer has a large security team. They likely spend millions of dollars a year on their cybersecurity. Again, by everything that we could tell,

we were given very limited information on the environment. As far as we could tell, they were doing most things right, and this just happened to be one area that they simply overlooked. This is an interesting intersection as well that we found. We do our cloud threat reports just about every six months. In February of this year, February of 2020, we did a different exercise where we actually looked at something known as infrastructure as code templates.

That sounds technical, but all it means is that in the old way of building applications in the cloud, you would go in and you had to manually, I want to click here for some storage, click here for some networking. Now, all that's done in a template or in code.

The way that fits with this current customer that we're talking about, they used infrastructure as code templates. And because of that, they actually made the problem worse because they had this one misconfigured role and then they used these templates to create their subsequent environments. They actually replicated that misconfiguration to their other environments. And that is what allowed us to get to all of their environments and own their entire infrastructure. So what's the lesson here?

I mean, for organizations around the world, what sort of steps should they be taking to make sure that they're not having the same sort of thing happen to them? Yeah, I mean, I think from our perspective, kind of what we walked away with is that, you know, for many years, the things that have been at the forefront has been, you know, make sure your systems are all patched. And that is absolutely still a baseline important thing. You have to make sure systems are patched. In that case, in this case here, this customer was patched. We talk about, you know, make sure that you've got, you know, strong passwords. We did not exploit anything to do with passwords, right? And As far as we know, they had strong passwords. What we walked away with here is that organizations,

especially those that have great scale in the cloud, they need now to be absolutely focused on identity and access management and the governance of it. Because in the cloud, this is something that's different, right? So even in an on-premise world, right, if a system itself, let's say you have just a server, and let's say that it's missing a patch and someone exploits that patch, they're able to now get onto that system. The blast radius, right, of what they're

able to do is typically limited to just that system. The attacker gets in, they may be able to get on that individual system, and then of course they start to look laterally, what else can I see? But that's usually the biggest part of it. Unfortunately, in the cloud, if you have misconfigured identities

or misconfigured roles like we saw in this case here, the blast radius can be much larger. Instead of it just being a single host that can be compromised, in this case here, and I'll talk about the second part of the research in a minute, the blast radius is not just the host anymore. Now it could be the entire cloud infrastructure that's attached to it. So that's kind of one of the big takeaways that we found as part of this research is that the blast radius and the impact tends to be much greater than it would have been if this was a traditional on-premise environment. Well, let's move on and talk about the second part of your research here. What else did you discover? We thought, okay, we carried out this exercise.

And as I mentioned, in a very short period period of time we were able to compromise the environment we wanted to pull back and really try to understand yes, this is a well-resourced customer but maybe they just had a bad day. Maybe this was just a misconfiguration and it would never happen again. So we wanted to look more broadly across the industry just to see how big of a

problem is it. And so what we did was we looked at one of our favorite sources for public data, and that is GitHub. Most people know GitHub. It's a place where developers love to store their code, share code, et cetera, store it there. And what we did is we leveraged GitHub and we downloaded well over 100,000 repositories that are publicly available using the GitHub searching API. We then began to mine through that looking for AWS account IDs. So we found literally thousands of AWS account IDs. The next step in the process

was making sure that they were valid accounts. And so we were able to do that. And then we started to also mine that data to look for those IAM roles that we were talking about previously. And so basically we now have a list of valid AWS accounts and a list of the most common role names.

And then we just started different combinations, trying these out. This is exactly what an attacker would do. They would try to do an attack that maybe is not even directly against a customer because they might see that, but they get as much information as they can in a very low and slow way. That's exactly what we did here. What we found was that this problem that we had found in this one customer was actually much more widespread.

In fact, we found literally hundreds of EC2 backups that we would have been able to access had we not been ethical in how we were doing this. We found encryption keys that were available publicly. And there were many accounts that, again, had this not been Unit 42, had this been an actual attacker, that they could have gotten access to. So again, we walked away from this saying, this wasn't an isolated issue with one customer. This is something that is likely affecting

thousands of cloud accounts worldwide. How can organizations go about checking themselves out? Is this a matter of an internal audit? I mean, obviously this organization reached out to you to test this. Is it likely that they would have found it on their own through their own processes? You know, they may have found it eventually, right? But unfortunately, and I mean, I say fortunately in the case of this customer, they were able to have forensics involved and they were able to determine that they were not breached.

No one else luckily had discovered this. But a lot of times, clients don't get lucky. So I think in this case here, what I would say organizations really need to focus on moving forward is two things. And we talk about this in the report. Near the end of it, we basically give 10 recommendations or best practices for really trying to eliminate these types of things. So I won't go over all 10, but I'd say there's three, in my view, that really stand out. The first is just the whole concept of granting least privilege.

just the whole concept of granting least privilege. And all that means is, look, it's about figuring out, here's a developer, what is it that they need to do on a regular basis? And then it's just figuring out, how do I give them the ability to do what they need to do and give them the ability to do nothing else? That is the concept of least privilege. What we see oftentimes, though, is that these accounts for developers, they may start off in some kind of development environment, and they start off with a lot of privileges. And then as things get down the road, those privileges never get pulled back. And then that perpetuates itself into then production environments.

So number one is to really look for a way to grant lease privilege to start. And then the second one has to do with just, you know, we talk a lot about auto remediation in the industry. How can you make things automatic? But when it comes to these types of identity misconfigurations, it becomes really important to automatically look for, right? So in this case here, what this customer is now doing, but should have been doing in the past, is they should have been automatically scanning their IAM roles looking for these types of misconfigurations. And you can do that. And then when you find it, instead of just kind of throwing out an alert and saying, hey, we have a misconfiguration,

throwing out an alert and saying, hey, we have a misconfiguration, actually automatically fixing it. These are the types of proactive things that we believe customers absolutely need to be doing. With the speed of DevOps, it must be automated. It cannot be manual. As organizations scale their cloud infrastructure, a lot of times the focus on the cost of doing that, it might be glossed over.

Simply because when organizations are spending a lot on cloud, a lot of times people don't really catch if maybe there's a couple thousand dollars more in one month. And the attackers that are carrying out these cryptojacking attacks, they've gotten smart. They don't take up tons and tons of resources anymore because they know they're going to get caught. And so they specifically design their scripts

to actually run at a low utilization. And so they can oftentimes go for longer periods of times and not get caught in these environments. And again, poorly configured environments are the ones that are most at risk to cryptojacking. Our thanks to Matt Chiodi from Palo Alto Networks for joining us. The research is the second half 2020 edition of their biannual Unit 42 cloud threat report. We'll have a link in the show notes. And now a message from Black Cloak.

Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365 with Black Cloak. Learn more at blackcloak.io. The Cyber Wire Research Saturday is proudly produced in Maryland out of the startup

studios of Data Tribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing Cyber Wire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening. Thank you.