DEPRECATED - Vulnerability Scan: Log4j CVE-2021-44228
| 3 Votes |
Versioning - This is the latest version.
| 1 | Vulnerability Scan: Log4j CVE-2021-44228 | 12/10/2021 9:53:10 AM |
| 2 | Vulnerability Scan: Log4j CVE-2021-44228 | 12/10/2021 5:08:44 PM |
| 3 | Vulnerability Scan: Log4j CVE-2021-44228 | 12/13/2021 7:45:21 AM |
| 4 | DEPRECATED - Vulnerability Scan: Log4j CVE-2021-44228 | 12/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 “true” 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
| 26897 | |
| Alpha - Code that was just developed | |
| DEPRECATED - Vulnerability Scan: Log4j CVE-2021-44228 | |
| Internal | |
| 12/10/2021 12:00:00 AM | |
| CVE, CVE-2021-44228, Log4j, vulnerability, scan | |
| True | |
| JasonWalker on 12/14/2021 9:37:36 AM | |
| JasonWalker on 12/21/2021 11:22:37 AM | |
| 10632 Views / 396 Downloads | |
* Average over 4 ratings.
** Log In or Register to add your rating.
|
Relevance
Actions
Action 1 (default)
// 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
This action will be considered successful when the applicability relevance evaluates to false.
Action 2
https://bigfix.me/cdb/fixlet/26728
Sharing
| Social Media: |
Comments
 |
|
| 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. | |
 |
|
| 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. | |
 |
|
| 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 | |
 |
|
| 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 | |
 |
|
| 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. | |
 |
|
| This KB is for remediation for BF apps. https://support.hcltechsw.com/csm/en?id=kb_article&sysparm_article=KB0095486 | |
 |
|
| Anyone have a remediation fix for when vulnerabilities are found? | |
|
|
| Does this fixlet only find Log4j-core files? Doesn't seem to identify Log4j-api files. | |
