Log4j and Spring4Shell Scanning
How does Panoptica's Log4j and Spring4Shell scanning work?
Panoptica Log4j Scanning
The Log4j scanning capability on Panoptica's platform is built on two different engines detecting the pre-exploitation and post-exploitation phases.
Pre-Exploitation Phase (CVE Scanning):
The first part is where we scan the vulnerable applications installed or stored on the current workloads in the cloud infrastructure.
The scanning engine finds all .jar, .war, .ear, .aar, .rar, .nar files recursively.
It also looks at the META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties entry from the JAR file and then compares it to the vulnerable versions.
The supported list of CVEs is:
Spring4Shell
- CVE-2022-22965 and CVE-2022-22963
Log4j v2
- CVE-2021-44228 (JndiLookup)
- CVE-2021-45046 (JndiLookup)
- CVE-2021-44832 (JDBCAppender)
- CVE-2021-45105 (DoS)
- CVE-2017-5645 (SocketServer)
- CVE-2020-9488 (SMTPAppender)
Log4j v1
- CVE-2021-4104 (JMSAppender)
- CVE-2019-17571 (SocketServer)
- CVE-2020-9488 (SMTPAppender)
- CVE-2022-23302 (JMSSink)
- CVE-2022-23305 (JDBCAppender)
- CVE-2022-23307 (chainsaw package)
Logback
- CVE-2021-42550
Post-Exploitation Phase (Log Scanning):
The second engine scans for successful exploitation against running workloads based on matching YARA rules against log files in the OS.
The YARA rules are written based on testing the public exploits on sandboxed machines.
Once successful exploitation is detected based on the YARA rules matching, a new security finding will be displayed in the platform as a new Malware indication.
Updated about 1 year ago