Vulnerability Scan: Log4j CVE-2021-44228 - superseded
Log In or Register to download the BES file, and more.

1 Votes

Versioning - This is an older version.

1Vulnerability Scan: Log4j CVE-2021-4422812/10/2021 9:53:10 AM
2Vulnerability Scan: Log4j CVE-2021-4422812/10/2021 5:08:44 PM
3Vulnerability Scan: Log4j CVE-2021-4422812/13/2021 7:45:21 AM
4DEPRECATED - Vulnerability Scan: Log4j CVE-2021-4422812/14/2021 9:37:36 AM

Description

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to &#8220;true&#8221; or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

This Task will scan local filesystems for file names matching Log4j JAR files and save the results to {pathname of storage folder of client}\BPS-Scans\CVE-2021-44228.txt

Those results will be parsed by an Analysis to flag whether the vulernable versions, i.e. earlier than 2.15.0, appear to be present.

 Update 12/13/2021: Better handling for AIX, Solaris, and MacOS scans, thanks to @Mario and Zane Sanderson


Property Details

ID26893
StatusAlpha - Code that was just developed
TitleVulnerability Scan: Log4j CVE-2021-44228
DomainBESC
SourceInternal
Source Release Date12/14/2020 12:00:00 AM
KeywordsCVE, CVE-2021-44228, Log4j, vulnerability, scan
Is TaskTrue
Added by on 12/13/2021 7:45:21 AM
Last Modified by on 12/13/2021 7:45:21 AM
Counters 4549 Views / 199 Downloads
User Rating 1 star 2 star 3 star 4 star 5 star * Average over 0 ratings. ** Log In or Register to add your rating.

Relevance

Used in 29 fixlets and 15 analyses   * Results in a true/false
Show indented relevance
if exists property "in proxy agent context" then not in proxy agent context else true

Actions

Action 1 (default)

Action Link Click here to deploy this action.
Script Type BigFix Action Script
// Log4j search pattern
parameter "FilePattern"="log4j-core*.jar"

// BES Client Folder Determination
if {name of operating system as lowercase starts with "win"}
parameter "BPSFolder" = "{pathname of parent folder of client}\BPS-Scans\"
else
    parameter "BPSFolder" = "{(if (version of client >= "9" as version) then (pathname of parent folder of data folder of client) else (pathname of parent folder of parent folder of client folder of site "actionsite"))}/BPS-Scans/"
endif

if {not exists folder (parameter "BPSFolder")}
folder create "{parameter "BPSFolder"}"
endif

parameter "ListFile"="{parameter "BPSFolder"}CVE-2021-44228.txt"

// Housekeeping, clear any previous scan output
delete __createfile
delete "{parameter "ListFile"}"

if {windows of operating system}
    createfile until EOF_EOF_EOF
{concatenation "%0d%0a" of ("dir /s /b " & it & "\" & parameter "FilePattern" & " >> %22" & (parameter "ListFile") & "%22 2>NUL") of names of drives whose (type of it = "DRIVE_FIXED")}
echo SCAN_COMPLETE >> "{parameter "ListFile"}"
EOF_EOF_EOF

    delete run_scan.cmd
    move __createfile run_scan.cmd
    
    action uses wow64 redirection false
//the scan will continue to run in the background
    runhidden cmd.exe /c run_scan.cmd

elseif {mac of operating system}
    createfile until EOF_EOF_EOF
#!/bin/sh
find / -not -fstype nfs -name {parameter "FilePattern"} > "{parameter "ListFile"}"
echo SCAN_COMPLETE >> "{parameter "ListFile"}"
EOF_EOF_EOF

    delete run_scan.sh
    move __createfile run_scan.sh
    wait chmod +x ./run_scan.sh
    
// Clear any previous scan output
    delete "{parameter "ListFile" of action}"
    
    run /bin/sh -c ./run_scan.sh

elseif {name of operating system starts with "AIX" OR name of operating system starts with "SunOS"}
    createfile until EOF_EOF_EOF
#!/bin/sh
find / ! -fstype nfs -name "{parameter "FilePattern"}" > "{parameter "ListFile"}"
echo SCAN_COMPLETE >> "{parameter "ListFile"}"
EOF_EOF_EOF

    delete run_scan.sh
    move __createfile run_scan.sh
    wait chmod +x ./run_scan.sh
    run /bin/sh -c ./run_scan.sh

// All other Linux flavors
else
    createfile until EOF_EOF_EOF
#!/bin/sh
find / -not -fstype nfs -name {parameter "FilePattern"} > "{parameter "ListFile"}"
echo SCAN_COMPLETE >> "{parameter "ListFile"}"
EOF_EOF_EOF

    delete run_scan.sh
    move __createfile run_scan.sh
    wait chmod +x ./run_scan.sh
    run /bin/sh -c ./run_scan.sh

endif
Success Criteria

This action will be considered successful when the applicability relevance evaluates to false.

Action 2

Action Link Click here to review this task in the bigfix.me Content Database.
Script Type URL
https://bigfix.me/cdb/fixlet/26728
    

Sharing

Social Media:
Share this page on Yammer

Comments

Log In or Register to leave comments!
jgstew -
there is an improved scan based upon Logpresso scan utility to look for Log4j that will find many more instances because it scans within JAR files, but it also should not follow symlinks and do a better job of avoiding network shares. That said, you should still be careful when deploying it to systems with known network shares before deploying it widely.
aspisak -
Couple of things here - #1 - This SCAN script for Linux and AIX does NOT Exclude automounted of NFS mounted file systems. Not sure why as it looks correct, but within our systems, it is including content matches for automounted file systems. #2 - While the JAR file is normally called log4j-core, it could be used within any jar,ear, or war file. A better more thorough solution would be to find any of these types of files (jar, ear, war), look into them using unzip and if you find a file named JndiLookup.class then determine the version. The jar files could be easily renamed by developers as they wish.
sirmaroc -
Replying to matt10b25, this fixlet does not need to be modified, all you have to do is modify the analysis by changing the 2.15.0 to 2.16.0
matt10b25 -
This link https://www.zdnet.com/article/second-log4j-vulnerability-found-apache-log4j-2-16-0-released/ confirms that you need version 2.16 to be secure and that 2.15 is still vulnerable. please could you update the Fixlet to reflect this latest information
bigfixusermatthew -
dwilson, I don't think the API component is vulnerable from what I understand, only the core. Also, the data I can find so far indicates only 2.x is vulnerable. Core files can exist inside other JAR files though. Some vendors are recommending searching log4j*.jar and peeking at the manifest in any JARs. So far that has only netted me 1.x files.
dwilson -
This KB is for remediation for BF apps. https://support.hcltechsw.com/csm/en?id=kb_article&sysparm_article=KB0095486
myee17 -
Anyone have a remediation fix for when vulnerabilities are found?
dwilson -
Does this fixlet only find Log4j-core files? Doesn't seem to identify Log4j-api files.
srimurthy82 -
I have tested this in our Environment, seems to be an awesome Task. Got the required Results, Thank you so much !
bigfixusermatthew -
Thanks for the help Jason
JasonWalker -
Updated the scan to include log4j-core.jar files that do not specify version as part of the filename.