Learning from the unfolding Log4j emergency – the new stack

Charlotte freeman

Charlotte has been writing about technology and security for over 20 years. She is currently a senior security writer for the Synopsys Software Integrity Group.

The infosec world has been “everyone on the bridge” to manage the Log4j vulnerability in the ubiquitous world Log4j Java-based open source logging framework. This vulnerability, listed under CVE-2021-44228 last week, was posted with a score of 10 out of 10 in the Common Vulnerability Scoring System (CVSS), which is why it is being treated as an emergency.

The vulnerability takes advantage of a recently discovered flaw that makes certain versions of Log4j capable of executing arbitrary text through the LDAP directory lookup protocol, which does not require authentication. This means that the Log4j_2 vulnerability, also known as Log4jShell, allows attackers to run code remotely to deploy ransomware, remote access Trojans, and web shells on vulnerable systems.

Since the vulnerability was first reported last week, more than 1.8 million attacks have been launched. Telemetry reports from security companies show that attackers, including state actors, have already targeted half of all global corporate networks using at least 70 distinct malware families. Lively discussions take place on Twitter, in forums and in group discussions around the world, helping to generate continued interest in vulnerability. These discussions are also stimulating research on how to alleviate not only this problem, but future problems like this as well.

There are DevSecOps and AppSec protocols that can help you protect your organization from this ongoing Log4j_2 crisis and the like. Here are six mitigation steps you should take to create more robust Defense-in-Depth and AppSec protocols to protect your organization against these threats.

  1. Vulnerability notification. You can’t fix a vulnerability that you don’t know, so implementing automated alerting systems can minimize the time between discovery of the vulnerability and the spread of information to your teams. This will help you maximize your ability to respond and identify applications that are using the problematic component. Using a robust software composition analysis (SCA) solution like Black duck, which sends real-time alerts directly to developers or product owners based on the elements of their software Nomenclature (SBOM), will streamline your ability to recover.
  2. Susceptibility to operation: validation of inputs and outputs. Successful exploitation of the Log4j_2 vulnerability means that you ignored multiple secure coding principles. Data from untrusted sources (that is, user-controlled entries) should generally not be concatenated into log files without cleaning. This is especially true when the data comes from an unauthenticated origin, be it human users or other applications. Data flowing through sensitive areas such as databases and logs that can be returned to others must be subject to output validation. Failure to do so is a log injection vulnerability in itself, which has been known for a long time and classified as CWE 117, in addition to being described in the Java CERT Encoding Rules. Your first line of defense is to make sure that your apps are free from these types of vulnerabilities.
  3. Network architecture and network-level access controls. Successful exploitation of the Log4j_2 vulnerability requires that an attacker can transfer a payload to or exfiltrate data from an external system. This can include transferring code to run a shell or to launch cryptomining malware. The initiation of communication with external hosts should always be kept to a minimum. Guidelines of the Center for Internet Security (CIS) cover this, as many other control frameworks do, including MITER ATT & CK, which has a whole category of mitigations in M1037 covering network filtering. For client-side applications, the use of sandbox technology, even if only the integrated operating system and JVM functionality, could further reduce the range of operating paths available.
  4. Application architectural risk. Defensive programming techniques, deployed appropriately, can help you avoid the worst-case scenario in which unauthenticated external users gain access to elements of the application that must be exposed for the application to function. A well-designed app should lock down server-side ingress filtering to limit the accepted data to only expected range types and values. Why must your login page allow the characters $ and {anyway? While it may be a good idea for free-text search fields to allow a wide range of characters, you should eliminate the spread of sensitive data such as log passwords throughout your architecture. Interactive analysis tools can help you visualize the flow of application data, including across application and microservice boundaries, so you can discover what data needs to go where, and make sure proper filtering exists.
  5. Logging, monitoring and anomaly detection. No, that’s not irony. Anomaly detection routines should detect when an application does something unusual, such as attempting to connect to an inappropriate host, launching processes, or accessing files with which it typically does not interact. There is a long list of layers of defensive and detection controls that can be configured as part of a sandbox environment to make real-world exploitation virtually impossible. Or, if an exploitation occurs, these checks can show what was viewed and help the violation investigation team determine the real impact on the business.
  6. Transparency of software components, supplier management and mature adoption of open source. One of the reasons the Log4j_2 vulnerability has been so critical is that it is a perfect example of the pervasive risk of software that we haven’t developed ourselves, including software that is embedded in the products we all use. days. That’s why you need to have an accurate SBOM – to streamline response and survey by identifying exactly where a component like Log4j is being used, and what products or vendors you engage with for remediation. Mature management of open source code is also a big part of this cyber fire. Like Tim Mackey, Senior Security Strategist at Synopsys Cybersecurity Research Center (CyRC), likes to say, “There is no such vendor as open source. In the case of Log4j, it appears that the library was still actively maintained and supported as part of a larger community initiative through the Apache Foundation. But many libraries are developed without the support of specific groups or even dedicated individuals, and then are abandoned or forgotten. Knowing where your open source components are coming from, including their level of community support, provides an indicator of where you might be vulnerable to this type of latent risk.

No one wants to gloss over the efforts of all the teams working around the clock right now to fix Log4j_2 vulnerabilities on the network, but it’s important to remember that the problem isn’t this particular hack. Every attack, of the infamous Bleeding heart to the recent disclosure Trojan horse source, is a learning opportunity for AppSec.

The first lessons of Log4j_2 indicate that security principles are essential to manage these high risk software supply chain security incidents. This incident is one in a long series of supply chain attacks, and the nature of the globally interconnected software supply chain means that vulnerable software components are likely to be a recurring threat for the foreseeable future. . For organizations to be successful, a range of security activities must be embedded in the culture of how IT systems are planned, built, and operated.

Characteristic image via Pexels.

Comments are closed.