Background
The vulnerability, known as “Log4Shell” and assigned CVE-2021-44228 reference, is a remote code execution vulnerability in the popular Log4J Java framework, this is used widely in a number of popular applications and services ranging from consumer services such as Minecraft to various enterprise applications. A simple to craft request is able to execute code on a remote server, that then downloads and executes a payload stored elsewhere on the internet.
Product Vulnerability
A comprehensive list is available at https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 and another similar version at https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ however we will provide key information for SEP2 partners within this page.
Check Point
- Check Point have verified that their entire product set (both on-premise and cloud based) is not vulnerable to this exploit.
- Prior to receiving this notification, we had performed ourselves several internal tests that were unable to trigger the exploit under all tested scenarios.
Please see the below for Check Point’s own statement:
LogRhythm
- LogRhythm have now announced the suite of their products which are vulnerable – see https://community.logrhythm.com/t5/Product-Security/LogJ4-Remediation-Update-LogRhythm-SIEM-Software-On-Premise/td-p/494475
- In the main SIEM solution, the Data Indexer (DX) component which runs Elasticsearch is vulnerable, specific mitigation guidance is available – see https://community.logrhythm.com/t5/Product-Security/Data-Indexer-Mitigate-log4j2-vulnerability/td-p/494473
- For the LogRhythm NetMon product, there is a mitigation patch to run – see https://community.logrhythm.com/t5/NetMon-Discussions/Mitigate-log4j2-vulnerability/td-p/494148
Mitigation and Detection
Most cyber security vendors have now released some protection against this vulnerability. Check the IPS or Threat Protection configuration of your systems to ensure the new protection is enabled.
- Check Point have released an IPS Protection for this, which can be activated by following the below instructions (if auto-activation is not enabled):
- Once active, for any similar exploit attempts running over a clear text protocol, the Check Point gateway will prevent these. If you do not run HTTPS Inspection, any exploit attempts over TLS will not be seen by IPS to prevent.
- Check Point’s IPS protection hits specifically can be searched for by searching in SmartConsole > Logs and Monitor. In the search bar enter blade:IPS AND attack_info:”Apache Log4j Remote Code Execution (CVE-2021-44228)”, this will show you any detected exploit attempts.
- To help gauge any further impact, you will see the User Agent field in the log for the IPS prevent/detect, this shows the URL that an exploited host would have to connect back to:
If the host was vulnerable, you would see in the above example a connection back to dest:172.111.48.30 on port:1389.
- If you run a SIEM that consumes your Check Point logs, then this may be used to help collate/review for specific indicators of compromise. We have a list of known IOCs that we can release upon request and for any SIEM Wingman customers are currently running a review against these.
- Check Point have not advised on specific mitigations available on other elements of their product set (e.g. Harmony Endpoint) at this stage.
If you have a SIEM solution deployed and are ingesting log data from your network protection devices, then a correlation rule can be used to alert you if a vulnerable system has had a compromise attempt.
If you also ingest log data from WAF devices or reverse proxy devices, then a simple correlation rule searching for *jndi* (or %jndi% depending on your platform) will be a good start.
Related Guidance
- Not all vendors have released statements as to whether a specific product is affected, but based upon your public-facing assets we would recommend to further research your known applications/vendors for their responses, initially for any major software/technology you have exposed to the internet. As Log4J tends to be a dependency within a larger software stack, this is a particularly difficult one to define exposure for without an in-depth approach.
- You may wish to consider using an online testing tool against your public facing assets to check manually for exploitability of any public facing services that you host for Log4Shell. An example of a testing tool is https://log4shell.huntress.com/ – please note that we do not guarantee the effectiveness of these and please run them in consultation with any specific application owners.
- Ultimately, implementing restricted access to the internet from hosts would help mitigate an actor’s ability to create a control connection to their host in the event of you being vulnerable, so if you are restricting connectivity outbound from your DMZ/network in policy, then that is a general good practice that will help here.
SEP2 Exposure
As a business with an online presence and several service delivery platforms, we have reviewed our own exposure and through a combination of active mitigations, software inventory and active monitoring, we do not believe ourselves to be exposed at this stage. We have monitored several compromise attempts on our infrastructure that have failed. We are still awaiting responses from several of our own third parties and will provide further communication on this subject on request.
Related Links
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://www.ncsc.gov.uk/news/apache-log4j-vulnerability
https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j.yml
