After Log4Shell was found in December 2021, businesses and organizations all around the world rushed to assess the threat it posed to them. In the weeks that followed the news of its discovery, organizations made massive reorganizations of their resource allocations. They devoted tens of thousands of hours in efforts to identify and correct the problem. One federal cabinet agency estimated that their security team dedicated 33,000 hours to respond to the Log4j issue alone. 

Unfortunately, according to the findings of Tenable’s most recent telemetry analysis, which was derived from information gleaned from over 500 million tests, 72 percent of companies are still susceptible to the Log4j vulnerability, also known as Log4Shell vulnerability as of October 1, 2022. After a year, Log4Shell continues to be a source of frustration, and it looks like it will continue to do so for some time. The most recent piece of evidence was presented on November 16, when the Cybersecurity and Infrastructure Security Agency and the FBI jointly announced that Iranian cybercriminals had breached the network of a federal civilian executive branch agency by taking advantage of a vulnerability that existed in a server that had not been patched. 

Continued Exploitation

Log4Shell is exceptional due to the ease with which it could be exploited everywhere it was present. There were very few limitations or intricacies that an attacker would need to overcome in order to take advantage of this vulnerability, making it a straightforward target. Logging utilities are used by developers to record the activities that occur within an application. To exploit Log4Shell, an attacker has only to get the system to log a certain string of code for them to be successful. They will then be able to seize control of their victim, at which point they may install malware or carry out other forms of digital attack. Loggers are going to log, which means that spreading the harmful snippet might be as simple as inserting it in the username of an online account or sending it in an email. 

Because of its persistence and ease of exploitation Log4Shell has been deemed an “endemic vulnerability” by the United States Cyber Safety Review Board, which means that it will continue to exist in systems for at least ten years. The ongoing danger posed by Log4Shell casts a sharp light on a number of wider painful facts about the state of cybersecurity and emphasizes the pressing need for a more effective response. 

Some Key Findings:

• As of the first of October in 2022, 28% of businesses worldwide have completed the remediation of Log4Shell. This is a 14-point increase over May 2022. 
• 53% of companies remained vulnerable to Log4j, which emphasizes the persistent nature of Log4j and the essential continuous efforts to remediate it even if full remediation was previously achieved.  
• As of the month of October 2022, 29% of exposed assets had Log4Shell reinstalled in them after full remediation had been completed. 
• Some sectors are in a far better position than others, with engineering (45%), legal services (38%), financial services (35%), non-profit companies (33%), and government (30%) topping the pack with the highest percentage of firms that have successfully completed remediation. 
• Approximately 28 percent of the organizations that make up the CISA’s definition of essential infrastructure have completely remedied the affected areas. 
• Following Europe, the Middle East, and Africa (27%), Asia-Pacific (25%), and Latin America (21%) as the regions with the highest percentage of enterprises that have completely remedied Log4j is North America (28%). 
• In a similar manner, North America is the leading area with the highest percentage of organizations that have partially remediated (90%), followed by Europe, the Middle East, and Africa (85%), the Asia-Pacific region (85%), and Latin America (81%)

Future Exploitation

According to Bob Huber, Chief Security Officer of Tenable, “Full remediation is exceedingly difficult to perform for a vulnerability that is so ubiquitous, and it is vital to bear in mind that vulnerability repair is not a “one and done” operation.” Even if a company may have been completely remedied at one point in time, if they have continued to add new resources to their environments, it is quite possible that they may run into Log4Shell in the future. Eliminating Log4Shell is a continuing struggle that requires enterprises to regularly examine their environments for that weakness and any other known vulnerabilities. In order to win this war, organizations must have a strong commitment to continuous vulnerability scanning. 

The situation is relevant to larger discussions about the software supply chain and the fact that many organizations do not have an adequate accounting of all the software they use in their systems, which makes it more difficult to identify vulnerable code and patch it. The fact that many organizations do not have an adequate accounting of all the software they use in their systems also resonates with the situation. Even if an organization has a list of all the software it has purchased or deployed, the programs may still contain other software components, particularly open-source libraries and utilities like Log4j, of which the end customer is not specifically aware and did not intentionally choose. This is a part of the challenge. This results in the rippling impact of a vulnerability such as Log4Shell as well as the long tail of patching, in which companies either aren’t aware that they are vulnerable or don’t understand the need to invest in upgrades. 

Positive Results

Researchers who are monitoring the vulnerability argue that a beneficial consequence of Log4j is the increased attention it has garnered to procedures like software composition analysis and software bill of materials (SBOM). Because of the difficulties that organizations have had in simply determining whether they are vulnerable or where the vulnerability might exist in their environment, a better understanding of the need for visibility into all of the components in their codebase has been fostered. This is especially true for components that come from open-source and third-party sources. 

According to Matthew Rose, the Chief Information Security Officer (CISO) of ReversingLabs, “The research into the Log4J problem has highlighted the necessity for stronger software supply chain attestation in addition to SBOMs that keep up with the speed of DevOps.” Program security and architecture teams have come to the realization that it is not sufficient to just look for risk in components of the application, such as source code, APIs, or open-source packages. They have come to the conclusion that it is equally as vital to detect SQLI or cross-site scripting (XSS) issues as it is to have a comprehensive grasp of the architecture of the program, he explains. 

Conclusion

Because Log4j is a chronic danger, protecting yourself against it calls for vigilance, competence, and experience. In order to maintain an effective security posture in the face of these and other threats, organizations need to recognize that continuing effort and attention to detail are essential. Counting on external platforms like GuardRails can help keep your code secure and your company protected against threats like Log4Shell, by continuously scanning in the background, detecting important security issues, and guiding your team to fix them. You can try it for free to automatically scan all your current and future repositories, or book a customized demo to learn more.

The post What happened with Log4Shell a year after being disclosed appeared first on GuardRails.

*** This is a Security Bloggers Network syndicated blog from GuardRails authored by GuardRails. Read the original post at: https://blog.guardrails.io/what-happened-with-log4shell-a-year-after-being-disclosed/