Author: David Hendri

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.

1. 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.

1. 1. 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.

Leveraging Snyk IaC scans, organizations can proactively identify and fix risky policies in their infrastructure as code, be it Terraform, Kubernetes, or CloudFormation.

When used in combination with Solvo, Snyk can generate secure policies in place of the risky ones and help organizations quickly fix misconfigurations and improve security without needing to bring on additional resources or expertise.

Synk Iac Fixes Security Issues in your Code

Snyk IaC provides information about the potential risk from this configuration and general advice for how to fix the problem, and Solvo takes this further by automatically generating the least privileged IAM configuration specific to your environment. Used together, you find and fix issues as you code them, to quickly make the necessary corrections and ensure that it is secure before deploying.

In this article, we’ll go through a workflow combining Solvo’s automatic platform with Snyk IaC to create a customized and secured access from a Lambda function to an S3 bucket.

More and more, organizations are shifting over to using the infrastructure as code model for managing their cloud resource configurations.

Configuring your infrastructure through code allows you to have better version and source control, making it easier to track and replicate conditions from one environment to another. This approach is particularly useful for spinning up AWS S3 buckets that can come in handy for storing your code or other useful bits of data. As a cloud resource, these S3’s are easily shareable with the rest of their team.

But sometimes, these S3’s become a little too shareable. When working quickly, writing a secure IAM policy for a cloud asset (S3, Lambda, EC2 or any other asset) is the last thing that developers think about. In the interest of speed and convenience, it is far from uncommon for a developer to misconfigure the bucket with overly permissive security policies that may put the contents of the bucket at risk of exposure.

Let’s take a look at some policy-based security risks and how we can avoid them.

An improperly configured Lambda example

Below we have a Terraform configuration that sets up an AWS Lambda which puts an image into an S3 bucket. You can also see here the code for the IAM role and security policy.

Which details can we glean from this configuration that should tell us a bit about its contents and level of security?

In our application, the Lambda is currently written to put images of dogs in an S3 bucket. This Lambda has a permission to do that, along with other actions like Put, Get, Delete, Create and List. And many more actions if we consider all the other services in addition to S3.

This happened because of what’s written in lines 52-54. We’re effectively ALLOWing all actions on all resources. These mean admin permissions.

This is far too permissive. The only type of action that should be permitted here is “put”, since anything else is excessive and could lead to data leakage, data corruption, or be used for recon on our assets.

If you know both Terraform and AWS IAM fairly well and you only had to review this one configuration, it might be easy to spot the problem. But, generally there is far more Terraform configuration and the knowledge of configuration details is tough to keep up with, making it unlikely that a developer or security team member will stumble across this risky policy buried deep inside a set of Terraform modules.

Thankfully, there are new tools available that are making the task of finding and fixing these issues a much more manageable lift and helping scale security responsibilities out to all the engineering teams using IaC.

Scanning for Insecure Configurations

Snyk Infrastructure as Code (IaC) is a new IaC testing tool that is capable of scanning Terraform, Kubernetes, and AWS CloudFormation configurations and identifying risky policies across services in AWS, Azure and GCP. This might be something as simple as an asterisk that makes the policy way too permissive, as in our example above. Or possibly a “write” where there should only be a “read”, for example.

By utilizing continuous, automated static testing, Snyk IaC is able to scan Terraform at a scale that makes it effective for organizations for managing their infrastructure as code. If the scan turns up a risky configuration, then Snyk will guide the engineer to a fix, but even better, Solvo can be used with Snyk IaC to automatically generate a secure policy that will mitigate the potential exposure.

Let’s see how it works in practice.

To run the scan, we can use the Snyk CLI to run a `snyk iac test` on our configuration:

Now we see that our policy only allows for “PutObject”, so our dog pics are safe from harm

Once Solvo enforced the policy, we scan the Terraform file again and Snyk IaC shows us that the administrative permissions are all gone:

Combining Integrations for Wider Coverage

Leveraging Snyk IaC scans, organizations can proactively identify and fix risky policies in their infrastructure as code in combination with Solvo. Learn how to quickly fix misconfigurations and improve security without needing to bring on additional resources or expertise.

For more information about how Solvo S3 bucket configurations can help to automatically reduce your cloud infrastructure risk, visit the Solvo website and get started or request a free demo. If you haven’t tried Snyk IaC, you can start using it for free here.

AWS S3 buckets have a well-earned reputation for being down right leaky.

Considering how widely used this useful object storage service is for developers, it has historically been fairly easy to misconfigure their security policies. And as case after case –– look at the recent Premier Diagnostics incident –– has shown, the results of an improperly secured S3 can have a significant negative impact on a company.

Thankfully, the crew over at AWS has made some pretty significant improvements in giving developers the tools they need to make their S3s much more secure. These measures are most visible in the way that they have gotten really good at blocking access to the buckets by default.

Currently when creating an item inside an S3 bucket through the AWS console, it is automatically blocked from public access.

That’s a great start.

AWS has gone the extra step in adding more precautions. Just in case you create an object that allows public access by mistake, the S3 bucket has an additional safety mechanism that blocks all public access. This is true even if you configure that specific item inside the bucket is accessible by an external user.

The controls here are automatic and you have to really go out of your way to make the stars align and end up with a leaky bucket.

With these great advancements in security in mind, let’s see how things are still going wrong.

Terraform — The Wild West to AWS’s Security Controls

The automatic, double layered security protections laid out above are effective. Just so long as you are configuring your S3 on the AWS console.

Unfortunately, they do not appear to be very effective when the buckets are configured using a terraform.

In the course of our own development here at Solvo, we recently realized that our S3’s were showing that these security mechanisms were coming up false. This meant that the protection that we assumed that we had by default when were configuring our buckets in the AWS console were just not being brought over like we expected that they would.

resource "aws_s3_bucket" "my_bucket" {

bucket = “my-tf-test-bucket”

acl    = “private”

tags = {

Name        = “My bucket”

Environment = “Dev”

}

}

This was an unpleasant surprise to say the least. Especially since Solvo — like many others out there — uses terraform for creating many of our cloud infrastructure resources, following the Infrastructure as Code (IaC) model that has become increasingly popular in recent years.

Infrastructure as Code helps to solve a lot of problems facing developers and especially DevOps teams when it comes to quickly and efficiently spinning up infrastructure like VMs, load balancers, etc. Instead of attempting to manually configure a copy of the exact configuration from one deployment or environment to another, it makes perfect a lot of sense to simply do it from code. It’s repeatable, scalable, and leaves less room for errors that can end in security disasters. For a quick and helpful brief on why IaC is playing such a significant role, check out this brief from Microsoft.

So how did this challenge shake out? you.

How We Solved Our Terraform Issue

The fix here was both straightforward and a bit of a drag.

We basically went into our terraform and added an additional resource that turned the blocking policies back on.

resource "aws_s3_bucket_public_access_block" "my_bucket_access_block" {

bucket = aws_s3_bucket.my_bucket.id

block_public_acls   = true

block_public_policy = true

ignore_public_acls = true

restrict_public_buckets = true

}

This was the good news.

The downside is that there wasn’t a way to automate this process, so we had to manually go through each form and add it ourselves.

Lessons for Configuring S3s Securely

By all appearances, there doesn’t seem to be any real reason that the good folks who developed the terraform at HashiCorp have dropped these protections. It was probably less of a decision and more of a good feature just not being carried over.

Maybe the lesson here is don’t expect every vendor that supports an ecosystem to cover every feature and tool in their own products. HashiCorp is not AWS and does a pretty stellar job of the things that they do.

As users of these products, we just need to be aware of their capabilities and limitations.

While it took some time, we successfully secured our infrastructure. Now we know to include this in our forms going forward, and so do you.

Everyone in IT is concerned with keeping up with trends, best practices and watching what others are doing. In such a fast-changing world, it’s easy to fall behind if you’re not paying attention and even when you are, it can just make things more confusing. Should you go with the flow and do what others are doing? Or is that a sign that you’re missing out on a better way?

It’s complicated.

The same idea applies to coding languages. Every developer has their favorite and every developer has at least one language they would really like to avoid. Some languages are generally agreed to be better suited for certain types of applications while others are more for general use. Put ten developers in a room with the job of making an app, and they’ll spend the first three hours arguing about what language to use.

Like we said, it’s complicated. 

This wide diversity of opinions on the topic of coding languages is what first got us thinking about asking our clients about the languages they used.

The original idea behind the survey was simply to gather information to help us understand our customers better. The preferences in coding languages was obviously something we were interested to know. The project became more interesting when we started to get questions from our customers about what kind of answers we received. Everyone wanted to know how their answers compared to others. That’s when we got the idea to share the results with everyone.

You can download the findings of our survey here.

The results are interesting for lots of reasons. For example, we were quite surprised to learn how diverse the AWS community is when it comes to coding languages. There are some similarities when we compare organization sizes but the AWS community features lots of variety. This shouldn’t come as too much of a surprise since developers value freedom and flexibility in their work, which is reflected in the data we gathered.

Other takeaways include:

1. The bigger the team, the more likely it is to use Java
2. S3 is the #1 service used no matter the size of the application
3. PHP is declining in popularity
4. Javascript is the top pick for both the smallest and biggest departments.
5. Python takes the top spot for those in the middle.

The results of the survey confirm what we have long believed — that developers just want to focus on doing what they do best, coding in the most efficient and convenient way possible, which often comes at the expense of security considerations.

That’s where Solvo comes in. We want to free developers to concentrate on doing the best job they can. And that means having the necessary backup security measures that make it possible.

If you want to learn more about which languages are being used in the AWS community, download our report here.