Security teams working to mitigate the organization’s exposure to Log4j vulnerabilities have many challenges to overcome. They include determining the full scope of exposure, finding workarounds for systems that cannot be patched, and ensuring that third-party products and services are protected.
Security experts said this week that for many people, the task will become more complicated due to the need to constantly monitor for signs of attackers trying to exploit the vulnerability or signs that they may have been attacked.
Log4j is a logging tool that exists in almost all Java applications. A serious remote code execution vulnerability (CVE-2021-44228) Exists in the Log4j version from 2.0-beta9 to 2.14.1, allowing the attacker to fully control the vulnerable system. The Apache Foundation released an updated version of the tool (Apache Log4j 2.15.0) last week, and then released a second update on Tuesday because the original fix did not fully prevent denial of service (DoS) attacks and data theft.
This vulnerability is widely regarded as one of the most dangerous vulnerabilities in recent memory because it is easy to exploit and exists in almost every IT environment. Vera CodeFor example, it was found that 88% of customers use a certain version of Log4j, and 58% of customers use a vulnerable version in their environment.
Since the vulnerability was first disclosed last week, attackers around the world have been trying to exploit the vulnerability. Many vendors have observed attempts to distribute coin miners, ransomware, remote access Trojan horses, web shells, and botnet malware. unarmed The report on Wednesday stated that approximately 35% of customers were actively attacked by the vulnerability, and 31% of customers were exposed to Log4j-related threats on unmanaged devices. The security vendor said it has observed as many as 30,000 attack attempts against its customers. Several other suppliers also reported similar activities.
Armis found that by far, the most targeted assets in the IT environment are servers, virtual machines, and mobile devices. In OT networks, 49% of infected devices are virtual machines and 43% are servers. Other target devices in the OT network include IP cameras, human machine interface (HMI) devices, and SCADA systems.
Defining the problem
Security experts say that one of the main challenges that organizations face when defending against attacks against Log4j is to figure out that they are completely exposed to the threat. The vulnerability exists not only in the organization’s Internet-facing assets, but also in internal and back-end systems, network switches, SIEM and other logging systems, internally developed and third-party applications, SaaS and cloud services, and the environment in which they are located middle. May not even know. The interdependence between different applications and components means that even if a component is not directly vulnerable, it may still be affected by it.
The way that Java packaging works often makes it difficult to identify the affected application. Nameless security Say. For example, a Java archive (JAR) file may contain all the dependencies of a particular component (including the Log4j library). But the JAR file may contain another JAR file, and the JAR file may contain another JAR file-essentially burying the vulnerability in several layers deep, the security vendor said.
“One of the main challenges that organizations face when mitigating the vulnerabilities found in Log4j is to identify all compromised assets,” said Gustavo Palazolo, a threat research engineer at Netskope. He added that the Log4j Apache Java-based logging library is very popular and can be used by many applications and IoT devices and legacy systems maintained for backward compatibility.
Even if a vulnerability is discovered in an application, it can be difficult to update it because the organization may not be able to withstand downtime or lack proper patch management controls.
“Therefore, in some cases, the time between identifying all the damaged systems and fixing the problem can take a long time,” Palazzolo said.
API and third-party risks
The application is not the only problem. The Log4j vulnerability also affects the application programming interface (API) environment. Noname said that the API server containing the vulnerability provides an attractive attack vector because many organizations have limited visibility into their API lists and API behavior. Companies that do not use the Log4j logging framework may be using trusted third-party APIs that contain Log4j flaws, putting them at risk.
“For an organization to minimize risk [Log4j vulnerability] Aner Morag, vice president of technology at Noname Security, said that using APIs requires several steps. This includes mapping all API-providing servers with any Java service, and disallowing any user input to log messages that reach any Java service. Morag said that the API server uses a proxy or other mechanism to control which servers the back-end service can connect to, and puts the API behind the API gateway or load balancer.
Another challenge for organizations is to ensure that all third-party products and services they use are properly patched or deficiencies are mitigated.
“Many suppliers’ products are affected, [and] Tom Gorup, vice president of security operations at Alert Logic, said the list of affected vendors is increasing every day. “Not all vendors have patches available.”
Gorup recommends that the security team check their supplier’s website or contact them directly to find out if any of their products are affected. Suppliers may be vulnerable to attacks, but have issued mitigations to protect their customers.
“At the very least, you need to know how to verify that your assets have received updates,” Gorup pointed out.He also recommends that the security team check the list of vulnerable products available in the past few days, such as This on GitHub.
“The response to this vulnerability may be,’We don’t use Java,'” Gorup said. “In this case, your third-party software may have embedded it, which may cause your vulnerability scan to not show [the threat].”
