Editor’s note: In our first blog post for this series, we announced that Wiz was expanding its risk assessment capabilities to include OS and application configuration analysis. Our second blog post was a deep dive into custom OS configuration rules.
We recently launched host configuration rules, enabling customers to see OS and app-level configuration issues with the same easy-to-deploy and non-intrusive agentless approach that Wiz is known for. In this blog post, we are excited to launch new high-risk application misconfiguration rules that are now correlated on the Wiz Security Graph, helping you protect against Remote Code Execution (RCE) and information disclosure.
Imagine the following scenario: a publicly exposed virtual machine (VM) in your cloud environment is hosting a Redis server, which has been misconfigured to allow unauthenticated access from any IP address. How long do you think it will take for this VM to be infected by a botnet and abused for cryptojacking?
When it comes to OS and application security, organizations often focus most on remediating critical vulnerabilities with CVEs. However, there are some misconfigurations that might not be associated with any CVEs but can just as easily lead to RCE or information disclosure, making them just as severe as traditional vulnerabilities that require immediate attention. Unlike vulnerabilities, these types of misconfigurations can impact the latest version of an application, sometimes even when using default settings. Our data shows that about 20% of all organizations have at least one misconfigured application that can lead to either RCE or information disclosure.
Much like an RCE vulnerability, application and OS misconfigurations that can lead to RCE could allow an attacker to compromise publicly exposed machines in your environment and move laterally to sensitive systems, causing downtime, data leaks and more. Attackers are actively looking to exploit these types of misconfigurations to gain access to your environment – this can be observed in GreyNoise for example, by querying for malicious scanners searching for publicly exposed Hadoop YARN ResourceManager instances that have been misconfigured to allow unauthenticated command execution, including the recently discovered HinataBot botnet. Offensive security tools such as Metasploit include readily available modules for exploiting misconfigurations, such as this module for exploiting the aforementioned misconfiguration in Hadoop YARN.
Since real attackers are on the lookout for these types of misconfigurations, they represent a crucial security risk factor in the cloud and should not go unnoticed. However, it can be challenging for organizations to detect the misconfigured applications in their cloud environment using traditional solutions as they often lack full coverage and do not take context into consideration, making it harder to understand which misconfigurations are more critical than others.
Much like vulnerabilities, remediating misconfigurations effectively requires a full understanding of the network paths and required permissions for the application, which is why context is so important. For example, if we know that an application instance with an RCE misconfiguration is also exposed to the internet and has high privileges in the environment, then we need to address it with high priority, as it poses a critical risk to the organization.
Similarly, an application containing sensitive data hosted on an internal server could also pose a security risk if it has been misconfigured to not require any authentication. If an attacker has somehow already gained initial access to the environment through other means, they might be able to move laterally to this server and exploit the misconfiguration to get their hands on the sensitive data.
Quickly identify critical application misconfiguration risks
Wiz is extending its risk assessment to identify application misconfigurations that could lead to an RCE or info disclosure, giving you the context you need on the security graph to understand the full criticality of the misconfiguration so you can respond appropriately.
The new built-in application misconfiguration rules for RCE were developed by our threat research team based on information about real-world attacks in which these misconfigurations were exploited, such as misconfigured PostgreSQL containers infected with Kinsing cryptojacking malware. Besides the new critical RCE rules, we also added rules to identify high-severity application misconfigurations that can cause information disclosure such as a file tree that can be traversed by unauthenticated users.
With the new security graph correlation for host configuration rules, customers are empowered with context around these misconfigurations to identify toxic combinations and proactively resolve both RCE and information disclosure misconfigurations. Customers can also create remediation flows for the misconfigured application to make sure that the alerts can get to the right people on time, as well as automatically remediate the issue.
Introducing the new critical application misconfiguration rules
Here are some examples of our new critical application misconfigurations rules with details about how each application could be misconfigured to allow RCE or information disclosure, and our remediation guidance to prevent this scenario:
Ensure Hashicorp Consul does not allow arbitrary code execution
This rule identifies a Consul instance with -enable-script-checks set to true, which could allow an attacker to register a check on a remote agent with a malicious payload, thereby achieving RCE. We have previously observed this technique being utilized by the Dreambus botnet to gain initial access to cloud environments (T1190), propagate itself across an internal network, and hijack infected servers for cryptojacking (T1496) and to spread to other networks.
The appropriate remediation action is to set enable-script-checks to false, or replace enable-script-checks with -enable-local-script-checks
Ensure Jupyter Notebook does not allow remote unauthenticated access
This rule checks if a resource has a Jupyter Notebook with the following critical configuration combination:
Allows remote access from any IP address, through the
c.NotebookApp.ip =0.0.0.0or*definitionDoes not require authentication, through
c.NotebookApp.token = ''orc.NotebookApp.password = ''definitions
Together, these configuration states can result in RCE. The remediation guidance for this rule is to ensure c.NotebookApp.ip is set to localhost or a specific trusted IP range, and that the Jupyter Notebook is configured with a strong password or token.
Ensure Redis does not allow remote unauthenticated access
This rule checks for a Redis server with a bind directive that is set to 0.0.0.0 or *, enabling remote connection to Redis from any IP address, a requirepassword directive set to an empty password or an ACL user directive set to nopass, and also has the protected -mode no config that allows unauthorized access, together resulting in RCE (the impact of which depends on the permissions of the Redis process on the host). Such misconfigured Redis instances have been targeted for cryptojacking by the HeadCrab botnet, among others.
# Redis configuration file example.
#
protected-mode no
bind 0.0.0.0
user guest +@all ~* nopass The remediation action in this case is to either enable protected-mode, set a strong password or ensure the bind definition is set to a specific trusted IP range or localhost.
Identify toxic combinations on the security graph
Host configuration rule findings are now shown on the Wiz security graph, allowing you to understand the toxic combinations in your environment involving misconfigured applications that require immediate attention. This adds another important layer of context to our existing host configuration rules by allowing you to correlate misconfigurations with other risk factors in your environment and prioritize the most impactful misconfigurations.
In the example shown below, we can see a Consul instance that has been configured to allow remote access (as described above). As you can see on the graph this machine also has a path that exposes it to the internet, and a high privilege risk that could lead to lateral movement, all this combined results in a toxic combination that is a critical risk.
Get started now identifying the critical application misconfigurations that result in toxic combinations in your environment on the Wiz Security Graph. You can learn more in the Wiz docs (login required). If you prefer a live demo, we would love to connect with you.
