International cybersecurity authorities have published an overview of the most routinely exploited vulnerabilities of 2021.
The post The top 5 most routinely exploited vulnerabilities of 2021 appeared first on Malwarebytes Labs.

A joint Cybersecurity Advisory, coauthored by cybersecurity authorities of the United States (CISA, NSA, and FBI), Australia (ACSC), Canada (CCCS), New Zealand (NZ NCSC), and the United Kingdom (NCSC-UK) has detailed the top 15 Common Vulnerabilities and Exposures (CVEs) routinely exploited by malicious cyber actors in 2021, as well as other CVEs frequently exploited.

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). These are the CVEs that made it into the top 10.

**1\. Log4Shell**

CVE-2021-44228, commonly referred to as Log4Shell or Logjam. This was a software flaw in the Apache Log4j logging utility. A logger is a piece of software that logs every event that happens in a computer system. The records it produces are useful for IT and security folks to trace errors or check any abnormal behavior within a system.

When Log4Shell emerged in December 2021, what caught many by surprise was the enormous number of applications and web services, including those offered by Twitter, Apple, Google, Amazon, Steam, and Microsoft, among others, that were relying on Log4j, many of which inherited the vulnerability.

This made for an exceptionally broad attack surface. Combine that with an incredibly easy to use exploit and there should be no surprise that this vulnerability made it to the top of the list.

The Cybersecurity and Infrastructure Security Agency (CISA) has launched an open source scanner to find applications that are vulnerable to the Log4j vulnerabilities listed as CVE-2021-44228 and CVE-2021-45046. The CISA Log4j scanner is based on other open source tools and supports scanning lists of URLs, several fuzzing options, DNS callback, and payloads to circumvent web-application firewalls.

**2\. CVE-2021-40539**

CVE-2021-40539 is a REST API authentication bypass vulnerability in ManageEngine’s single sign-on (SSO) solution with resultant remote code execution (RCE) that exists in Zoho ManageEngine ADSelfService Plus version 6113 and prior. When word of this vulnerability came out it was already clear that it was being exploited in the wild. Zoho remarked that it was noticing indications of this vulnerability being exploited. Other researchers chimed in saying the attacks had thus far been highly targeted and limited, and possibly the work of a single threat actor. It was clear from the start that APT threat-actors were likely among those exploiting the vulnerability.

The vulnerability allows an attacker to gain unauthorized access to the product through REST API endpoints by sending a specially crafted request. This allows attackers to carry out subsequent attacks resulting in RCE.

For those that have never heard of this software, it’s a self-service password management and single sign-on (SSO) solution for Active Directory (AD) and cloud apps. Which means that any attacker that is able to exploit this vulnerability immediately has access to some of the most critical parts of a corporate network. A patch for this vulnerability was made available on September 7, 2021. Users were advised to update to ADSelfService Plus build 6114. The FBI, CISA, and CGCYBER also strongly urged organizations to make sure that ADSelfService Plus was not directly accessible from the Internet.

The ManageEngine site has specific instructions on how to identify and update vulnerable installations.

**3\. ProxyShell**

Third on the list are 3 vulnerabilities that we commonly grouped together and referred to as ProxyShell. CVE-2021-34523, CVE-2021-34473, and CVE-2021-31207.

The danger lies in the fact that these three vulnerabilities can be chained together to allow a remote attacker to run code on an unpatched Microsoft Exchange server. Attackers use them as follows:

*   **Get in** with CVE-2021-31207, a Microsoft Exchange Server security feature bypass vulnerability. The vulnerability allows a remote user to bypass the authentication process.
*   **Take control** with CVE-2021-34523, a Microsoft Exchange Server elevation of privilege (EoP) vulnerability. The vulnerability allows a user to raise their permissions.
*   **Do bad things** with CVE-2021-34473, a Microsoft Exchange Server remote code execution (RCE) vulnerability. The vulnerability allows an authenticated user to execute arbitrary code in the context of SYSTEM and write arbitrary files.

The vulnerabilities were found in Microsoft Exchange Server, which has a large userbase and which is usually set up as an Internet-facing instance. Plus, many publications have provided proof-of-concept (PoC) methodologies which anyone can copy and use.

Microsoft’s Security Update from May 2021 remediates all three ProxyShell vulnerabilities.

**4\. ProxyLogon**

After the ProxyShell entries we go straight to four vulnerabilities that are grouped under a similar name—ProxyLogon—for similar reasons. CVE-2021-26855, CVE-2021-26857, CVE-2021-2685, and CVE-2021-27065 all share the same description—”This vulnerability is part of an attack chain. The initial attack requires the ability to make an untrusted connection to Exchange server port 443.”

While the CVE description is the same for the 4 CVE’s we have learned that CVE-2021-26855 is a server-side request forgery (SSRF) vulnerability in Exchange that was used to steal mailbox content. The RCE vulnerability CVE-2021-26857 was used to run code under the System account. The other two zero-day flaws—CVE-2021-26858 and CVE-2021-27065—would allow an attacker to write a file to any part of the server.

Together these four vulnerabilities form an attack chain that only requires the attacker to find the server running Exchange, and the account from which they want to extract email. After exploiting these vulnerabilities to gain initial access, threat actors deployed web shells on the compromised servers to gain persistence and make more changes. Web shells can allow attackers to steal data and perform additional malicious actions.

ProxyLogon started out as a limited and targeted attack method attributed to a group called Hafnium. Unfortunately it went from limited and targeted attacks to a full-size panic in no time. Attackers started using the Exchange bugs to access vulnerable servers before establishing web shells to gain persistence and steal information.

Microsoft has released a one-click mitigation tool for Exchange Server deployments. The Microsoft Exchange On-Premises Mitigation Tool will help customers who do not have dedicated security or IT teams to apply these security updates. Details, a download link, user instructions, and more information can be found in the Microsoft Security Response Center.

**5\. CVE-2021-26084**

CVE-2021-26084 is an Object-Graph Navigation Language (OGNL) injection vulnerability that exists in some versions of Confluence Server and Data Center that can allow an unauthenticated attacker to execute arbitrary code on a Confluence Server or Data Center instance. This was a zero-day vulnerability that was only patched after it was found to be actively exploited in the wild. An attacker could exploit the vulnerability by simply sending a specially crafted HTTP request containing a malicious parameter to a vulnerable install.

Shortly after the vulnerability was disclosed and a patch came out, researchers noticed massive scanning activity for vulnerable instances and crypto-miners started to use the vulnerability to run their code on unpatched servers.

On the Confluence Support website you can find a list of affected versions, instructions to upgrade, and a workaround for those that are unable to upgrade.

**Lessons learned**

What does this list tell us to look out for in 2022?

Well, first off, if you haven’t patched one of the above we would urgently advise you to do so. And it wouldn’t hurt to continue working down the list provided by CISA.

Second, you may have noticed a pattern in what made these vulnerabilities so popular to exploit:

*   **A large attack surface**. Popular and widely used software makes for a larger number of potential victims. The money is in the numbers.
*   **Internet-facing instances**. Remember, your Internet-connected software shares the Internet with every basement-dwelling criminal hacker in the world.
*   **Easy exploitability**. When vulnerabilities are easy to exploit, and PoCs are publicly available and easy to deploy, the number of potential threat actors goes up.

So, if you notice or hear about a vulnerability that meets these “requirements” move it to the top of your “to-patch” list.

Stay safe, everyone!

The top 5 most routinely exploited vulnerabilities of 2021

The startup is the latest company to try to solve the problem of organizing and sharing secrets.

Secrets management continues to be an ongoing challenge in application security, as developers struggle to organize secrets used in source code and manage distributed systems and infrastructure.

The latest startup to address this space is Doppler, whose platform helps developers securely store, transmit, and audit secrets. The Doppler platform syncs secrets across devices, environments, and team members so that developers don't wind up sharing secrets on insecure platforms (such as Slack or email) or including them within .git and .zip files. The platform can also handle secrets rotation, and it sends developers alerts over Slack and Microsoft Teams to inform them when the secrets are changed.

Secrets refer to sensitive pieces of data, such as tokens, encryption keys, API keys, and digital certificates. A survey by 1Password last year found that 65% of companies juggle more than 500 secrets, and 18% said they have "more than they can count."

The secrets are scattered across source code, container and infrastructure images, and configuration files. Over 6 million secrets were detected in scans of public GitHub repositories in 2021, according to GitGuardian's State of Secrets Sprawl 2022 report.

Adversaries routinely attempt to intercept these secrets in order to gain access to cloud environments, help with lateral movement, and access data in applications. Earlier this month, GitHub said adversaries were able to download private data from some organizations using Heroku and Travis-CI after stealing a handful of OAuth tokens used by those two platforms. Last year, attackers compromised Codecov and stole secrets belonging to Codecov's customers. Those secrets were then used to compromise the customers.

1Password estimates the cost of a company losing control of its secrets at $1.2 million per year.

**Security Management Is Key**  
Enterprises need processes in place to handle secrets management, such as inventorying what secrets they have, controlling access, sharing secrets safely with collaborators, and promptly revoking those secrets when they are exposed. It also needs to be scalable, considering the sheer number of secrets developers are using, and not time-intensive.

In the same 1Password survey, DevOps and IT workers said they spend an average of 25 minutes each day managing secrets – which the company estimated to add up to an annual payroll expense of roughly $8.5 billion.

Secrets management is shaping up to be a fairly crowded market. HashiCorp Vault offers a vault for teams to securely store tokens, passwords, certificates, and encryption keys. 1Password acquired SecretHub last year, which was the basis for its 1Password Secrets Automation service. Cloud giants Amazon Web Services and Google Cloud offer AWS Secrets Manager and Secrets Manager, respectively. GitHub, GitLab, and Atlassian all offer various levels of secrets-scanning tools for their code repositories.

Then there's Doppler, which recently raised $20 million as part of a series A funding round.

"The ability to securely store, transmit and audit secrets has never been more critical as one minor error can lead to catastrophic results," said Murat Bicer, a general partner at CRV (which led the funding round), in a statement. "In a world where putting a single space in the wrong place can literally take down a company's entire website, Doppler makes it easy to prevent leaks and outages with their developer focused approach."

Doppler Takes on Secrets Management

The move to IaC has its challenges but done right can fundamentally improve an organization's overall security posture.

Infrastructure as code (IaC) has become a core part of many organizations' IT practices, with adoption of technologies like HashiCorp's Terraform and AWS CloudFormation increasing rapidly. The move to IaC sees companies moving away from either manually configuring servers or using imperative scripting languages to automate those changes and toward a model in which declarative code is used to outline a resource's preferred final state.

As with any change in approach to IT, there are security considerations to understand. The move to IaC presents some risks along with opportunities to improve the way companies secure their environments. Given IaC's key role in configuring the security parameters of an organization's systems and the speed at which a flawed template could be rolled out across a large number of systems, ensuring that good security practices are adhered to is vital to making the best use of this technology.

**IaC Security Risks and Opportunities**  
With the move to IaC, there are new security risks to consider. The first is secrets management. When creating and managing resources, credentials will often be needed to authenticate to remote systems; when IaC code is written to automate these tasks, there is a risk that credentials or API keys may be hard-coded into the code. Care should be taken to ensure that proper secrets management processes are followed to avoid this. Secrets should be held in a secure location, such as a cloud key management service (KMS), and retrieved on demand by scripts as they run.

A second risk is that misconfigurations may creep into the IaC templates — for example, if code is copy/pasted in from an external source — and then propagate throughout an environment quickly as the IaC is used. Avoiding this risk requires both automated and manual review, as with any other source code.

The opportunity inherent in moving to IaC-driving environments is that once all of your infrastructure is defined in code, it's possible to apply common automated linters and review tools to it to ensure that good practices are followed. Tooling can draw from common libraries of good practice and be supplemented with custom rules that apply organization-specific practices.

Additionally, with an IaC-based approach, all configurations should be stored in version- controlled source code repositories. This provides improved tracking of changes so that companies can track modifications over time and also ensure appropriate access control and that auditing is in place.

Lastly, IaC-based deployment means that test environments should be able to effectively mirror production, meaning that security testing can be safely conducted with higher confidence that any results will be meaningful in production.

**IaC Technology Stacks**  
There are a variety of options for IaC. Typically, large organizations will use many of these at the same time, as different tools have different strengths and weaknesses.

Terraform from HashiCorp is one of the most widely used IaC toolsets. It has the advantage of being open source and not tied to any one cloud platform or infrastructure provider, meaning that it works across a range of environments.

Unsurprisingly, the major cloud service providers also have IaC toolsets that focus on their clouds. Amazon's CloudFormation, Microsoft's ARM and Bicep, and Google's Cloud Deployment Manager all provide a means for users of that company's cloud to take advantage of the IaC paradigm.

Another popular option for cloud-native IaC is Pulumi, which allows developers to use programming languages they already know (e.g., JavaScript or Golang) to write their IaC templates.

**IaC Review Tools**  
There are a number of open source tools that can help with the process of security reviews of IaC code. These tools take a similar approach in providing a rule set of common security misconfigurations for a given set of IaC languages. In addition to the main IaC format, some of these tools will review other formats, like Kubernetes manifests and Dockerfiles. Some of the commonly used tools in this arena include the following:

*   Trivy is a vulnerability and misconfiguration scanner that includes rules from the tfsec and cfsec projects covering Terraform and CloudFormation, as well as a set of rules for Kubernetes and Docker. It can be easily integrated into a CI/CD pipeline and run by developers as part of the coding environment.
*   Checkov is a tool written in Python that covers a wide range of IAC languages, including Terraform, CloudFormation, Azure Bicep and ARM, and Kubernetes manifests. It also helps with the challenge of ensuring that IaC files don't hard-code secrets by scanning for instances where this can occur.
*   Terrascan is another popular option for IaC scanning. Despite the name, it supports a range of IaC formats in the same way as Trivy and Checkov. Similarly to Trivy, Terrascan is written in Golang and can be integrated into CI/CD pipelines and run as a standalone program.

**Smoothing the Security Path**  
The move to IaC is well underway at a variety of organizations. While it does bring challenges, the process — if well handled — can fundamentally improve organizations' overall security posture by allowing all of their system configurations to be held in version-controlled source code repositories and regularly checked for misconfigurations.

Given the power of IaC, it is vital that its adoption be accompanied by strong security practices, with scanning and validation key to those processes. By using open source review tools like the ones mentioned above, companies can help to smooth their path in adopting this technology.

The Ins and Outs of Secure Infrastructure as Code

Researchers propose fresh approaches to cloud-security bugs and mitigating exposure, impact and risk.

Researchers propose fresh approaches to cloud-security bugs and mitigating exposure, impact and risk.

Big gaps exist in the 22-year-old Common Vulnerability and Exposures (CVE) system that do not address dangerous flaws in cloud services that drive millions of apps and backend services. Too often, cloud providers needlessly expose customers to risk by not sharing the details of bugs discovered on their platform. A CVE-like approach to cloud bug management must exist to help customers weigh exposure, impact and mitigate risk.

That is the opinion of a growing number of security firms pushing for a better cloud vulnerability and risk management. They argue because of CVE identification rules, which only assign CVE tracking numbers to vulnerabilities that end-users and network admin can directly manage, the current model is broken.

MITRE, the non-profit organization behind the CVE system, does not designate CVE IDs for security issues deemed to be the responsibility of cloud providers. The assumption is that cloud providers own the problem, and that assigning CVEs that are not customer-controlled or patched by admins falls outside of the CVE system purview.

_\[**Editor’s Note:** This article was originally published in the free Threatpost eBook “Cloud Security: The Forecast for 2022.” In it we explore organizations’ top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists. Please download the FREE eBook for the full story\]_

“\[It is a false\] assumption that all issues can be resolved by the cloud provider and therefore do not need a tracking number,” wrote Scott Piper, a cloud-security researcher with Summit Route, in a recent blog. “This view is sometimes incorrect, and even when the issue can be resolved by the cloud provider, I still believe it warrants having a record.”

Piper’s critiques are part of his introduction to a curated list of dozens of documented instances of cloud-service provider mistakes that he says prove the point.

Over the past year, for example, Amazon Web Services snuffed out a host of cross-account vulnerabilities. As well, Microsoft recently patched two nasty Azure bugs (ChaosDB and OMIGOD). And, last year, Alphabet’s Google Cloud Platform tackled a number of bugs, including a policy-bypass flaw.

“As we uncover new types of vulnerabilities, we discover more and more issues that do not fit the current \[MITRE CVE reporting\] model,” wrote cloud researchers Alon Schindel and Shir Tamari with the cloud security firm Wiz, in a post. “Security industry call to action: we need a \[centralized\] cloudvulnerability database.”

The researchers acknowledged that cloud service providers do respond quickly to cloud bugs and work fast to mitigate issues. However, the process of identifying, tracking and helping those affected to assess risk needs streamlining.

![AWS computing](https://media.threatpost.com/wp-content/uploads/sites/103/2020/08/21091044/podcast-news-wrap-300x203.jpg)

An example: When researchers found a series of cross-account AWS vulnerabilities in August, Amazon moved quickly to mitigate the problem by changing AWS defaults and updating the user set-up guides. Next, AWS emailed affected customers and urged them to update any vulnerable configurations.

“The problem here is that \[many\] users weren’t aware of the vulnerable configuration and the response actions they should take. Either the email never made it to the right person, or it got lost in a sea of other issues,” Schindel and Tamari wrote.

In the context of cloud, affected users should be able to easily track a vulnerability and whether it has already been addressed in their organizations, as well as what cloud resources have already been scoped and fixed, the researchers said.

The CVE approach to cloud bugs also has the support of the Cloud Security Alliance (CSA), which counts Google, Microsoft and Oracle as executive members.

**Cloud Bug CVE Approach: Shared Industry Goals**

The efforts share many of the same goals, including:

*   Standardized notification channels to be used by all cloud service providers
*   Standardized bug or issue tracking
*   Severity scoring to help prioritize mitigation efforts
*   Transparency into the vulnerabilities and their detection

In August, Brian Martin, on his blog Curmudgeonly Ways, pointed out that MITRE’s history covering cloud vulnerabilities is mixed.

“At times, some of the CVE (editorial) Board has advocated for CVEs to expand to cover cloud vulnerabilities, while others argue against it. At least one who advocated for CVE coverage said they should get CVE IDs, \[with\] others that supported and disagreed with the idea saying that if cloud was covered, \[those bugs\] should get their own ID scheme,” he wrote.

Martin also pointed out that even if a CVE-like system were created, the question remains: Who will run it?

“The only thing worse than such a project not getting off the ground is one that does, becomes an essential part of security programs, and then goes away,” he said.

In July, under the auspices of CSA, the Global Security Database Working Group was chartered to go one step further than the idea of expanding CVE tracking. Its goal is to offer an alternative to CVEs and what the group called a one-size-fits-all approach to vulnerability identification. The working group believes the “on-demand” nature and continued growth of IT infrastructures brought on by cloud migration necessitate a corresponding maturity in cybersecurity.

“What we see is a need to figure out how to create identifiers for vulnerabilities in software, services and other IT infrastructure that is proportional to the amount of technology in existence,” said Jim Reavis, cofounder and chief executive officer of CSA, when introducing the working group. “The common design goal is for vulnerability identifiers to be easily discovered, fast to assign, updatable and publicly available” – not just in the cloud, but across IT infrastructure.

**_Moving to the cloud? Discover emerging cloud-security threats along with solid advice for how to defend your assets with our_** **_FREE downloadable eBook_****_, “Cloud Security: The Forecast for 2022.”_** **_We explore organizations’ top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists._**

Firms Push for CVE-Like Cloud Bug System

In Terramaster F4-210, F2-210 TOS 4.2.X (4.2.15-2107141517), an attacker can self-sign session cookies by knowing the target's MAC address and the user's password hash. Guest users (disabled by default) can be abused using a null/empty hash and allow an unauthenticated attacker to login as guest.

CVE-2021-45841: How to summon RCEs

It is possible to obtain the first administrator's hash set up in Terramaster F4-210, F2-210 TOS 4.2.X (4.2.15-2107141517) on the system as well as other information such as MAC address, internal IP address etc. by performing a request to the /module/api.php?mobile/wapNasIPS endpoint.

CVE-2021-45842: How to summon RCEs

The "hotpatch" released by Amazon Web Services (AWS) in response to the Log4Shell vulnerabilities could be leveraged for container escape and privilege escalation, allowing an attacker to seize control of the underlying host.
"Aside from containers, unprivileged processes can also exploit the patch to escalate privileges and gain root code execution," Palo Alto Networks Unit 42 researcher Yuval

Amazon's Hotpatch for Log4j Flaw Found Vulnerable to Privilege Escalation Bug

By Darin Smith.TeamTNT is actively modifying its scripts after they were made public by security researchers.These scripts primarily target Amazon Web Services, but can also run in on-premise, container, or other forms of Linux instances.The group's payloads include credential stealers,...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

TeamTNT targeting AWS, Alibaba

New research shows threat actors increasingly leveraging social networks for attacks, with LinkedIn being used in 52% of global phishing attacks.

Shipping, retail, and tech companies are no longer the most popular brands used to hide phishing attacks. Instead, social media platforms have become the brands of choice used to dupe victims and steal their personal data, with LinkedIn-related lures accounting for a full 52% of all global phishing attacks during January, February, and March of 2022, according to new data.

LinkedIn phishing-lure use exploded by 44% over the previous quarter, when it was used in just 8% of phishing attempts, according to Check Point's latest Brand Phishing Report.

"As well as LinkedIn being the most targeted brand by a considerable margin, WhatsApp maintained its position in the top ten, accounting for almost 1 in 20 phishing-related attacks worldwide," the report said.

Shipping is still a draw, even though LinkedIn overtook DHL as the brand most often used in phishing attacks. DHL is now the second-most abused brand, behind 14% of attempts during the same time period. FedEx moved up from seventh place to fifth over the past quarter, with 6% of all phishing attempts spoofing its brand.

**Check Point's List of Top 10 Abused Brands**  

1.  LinkedIn (accounting for 52% of all global phishing attacks over the quarter)
2.  DHL (14%)
3.  Google (7%)
4.  Microsoft (6%)
5.  FedEx (6%)
6.  WhatsApp (4%)
7.  Amazon (2%)
8.  Maersk (1%)
9.  AliExpress (0.8%)
10.  Apple (0.8%)

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

LinkedIn Brand Now the Most Abused in Phishing Attempts

Amazon AWS amazon-ssm-agent before 3.1.1208.0 creates a world-writable sudoers file, which allows local attackers to inject Sudo rules and escalate privileges to root. This occurs in certain situations involving a race condition.

Compare

Choose a tag to compare

**Amazon SSM Agent - Release 3.1.1208.0 - 2022-04-04**

![@mmcgovs](https://avatars.githubusercontent.com/u/95885330?s=40&v=4) mmcgovs released this

· 7 commits to mainline since this release

3.1.1208.0

`b3a8f2b`

Compare

Choose a tag to compare

*   Updated ec2detector module to use Get-CmiInstance instead of wmic.exe
*   Fixed file creation mode of ssm-agent-users sudoer file

**Assets**2

*   Source code (zip)
*   Source code (tar.gz)

Tag

#amazon