Scribd Logo
Upload

Welcome to Scribd!

  • 44 views

    4 Step Mitigation For Log4j Attacks

    Uploaded by

    karthikp86
    The document outlines 4 steps for immediate mitigation of Log4j attacks: 1) Secure public-facing critical assets first, 2) Validate network security controls, 3) Utilize network security controls like WAFs and IPSs, and 4) Keep assets up-to-date while continuing to simulate attacks and harden perimeter security. It notes that fully discovering all vulnerable assets is challenging due to Log4j's widespread use and provides examples of how the Picus platform can help with attack simulation, testing security controls, and ongoing validation.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    4 Step Mitigation For Log4j Attacks

    Uploaded by

    karthikp86
    44 views3 pages
    The document outlines 4 steps for immediate mitigation of Log4j attacks: 1) Secure public-facing critical assets first, 2) Validate network security controls, 3) Utilize network security controls like WAFs and IPSs, and 4) Keep assets up-to-date while continuing to simulate attacks and harden perimeter security. It notes that fully discovering all vulnerable assets is challenging due to Log4j's widespread use and provides examples of how the Picus platform can help with attack simulation, testing security controls, and ongoing validation.

    Original Description:

    Log4j

    Original Title

    4 Step Mitigation for Log4j Attacks

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document outlines 4 steps for immediate mitigation of Log4j attacks: 1) Secure public-facing critical assets first, 2) Validate network security controls, 3) Utilize network security controls like WAFs and IPSs, and 4) Keep assets up-to-date while continuing to simulate attacks and harden perimeter security. It notes that fully discovering all vulnerable assets is challenging due to Log4j's widespread use and provides examples of how the Picus platform can help with attack simulation, testing security controls, and ongoing validation.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    44 views3 pages

    4 Step Mitigation For Log4j Attacks

    Uploaded by

    karthikp86
    The document outlines 4 steps for immediate mitigation of Log4j attacks: 1) Secure public-facing critical assets first, 2) Validate network security controls, 3) Utilize network security controls like WAFs and IPSs, and 4) Keep assets up-to-date while continuing to simulate attacks and harden perimeter security. It notes that fully discovering all vulnerable assets is challenging due to Log4j's widespread use and provides examples of how the Picus platform can help with attack simulation, testing security controls, and ongoing validation.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 3

    4 Step Immediate Mitigation for

    Log4j Attacks (Log4Shell)


    Even though a patch for CVE-2021-44228 was released on December 10th, 2021, another
    vulnerability (CVE-2021-45046) was found on December 14th, 2021. It seems that we will
    be talking about Log4j for weeks, maybe months to come.
    Picus updated Picus Threat Library and gave detailed explanations on how to
    simulate Log4Shell attacks and mitigate those attacks in our previous blog posts.

    In this article, we explain 4-step immediate mitigation for Log4j attacks.

    Why Is the Remediation of Log4j Vulnerability Challenging?


    In most cases, when there is a vulnerability in a product, it is easy to detect whether we have
    a vulnerable version of this product in our environment or not. We can check product
    banners, names, paths, and file hashes to find vulnerable product versions. For example, you
    can quickly check your systems for Sunburst vulnerability in Solarwinds by just checking the
    product version displayed in the footer of the Orion Web Console login page.

    However, it is challenging to check your environment for a vulnerable Log4j version because
    of the following reasons:

    ● It is a library widely used in many software and applications. Some products utilize the
    Log4j library externally, but some standalone Java applications use it embedded in
    their executables. It is tough to detect a Log4j library embedded in a standalone
    executable.

    ● The Java Runtime Environment (JRE) may also be embedded in this standalone
    application. In other words, the absence of a JRE installation on a system does not
    mean that Log4j cannot be exploited on this system.

    ● Although externally used Log4j libraries are easier to detect than embedded ones,
    there is another difficulty. Since it is open-source software, anyone may modify and
    compile it. So, the effectiveness of hash lists is limited.

    ● If a transitive dependency to Log4j exists in your applications, which means that


    although an application you are using does not directly use Log4j, another library that
    the application depends on may be able to use Log4j.

    Briefly, it is very challenging to discover 100% of vulnerable assets. As with the ShellShock
    vulnerability, you may encounter applications with the Log4j vulnerability after months.
    Moreover, many public exploits are available, and research for different methods to exploit
    the vulnerability is still underway. Incident response and threat hunting are also challenging
    since the JNDI string is not actually logged if the exploitation is successful.

    1
    What are the Immediate Mitigation Measures?
    While mid and long term operations continue to discover vulnerable assets, respond to
    potential incidents, and hunt for retroactive threats, you must take the following immediate
    measures to limit the attack surface:

    1- Secure Public-Facing Critical Assets First


    Since detecting all vulnerable assets in the network is hard, it is best to start with
    public-facing critical assets to limit the attack surface. Note that the effectiveness of
    black-box external scanning is very limited for the Log4j vulnerabilities. This type of scan
    focuses on finding vulnerable services according to banners of web server applications,
    such as Apache Tomcat. However, the attack surface is larger than the applications focused
    on external scans. Log4j rabbit hole runs deep, where finding vulnerable assets is
    challenging for even white-box internal scans; relying only on external scans creates a false
    sense of security.

    2- Validate Network Security Controls


    You should simulate attacks to understand whether your security devices are preventing
    these attacks or not. To measure the actual effectiveness of your security products against
    Log4j vulnerability exploitation attacks, you should test all valid variants of Log4j exploits,
    including evasive payloads. You should also test JNDI-related naming services other than
    LDAP, such as DNS, RMI, NDS, NIS, and CORBA. However, generating all applicable
    payloads, setting up a test environment, and testing your security controls against all these
    payloads is also a time-consuming process.

    How Does Picus Help?

    Picus platform automatically simulates 48 known variants of Log4j exploits


    within minutes without causing single damage to your environment and
    assesses your security posture. Picus Labs’ experts continuously research
    new variants and add them to the platform.

    2
    3- Utilize Your Network Security Controls
    Remote code execution (RCE) attempts to exploit the Log4j vulnerability can be blocked by
    web application firewalls (WAF) and intrusion prevention systems (IPS) by inspecting ingress
    network traffic. For egress JNDI traffic from the vulnerable system to the attacker’s system,
    firewall rules should be set in place to block attacks.

    How Does Picus Help?

    Picus platform provides prevention signatures of WAF, IPS, and NGFW


    vendors, such as F5, Citrix, ModSecurity, Cisco, Palo Alto, Fortinet, Check
    Point, Forcepoint, McAfee, Trend Micro, and Snort.
    See our previous blog post.

    4- Keep Your Assets Up-to-date but Continue to Simulate Attacks and Harden
    Your Perimeter Security
    Apache released a patch for CVE-2021-44228. However, it was incomplete, and
    CVE-2021-45046 was discovered, and a new patch was released. There might be more
    patches on the way, and it is crucial to follow vendor updates. In addition, you should run
    attack simulations, identify the gaps in your security controls and fix these gaps as a
    continuous effort.

    How Does Picus Help?

    Picus helps you to:

    ● Simulate Log4j vulnerability exploit (a.k.a. Log4Shell) attacks


    ● Test your WAF, IPS, and NGFW against Log4j attacks and
    uncover gaps
    ● Enable prevention signatures to fix gaps and block Log4j attacks
    ● Secure your network against Log4j attacks
    ● Continuously validate your security controls and Log4j resilience.

    Click here for a free demo of Picus Platform and


    be resilient for Log4j attacks!

    BOOK A DEMO

    You might also like