Security Vulnerability Reported: Apache Log4j

Nina_Makkonen — Fri, 25 Feb 2022 08:14:30 GMT

28 December 2021: The hotfixes for log4j are now available:

FP18: 7.0.18.5
FP17: 7.0.17.10
FP16: 7.0.16.123
FP15: 7.0.15.15

------------------------

Cloud:

21Q4 release: Log4j has been upgraded to a newer version, and actions recommended by the vendor are implemented.
22Q1 release: Log4j dependency has been removed from the product.

------------------------

22 December 2021: Important update! Based on the latest information, adjusting the nolookup attribute is not enough. For more information, see https://logging.apache.org/log4j/2.x/security.html#

In addition to the initial instructions below, you should remove the following class from use: "JndiLookup.class". This can be done with the example PowerShell script below. As always, we recommend validating these changes in the development environment first before moving them to production.

Copy the script to your Notepad, save as a .ps1 file and run it in PowerShell.

# start script
Add-Type -AssemblyName 'System.IO.Compression';

$vus = 'D:\SAP\ContactCenter\VU';

gci $vus -Filter 'log4j2.xml' -Recurse | ForEach {($_ | gc -Raw | ForEach { $_ -replace '%msg%n', '%m{nolookups}%n' }) | sc $_.FullName -Verbose}

Get-ChildItem $vus -Filter 'log4j-core-*.jar' -Recurse | ForEach {Remove-File-From-Zip $_.FullName 'JndiLookup.class'}

function Remove-File-From-Zip {
[CmdletBinding()]
param (
[Parameter(Mandatory)]
[string]$zipfile,
[Parameter(Mandatory)]
[string[]]$files
)

Write-Output 'Opening: '$_.FullName;
$stream = New-Object IO.FileStream($zipfile, [IO.FileMode]::Open)
$mode = [IO.Compression.ZipArchiveMode]::Update
$zip = New-Object IO.Compression.ZipArchive($stream, $mode)
$deleted = $false;

($zip.Entries | ? { $files -contains $_.Name }) | % {
Write-Output "Deleting file '$_' from '$zipfile'";
$_.Delete();
$deleted = $true;
}
if (-not $deleted) {
Write-Output 'Nothing found';
}

$zip.Dispose()
$stream.Close()
$stream.Dispose()
}
# end script

The output should look like this:

Opening: 
D:\SAP\ContactCenter\VU\VU_ECF_Agent\tomcat\webapps\ecfs\WEB-INF\lib\log4j-core-2.8.2.jar
Deleting file 'org/apache/logging/log4j/core/lookup/JndiLookup.class' from ' D:\SAP\ContactCenter\VU\VU_ECF_Agent\tomcat\webapps\ecfs\WEB-INF\lib\log4j-core-2.8.2.jar'

The recommendation is to do this as soon as possible. This also slightly affects hotfix plans:

FP18 plan not affected
Versions from FP15 to FP17 will receive the fix above
Versions FP14 or older no hotfix; carry out the steps in the instructions or update to a newer version Contact Pro

-----------------------------------------

Original post 13 December 2021:

For more information, see:
https://www.lunasec.io/docs/blog/log4j-zero-day/

https://www.randori.com/blog/cve-2021-44228/

Sinch development is working on this issue, and for now we recommend on-premise customers to do the following:

As a temporary and immediate solution, log writing for all internet facing Java components using Log4j should be disabled.
- To do this, change the EcfFrontEndServer logs in both ECF_Agent and ECF_Visitor side:
  LogLevel = never
  LogModule.LibIpc.Level = warning
For a solution which allows you to enable logging again:
- Ensure that the installed Java 8 version on application servers is 191 or higher.
- To fix the log4j2, follow the instruction in https://logging.apache.org/log4j/2.x/ for CVE-2021-44228. You can use the following PowerShell script to adjust the nolookups attribute and modify the path in front of the line to match the install directory but it does not have to point to the correct ECF folder:

gci 'D:\SAP\ContactCenter\VU' -Filter 'log4j2.xml' -Recurse | ForEach {($_ | gc -Raw | ForEach { $_ -replace '%msg%n', '%m{nolookups}%n' }) | sc $_.FullName -Verbose}

Sinch development is working on a permanent solution which is delivered as a hotfix.
- For installation on FP14 or older, we recommend upgrade to a newer release or to carry out the steps listed above. Note that the upgrade or hotfix installation will reverse the changes to nolookups. For more information, contact support.
- For installation from FP15 to FP17, we will deliver a hotfix to set the nolookups disabled.
- For installation on FP18, we will deliver hotfix where Log4j dependency has been removed from the product.

For the environments of the cloud customers, these actions are carried out by Sinch.

Re: Security Vulnerability Reported: Apache Log4j

Jukka — Wed, 22 Dec 2021 09:33:58 GMT

TIP: Signing to community allows you to subscribe into interested topic. For example in this one there is three dots button on top left corner and also and arrow down button. Under those you can find subscribe button. This way you ensure that you get latest updates.

Re: Security Vulnerability Reported: Apache Log4j

thomashoegl — Wed, 16 Mar 2022 10:29:39 GMT

Hello,

as s solution for this we have installed hotfix 7.0.16.123 and have activated logging again.

Our customer asked me now, how this issue was resolved in the end?

Has Log4j been upgraded to a newer version (like in 21Q4 cloud release) with 7.0.16.123, or has Log4j dependency removed completly (like 22Q1 cloud release)? If upgraded, to which version?

Thanks.

Re: Security Vulnerability Reported: Apache Log4j

Jukka — Wed, 16 Mar 2022 11:00:19 GMT

Hi Thomas,

Good that you asked and here is the answer shortly from onprem point of view:

FP18 dependency for log4j has been replaced in the hotfix with our own logging solution and we are no more using log4j in Contact Pro
Hotfixes for FP17 and older contains actions recommended by Apache in this document and logging is using log4j

In other words we recommend customers upgrading to latest release or minimum to apply hotfix to mitigate the problem.

//Jukka

topic Re: Security Vulnerability Reported: Apache Log4j in Contact Pro

Security Vulnerability Reported: Apache Log4j

Re: Security Vulnerability Reported: Apache Log4j

Re: Security Vulnerability Reported: Apache Log4j

Re: Security Vulnerability Reported: Apache Log4j