In recent weeks a critical vulnerability (CVE-2021-44228) has been discovered in Log4j2, a popular logging library for Java applications. Attackers can exploit this flaw by performing Remote Code Execution (RCE) on any systems where it is implemented.
Microsoft recently published two critical CVEs related to Active Directory (CVE-2021-42278 and CVE-2021-42287), which when combined by a malicious actor could lead to privilege escalation with a direct path to a compromised domain. In mid-December 2021, a public exploit that combined these two Microsoft Active Directory design flaws (referred also as “noPac”) was released.
IDOR is a broken access control vulnerability where invalidated user input can be used to perform unauthorized access to application functions. IDOR can result in sensitive information disclosure, information tampering etc. This issue was previously part of OWASP top 10 2007, later it was merged with OWASP top 10 A5 Broken Access control vulnerability.
URLs have forever changed the way we interact with computers. Conceptualized in 1992 and defined in 1994, the Uniform Resource Locator (URL) continues to be a critical component of the internet, allowing people to navigate the web via descriptive, human-understandable addresses. But with the need for human readability came the need for breaking them into machine-usable components; this is handled with URL parsers.
Earlier this week, the FTC issued a warning to companies regarding the Log4j vulnerability. Given the rampant exploitation of the recently discovered vulnerabilities in this ubiquitous open source logging package, it’s encouraging to see the agency take this rare step, beginning to form a firm stance on software supply chain security. Although this increased scrutiny from the FTC may at first seem daunting, violations can be remediated with the right practices.
Very recently, the JFrog security research team has disclosed an issue in the H2 database console which was issued a critical CVE – CVE-2021-42392. This issue has the same root cause as the infamous Log4Shell vulnerability in Apache Log4j (JNDI remote class loading). H2 is a very popular open-source Java SQL database offering a lightweight in-memory solution that doesn’t require data to be stored on disk.
No matter your role in tech, you’ve probably already heard about, or dealt with, the ubiquitous Log4Shell vulnerability impacting a large number of Java applications. To help spread the latest info on this critical, zero-day vulnerability, we recently hosted a webinar to get everyone up to speed.
Since December 10, in a span of just 20 days, there have been four different vulnerabilities published against Log4j. Engineers who worked long hours to update their Log4j versions to 2.15.0 on December 11th, were told three days later that they needed to do it all over again and upgrade to version 2.16.0. This is not sustainable. And yet the risks are high. Looking backward, we see that Log4j has been vulnerable since 2013 to the kinds of attacks described in CVE-2021-44228.
As CVE-2021-44228, a.k.a "Log4Shell" or Apache Log4j Remote Code Execution vulnerability continues to send shockwaves across the world of software, many security vendors and practitioners are rushing to provide recommendations on dealing with the crisis. If you need immediate help mitigating the impact of Log4shell, we're here for that. But the goal of this post is to look forward. This isn't the first and won't be the last high-impact vulnerability to be uncovered. So it's worth preparing your organization for the next one, so that you can respond faster, mitigate and remediate sooner - and have fewer weekends like the last one.
