SBN

Log4j 2 – Beyond Patching: What’s Next?

Learn more about Log4j vulnerabilities and how you can prevent this issue from ever happening in your AWS, Azure, and GCP environment

As many infosec practitioners are well aware by now, a critical vulnerability (CVE-2021- 44228) was disclosed late last week on 12/9/21 within the Apache Log4j 2 Java logging library. This vulnerability is classified as severe and allows for unauthenticated remote code execution (RCE.) Adding insult to injury, the level of skill required to exploit this vulnerability is very low. All one has to do is send a malicious code string payload to a vulnerable target and game over. From there, the attacker can load arbitrary code on a remote server, allowing them to take control of the vulnerable target workload. This is bad, to say the least.

The prevalence of this vulnerability is vast and spans millions of machines, VMs, containers, and workloads across the Internet. Given the stratospheric rise in cloud computing, this makes any cloud environment the perfect target with a potentially huge attack surface. 

Many vendors are rushing to provide detections for the vulnerability in order to expose vulnerable workloads for subsequent patching. This is necessary and should be a top priority for every organization at this moment. However, it should be a top priority for security and operations teams to take a proactive approach and start looking inside their cloud for additional risks and indicators of compromise. 

Since the Log4j 2 vulnerability was disclosed, Sonrai has been working to help customers not only identify the vulnerability and mitigate exploitation impact across their public cloud workloads in AWS, Azure, and GCP but also to continuously monitor for indicators of additional compromise.

While patching is an essential requirement to help mitigate this vulnerability on workloads, Sonrai is helping customers understand all possible impact scenarios across their cloud environments for full lateral movement visibility and subsequent remediation.  In most organizations, VMs are over permissioned and should an attacker gain access to a workload, anything that is run on that workload inherits the same permissions. A VM compromised due to the Log4j 2 vulnerability could easily become a significant foothold into your cloud and in the worst case, it could be the very thing that causes real damage. Sonrai provides visibility to identify over-privileged resources, which can have access to services, roles and data throughout the cloud provider’s platform. Then, Sonrai helps to not only get to but maintain least privilege. This is something that a traditional vulnerability management tool is not going to have visibility into. Sonrai’s patented Effective Permissions engine is continuously connecting the dots for customers so they can see full end-to-end worst-case scenarios should a vulnerable system become compromised. In the example below, we see a VM in a Dev environment that through various paths has access to a sensitive data container in Production.

In addition to inventorying resources and their effective permissions, Sonrai is continuously monitoring them to create a security baseline. Should a deviation from that baseline occur, (e.g.a VM that has never attempted to read data suddenly takes that action) an alert is fired to notify incident response teams of the anomalous behavior. In response to the alert, intelligent workflows and automation can be configured to react quickly, contain the damage and reduce the risk to the rest of the environment. This is done at scale and thus can knock the legs out of an attack in ways that we could have only dreamed of in the past.

Beyond Log4j 2

We have released content that allows our customers to effectively manage the severity of risk across their workloads. They can quickly prioritize the highest risk workloads based on their ability to directly access data, self-escalate their privileges via assumed roles & service accounts as well as workloads themselves being excessively permissioned across the platform itself. These workloads need to be identified as top priority for any organization to target as the most critical for patching and remediation.

Sonrai’s Cloud Experts developed a number of new built-in alerts that include visibility across cloud providers into the following:

  • Presence of the Log4j 2 Vulnerability 
  • Privileged Hosts with the Log4j 2 Vulnerability 
  • Publicly Exposed Compute with the Log4j 2 Vulnerability 
  • Privileged Access and Public Compute with the Log4j 2 Vulnerability 
  • Administrative Access and Public Compute with the Log4j 2 Vulnerability 

Sonrai contains built-in alerts beyond Log4j 2 for any compute resources exposed to the Internet. Compute that’s over-privileged can permission-chain to assume roles and service accounts further escalating their privileges and access to sensitive data.

Essentially, you need to be thinking beyond the presence of vulnerable systems on the boundary of your environment and be proactively looking for risks at all levels. Simultaneously, you need continuous monitoring for deviations from your security baseline allowing you to respond quickly.

Ultimately, this vulnerability is shining a spotlight on our mission to help our customers identify overprivileged workloads, determine blast radius scenarios, and help remove those risks promptly.

Log4j 2 is not the first critical vulnerability to raise the awareness of this overall identity-based risk landscape, nor will it be the last. This situation just further exposes the criticality of having a lack of visibility into the identities in your cloud and what their permissions allow them to do.

Where the network once formed the security boundary, identity is the new perimeter from both a functionality and risk standpoint in the cloud. Sonrai is uniquely able to help customers understand, mitigate and govern identities and data in the cloud. With our help should something go bump in the night, it can be addressed at the speed and scale of the cloud.

The post Log4j 2 – Beyond Patching: What's Next? appeared first on Sonrai Security.

*** This is a Security Bloggers Network syndicated blog from Blog - Sonrai Security authored by Jeff Moncrief. Read the original post at: https://sonraisecurity.com/blog/log4j-risk/