Just a few days after CVE-2021-45046 was released and fixed, a third zero-day vulnerability was discovered in Apache Log4j, tracked as CVE-2021-45105. The bug was reported on December 15, 2021, and disclosed on December 18, 2021. This third vulnerability has received a CVSS score of 7.5 out of 10, whereas the first one known as Log4Shell (CVE-2021-44228) received the maximum CVSS score of 10 due to its criticality.

While many organizations are patching the two recent Apache Log4j vulnerabilities (CVE-2021-44228 and CVE-2021-45046), attackers have been racing to exploit them to deliver malware, such as botnets, backdoors, and cryptominers. Among the threats delivered using Log4Shell exploits, a new ransomware family was found by Bitdefender: Khonsari.

Shortly after the Apache Software Foundation (ASF) released the bug fix for the vulnerability known as Log4Shell or LogJam (CVE-2021-44228), a new vulnerability was discovered in Log4j Java-based logging library, tracked as CVE-2021-45046. While Log4Shell had the maximum CVSS score of 10, this new vulnerability is rated as 3.7, affecting all versions of Log4j between 2.0-beta9 and 2.12.1, as well as between 2.13.0 and 2.15.0.

Here at Netskope, our corporate culture means everything to us. In our core values, we strive to be collaborative and transparent, to cut out politics and bureaucracy, and to always have fun. With all of these values in mind, we are so excited to announce that Netskope has been named one of Battery Venture’s 25 Highest Rated Private Cloud-Computing Companies to Work For!

CVE-2021-44228 (Log4Shell or LogJam) is a recently discovered zero-day vulnerability in the ubiquitous Apache Log4j Java-based logging library. It was reported by the Alibaba Cloud Security team as an unauthenticated RCE vulnerability in Log4j 2.0-beta9 up to 2.14.1 and could allow a complete system takeover on vulnerable systems. The bug has received the maximum CVSS score of 10, reflecting its importance and ease of exploitation.

What comes to mind when you think of security “out-of-the-box?” You’re probably looking for something that will keep users as secure as possible while minimizing implementation friction points to your users. And with ransomware, malware, and phishing threats spreading faster and costing businesses more each year, IT teams must take a full-stack approach to defend against external attacks and internal vulnerabilities, while keeping the business running.

Cloud accounts continue to be a valuable target for cybercriminals: not only do the resources of a compromised IaaS environment grant an immediate profit for the attackers, but the same infrastructure also provides a trusted environment to launch attacks against other targets.

Gartner made an interesting prediction just a few years ago: “Through 2025, 99% of cloud security failures will be the customer’s fault.” Practically every single cloud security failure can be fairly described as a misconfiguration of one kind or another. The 2025 end is kind of arbitrary, really; the prediction is likely to be true until the end of time. In my previous article, I discussed targeting these misconfigurations at their root.

Executive Order 14028 on Improving the Nation’s Cybersecurity was released in May with nine sections outlining specific focus areas for security improvements. As we noted at the time, Netskope applauded the EO for how it placed significant emphasis on zero trust security adoption, mentioning it no fewer than 11 times, and insisting on proactive action.

In this blog, we’ve analyzed data from Netskope customers that include security settings of over 1 million entities in 156,737 Google Cloud (GCP) projects across hundreds of organizations (see Dataset and Methodology for more details on the dataset). We will specifically look at the configuration of service accounts, see what’s commonly occurring in the real world, and analyze how multiple security misconfigurations can lead to escalation of privileges and lateral movement.