Skip to content

SHARK and the Log4Shell vulnerability#

Updated: 2021.12.20

The Log4Shell injection vulnerability (CVE-2021-44228) related to the use of the widespread
Log4J2 logging library has over the last week been massively reported and described.

Basically, the vulnerability allows an attacker to execute arbitrary/malicious code external
to applications using the Log4J2 logging library.

In the links below the vulnerability is described in greater detail.

Cloud Installations#

SHARK versions with build number 2267 -> 2433 includes the Log4J code with this vulnerability. If your installation is older or newer than this, there are no problems. You can find the build number from either the PC Client using the menu Help -> About or from the PDA client by selecting the INFO button.

The Log4J code are used for the PDA Application at the server side and for the SHARK PC client. It is important to understand, that to exploit this vulnerability, the perpetrator needs access to the application itself.
Either to the SHARK Java client or to the Gator web application.

Installations using the sharkwms.com servers, have already been fixed at the Logiware server side and after a restart of the SHARK PC client, updated code for the client, will be downloaded automatically with a fix.

Installations using sharkwmw.eu servers, will require a transfer to the sharkwms.com servers or will be fixed one-by-one. This will be done during the next days.

On-premise Installations#

Which versions of SHARKS are affected?#

The vulnerability is related to Log4J 2.0 <= version < 2.16.0.

All SHARK versions prior to build 2267 which was available on the 26th of August 2020
are NOT affected.

SHARK versiona prior to build 2267 used Log4J version 1.
The great majority used 1.2.17 but some also 1.2.16.
There are currently no indications of Log4J version 1 is affected by this vulnerability
but as Log4J version 1 went out of service in 2015 there might of course be other
issues to this version.

SHARK from build 2267 and until build 2231 uses Log4J version 2.13.3 which is affected.
SHARK build 2232 & 2233 uses Log4J version 2.15.0 which until yesterday (2021-12-14)
was reported ok.

We have provided a new build using Log4J version 2.17.0.
The vulnerability affects both the SHARK client itself and the server related services
including the Gator web client. It is not possible, just to replace the Log4J jar files, with new version. It requires a complete update.

How is SHARK affected?#

To understand how SHARK is affected, it is important to understand, that to exploit
this vulnerability, the perpetrator needs access to the application itself.
Either to the SHARK Java client or to the Gator web application.

As soon as SHARK is running on premise it is a mitigating aspect while consequently
the perpetrator must have access to the customer network in general in order
to access SHARK. If this is the case the perpetrator is already in the network and
can basically do whatever he wants and he most likely will not go for SHARK to fulfill
his malicious purpose.

Should the perpetrator choose to use SHARK as his target, he would have to enter
a malicious string, as described in the links below, in a text field being logged by Log4J.
This is certainly not all text fields in SHARK, but on the other hand there are some.

What can be done?#

It is strongly recommended that everyone interested in this issue to read the links below.

  1. Set an environment variable to disable the so-called message lookups
    set LOG4J_FORMAT_MSG_NO_LOOKUPS=true

This must be done on all clients and servers. Services must be restarted and clients also. Be sure that the environment variable is set for the system, and not only for the user.

  1. Patch the log4j-core-2.13.3.jar file according to the description in the links below. A patched version of the file can also be downloaded from here. The file is typically found in %ProgramPath%\shark\lib and %ProgramPath%\SHARK\webapps\shark_inst\install\lib. Once the patched file is in place the following must be done: All SHARK services must be restarted.

  2. In the folder %ProgramPath%\shark\webapps\shark_inst\install the batch file update_files.cfg.cmd must be executed. This will update the relevant hash values in file_cfg.yml file which in turn will force the clients to update and download the patched file from the server.

  3. Lastly the possibility of limiting outbound traffic in the firewalls for JNDI and RMI traffic can be considered, but this is outside the realm of this article and should be handled by customer IT services.

If you need help with this, you can contact LogiWare.

References#

Log4Shell explained – how it works, why you need to know, and how to fix it
Log4Shell / Apache Log4j Injection Vulnerability CVE-2021-44228: Impact and Response
Apache Log4j Security Vulnerabilities