A few simple tips to help keep safe from Log4J attacks
It’s been almost two weeks since the vulnerability was brought to public attention, and despite endless updates and patches, it is still wreaking havoc
On December 9, 2021, a remote code execution (RCE) vulnerability in Apache Log4j was identified as being exploited in the wild. The first attacks seemed only to target Apache web servers, but following investigations showed that hundreds of high-profile products and open-source modules were also vulnerable, as the log4j module is not limited to webserver only but is virtually everywhere (For example, organizations might log failed login attempts with log4j, allowing to send the exploitation payload via a username field). On December 9, 2021, a remote code execution (RCE) vulnerability in Apache Log4j was identified as being exploited in the wild. The first attacks seemed only to target Apache web servers, but following investigations showed that hundreds of high-profile products and open-source modules were also vulnerable, as the log4j module is not limited to webserver only but is virtually everywhere (For example, organizations might log failed login attempts with log4j, allowing to send the exploitation payload via a username field).
Organizations that use log4j for custom logging their applications or security events, now face countless organization-specific exploitation vectors. Exploitation is very easy, allowing attackers to get full control of the attacked system with just one request.
Thus far, massive scanning activity for CVE-2021-44228 (i.e., log4j vulnerability) has begun. Similar to the COVID pandemic, it didn't take long before dangerous evading variants appeared that bypassed initial signature-based protection. The current situation is a continuous race against time for defenses to block new variants before significant damage is done.
As with other high-profile CVEs, we expect a surge of high-profile stealthy targeted attacks within several days. Experience shows that it takes no more than several hours to morph attacking payload in a way that will bypass WAF signatures. Additionally, we expect weaponization of the vulnerability for lateral movement.
Best practices to protect your web and API assets from log4J attacks
It is critical for organizations to quickly identify, review, and patch modules and products that are vulnerable to a new type of attack. The latest case of log4j illustrates this.
However, as attackers won't wait for patches, we present here the best practices for such cases.
Monitoring solutions such as IPS should be use to report on the existence of the threat while directing the patching process.
Signature-based patching should only be used during the first few days, since attackers will quickly move to weaponize the vulnerability for targeted attacks against organizations.
Active API protection solution should be deployed since it identifies and protects from attacks via API traffic and will be a critical component of the overall security architecture.
Expand your API monitoring to include internal APIs. Due to work-from-home practices, unnoticed APIs might still be exposed to the internet. Also, the log4j vulnerability is going to be used for lateral movement. As EDR, XDR, and infrastructure protection solutions are virtually blind to the API traffic (especially TLS encrypted API traffic) API security is needed, also for the internal network.
Yisrael Gross is the Co-Founder of API security solution company, L7 Defense