Log4j FAQ

Frequently Asked Questions concerning the Log4j vulnerability

On Thursday, December 9th a serious vulnerability was discovered in the much-used Apache Log4j Java logging library (Log4j). Through this vulnerability, an unauthenticated, unauthorized RCE (Remote Code Execution) is made possible, which can be used to take over a server. A patch was quickly made available, but given the expanding complexities of this vulnerability, more needs to be done.

Am I affected by the CVE-2021-44832 vulnerability (published on Dec 28th) in Log4j version 2.17.0? How do I protect my environment?

• This is a medium vulnerability.This exploit can take place if the attacker has permission to modify the configuration file of Log4j or is in possession of the credentials to access the webapp or host. It would be necessary for the attacker to have permission to use and control the Mapped Diagnostic Context (MDC) tool to log key information from an internal project.The vulnerability can be solved by patching Log4j to the 2.17.1 version, and limiting JNDI data source names to the java protocol in Log4j versions 2.17.1, 2.12.4, and 2.3.2.A patch for this problem should be applied on all software that use Log4j when it becomes available, but it is not as urgent as the previous vulnerabilities.

How do I know what applications I still need to patch?

• Overview of vulnerable software (NCSC)
• Overview of vulnerable software (CISA

How can I find out ASAP which apps are vulnerable?

• CERT/CC scanning tool

What is a good approach to this vulnerability?

1. Patch!
2. For inbound access:
   1. Block attacks with an IOC address (scanning activity). The hard part is keeping the IOC list up to date;
   2. Use the IPS function to scan for the attack string in packets. There are many evasive techniques, they’re very dynamic; make sure to check the latest versions of NGFW vendors;
3. Use an endpoint solution EDR at the web server:
   1. Signature based
   2. Behavioral base
4. If you have a log server and a webserver in separate segments: make sure to do all checks also at the segment boundary (you will have to decrypt);
5. Use an EDR solution at the log server;
6. Block all outgoing traffic from the log server. If this is not possible, be as specific as possible and make sure to always block LDAP and RMI protocols;
7. Use IPS / anti-virus malware detection for inbound packets from rogue LDAP server;
8. Stop C2 connections: you can use all of the above (blocking, IPS).

• In short, the most effective approach is:
  • Patching
  • Making sure servers have no outgoing connections

In our own environment

• We have investigated our systems and services on the presence of this vulnerability.
• We patch our systems with the most recent version of relevant software updates as soon as they become available (only if we are affected by that patch, and/or no other mitigations are in place)
• We have investigated whether our systems are infected and exploited by this vulnerability. No Indicators of Compromise were found.
• We keep updating our systems with an updated list of Indicators of Compromise.
• We continuously monitor our systems to detect possible infection or exploitation.
• We continuously monitor statements and advisories from authorities (such as NCSC and CISA).
• We have implemented Zero Trust segmentation that will by design limit the impact if a vulnerability is exploited.

With regard to the vendors whose hardware and software we manage in our managed service contracts

• We continuously monitor for new releases of security patches from relevant vendors.
• We implement security patches and other mitigating measures when a (new) vulnerability is identified.
• We continuously monitor all policies in managed instruments against best practices and actively inform customers with advisories for optimal security

Our customers’ infrastructure

• As part of our Managed Security Services, we continuously monitor customer environments for the presence of this vulnerability and possible exploitation signs.
• We provide specific security updates and advisories to customers via phone, email and our portal.
• In addition to our general investigation and mitigations, we work together on demand with individual customers, taking into account the relevant management service contracts, parts of the customer infrastructure that are not actively managed by ON2IT and specific needs or requirements related to the Log4J vulnerability, including:
• • detection of vulnerable software
  • scanning tools and active network scanning
  • network monitoring and log analysis with advanced XDR tools for compromise attempts and post-exploitation behavior
  • implementation of policy validations advisories: IOC’s, inbound/outbound/ traffic rules, decryption, blocklists, most recent versions of IOC’’s
  • compliance and regulatory playbooks

Patch your systems and consider all other mitigation measures listed below:

Should I prioritize blocking inbound or outbound internet traffic?

• Outbound traffic should be restricted for potentially vulnerable systems offering services. The generic Zero Trust approach prescribes a strict, specific inbound access policy to be in place – and fundamental ON2IT standards have always enforced full detection and mitigation of high-severity vulnerabilities.

Should I block outbound traffic from my server networks in the firewall?

• Blocking all (unnecessary) outbound traffic will help, since the nature of the attack requires a connection with a malicious source. In opportunistic attacks this source will mostly be on the Internet. In the case of targeted attacks, this source could already be in the Network (Zero Trust will help here). ON2IT is helping its managed customers block all unnecessary outgoing (Internet) access as soon as possible.

Do customers need additional rules in their firewalls (blocklists, IOC, IPS signatures etc)?

• Additional rules can reduce the likelihood and impact of an attack. ON2IT does this for her managed customers and ensures a correct policy configuration.

Does an IP Blocklist work?

• Using an IP block list with known bad IPs will help, however IP addresses will change frequently, which means this IP blocklist also needs to be updated frequently. Be aware that you will only block known IPs and there will always be new or yet unknown IPs. For managed customers, ON2IT will maintain and configure this IP blocklist.

Another client has been blocking threat actor IPs as they popup, but isn’t that a whack-a-mole exercise?

• That is true, and whack-a-mole isn’t a sound mitigation strategy in the end. It may alleviate the strain though, especially in the first ramp-up phase of new classes of exploitations.

Will signatures in my endpoint protection solution help?

• Similar to IPS signatures on a firewall, signatures on the endpoint help with detection of known indicators. However, as with the firewall evasion, new threat techniques are constantly developed. ON2IT will make sure that its managed customers have up-to-date signatures installed.

My firewall has IPS signatures for LOG4J, is this sufficient?

• IPS signatures on firewalls will help, but traffic needs to be “readable” (decrypted) and new evasion techniques are constantly developed by threat actors, resulting in a cat and mouse game. ON2IT will make sure that its managed customers always run with an up-to-date IPS database.

Can I expect incognito Log4j activity (will I continue to have insight into all Log4j activity via our logs or might it show up as something else we are not focusing on)?

• New exploitations may always come to light, but at this point the wide spectrum of exploits against the Log4j/JDNI query vulnerabilities is detected in a way that matches the overall pattern, rather than a narrow set of specific instances.

Does removing a certain java file on my filesystem help?

• Yes, removing the JndiLookup.class will remove the exploit. However, this might break some functionalities or services that depend on this class.

I found an at-risk application environment with Log4j and turned off logging. Is that correct?

• Turning of logging is not a remediation, and furthermore leads to blindness, which is in itself undesirable and runs contrary to a healthy security process. As said above, removing the JNDI class from the Log4j library does count as “remediation”, but can cause the application to stop functioning at 100%.

What about DNS? How can I block malicious DNS requests that resulted from Log4J?

• Currently the initial attack won’t be using DNS, however in a second phase command and control traffic might. Blocking more advanced DNS queries requires specific products/licenses f.e. DNS Security by Palo Alto Networks. For the more basic queries, blocking bad domain names or newly registered domains is effective. ON2IT makes sure its managed customers have this policy in place.

Will blocking LDAP, LDAPs traffic and RMI help?

• Blocking outgoing traffic based on the known used protocols will help, however this needs to be done on application level (App-ID), since available examples already let you choose common ports (e.g 25, 443) for the (LDAP) traffic. ON2IT will implement blocking of known applications and protocols for its managed customers, after agreement of the customer.
• A better approach is to block all traffic and only explicitly allow required traffic.

Will special IOC’s in my SIEM software help?

• General SIEM software is limited in detection of undefined use cases (i.e., variants that need manual implement handling), but will not help with protection. These mitigations will provide some protection, but are no full solution. Due to the nature of this vulnerability, we expect these mitigations will be relatively easy to circumvent. The only real solution is to patch all systems as soon as possible. ON2IT is constantly updating its IOC for early detection with its managed customers.

Be sure that you have done the patching, and that this is not executed by the hackers to prevent others hackers from exploiting.

How do I know if someone has already hacked my system?

• To be sure, we advise you to proactively inspect your environment. Scanning tools are published and lists of vulnerable software are published by NCSC and CISA.

How to find out if we have been exploited?

• You need historical data from endpoint and network, Cortex XDR Pro combines both types of data in data lake, so you can do queries, i.e. for suspect LDAP activity prior to the patch. Behavioral threat detection helps, i.e. suspect privilege escalation that is not normal.

From compliance perspective, what can we do today?

• During mitigations of the Log4j vulnerability, we advise you to document all steps and actions to establish and audit trail. This will provide an overview of what is already done and what needs to happen.

To what extent can a Zero Trust approach reduce impact of such a vulnerability?

• Zero Trust drastically reduces the likelihood of an exploit, as well as the impact. We can not prevent the vulnerability itself, but by default we allow nothing, exceptions are only if there is a policy rule granting access and traffic inspection. Segmentation according to Zero Trust should reduce the potential impact or ‘blast radius’. In addition, there will be less or no lateral movement within the infrastructure.

This Tech Talk is dedicated to the recent Log4j vulnerability and is meant as a Q&A session for anyone who has questions about this high impact vulnerability.

This session is hosted by ON2IT Global CISO prof. Yuri Bobbert.

Sign up