Log4j vulnerability puts organisations and applications at risk

Flaw reinforces why companies of all sizes need to have active 24/7 cybersecurity capabilities in place

Numata’s Security Operations-as-a-Service identifies and responds to severe vulnerabilities 24/7, 365 days a year. We also actively hunt for threats in our customers’ cloud, network and endpoint environments. In today's world, there are some vulnerabilities you simply should never ignore.

Recently, a critical vulnerability in the Apache Log4j Java-based logging utility was announced – a common logging system used by developers of web and server applications based on Java and other programming languages. The vulnerability affects a broad range of services and applications on servers, including cloud platforms, web applications and email services, meaning there is a wide range of software that could be at risk from cybercriminal attempts to exploit the vulnerability, making it extremely dangerous.

Numata’s 24/7 Security Operations Centre (SOC) Team saw repeated cybercriminal attempts to exploit this vulnerability, including in real-world scenarios, and within our clients’ environments. Thankfully, we were able to immediately contain and apply configuration changes to our affected clients.

“Our advanced breach detection and cyber-terrorist network connections monitoring provide detection of shell scripts and other techniques which may be used in an attack,” says Cyber Security Product Manager, Liza Weschta. “Our SOC Team has been monitoring customer devices closely to detect compromises. It's common for cybercriminals to make attempts to exploit widely disclosed vulnerabilities and take advantage of them before they are remediated.”

Liza says that the most important aspect of containing a threat is to detect it fast and respond to it fast. “Your time to detect will be your saving grace from a security breach,” she says.

The challenge is for organisations to find time, talent and tools to detect, attend and prioritise vulnerabilities, as they are ever-increasing, which is why we have launched Numata’s Managed Security Operations as a Service, to help SMEs battle cybercrime.

Our team of security analysts detects and responds to threats across endpoints, networks and cloud attack vectors 24/7/365, enabling IT professionals to cut through the noise and focus on critical issues that need to be remediated, while we continue to have full visibility across their endpoints, networks and cloud environments.

Round-the-clock monitoring eliminates the need to recruit and staff highly compensated cyber engineers to perform detection, triage and examination of the mountains of threat data from myriad point solutions. Our skilled SOC analysts escalate only important actionable incidents. When necessary, we can apply automated remediation and isolation technology remedies or guidance for a threat to contain and isolate a device on the network, to prevent a cyber-attack.

Do you have the right security capabilities in place? Contact us today to learn how we can help you protect your most critical assets and shield your business from a cybersecurity attack because it’s not a question of if, but when.

The image below was created by the Swiss Government Computer Emergency Response Team and is perhaps the easiest-to-understand visual representation of the attack (credit: GovCERT.ch). The best defence is to upgrade log4j to 2.16.0 or apply the log4j configuration changes to mitigate the attack as outlined in the Apache Security Notice at: https://logging.apache.org/log4j/2.x/security.html

The Log4j JNDI Attack

It has been found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

A new CVE has been issued (CVE-2021-45046) and Apache has released a new Log4j version – 2.16.0. This means, if you upgraded to 2.15.0 or applied mitigation recommendations, you may still be vulnerable. Users should immediately update to the new release (2.16.0) or review the mitigation recommendations at the Apache site: https://logging.apache.org/log4j/2.x/security.html

Back to Blog