Operations | Monitoring | ITSM | DevOps | Cloud

At many organizations, the surprise discovery that the widely used Apache log4j open source software has harbored a longtime critical vulnerability was as if Scrooge and the Grinch had teamed up for the biggest holiday heist of all. Incident response teams across the globe have scrambled to remediate thousands, if not millions of applications. “For cybercriminals this is Christmas come early,” explained Theresa Payton, former White House CIO and current CEO of Fortalice Solutions.

The internet has been ablaze since the announcement of Log4Shell, the nickname for CVE-2021-44228, an arbitrary remote code execution vulnerability in the Java logging utility Log4j. So far two additional vulnerabilities ( CVE 2021-45046, CVE-2021-45105) have now been identified. The code has been vulnerable since 2013 and millions of hosts and services are affected.

This post originally appeared on The New Stack and is re-published here with permission. In our technology-driven business climate, most companies have at least some, if not all, workloads on the cloud. And unlike on-premises networks, these cloud environments lack secure outer perimeters and specific off times. Cloud networks are always on and always available. While convenient, this also means hackers can access them at any time.

In our recent webinar, Log4j Log4Shell Vulnerability Explained: All You Need To Know, our Senior Director Security Research expert Shachar Menashe shared information on the security issue and how to detect and remediate it. We are happy to share additional information in the following Q&A, based on the questions raised during the webinar.

Just when the Microsoft Exchange exploit CVE-2021-26855 thought it would win the “Exploit of the year” award, it got unseated by the – still evolving – Log4J exploit just weeks before the end of the year! Had somebody asked Sysadmins in November what Log4J was then I suspect that the majority would have had no idea. It seems that the biggest challenge the Log4J exploit poses for Sysadmins is simply the fact that nobody knows all the places where Log4J is being used.

On December 9, 2021, a vulnerability was reported that could allow a system running Apache Log4j 2 version 2.14.1 or below to be compromised and allow an attacker to execute arbitrary code on the vulnerable server. This vulnerability was registered on the National Vulnerability Database as CVE-2021-44228, with a severity score of 10. Here is a diagram of the attack chain from the Swiss Government Computer Emergency Response Team (GovCERT).

At Avantra, our customers trust us to keep their business operations based on SAP running smoothly. I have written in the past about the importance of SAP security, and how I believe that in the next few years, SAP risks becoming an attack vector for hackers. It should come as no surprise that security is an area in which Avantra has invested significantly since I became CEO.

Last week, a researcher from the Alibaba Cloud Security Team dropped a zero-day remote code execution exploit on Twitter, targeting the extremely popular log4j logging framework for Java (specifically, the 2.x branch called Log4j2). The vulnerability was originally discovered and reported to Apache by the Alibaba cloud security team on November 24th. MITRE assigned CVE-2021-44228 to this vulnerability, which has since been dubbed Log4Shell by security researchers.

I’m probably dating myself, but I used to love the television show The A-Team when I was little. Every week, the team would be put into the middle of a problem and work together to overcome some challenge. Plus, they had Mr. T and a really cool van.

Recent news about Log4j has enterprises and vendors scrambling for information and answers, including customers of messaging middleware and Integration Infrastructure Management (i2M) products. Nastel Technologies customers will not be exposed to any risks from this vulnerability, but enterprises are encouraged to check with their Cloud and other solution vendors to protect themselves and their data.