Log4j (https://logging.apache.org/log4j/2.x/index.html) is a Java logging framework that is part of the Apache Logging Services (https://logging.apache.org/). Log4j is also the most commonly used framework used by Java applications for logging. Log4Shell (CVE-2021-44228) is a remote code execution vulnerability in Log4j2 versions 2.14.1 and below originally disclosed by the Apache Foundation on December 6, 2021 (https://logging.apache.org/log4j/2.x/security.html).
The vulnerability uses the Java Naming and Directory Interface™ (JNDI) is an API which allows Java applications to lookup remote services in a resource-independent way. For example, JNDI can be used to perform an LDAP by connecting to an ldap server with a URI like “jndi:ldap://$ldaphost:$ldapport”. The vulnerability in Log4j comes into play when a malicious user can get Log4j to log a JNDI URI that points to a malicious LDAP (or some other JNDI resource) service hosting malicious code. When the malicious JNDI URI is logged on a system running a vulnerable version of Log4j, Java will attempt to connect to the malicious URI, download the payload, and execute it. All a malicious user needs to do to exploit this vulnerability is create a log and this can be done in a variety of ways depending on the application in question. For example, the most common method we have seen is by targeting Java web applications and including the malicious URI in the HTTP request or even the User-Agent. Log4Shell has also been exploited in applications such as Minecraft by sending a malicious URI via game chat. There have been claims from security researchers that they were able to trigger exploits in LinkedIn and Twitter by making posts that including malicious URIs (https://github.com/YfryTchsGD/Log4jAttackSurface).
This vulnerability has been patched in the latest version of Log4j (https://mail-archives.apache.org/mod_mbox/www-announce/202112.mbox/%3cD88D40C5-8884-470E-8FA3-3B6D6899A7B0@apache.org%3e); however, this isn’t the end of the story. The real impact of this vulnerability is that Log4j is used by thousands of different applications and services. So far, the most complete list of vendors we have found along with their current status regarding this vulnerability can be found at https://github.com/NCSC-NL/log4shell/tree/main/software. This list is maintained by a third party, so we cannot comment on how up to date it is, but they have been including source links for their updates.
Log4Shell was publicly disclosed more than a week ago, but it wasn’t until last Thursday that it really began getting attention after a proof-of-concept was publicly released. Since then, researchers and threat actors alike have been massively scanning for vulnerable services. Since Friday (3 days ago), we have observed over 56,000 individual hits from various sources. For the most part, the scans we have observed have been following a spray-and-pray tactic. Attackers are sending out payloads in mass without any attempts to verify what application they are targeting; they are simply including malicious URIs in every field possible and hoping something hits. The payloads we have directly observed so far have been attempts to install coin miners. This is similar behavior to what was observed when the ProxyLogon vulnerability was first disclosed (https://perchsecurity.com/perch-news/perch-bulletin-exchange-marauder-update/). Microsoft claims they have also observed Cobalt Strike payloads (https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/) and that there are some more targeted attacks taking place. We expect to see the mass scanning to continue for the next few weeks, but as time goes on, threat actors will began creating more advanced targeted attacks eventually leading to ransomware and other payloads.
The good news, as mentioned above, is that there is already a patch for this vulnerability, and if you are unable to patch your systems, there is also a workaround to mitigate this vulnarability. According to https://logging.apache.org/log4j/2.x/security.html:
Mitigation: In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Like many vendors, some ConnectWise products were affected by this vulnerability. Up to date information on ConnectWise products can be found at our Trust Center at https://www.connectwise.com/company/trust/advisories. All affected ConnectWise products have been mitigated and there is no evidence of any exploitation. Again, please refer to the Trust Center for the most current information regarding our products.
So, what can you do about all this? First, if you have any in-house Java applications either update Log4j immediately or deploy the suggested mitigation as listed above. Next, we recommend you perform a full audit of all the applications and services you use to determine which might be affected and need updated. Thankfully, our friends over at Huntress (https://www.huntress.com/) have put together a vulnerability tester that you can use to test your applications at https://honey.codacloud.net/. Tenable has also published a list of plugins that can be used with Nessus to scan for the vulnerability within your environment at https://community.tenable.com/s/article/Plugins-associated-with-CVE-2021-44228-Log4Shell.
The CRU also pushed out several new IDS signatures on Friday that will detect attempts to exploit Log4Shell and shared them freely on our Twitter account (https://twitter.com/ConnectWiseCRU). We have continued working on these over the weekend watching how attackers have modified their payloads to evade detection and today are releasing a single signature that will work with all known attack vectors for Log4Shell and will even work with the various evasion techniques attackers have deployed:
alert tcp any any -> $HOME_NET any (msg:"[ConnectWise CRU] Potential Log4j RCE (CVE-2021-44228)"; flow:established, to_server; content:"|24 7b|"; nocase; pcre:"/(\${(.?:|.?:.*?:-|env:.*|upper:|lower:)('|"|`)*(?1)}*|[jndi:(ldaps|rm|n|io|htt)]('|"|`)*}*){9,10}/Ri"; tag:session,5,packets; reference:url, logging.apache.org/log4j/2.x/security.html; classtype:web-application-activity; sid:900537; rev:4; metadata: created_at 2021_12_10, updated_at 2021_12_10, cve CVE_2021_44228, mitre_tactic_id TA0000, mitre_tactic_name Initial_Access, mitre_technique_id T1190, mitre_technique_name Exploit_Public_Facing_Application;)
This signature has been pushed out to all Perch sensors and has been detecting massive amount of scanning activity all weekend. We will continue to push out regular updates to the ConnectWise CRU (https://twitter.com/ConnectWiseCRU) Twitter account as we gather more information.
References
https://logging.apache.org/log4j/2.x/index.html
https://logging.apache.org/log4j/2.x/security.html
https://github.com/YfryTchsGD/Log4jAttackSurface
https://mail-archives.apache.org/mod_mbox/www-announce/202112.mbox/%3cD88D40C5-8884-470E-8FA3-3B6D6899A7B0@apache.org%3e
https://github.com/NCSC-NL/log4shell/tree/main/software
https://perchsecurity.com/perch-news/perch-bulletin-exchange-marauder-update/
https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
https://community.tenable.com/s/article/Plugins-associated-with-CVE-2021-44228-Log4Shell
https://honey.codacloud.net/
https://twitter.com/ConnectWiseCRU
