Apache Log4j is a logging utility that is part of the Apache Logging Services. The nature of this logging service is that it accepts logged messages to contain format strings that can be referenced remotely thru Java Naming and Directory Interface (JNDI). Information can be obtained remotely via a variety of protocols, including the Lightweight Directory Access Protocol (LDAP), Remote Method Invocation (RMI), and Domain Name Service (DNS).
Does websites using cPanel are affected?
A basic cPanel service is not affected, some services have the Apache Solr on it since the Solr service cannot be accessed remotely. All big companies that utilize cPanel like GoDaddy, Bluehost, and Hostgator are not affected by this vulnerability.
Is Pantheon affected by log4j vulnerability?
No, Pantheon is not affected by the log4j vulnerability. Here’s the information from their status page:
Pantheon has verified that the platform is not vulnerable to the security issue related to the open-source Apache “Log4j2″ utility.
https://status.pantheon.io/incidents/w2p9bgp05j0j
Log4j is a Java-based logging utility found in a large number of software products.
The CVE-2021-44228 [1] vulnerability (aka the “Log4Shell” vulnerability) was disclosed by the Apache Log4j project. If exploited, this vulnerability could potentially allow a remote attacker to execute code on the server.
Once this vulnerability was publicly disclosed on the 9th December 2021, Pantheon began an audit of our infrastructure, as well as engaging with our software vendors, to determine potential impact. While our exposure to the vulnerability has been minimal, we have directly remediated components and verified that existing defense in depth measures prevent exploitation as researchers have published.
Is WPEngine affected by log4j vulnerability?
No, WPEngine does not utilize the log4j on their platform stack.
Is Platform.sh affected by log4j vulnerability?
No by default but if the site has custom Java code better contact the development team to review the code. Here’s their official statement:
A thorough investigation of our products and services has led us to believe our services are protected from the worst form of remote code execution. The threat of information disclosure is reduced because we aren’t sending application variables to these services. To further reduce that threat, these services are also receiving updates to disable the undesired behavior of Log4j. We’ve confirmed with our backend IaaS providers and with Fastly that they’ve either been unaffected or have mitigated any exposures.
If your project is running custom JAVA code in an app container, please immediately ask your developers to review your code for Lib4j2 usage and update it to the latest 2.15 branch.
https://status.platform.sh/incidents/k443m60v5txh
Other resources
Christophe Tafani-Dereeper demonstrates this vulnerability, on this GitHub repository https://github.com/christophetd/log4shell-vulnerable-app by means of a Docker container with the version of log4j that is vulnerable.
In a terminal run:
docker run --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-appUse this DNS logger tool dnslog.cn on your test payloads.
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}'
You can also use the site(dnslog.cn) to identify if your server is vulnerable.
Here are some guides on how to mitigate the vulnerability.