How to prevent and protect your business against the Log4j Vulnerability, Cybersecurity in Africa

Log4j Vulnerability in Africa: How to prevent and protect your business against the Log4j Vulnerability, Cybersecurity in Africa. Log4Shell, an internet vulnerability that affects millions of computers, involves an obscure but nearly ubiquitous piece of software, Log4j.

Log4j or Log4Shell, a critical vulnerability in the widely used Apache Log4j Library, has raised alarms and security concerns across the tech and info security communities. How to protect digital security and privacy tips for business owners in 2022.

Since then a lot of work has been done to introduce several patches to secure different software. However, despite all these patches, there have been reports in different parts of the world of breaches arising from the vulnerability. 

What Is Log4j and how does do hackers exploit the flaw? Apache Log4j is a Java-based logging utility developed by the Apache Software Foundation. Several companies use the Log4j library worldwide to enable logging and configure a wide set of applications. The Log4j flaw allows hackers to run any code on vulnerable machines or hack into any application directly using the Log4j framework.

Actions to proctect your business and organizatio from the Log4j Vulnerability

Below are some of the basic steps African or Nigerian businesses can take to prevent and protect systems from the Log4j Vulnerability

1. CISA Log4j Vulnerability Fix

Federal agencies and security personnel across the globe are working on several mitigation measures to fix this flaw and identify any associated threat activity. How to Protect Healthcare Organization Networks From Hackers and Cyberattacks.

CISA has urged all organizations and security admins to upgrade their systems to log4j version 2.15.0 or apply their appropriate vendor-recommended mitigations immediately to prevent any risks. “To be clear, this vulnerability poses a severe risk. We will only minimize potential impacts through collaborative efforts between the government and the private sector. We urge all organizations to join us in this essential effort and take action,” CISA said.

CISA recommends asset owners take three immediate steps to mitigate the risks from this vulnerability, which include:

  • Enumerating any external-facing devices that have log4j installed
  • Ensuring your security operations center is actioning every single alert on the devices that fall into the category above
  • Installing a web application firewall (WAF) with rules that automatically update so your SOC can concentrate on fewer alerts

For more information, visit Apache Log4j Vulnerability Guidance.

2. Apache Log4j Vulnerability Fix

The Apache Log4j team has issued patches and suggested mitigation steps to address the Log4j security flaw. Ultimate Tips To Improve Cybersecurity and Information Security Standards In 2022.

  • Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
  • Log4j 2.x mitigation: Implement one of the mitigation techniques.
  • Java 8 (or later) users should upgrade to release 2.16.0.
  • Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
  • Otherwise, Apache recommends removing the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

3. Cisco Talos Log4j Vulnerability Fix

Cisco Talos in its advisory recommends disabling the JNDI feature.

“For the largest segment of users, JNDI represents an unnecessary risk, so we suggest disabling this feature so that this threat surface is unavailable. Therefore, we recommend upgrading to Log4j 2.16.0—the latest version—which disables JNDI by default,” said Talos.

Per the advisory, Log4j 2.16.0 is the most recent patch Apache has released. It fixes CVE-2021-44228 and CVE-2021-45046 by:

  • Disabling JNDI by default and limiting the default protocols to Java, LDAP, and LDAPS.
  • Requiring the log4j2.enableJndi system property to be set to “true” to allow JNDI.
  • Completely removing support for Message Lookups.
  • Customers are encouraged to examine their internal and third-party usage of Log4j for vulnerable configurations and take remediation actions.

“If you are uncertain or unable to determine if your implementation is vulnerable, patch aggressively. Given the risk of third-party appliances that include Log4j, we also recommend that customers and partners conduct routine vulnerability scanning and engage in conversations with vendors, partners, and suppliers for additional mitigation support.”

4. SOPHOS Log4j Vulnerability Fix

Sophos’ Naked Security revealed IPS rules, WAF rules, firewall rules, and web filtering could help by blocking malicious CVE-2021-44228 data from outside, and by preventing servers from connecting to unwanted or known bad sites. It recommends that users:

  • Patch systems right now. Don’t wait for everyone else to go first.
  • Use one of the mitigations if you can’t patch yet.
  • Be part of the solution, not part of the problem!

How to Check for Apache Log4J Vulnerability?

The first step should be to investigate if an attack has already happened. This can be done by searching the system logs for parts of the RCE payload. If a search for keywords such as “jndi”, “ldap”, “${::” returns any logs, it should be investigated further if it was an actual attack or just a fingerprinting by security researchers.

Many attacks were observed in the wild which did not deliver any malicious payload. Still, they were done by security researchers to get an idea of how many applications are vulnerable to this attack.

The next step is to identify all projects using the Log4J library. The project might be vulnerable if versions between 2.0-beta9 and 2.14.1 are used. Since it is tough to figure out where this vulnerability is present, it might be safer to assume the project is vulnerable, and patching the library is the best action to remove the risk from code execution.

If the used version is below 2.0-beta9, the project will not be vulnerable, but the Log4J library should still be updated because versions in the 1.x range are outdated and do not receive updates anymore.

In case a vulnerable project is found, it is recommended to check if any information logged with Log4J includes information that the user can manipulate. This information includes URLs, any request parameters, headers, or cookies. If one of these is being logged, the project is vulnerable.

This knowledge might help to dig deeper into the system logs and analyze if your web application was already targeted.

There are free tools available on the internet that can test if the web application is vulnerable. One of these tools is https://log4shell.huntress.com/ which is open source and can be found on GitHub https://github.com/huntresslabs/log4shell-tester.

If a vulnerable part of code was identified in the web application, one can use the payload provided by the mentioned tool and inject it into the web application. If the vulnerability was triggered, the testing tool would show the connections from your web application to their LDAP server.

Leave A Reply

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.

AllEscort