How to limit a hacker’s access to your cloud account?
The LAPSUS$ hacking group has been around for a few months now (at least publicly, based on their achievements they must have been around for much longer). Two people associated with it were even arrested, and no new dumps were released in the last couple of months.
Recent requests we’ve been getting from our customers, regarding similar vectors and attackers, motivated us to take a closer look at what was publicly available about these attacks and how Solvo’s platform can be leveraged in order to prevent similar incidents.
-
Entrance vector
This one doesn’t seem to change. It’s either people keeping credentials in clear text, using admin/admin, leaving keys in GitHub, falling for a phishing campaign or, sadly, knowingly cooperating with the attackers for profit.
These are all vectors that have been discussed many times before, are not unique to the cloud and, apparently, will keep on working. And why? Because we’re humans, we’re looking to preserve our energy. We’re no longer hunting mammoths, we deploy code, but we’re looking for ways to make things faster and by that we cut security corners.
But still, what can be done? I’d recommend making sure you know which ones of your crown-jewels have access to the internet, external accounts and 3rd parties.
2. 3rd parties access (aka Supply chain attacks)
we all use them in our code, infrastructure or applications. Attackers love them because a single point of failure could become an entrance vector to many other organizations (that’s actually another form of energy preservation).
The previous two sections were examples of the entrance vectors used by hacking groups such as LAPSUS$, and potential ways to reduce the risk to your cloud assets.
Now, let’s look at some risks and misconfigurations that grant the hackers with privileges to perform reconnaissance, privilege escalation and execution of other risky actions:
3. Listing permissions (as part of a reconnaissance) –
knowing what kind of permissions exist in the account is very important. The attacker would know what identities might be more valuable than others and would try to get those permissions.
We, the human users, usually name assets and identities with indicative names (Admin, Administrator, DevOps,FullAccess etc), so finding the highly privileged permissions is not hard.
So, you might want to know who can actually list the permissions you have in your account and make sure only entities that actually need to make that kind of list can do that.
Remove permissions from unnecessary users and assets, and consider removing the iam:List* actions from the policies where it exists.
In the example below you can see who can run the ListPolicies call:
You don’t have to “settle” for listing the actions. Instead, you can run a query and look who can read or list from an IAM resource:
In the example above, we filtered in only users and Lambda functions who can read/list IAM actions.
Actions from the listing family are very handy when looking for sensitive S3 buckets. In this case below, you would want to make sure that a flow of the actions mentioned is not available to unauthorized entities:
1. S3:ListAllMyBuckets
– will show us who can list all the buckets. It makes the attacker’s life easier when wanting to choose only the PII bucket, and we don’t want that.
-
-
2. S3:ListBucket–
– will show us who can list items in the bucket. In the example below, we can see that in the demo account we have several buckets that are overly permissive to account outsiders.
-
3. S3:GetObject
– Now we want to make sure that even if someone has access to the metadata of your cloud account, they can’t actually obtain items out of it.
4. Excessive permissions –
you’d be surprised to learn about the funky hacks you can run using excessive permissions you didn’t think of. I’m not referring to the trivial Administrator or root access, but to other, less audited, permissions.
For example, access to your Parameter Store. This popular AWS service is integrated/accessible with other services like KMS, SNS compute and code services. Being able to list parameters might expose where your crown-jewels are and potentially how to obtain them.
We have countless similar examples, and there’s no end in sight. The more we use the cloud, the more attackers use it, and learn how to exploit it in new and creative ways.
No product can promise you to block or detect 100% of attack attempts, just because there isn’t a finite number of patterns. Every service can be exploited when misconfigured, what we might be able to control is the blast radius. The more excessive permissions we have, the wider the radius is.
It’s not easy, and it doesn’t make much sense to audit your cloud account policy by policy, looking for the wildcards, sensitive actions and possibly-risky configurations. This is exactly why Solvo creates two products to make your life easier:
1. The IAMagnifier
where you can query for risky actions, high privileges and exposed assets, get a graph result of your questions and set alerts for any configuration changes and drafts.
2. The Policy Manager
Solvo’s product that analyzes existing configuration, and the behavior of your cloud application. The output of this analysis is a tailor-made and least-privilege security policy, created based on the unique needs of every component in your cloud application.
The policy is updated if the behavior of the application changes, and the user gets notified and approves the change. This also comes in Terraform, CloudFormation and CLI formats.
Do you think your account is well configured? Try out our NEW SecurityGenie report, and see the top risks found by the IAMagnifier.