Now Reading
Protect Your AWS Environment beyond Patching Log4j

Protect Your AWS Environment beyond Patching Log4j

Protect Your AWS Environment Beyond Patching Log4j

Unless youre living under a rock or are otherwise not on the cybersecurity grid, chances are you have heard of the serious vulnerability in this. Apache Log4j library. This vulnerability affects Log4j2 2.0 – beta9 through 2.12.1, 2.13.0 and 2.15.0. It allows an attacker to control log messages or parameters and execute arbitrary code from LDAP servers when message substitution is enabled.

This vulnerability is important because Log4j library is so ubiquitous that it has been called a realization of August 2020 Comic by xkcd:

Source: https://xkcd.com/2347/

Log4j has been widely used, making software extremely vulnerable. This has had an enormous impact on the security of the software. There are many vendors.

We have thoroughly examined the technical aspects of this vulnerability and won’t be taking the time to go into detail here. Check out the following technical review. Log4j PostBy Mitiga’s colleagues and the relevant List of technical resourcesThey have compiled.

We feel the need for us to discuss the general and more strategic lessons we can learn from this incident. Even though this is a serious cybersecurity breach, Log4j will not be the only one discovered. In fact, it is likely that it will not be the only one putting infrastructure all over the globe at risk.

This is how many people might approach this incident. Log4j 2.17.0 will work fine.

From “Gunshow” by K.C. Green

While you may have resolved the problem at hand, you are not addressing other threats that could affect your infrastructure. Recognizing that such an event is likely to happen again can help you improve your cybersecurity strategy so you are better prepared for the next one.

Log4j and Your AWS Security Strategy

This finding does not affect AWS services, but you can keep track through AWS bulletins such as this oneLog4j is a spotlight on the other aspects of AWS security strategy which are on your side of Shared Responsibility Model. These include the permanent credentials and third party accessibility to your AWS resources.

Permanent AWS Credentials – What Are They Good For?

AWS credentials can be saved in environment variables and/or files on computing resources or workloads. Criminals creating malware have not been able to access these storage locations. TNT team winsWe reported on this earlier in 2021. Christophe Tafani Deeper, in his analysis of 2021 Cloud Security Breach and VulnerabilitiesStatic credentials are still the main access vector to breach cloud environments.

Greg Linares has described how the weaponization and harvesting of AWS credentials from these locations took only a few hours.

And it was quite popular.

Identity impersonation can be especially dangerous when harvested credentials, such as IAM user acces keys, are permanent. The Log4j vulnerability detection is timely reminder for security professionals to ask themselves what permanent credentials are good for. The answer — typically very little.

It is convenient to use IAM users, access keys, as setting up a replacement can be quite difficult. It is difficult enough for organizations to give up permanent credentials. They don’t see the value in removing them. However, we argue that the potential consequences of permanent credentials being hacked is far greater than the inconvenience of replacing them.

This aspect of credentials management can also be worth your time, as many solutions are available today for just about any use of IAM and access keys. Here are some:

  • Are you using access keys to CLI? Next, move on to using AWS SSOIf possible, consider adopting saml2awsUse temporary credentials that are generated using identities from another source to obtain temporary credentials. If you have to, use aws-vaultTo store credentials in the OSs Secure Keystore
  • Are you allowing IAM users to access AWS console? Switch to federating identities through your identity provider, or adopt AWS SSL for multi-account management.
  • Do you grant IAM user access keys that allow third parties to access resources in your organization? STOP DOING EVERYTHING AND CHANGE TO A SERVICE YOU CAN ACCESS. Use a third-party role with an external ID properly set upThen, disable the permanent access keys.

Aidan Steele recently posted his thoughts about exactly this topic.

Aidan continues to explain how even for the odd case of a Raspberry pi being stored in a closet, he could suggest a good substitute (and provide) open sourceTo assist with its implementation.

Bottom line: It might take some time to eliminate IAM user access key or IAM users from your environment. If you are concerned about AWS credentials being stolen, the Log4j incident is a solid example of why eliminating permanent credentials is worth your time and effort. You should avoid static credentials in general.

Third Party Access – Do You Have It Under Control?

Supply chain security is an extremely important part of your overall security posture – and doesnt always get center stage. There are very few legal and technical controls available to ensure that access granted to third parties is not compromised. You must ensure that you monitor and manage such access carefully as it could be a way for malicious actors to gain unfettered access.

There is a way to allow external organizations access your AWS environment. However, even if access is granted correctly and legally, it can be misused. These threats are not only theoretical. It is very possible that vendors who have legitimate access the cloud resources were exposed to this vulnerability, potentially allowing attackers access to your environment. How can you keep it under control?

Keep track of vendor release notices that relate to the vulnerability. If you cannot find such a notice in your vendor database, don’t be embarrassed to contact each vendor directly and ask them if they were exposed as well as how they are actively mitigating this vulnerability. The entire event should serve as a wake-up call to you to monitor all third party access closely and keep them under constant surveillance. Next, ask yourself if you are aware if any third parties have access currently to your AWS environment. Is it possible to know what actions they are allowed to perform and if they really need access to provide the services that they offer? Is the access still active, or is it a relic from an old project that was never removed?

Where does Ermetic fit in?

As a cloud security vendor we are committed to providing proper controls for strategic issues. Using our SaaS technology we constantly and continuously review your environments configurations, permissions and logs – allowing you to easily gain insights on the threats arising from such configurations. Let’s see what happens.

Detection and Verification of Static AWS Credentials

The unique view of Ermetic platforms into identity intelligence allows you to immediately see if there are any static credentials in the form IAM user access keys.

Ermetic's identity intelligence filtered to show IAM Users with active access keys

The platform gives instant results about which identities have been inactive for significant periods of time. These findings are likely to be a quick win that can be discarded.

Ermetic's excessive permissions dashboard showing inactive IAM users with active access keys

Permissions Rightsizing

The platform can access the permissions of each identity and logs that indicate which actions they are actually performing on which resource. This allows it to automatically generate a per identity least privilege policy recommendation to carry out relevant business functions.

In order to reduce the risk of any type of compromise, it is highly effective to proactive rightsize the permissions of all identities with access. This is also true in relation to vulnerability Log4j.

Let’s say, for example, that one of your workloads runs on an EC2. While you know that this EC2 requires access to S3 buckets you don’t quite know which, and for what purpose. You attach the AmazonS3FullAccess policy or even the S3ReadOnlyAccess policy as an IAM role to the EC2. Although this is a very bad practice we all know it’s more frequent than we care.

See Also

If the EC2 runs software with a vulnerable Log4j version, it could have extensive access to all S3 pools within the environment. This could potentially have catastrophic consequences for the availability of mission-critical data and/or confidential or sensitive information. Kat Traxler did a wonderful job of explaining. Log4j can be used for exfiltrating credentials from EC2 cases – allowing attackers to impersonate the EC2 and use its permissions in the attacked environment. The potential consequences of such a breach will be minimal if the EC2 allowed actions are limited to the bare business functions.

It can be difficult to prevent permissions from being granted at large scale. Ermetic supports this process by automatically generating the right-sized policies, allowing AWS environment administrators access to them, and over permissive policies.

Ermetic automatically generating a suggestion for a rightsized policy based on CloudTrail activity log

Anomalous Behavior Alerts

Ermetic can detect anomalous behavior in your environment by analysing CloudTrail logs.

In a Recent webinar, we used the Pacu exploitation framework to demonstrate various elements of the cyber Kill Chain” that an adversary would use to wage a campaign on a victims environment. We demonstrated multiple behaviors that a threat actor might be inclined (if not forced) to do in an attacked environment. The session also showed how log analysis allows the person responsible for managing the environment to detect malicious activity and stop it from spreading.

An attacker might be inclined to privilege escalate on itself by attaching a permissive policy to a role it is allowed to assume. Ermetic will immediately raise an alert if this has never happened before.

Ermetic detecting anomalous behavior of an IAM Role escalating its privileges

Controlling Third Parties

It is essential to correctly size policies and keep track of identities. Third party identities are extremely important. If they are compromised, the consequences can be devastating and far beyond your control.

Permissions granted to third party are typically as per their request. Administrators rarely question vendors’ requests and actual needs. For example, as part of our work with many vendors, we received a CloudFormation template that provisioned a role with an inline policy that allowed the vendor to use iam:AttachRolePolicy on *. This specific permission may seem harmless – but it actually allows the subject to privilege escalate their permissions to admin. Our analysis of the actual usage by the third parties revealed that the permission was excessive. It was not necessary for the regular business function that the third party served and could have been removed.

Inline IAM policy generated for 3rd party including the iam:AttachRolePolicy action

Ermetic can also help you find forgotten roles, allowing third-party access that haven’t been used in a significant time.

Ermetic's excessive permissions dashboard showing inactive IAM Roles allowing access to 3rd parties

Summary and a New Year Resolution

The Log4j problem was a serious and high-profile incident that required immediate attention from all parties. We encourage you use every tool available to detect and remedy exposure to the Log4j vulnerability. These actions are not tactical. Log4j, although it is not a one-off, will help you see the bigger picture. Haroon Meer put it ironically

Other severe and ubiquitous vulnerabilities are surely lurking in the shadows – and will surface one day. Log4j can help you take strategic action. Take a deep, detailed look at your security measures and assess how well you manage and control your AWS environment security. Then take decisive steps to improve it.

The post Protect your AWS Environment beyond patching Log4jThis article was first published on Ermetic.

*** This is a Security Bloggers Network syndicated blog from ErmeticLior Zatlavi authored this article. You can read the original post at: https://ermetic.com/blog/aws/protect-your-aws-environment-beyond-patching-log4j/

View Comments (0)

Leave a Reply

Your email address will not be published.