12/10/2021: Apache Log4j 2 Remote Code Execution Vulnerability

Comments

21 comments

  • Avatar
    Kirsten Flores

    On December 11, 2021. Alert Logic released scan coverage to identify this vulnerability in protected assets. 

    0
    Comment actions Permalink
  • Avatar
    Steven Damiani

    please let me know if the scan against protect assets should use the cve-2021-44228 and or a different search criteria, thank you

    0
    Comment actions Permalink
  • Avatar
    Anwar Hayath

    How to confirm if the detection is made available on our appliance. Is there a way to force update the detection/signature on appliances, to ensure it uses the latest detection. Dont want to run scan and later to find out appliance was missing this detection. 

    0
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Hi Steven Damiani - If a scan finds that one of your protected assets is vulnerable to CVE-2021-44228, a new exposure will be listed on the Exposures page in the Alert Logic console. You can search on the Exposures page by the CVE to see if you are vulnerable. 

    1
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Hi Anwar Hayath - The detection was pushed to appliances on Friday at midnight, so your appliance should already have it. 

    1
    Comment actions Permalink
  • Avatar
    Otto Aulicino

    Is it possible to know what is the signature checking for, specifically for the vulnerability scanning?

    0
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Hi Otto Aulicino - An authenticaed scan (a scan with credentials) will check for the version of Apache log4j. An exposure will be raised if the version of Apache log4j is between 2.0-beta 9 and 2.14.1.

    0
    Comment actions Permalink
  • Avatar
    Jason Lebaron

    Kirsten Flores, is it looking within the various JAR files for that version, or just specific files?  Or logs?  Thank you

    0
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Hi Jason Lebaron - The authenticated scan determines the version by logging into the host and running a command that lists all packages. 

    0
    Comment actions Permalink
  • Avatar
    Otto Aulicino

    Kristen, will the agent-based vulnerability scan also do the job, in the absence of a successful vulnerability scan?

    0
    Comment actions Permalink
  • Avatar
    Jason Lebaron

    Kirsten Flores, thank you.  In our testing it appears there are some shadows with detections.  It would appear to be more successful, it's going to need to look within the JAR files and/or their manifests to extract enough information for complete results.  Hopefully the scanning approach can continue to mature.

    0
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Otto Aulicino - We are still researching and testing our agent-based scanning capabilities in regards to this particular vulnerability. I will keep you posted here as I learn more. The recommendation for now is to run an authenticated internal scan for the most accurate detection. 

    1
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Jason Lebaron - Thank you for your feedback. I will definitely pass on your comments to our scan team. If you have any immediate concerns about your scans and detecting log4j versions, please let me know and I'd be happy to start a ticket for you for further investigation. 

    0
    Comment actions Permalink
  • Avatar
    David Shu

    To be frank having a software/library manifest (e.g. from Software Composite Analysis tools - Snyk etc) will be more useful in identifying vulnerable versions of log4j.  For most this is a 'challenge' to tackle with the Dev/DevOps folks rather than Infrastructure.... Then there is a massive log tail of packaged software updates and notifications from SaaS suppliers (who may be using log4j).  For those who haven't already seen this, it might be useful: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

    2
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Apache has updated their guidance for mitigating this vulnerability. It is now recommended to update to Apache Log4j 2.16.0. More details are available in Apache's security vulnerability documentation.

    Additionally, on December 13 and 14, Alert Logic released several specific IDS signatures to detect attacks targeted at exploiting this vulnerability. 

    0
    Comment actions Permalink
  • Avatar
    Paul Phan

    On December 14, 2021, Alert Logic released unauthenticated detection through PCI scanning.

    0
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Apache has updated their guidance for mitigating this vulnerability. It is now recommended to update to Apache Log4j 2.17.0 due to related additional vulnerabilities. More details are available in Apache's security vulnerability documentation.

    0
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    This article has been significantly updated to include information about additional, less critical CVEs discovered in Apache Log4j after the initial discovery of CVE-2021-44228. Additionally, more context has been added to the article about Alert Logic's detection capabilities through network IDS and web application firewall. 

    0
    Comment actions Permalink
  • Avatar
    Greg Platek

    So we have PCI scanning detection, but what about the standard scan schedules? Are these different?

    0
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Hi Greg Platek - You can schedule external, internal, PCI scans in the Alert Logic console, all within the Scan Schedules feature. If your standard scan schedules are internal scans, our scanning coverage will detect vulnerable versions of Apache Log4j for any in-scope assets as long as you have added credentials for the scan, making it an authenticated scan. If a vulnerable version is found, an exposure will be raised on the Exposures page in the Alert Logic console.

    0
    Comment actions Permalink
  • Avatar
    Kirsten Flores

    Greg Platek - Sorry, I think I only half answered your question. In addition to the authenticated scanning for internal scans, we also can detect vulnerable versions via unauthenticated (non-credentialed) PCI scans. 

    0
    Comment actions Permalink

Please sign in to leave a comment.