Learning from the unfolding Log4j emergency – the new stack

0

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 deal with the Log4j vulnerability in the ubiquitous Log4j Java open source logging framework. This vulnerability, which was listed as 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 vulnerability 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 their software nomenclature (SBOM) elements, will streamline your recovery capacity.
  2. Susceptibility to operation: validation of inputs and outputs. Successful exploitation of the Log4j_2 vulnerability means that you have bypassed several safe 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, as described in the CERT Java 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. The Center for Internet Security (CIS) guidelines cover this, as do many other control frameworks 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 application should lock down server-side input filtering to limit 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 analytics 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 ensure that filtering appropriate 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 products that we all use. days. That’s why you need to have an accurate SBOM – to streamline response and investigation 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. As Tim Mackey, senior security strategist at the Synopsys Cybersecurity Research Center (CyRC), likes to say, “There is no such thing 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, from the infamous Heartbleed to the recently disclosed Trojan 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.


Source link

Share.

About Author

Comments are closed.