Already existing codes and codes created from scratch

Earlier, an author of software wrote each code from scratch for the software, but things have changed. Nowadays, it’s not an individual but teams that write codes for software. And the authors or teams use existing code with their written code to create software.

You can think of the codes as building blocks of software, and software is made up of codes created from scratch and codes that already exist. Once the teams have created their code, they bring both code types together to build software.

Using an already existing building block saves time for a team as they don’t have to write the code from scratch.

What is Log4j?

Log4j is an already existing code that has been pulled together with the codes created from scratch to create several popular software. Many organizations use it for a common but necessary task. Log4j tracks the activity in an application or online service; Log4j is a journal that records what happens in a system or application.

What’s the issue in Log4j?

A vulnerability was detected in Log4j, and since Log4j is used in most of the popular software, it immediately posed a threat to millions of users across the globe. If the vulnerability isn’t fixed, attackers can break into systems, pilfer data, plant malware in systems, steal passwords, etc.

The most worrisome aspect of the vulnerability is that it requires little to no expertise to exploit the vulnerability.

Who are vulnerable?

As Log4j is used in most of the software, any user using a device or software for their everyday online activity is vulnerable. As the article puts it, “ For individuals, Log4j is almost certainly part of the devices and services you use online every day.”

Another article states, “A new report by Checkpoint Research (CPR) now records a spike in attacks targeted at this vulnerability. The report mentions that CPR is observing over 100 hacks per minute related to LogJ4. With this, more than 40 percent of corporate networks in India have already had an attempted exploit. Around the world, about 2 lakh targeted attempts were made within twenty-four hours of the initial outbreak.”

What can you do?

Keep your software, web browser, and apps updated. Check for updates regularly over the next few weeks. This is the best you can do to stay cyber safe.

For organizations, it may be uncertain whether their browsers, web servers, web applications, network devices have Log4j. But you can take the following mitigating steps:

  • Install the latest updates immediately wherever Log4j is known to be used
  • Discover unknown instances of Log4j within your organisation
  • Deploy protective network monitoring/blocking

Also read,

Kind of Mitigation

Removing the JndiLookup class

The vulnerability in Log4j exists because Log4j uses a Java feature called JNDI(Java Naming and Directory Interface). JNDI allows the loading of additional Java objects while executing runtime; thereby, it can be used for loading such objects from remote naming services over several protocols.

The exploit in its original form used LDAP (Lightweight Directory Access Protocol), which is the most commonly used. However, others can also be used: DNS (Domain Name System), RMI (Remote Method Invocation), NDS (Novell Directory Services), NIS (Network Information Service), and CORBA (Common Object Request Broker Architecture).

One can fix the vulnerability by disabling the use of JNDI message lookups, and this method is used by Log4j 2.16.0. But this can also be done by wresting the entire JndiLookup class, which executes this operation, from an impacted Log4j package

Hot patching using a Java agent

Hot patching refers to applying a patch to a process while it’s being used without needing to restart it. Java can sustain the on-the-go alteration of byte-code that’s being used in a Java Virtual Machine (JVM) via API instrumentation and Java agents. A java agent is a JAR (Java Archive) file that can be connected to a JVM during operation.

Exploiting the flaw itself to temporarily prevent exploitation

It’s possible to wield the vulnerability on affected servers to alter the live system and application that will stop further exploitation. Cybereason, a security firm, developed such exploit prevention. The exploit prevention was further enhanced by Lunasec.

The above approach can be used for third-party vendor products, which haven’t received patches yet or end-of-the-life products that have become vulnerable because they aren’t going to receive official updates. Leveraging the vulnerability against itself can be a feasible option. However, the above fix comes with the following disclaimer

The fix is temporary because the changes applied to the exploit that executes the java process will be undone once the JVM restarts.

The method has been applied to various systems and configurations, but a possibility exists that it may fail on some and could crash the system. You can fix the crash by rebooting the server, but the method won’t be feasible to try on crucial systems.

Identifying vulnerable system

The first step is to identify applications and systems that could be susceptible to Log4j. Response strategy, mitigation strategy become secondary to the identification. Identification is difficult because each app can have Log4j independently and also could load it through third-party dependency.

Security community and CERTs keep many Log4Shell vendor advisories list, but it won’t be complete.

The security community has responded swiftly by coming up with open-source tools to automate the identification of vulnerable servers and apps that can have Log4j. Other vulnerability scanners and tools have modified their system to identify Log4j.

For more updates on Log4j, you can go to this website