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:
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.
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.
Here are the AWS Variables I see being targeted by wild by #log4jExploits at this point (even without rce).
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
AWS_SHARED_CREDENTIALS_FILE
AWS_WEB_IDENTITY_TOKEN_FILE
AWS_PROFILE
AWS_CONFIG_FILE
AWS_ACCESS_KEY_IDGreg Linares, @Laughing_Mantis December 11, 2021
And it was quite popular.
The most common attempted env thefts have been:
AWS credentials
Docker credentials
Hadoob installsRansomware payloads – 4%
Payloads for cryptominers: 22%
Info stealer payloads: 61%
Unknown payloads: 13%JDNI gadget payloads: 23%
Spray N Pray Headers – 70%
Single Attempt: 21%
Other: 9%Greg Linares, @Laughing_Mantis December 15, 2021
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.
I think there’s no need for AWS IAM users today. So I made a PoC to “prove” it. First, here are the general creds use-cases
* AWS SSO works great for humans
* Roles work fine inside AWS
* Federation works fine from other clouds
* Raspberry Pi in your closet
1/4Aidan W Steele (@__steele) November 5, 2021
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.
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.
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.
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.
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.
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.
Ermetic can also help you find forgotten roles, allowing third-party access that haven’t been used in a significant time.
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
Good news:
Log4j is the only library that has been trivially vulnerable for more than a decade.haroon meer (@haroonmeer) December 20, 2021
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/