On Jan. 18, 2022, researchers found a heap base buffer overflow flaw (CVE-2022-0185) in the Linux kernel (5.1-rc1+) function “legacy_parse_param” of filesystem context functionality, which allows an out-of-bounds write in kernel memory. Using this primitive, an unprivileged attacker can escalate its privilege to root, bypassing any Linux namespace restrictions.

What do Linux vulnerabilities and natural disasters have in common? Something seemingly dormant can suddenly spring to life, exposing activity beneath the surface. Several days ago, a security researcher published a high-severity vulnerability named PwnKit that impacts most major Linux distributions. The scary part? It’s existed since May of 2009. Polkit is a component for controlling privileges in Unix-like operating systems and is included by default on most major Linux distributions.

On January 25, 2022, Qualys announced the discovery of a local privilege escalation vulnerability that it identified as PwnKit. The PwnKit vulnerability affects PolicyKit’s pkexec, a SUID-root program installed by default on many Linux distributions. The same day of the announcement, a proof of concept (PoC) exploit was built and published by the security research community.

A new advisory from Qualys discloses a local privilege escalation bug in SUID-set program ‘pkexec’. The flaw has been designated the CVE ID of CVE-2021-4034 and nicknamed “pwnkit” by the vulnerability finders. The CVSSv3 base score is calculated to be a high 7.8 out of 10.0. The vulnerable program is a part of Polkit, which manages process privileges.

During an investigation of a malware campaign, I discovered that multiple emails were bypassing a specific email security system. Interestingly, there were no bypass techniques used. Instead, the flood of spear-phishing emails made the email security system allow some of the emails, at which point I began my research on Microsoft Outlook. The issue in this case was that the specially crafted malicious link parsing on the security system was weak.

Since 2009, more than 12 years ago, all major Linux distributions have been incorporating a high severity security hole that remained unnoticed until just recently. The vulnerability and exploit, dubbed “PwnKit” (CVE-2021-4034), uses the vulnerable “pkexec” tool, and allows a local user to gain root system privileges on the affected host. Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems.

“Crowdsourced security provides a way for security teams to expand their efficiency, especially when it comes to managing their external attack surface,” said Rickard Carlsson, Co-founder and CEO of Detectify. “Hackers have eyes and ears all over the web, and they’re constantly monitoring attack surfaces for exploitable entry points.

The Trustwave Threat Hunting team has authored a practical guide to help the cybersecurity community address the Linux “polkit” Local Privilege Escalation vulnerability (CVE-2021-4034) by identifying common behavior in exploitation.

Trustwave security and engineering teams became aware of the vulnerability in Polkit's pkexec component identified as CVE-2021-4034 (PwnKit) on January 25. We immediately investigated the vulnerability and potential exploits and continue to actively monitor the situation for our clients. Check your distribution for specific patches. As part of a strong patch management program, ensuring your infrastructure and applications are up to date is critical for mitigating cyber risk..

In January 2022, Microsoft disclosed a remote code execution vulnerability for Internet Information Server (IIS) identified as CVE-2022-21907, which they have subsequently reported as wormable. Through Microsoft, Corelight Labs was able to review a proof of concept for an attack against the vulnerability. This blog presents an open source detection method that Corelight Labs is releasing to detect exploit attempts of CVE-2022-21907.

The Log4Shell vulnerability took the Java community by surprise at the end of 2021, and many organizations are still mitigating its impact. To help development teams stay informed as the situation unfolds, Snyk has created and continues to update its Log4j vulnerability resource center.

If you've already heard about the Apache Log4j CVE-2021-44228 (also known as Log4Shell and formally LogJam) vulnerability then you will know that this is a significant issue as many organisations are scrambling to secure their infrastructure from this critical remote code execution (RCE) vulnerability. With these considerations in mind, we wanted to bring you a guide that outlines the steps that can be followed to ensure the security of your systems from CVE-2021-44228.

In the last few days, Linux maintainers disclosed a broadly available Linux kernel vulnerability that enables attackers to escape containers and get full control over the node. To be able to exploit this vulnerability, the attacker needs to be able to run code in the container and the container must have CAP_SYS_ADMIN privileges. Linux kernel and all major distro maintainers have released patches.

This week, Linux maintainers and vendors disclosed a heap overflow vulnerability in the Linux Kernel. The vulnerability has been issued a Common Vulnerability and Exposures ID of CVE-2022-0185 and is rated as a High (7.8) severity. The flaw occurs in the Filesystem Context system when handling legacy parameters. An attacker can leverage this flaw to cause a DDoS, escape container environments, and elevate privileges.

There are truisms that span history. One truism is that a single mistake can lead to disaster, and to some extent the series of vulnerabilities affecting the organizations that use Apache Log4j.

No sooner did word start to spread about Apache Log4j that the usual torrent of blaring headlines, vendor marketing, and tips and tricks-style “information” quickly followed. You can find plenty of solid technical analysis out there about Log4j, and we’ve already posted information about Netskope protections and threat coverage from Netskope Threat Labs. But that’s not this post.

Our security research team will explain a real attack scenario from the black box and white box perspective on how a vulnerable AWS Lambda function could be used by attackers as initial access into your cloud environment. Finally, we show the best practices to mitigate this vector of attack. Serverless is becoming mainstream in business applications to achieve scalability, performance, and cost efficiency without managing the underlying infrastructure.

Following the discovery of Log4Shell, a vulnerability in Log4J2, Elastic released a blog post describing how users of our platform can leverage Elastic Security to help defend their networks. We also released an advisory detailing how Elastic products and users are impacted.

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.

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.

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.