30,000 websites at risk: Check yours ASAP! (800 Million Ostriches Can’t Be Wrong.)

The post WordPress Plugin Supply Chain Attack Gets Worse appeared first on Security Boulevard.

Key Capabilities of Cyble Vision X include: 

• Attack Surface Management: Ensures digital security by identifying and mitigating threats.  

• Brand Intelligence: Comprehensive protection against online brand abuse, including brand impersonation, phishing, and fraudulent domains. 

• Cyber Threat Intelligence: Helps organizations gain insights and enhance their defense with AI-driven analysis and continuous threat monitoring. 

• Dark Web and Cyber Crime Monitoring: Helps organizations stay vigilant and ahead of cybercriminals 

• Third-Party Risk Management (TPRM):  Helps organizations identify, assess, and mitigate risks that may arise from a business's interactions with third parties. 

On June 25, 2024, Progress Software published information on two new vulnerabilities in MOVEit Transfer and MOVEit Gateway: CVE-2024-5806, a high-severity authentication bypass affecting the MOVEit Transfer SFTP service in a default configuration, and CVE-2024-5805, a critical SFTP-associated authentication bypass vulnerability affecting MOVEit Gateway. Attackers can exploit these improper authentication vulnerabilities to bypass SFTP authentication and gain access to MOVEit Transfer and Gateway.

CVE-2024-5806 is an improper authentication vulnerability affecting the MOVEit Transfer SFTP service that can lead to authentication bypass. Rapid7 researchers tested a MOVEit Transfer 2023.0.1 instance, which appeared to be vulnerable in the default configuration. As of June 25, the known criteria for exploitation are threefold: that attackers have knowledge of an existing username, that the target account can authenticate remotely, and that the SFTP service is exposed. It’s possible that attackers may spray usernames to identify valid accounts. Rapid7 recommends installing the vendor-provided patches for CVE-2024-5806 on an emergency basis, without waiting for a regular patch cycle to occur.

According to Progress Software’s advisory, CVE-2024-5805 is a critical authentication bypass vulnerability that affects the SFTP feature of the MOVEit Gateway software in version 2024.0.0; earlier versions do not appear to be vulnerable, which likely limits available attack surface area. MOVEit Gateway is an optional component designed to proxy traffic to and from MOVEit Transfer instances. A patch is available for CVE-2024-5805 and should be applied on an emergency basis for organizations running MOVEit Gateway.

Progress MOVEit is an enterprise file transfer suite, which inherently makes it a highly desirable target for threat actors. Since enterprise file transfer software typically holds a large volume of confidential data, smash-and-grab attackers target these solutions to extort victims. In June 2023, an unauthenticated attack chain targeting MOVEit Transfer was widely exploited by the Cl0p ransomware group. Shodan queries indicate that there are approximately 1,000 public-facing MOVEit Transfer SFTP servers and approximately 70 public-facing MOVEit Gateway SFTP servers. (Note that not all of these may be vulnerable to these latest CVEs.)

Notably, Rapid7 observed that installers for the patched (latest) version of the MOVEit Transfer have been available on VirusTotal since at least June 11, 2024. Vulnerability details and proof-of-concept exploit code are publicly available for MOVEit Transfer CVE-2024-5806 as of June 25, 2024. Security nonprofit Shadowserver has reported exploit attempts against their honeypots as of the evening of June 25 (note that honeypot activity does not always correlate to threat activit in real-world production environments).

Mitigation guidance

MOVEit customers should apply vendor-provided updates for both vulnerabilities immediately.

The following versions of MOVEit Transfer are vulnerable to CVE-2024-5806:

• MOVEit Transfer 2023.0.x (fixed in MOVEit Transfer 2023.0.11)
• MOVEit Transfer 2023.1.x (fixed in MOVEit Transfer 2023.1.6)
• MOVEit Transfer 2024.0.x (fixed in MOVEit Transfer 2024.0.2)

The advisory notes that “Customers using the MOVEit Cloud environment were patched and are no longer vulnerable to this exploit.”

Only MOVEit Gateway 2024.0.0 is vulnerable to CVE-2024-5805, per the vendor advisory. The vulnerability is fixed in MOVEit Gateway 2024.0.1. The advisory indicates that “MOVEit Cloud does not use MOVEit Gateway, so no further action is needed by MOVEit Cloud customers.”

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2024-5805 and CVE-2024-5806 with authenticated vulnerability checks available in today’s (June 25) content release.

Updates

June 25, 2024: Exploit attempts have been reported against honeypots. Rapid7 customer language updated to note general availability of InsightVM/Nexpose checks.

Safeguarding your Linux environment from potential threats is more critical than ever. Whether you’re managing a small server or an extensive network, having hands-on knowledge of intrusion detection systems (IDS) is essential. IDS tools play a vital role in maintaining the security and integrity of your system. This guide will walk you through the practical […]

The post Intrusion Detection in Linux: Protecting Your System from Threats appeared first on TuxCare.

The post Intrusion Detection in Linux: Protecting Your System from Threats appeared first on Security Boulevard.

The Gartner Security & Risk Management Summit 2024 showcased the transformative power of artificial intelligence (AI) across various industries, with a particular focus on the cybersecurity landscape. As organizations increasingly adopt AI for innovation and efficiency, it is crucial to understand the opportunities and challenges that come with this technology. Here are the top three […]

The post AI Everywhere: Key Takeaways from the Gartner Security & Risk Management Summit 2024 first appeared on SlashNext.

The post AI Everywhere: Key Takeaways from the Gartner Security & Risk Management Summit 2024 appeared first on Security Boulevard.

Azure Key Vault service offers a secure storage solution for cryptographic keys, API keys, passwords, and certificates in the cloud. However, managing this vault typically involves manual updates and additions by cloud administrators. Given the large volume of certificates and keys and the frequent updates they require, manual updates can become quite tedious and time-consuming. […]

The post Simplifying Azure Key Vault Updates With AppViewX Automation appeared first on Security Boulevard.

As per recent reports, cybersecurity experts uncovered a troubling development on the Python Package Index (PyPI) – a platform used widely by developers to find and distribute Python packages. A malicious package named ‘crytic-compilers‘ was discovered, mimicking the legitimate ‘crytic-compile’ library developed by Trail of Bits. This fraudulent package was designed with sinister intent: to […]

The post Python Developers Targeted Via Fake Crytic-Compilers Package appeared first on TuxCare.

The post Python Developers Targeted Via Fake Crytic-Compilers Package appeared first on Security Boulevard.

From banking to real estate, healthcare, ride sharing, and more, it’s increasingly clear that no...

The post Identity Fraud Does Not Discriminate appeared first on Entrust Blog.

The post Identity Fraud Does Not Discriminate appeared first on Security Boulevard.

Midway through 2024, we’ve moved beyond digital transformation to become digital first. From shopping to...

The post Digital Identity: There’s a Lot at Stake appeared first on Entrust Blog.

The post Digital Identity: There’s a Lot at Stake appeared first on Security Boulevard.

The problems with passwords drive the interest to adopt newer authentication methods, like passkeys, a type of passwordless technology.

The post Criminals are Easily Bypassing Passkeys – How Organizations Can Stay Safe appeared first on Security Boulevard.

The digital landscape is no longer solely populated by human actors. Lurking beneath the surface is a silent legion – non-human or machine identities . These non-human identities encompass computers, mobile devices, servers, workloads, service accounts, application programming interfaces (APIs), machine learning models, and the ever-expanding internet of things (IoT) devices. They are the backbone […]

The post The Impending Identity Crisis Of Machines: Why We Need To Secure All Non-Human Identities, From Genai To Microservices And IOT appeared first on Security Boulevard.

Our engineering team has been hard at work, reworking our flagship platform to enhance the Chariot platform to remain the most comprehensive and powerful CTEM platform on the market. So what’s new? Here are several new features recently added to Chariot: 1. Unmanaged Platform Chariot, Praetorian’s Continuous Threat Exposure Management (CTEM) solution, is now available […]

The post Chariot Continuous Threat Exposure Management (CTEM) Updates appeared first on Praetorian.

The post Chariot Continuous Threat Exposure Management (CTEM) Updates appeared first on Security Boulevard.

Copilot Plus? More like Copilot Minus: Redmond realizes Recall requires radical rethink.

The post Recall ‘Delayed Indefinitely’ — Microsoft Privacy Disaster is Cut from Copilot+ PCs appeared first on Security Boulevard.

Attack Path Management

Because Every Snowflake (Graph) is Unique

Introduction

On June 2nd, 2024, Snowflake released a joint statement with Crowdstrike and Mandiant addressing reports of “[an] ongoing investigation involving a targeted threat campaign against some Snowflake customer accounts.” A SpecterOps customer contacted me about their organization’s response to this campaign and mentioned that there seems to be very little security-based information related to Snowflake. In their initial statement, Snowflake recommended the following steps for organizations that may be affected (or that want to avoid being affected, for that matter!):

1. Enforce Multi-Factor Authentication on all accounts;
2. Set up Network Policy Rules to only allow authorized users or only allow traffic from trusted locations (VPN, Cloud workload NAT, etc.); and
3. Impacted organizations should reset and rotate Snowflake credentials.

While these recommendations are a good first step, I wondered if there was anything else we could do once we better grasped Snowflake’s Access Control Model (and its associated Attack Paths) and better understood the details of the attacker’s activity on the compromised accounts. In this post, I will describe the high-level Snowflake Access Control Model, analyze the incident reporting released by Mandiant, and provide instructions on graphing the “access model” of your Snowflake deployment.

These recommendations address how organizations might address initial access to their Snowflake instance. However, I was curious about “post-exploitation” in a Snowflake environment. After a quick Google search, I realized there is very little threat research on Snowflake. My next thought was to check out Snowflake’s access control model to better understand the access landscape. I hoped that if I could understand how users are granted access to resources in a Snowflake account, I could start to understand what attackers might do once they are authenticated. I also thought we could analyze the existing attack paths to make recommendations to reduce the blast radius of a breach of the type Crowdstrike and Mandiant reported.

While we have not yet integrated Snowflake into BloodHound Community Edition (BHCE) or Enterprise (BHE), we believe there is value in taking a graph-centric approach to analyzing your deployment, as it can help you understand the impact of a campaign similar to the one described in the intro to this post.

Snowflake Access Control Model

My first step was to search for any documentation on Snowflake’s access control model. I was pleased to find a page providing a relatively comprehensive and simple-to-understand model description. They describe their model as a mix of Discretionary Access Control, where “each object has an owner, who can in turn grant access to that object,” and Role-based Access Control, where “privileges are assigned to roles, which are in turn assigned to users.” These relationships are shown in the image below:

Notice that Role 1 “owns” Objects 1 and 2. Then, notice that two different privileges are granted from Object 1 to Role 2 and that Role 2 is granted to Users 1 and 2. Also, notice that Roles can be granted to other Roles, which means there is a nested hierarchy similar to groups in Active Directory. One thing that I found helpful was to flip the relationship of some of these “edges.” In this graphic, they are pointing toward the grant, but the direction of access is the opposite. Imagine that you are User 1, and you are granted Role 2, which has two Privileges on Object 1. Therefore, you have two Privileges on Object 1 through transitivity.

We have a general idea of how privileges on objects are granted, but what types of objects does Snowflake implement? They provide a graphic to show the relationship between these objects, which they describe as “hierarchical.”

Notice that at the top of the hierarchy, there is an organization. Each organization can have one or many accounts. For example, the trial I created to do this research has only one Account, but the client that contacted me has ~10. The Account is generally considered to be the nexus of everything. It is helpful to think of an Account as the equivalent of an Active Directory Domain. Within the Account are Users, Roles (Groups), Databases, Warehouses (virtual compute resources), and many other objects, such as Security Integrations. Within the Database context is a Schema, and within the Schema context are Tables, Views, Stages (temporary stores for loading/unloading data), etc.

As I began understanding the implications of each object and the types of privileges each affords, I started to build a model showing their possible relationships. In doing so, I found it helpful to start at the top of the hierarchy (the account) and work my way down with respect to integrating entity types into the model. This is useful because access to entities often depends on access to their parent. For example, a user can only interact with a schema if the user also has access to the schema’s parent database. This allows us to abstract away details and make educated inferences about lower-level access. Below, I will describe the primary objects that I consider in my model.

Account (think Domain)

The account is the equivalent to the domain. All objects exist within the context of the account. When you log into Snowflake, you log in as a user within a specific account. Most administrative privileges are privileges to operate on the account, such as CREATE USER, MANAGE GRANTS, CREATE ROLE, CREATE DATABASE, EXECUTE TASK, etc.

Users (precisely what you think they are)

Users are your identity in the Snowflake ecosystem. When you log into the system, you do so as a particular user, and you have access to resources based on your granted roles and the role’s granted privileges.

Roles (think Groups)

Roles are the primary object to which privileges are assigned. Users can be granted “USAGE” of a role, similar to being added as group members. Roles can also be granted to other roles, which creates a nested structure that facilitates granular control of privileges. There are ~ five default admin accounts. The first is ACCOUNTADMIN, which is the Snowflake equivalent of Domain Admin. The remaining four are ORGADMIN, SYSADMIN, SECURITYADMIN, and USERADMIN.

Warehouses

A Warehouse is “a cluster of computer resources… such as CPU, memory, and temporary storage” used to perform database-related operations in a Snowflake session. Operations such as retrieving rows from tables, updating rows in tables, and loading/unloading data from tables all require a warehouse.

Databases

A database is defined as “a logical grouping of schemas.” It is the container for information that we would expect attackers to target. While the database object itself does not contain any data, a user must have access to the database to access its subordinate objects (Schemas, Tables, etc.).

Privileges (think Access Rights)

Privileges define who can perform which operation on which resources. In our context, privileges are primarily assigned to roles. Snowflake supports many privileges, some of which apply in a global or account context (e.g., CREATE USER), while others are specific to an object type (e.g., CREATE SCHEMA on a Database). Users accumulate privileges through the Roles that they have been granted recursively.

Access Graph

With this basic understanding of Snowflake’s access control model, we can create a graph model that describes the relationships between entities via privileges. For instance, we know that a user can be granted the USAGE privilege of a role. This is the equivalent of an Active Directory user being a MemberOf a group. Additionally, we find that a role can be granted USAGE of another role, similar to group nesting in AD. Eventually, we can produce this relatively complete initial model for the Snowflake “access graph.”

This model can help us better understand what likely happened during the incident. It can also help us better understand the access landscape of our Snowflake deployment, which can help us reduce the blast radius should an attacker gain access.

About the Incident

As more details have emerged, it has become clear that this campaign targeted customer credentials rather than Snowflake’s production environment. Later, on June 10th, Mandiant released a more detailed report describing some of the threat group’s activity discovered during the investigation.

Mandiant describes a typical scenario where threat actors compromise the computers of contractors that companies hire to build, manage, or administer their Snowflake deployment. In many cases, these contractors already have administrative privileges, so any compromise of their credentials can lead to detrimental effects. The existing administrative privileges indicate that the threat actor had no need to escalate privilege via an attack path or compromise alternative identities during this activity.

Mandiant describes the types of activity the attackers were observed to have implemented. They appear interested in enumerating database tables to find interesting information for exfiltration. An important observation is that, based on the reported activity, the compromised user seems to have admin or admin-adjacent privileges on the Snowflake account.

In this section, we will talk about each of these commands, what they do and how we can understand them in the context of our graph.

As Mandiant describes, the first command is a Discovery command meant to list all the tables available. According to the documentation, a user requires at least the USAGE privilege on the Schema object that contains the table to execute this command directly. It is common for a production Snowflake deployment to have many databases, each with many schemas, so access to tables will likely be limited to most non-admins. We can validate this in the graph, though!

Next, we see that they run the SELECT command. This indicates that they must have found one or more tables from the previous command that interested them. This command works similarly to the SQL query and returns the rows in the table. In this case, they are dumping the entire table. The privilege documentation states that a user must have the SELECT privilege on the specified table (<Target Table>) to execute this command. Additionally, the user must have the USAGE privilege on the parent database (<Target Database>) and schema (<Target Schema>).

Like tables, stages exist within the schema context; thus, the requisite privilege, CREATE STAGE, exists at the schema level (aka <Redacted Schema>). The user would also require the USAGE privilege on the database (<Redacted Database>). Therefore, a user can have the ability to create a stage for one schema but not another. In general, this is a privilege that can be granted to a limited set of individuals, especially when it comes to sensitive databases/schemas.

Finally, the attackers call the COPY INTO command, which is a way to extract data from the Snowflake database. Obviously, Mandiant redacted the path, but one possible example would be to use the temporary stage to copy the data to an Amazon S3 bucket. In this case, the attacker uses the COPY INTO <location> variant, which requires the WRITE privilege. Of course, the attacker created the stage resource in the previous command, so they would likely have OWNERSHIP of the stage, granting them full control of the object.

Build Your Own Graph

At this point, some of you might be interested in checking out your Snowflake Access Graph. This section walks through how to gather the necessary Snowflake data, stand up Neo4j, and build the graph. It also provides some sample Cypher queries relevant to Snowflake’s recommendations.

Collecting Data

The first step is to collect the graph-relevant data from Snowflake. The cool thing is that this is actually a relatively simple process. I’ve found that Snowflake’s default web client, Snowsight, does a fine job gathering this information. You can navigate to Snowsight once you’ve logged in by clicking on the Query data button at the top of the Home page.

Once there, you will have the opportunity to execute commands. This section will describe the commands that collect the data necessary to build the graph. My parsing script is built for CSV files that follow a specific naming convention. Once your command has returned results, click the download button (downward pointing arrow) and select the “Download as .csv” option.

The model supports Accounts, Applications, Databases, Roles, Users, and Warehouses. This means we will have to query those entities, which will serve as the nodes in our graph. This will download the file with a name related to your account. My parsing script expects the output of certain commands to be named in a specific way. The expected name will be shared in the corresponding sections below.

I’ve found that I can query Applications, Databases, Roles, and Users as an unprivileged user. However, this is different for Accounts, which require ORGADMIN, and Warehouses, which require instance-specific access (e.g., ACCOUNTADMIN).

Applications

• Command: SHOW APPLICATIONS;
• File Name: application.csv

Databases

• Command: SHOW DATABASES;
• File Name: database.csv

Roles

• Command: SHOW ROLES;
• File Name: role.csv

Users

• Command: SHOW USERS;
• File Name: user.csv

Warehouses

• Command: SHOW WAREHOUSES;
• File Name: warehouse.csv

Note: As mentioned above, users can only enumerate warehouses for which they have been granted privileges. One way to grant a non-ACCOUNTADMIN user visibility of all warehouses is to grant the MANAGE WAREHOUSESprivilege.

Accounts

At this point, we have almost all the entity data we need. We have one final query that will allow us to gather details about our Snowflake account. This query can only be done by the ORGADMIN role. Assuming your user has been granted ORGADMIN, go to the top right corner of the browser and click on your current role. This will result in a drop-down that displays all of the roles that are effectively granted to your user. Here, you will select ORGADMIN, allowing you to run commands in the context of the ORGADMIN role.

Once complete, run the following command to list the account details.

• Command: SHOW ACCOUNTS;
• File Name: account.csv

Grants

Finally, we must gather information on privilege grants. These are maintained in the ACCOUNT_USAGE schema of the default SNOWFLAKE database. By default, these views are only available to the ACCOUNTADMIN role. Still, users not granted USAGE of the ACCOUNTADMIN role can be granted the necessary read access via the SECURITY_VIEWER database role. The following command does this (if run as ACCOUNTADMIN):

GRANT DATABASE ROLE snowflake.SECURITY_VIEWER TO <Role>

Once you have the necessary privilege, you can query the relevant views and export them to a CSV file. The first view is grants_to_users, which maintains a list of which roles have been granted to which users. You can enumerate this list using the following command. Then save it to a CSV file and rename it grants_to_users.csv.

SELECT * FROM snowflake.account_usage.grants_to_users;

The final view is grants_to_roles, which maintains a list of all the privileges granted to roles. This glue ultimately allows users to interact with the different Snowflake entities. This view can be enumerated using the following command. The results should be saved as a CSV file named grants_to_roles.csv.

SELECT * FROM snowflake.account_usage.grants_to_roles WHERE GRANTED_ON IN ('ACCOUNT', 'APPLICATION', 'DATABASE', 'INTEGRATION', 'ROLE', 'USER', 'WAREHOUSE'); 

Setting up Neo4j

At this point, we have a Cypher statement that we can use to generate the Snowflake graph, but before we can do that, we need a Neo4j instance. The easiest way that I know of to do this is to use the BloodHound Community Edition docker-compose deployment option.

Note: While we won’t use BHCE specifically in this demo, the overarching docker-compose setup includes a Neo4j instance configured to support this example.

To do this, you must first install Docker on your machine. Once complete, download this example docker-compose yaml file I derived from the BHCE GitHub repository. Next, open docker-compose.yaml in a text editor and edit Line 51 to point to the folder on your host machine (e.g., /Users/jared/snowflake:/var/lib/neo4j/import/) where you wrote the Snowflake data files (e.g., grants_to_roles.csv). This will create a bind mount between your host and the container. You are now ready to start the container by executing the following command:

docker-compose -f /path/to/docker-composer.yaml up -d

This will cause Docker to download and run the relevant Docker containers. For this Snowflake graph, we will interact directly with Neo4j as this model has not been integrated into BloodHound. You can access the Neo4j web interface by browsing to 127.0.0.1:7474 and logging in using the default credentials (neo4j:bloodhoundcommunityedition).

Data Ingest

Once you’ve authenticated to Neo4j, it is time for data ingest. I originally wrote a PowerShell script that would parse the CSV files and handcraft Cypher queries to create the corresponding nodes and edges, but SadProcessor showed me a better way to approach ingestion. He suggested using the LOAD CSV clause. According to Neo4j, “LOAD CSV is used to import data from CSV files into a Neo4j database.” This dramatically simplifies ingesting your Snowflake data AND is much more efficient than my initial PowerShell script. This section describes the Cypher queries that I use to import Snowflake data. Before you begin, knowing that each command must be run individually is essential. Additionally, these commands assume that you’ve named your files as suggested. Therefore, the file listing of the folder you specified in the Docker Volume (e.g., /Users/jared/snowflake) should look this:

-rwx------@ 1 cobbler  staff    677 Jun 12 20:17 account.csv
-rwx------@ 1 cobbler  staff    227 Jun 12 20:17 application.csv
-rwx------@ 1 cobbler  staff    409 Jun 12 20:17 database.csv
-rwx------@ 1 cobbler  staff   8362 Jun 12 20:17 grants_to_roles.csv
-rwx------@ 1 cobbler  staff    344 Jun 12 20:17 grants_to_users.csv
-rwx------@ 1 cobbler  staff    114 Jun 12 20:17 integration.csv
-rwx------@ 1 cobbler  staff    895 Jun 12 20:17 role.csv
-rwx------@ 1 cobbler  staff  12350 Jun 12 20:17 table.csv
-rwx------@ 1 cobbler  staff    917 Jun 12 20:17 user.csv
-rwx------@ 1 cobbler  staff    436 Jun 12 20:17 warehouse.csv

Note: If you don’t have a Snowflake environment, but still want to check out the graph, you can use my sample data set by replacing file:/// with https://gist.githubusercontent.com/jaredcatkinson/c5e560f7d3d0003d6e446da534a89e79/raw/c9288f20e606d236e3775b11ac60a29875b72dbc/ in each query.

Ingest Accounts

LOAD CSV WITH HEADERS FROM 'file:///account.csv' AS line
CREATE (:Account {name: line.account_locator, created_on: line.created_on, organization_name: line.organization_name, account_name: line.account_name, snowflake_region: line.snowflake_region, account_url: line.account_url, account_locator: line.account_locator, account_locator_url: line.account_locator_url})

Ingest Applications

LOAD CSV WITH HEADERS FROM 'file:///application.csv' AS line
CREATE (:Application {name: line.name, created_on: line.created_on, source_type: line.source_type, source: line.source})

Ingest Databases

LOAD CSV WITH HEADERS FROM 'file:///database.csv' AS line
CREATE (:Database {name: line.name, created_on: line.created_on, retention_time: line.retention_time, kind: line.kind})

Ingest Integrations

LOAD CSV WITH HEADERS FROM 'file:///integration.csv' AS line
CREATE (:Integration {name: line.name, created_on: line.created_on, type: line.type, category: line.category, enabled: line.enabled})

Ingest Roles

LOAD CSV WITH HEADERS FROM 'file:///role.csv' AS line
CREATE (:Role {name: line.name, created_on: line.created_on, assigned_to_users: line.assigned_to_users, granted_to_roles: line.granted_to_roles})

Ingest Users

LOAD CSV WITH HEADERS FROM 'file:///user.csv' AS line
CREATE (:User {name: line.name, created_on: line.created_on, login_name: line.login_name, first_name: line.first_name, last_name: line.last_name, email: line.email, disabled: line.disabled, ext_authn_duo: line.ext_authn_duo, last_success_login: line.last_success_login, has_password: line.has_password, has_rsa_public_key: line.has_rsa_public_key})

Ingest Warehouses

LOAD CSV WITH HEADERS FROM 'file:///warehouse.csv' AS line
CREATE (:Warehouse {name: line.name, created_on: line.created_on, state: line.state, size: line.size})

Ingest Grants to Users

LOAD CSV WITH HEADERS FROM 'file:///grants_to_users.csv' AS usergrant
CALL {
    WITH usergrant
    MATCH (u:User) WHERE u.name = usergrant.GRANTEE_NAME
    MATCH (r:Role) WHERE r.name = usergrant.ROLE
    MERGE (u)-[:USAGE]->(r)
}

Ingest Grants to Roles

:auto LOAD CSV WITH HEADERS FROM 'file:///grants_to_roles.csv' AS grant
CALL {
    WITH grant
    MATCH (src) WHERE grant.GRANTED_TO = toUpper(labels(src)[0]) AND src.name = grant.GRANTEE_NAME
    MATCH (dst) WHERE grant.GRANTED_ON = toUpper(labels(dst)[0]) AND dst.name = grant.NAME
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'USAGE' THEN [1] ELSE [] END | MERGE (src)-[:USAGE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'OWNERSHIP' THEN [1] ELSE [] END | MERGE (src)-[:OWNERSHIP]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLYBUDGET' THEN [1] ELSE [] END | MERGE (src)-[:APPLYBUDGET]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'AUDIT' THEN [1] ELSE [] END | MERGE (src)-[:AUDIT]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'MODIFY' THEN [1] ELSE [] END | MERGE (src)-[:MODIFY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'MONITOR' THEN [1] ELSE [] END | MERGE (src)-[:MONITOR]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'OPERATE' THEN [1] ELSE [] END | MERGE (src)-[:OPERATE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLY AGGREGATION POLICY' THEN [1] ELSE [] END | MERGE (src)-[:APPLY_AGGREGATION_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLY AUTHENTICATION POLICY' THEN [1] ELSE [] END | MERGE (src)-[:APPLY_AUTHENTICATION_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLY MASKING POLICY' THEN [1] ELSE [] END | MERGE (src)-[:APPLY_MASKING_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLY PACKAGES POLICY' THEN [1] ELSE [] END | MERGE (src)-[:APPLY_PACKAGES_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLY PASSWORD POLICY' THEN [1] ELSE [] END | MERGE (src)-[:APPLY_PASSWORD_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLY PROTECTION POLICY' THEN [1] ELSE [] END | MERGE (src)-[:APPLY_PROTECTION_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLY ROW ACCESS POLICY' THEN [1] ELSE [] END | MERGE (src)-[:APPLY_ROW_ACCESS_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'APPLY SESSION POLICY' THEN [1] ELSE [] END | MERGE (src)-[:APPLY_SESSION_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'ATTACH POLICY' THEN [1] ELSE [] END | MERGE (src)-[:ATTACH_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'BIND SERVICE ENDPOINT' THEN [1] ELSE [] END | MERGE (src)-[:BIND_SERVICE_ENDPOINT]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CANCEL QUERY' THEN [1] ELSE [] END | MERGE (src)-[:CANCEL_QUERY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE ACCOUNT' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_ACCOUNT]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE API INTEGRATION' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_API_INTEGRATION]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE APPLICATION' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_APPLICATION]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE APPLICATION PACKAGE' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_APPLICATION_PACKAGE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE COMPUTE POOL' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_COMPUTE_POOL]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE CREDENTIAL' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_CREDENTIAL]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE DATA EXCHANGE LISTING' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_DATA_EXCHANGE_LISTING]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE DATABASE' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_DATABASE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE DATABASE ROLE' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_DATABASE_ROLE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE EXTERNAL VOLUME' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_EXTERNAL_VOLUME]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE INTEGRATION' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_INTEGRATION]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE NETWORK POLICY' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_NETWORK_POLICY]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE REPLICATION GROUP' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_REPLICATION_GROUP]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE ROLE' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_ROLE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE SCHEMA' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_SCHEMA]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE SHARE' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_SHARE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE USER' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_USER]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'CREATE WAREHOUSE' THEN [1] ELSE [] END | MERGE (src)-[:CREATE_WAREHOUSE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'EXECUTE DATA METRIC FUNCTION' THEN [1] ELSE [] END | MERGE (src)-[:EXECUTE_DATA_METRIC_FUNCTION]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'EXECUTE MANAGED ALERT' THEN [1] ELSE [] END | MERGE (src)-[:EXECUTE_MANAGED_ALERT]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'EXECUTE MANAGED TASK' THEN [1] ELSE [] END | MERGE (src)-[:EXECUTE_MANAGED_TASK]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'EXECUTE TASK' THEN [1] ELSE [] END | MERGE (src)-[:EXECUTE_TASK]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'IMPORT SHARE' THEN [1] ELSE [] END | MERGE (src)-[:IMPORT_SHARE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'MANAGE GRANTS' THEN [1] ELSE [] END | MERGE (src)-[:MANAGE_GRANTS]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'MANAGE WAREHOUSES' THEN [1] ELSE [] END | MERGE (src)-[:MANAGE_WAREHOUSES]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'MANAGEMENT SHARING' THEN [1] ELSE [] END | MERGE (src)-[:MANAGEMENT_SHARING]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'MONITOR EXECUTION' THEN [1] ELSE [] END | MERGE (src)-[:MONITOR_EXECUTION]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'OVERRIDE SHARE RESTRICTIONS' THEN [1] ELSE [] END | MERGE (src)-[:OVERRIDE_SHARE_RESTRICTIONS]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'PURCHASE DATA EXCHANGE LISTING' THEN [1] ELSE [] END | MERGE (src)-[:PURCHASE_DATA_EXCHANGE_LISTING]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'REFERENCE USAGE' THEN [1] ELSE [] END | MERGE (src)-[:REFERENCE_USAGE]->(dst))
    FOREACH (_ IN CASE WHEN grant.PRIVILEGE = 'USE ANY ROLE' THEN [1] ELSE [] END | MERGE (src)-[:USE_ANY_ROLE]->(dst))
} IN TRANSACTIONS

Once you finish executing these commands you can validate that the data is in the graph by running a query. The query below returns any entity with a path to the Snowflake account.

MATCH p=()-[*1..]->(a:Account)
RETURN p

This is a common way to find admin users. While Snowflake has a few default admin Roles, such as ACCOUNTADMIN, ORGADMIN, SECURITYADMIN, SYSADMIN, and USERADMIN, granting administrative privileges to custom roles is possible.

Queries

Having a graph is great! However, the value is all about the questions you can ask. I’ve only been playing around with this Snowflake graph for a few days. Still, I created a few queries that will hopefully help you gather context around the activity reported in Mandiant’s report and your compliance with Snowflake’s recommendations.

Admins without MFA

Snowflake’s primary recommendation to reduce your exposure to this campaign and others like it is to enable MFA on all accounts. While achieving 100% coverage on all accounts may take some time, they also recommend enabling MFA on users who have been granted the ACCOUNTADMIN Role. Based on my reading of the reporting, the attackers likely compromised the credentials of admin users, so it seems reasonable to start with these highly privileged accounts first.

There are two approaches to determining which users have admin privileges. The first is to assume that admins will be granted one of the default admins roles, as shown below:

MATCH p=((n:User WHERE n.ext_authn_duo = "false")-[:USAGE*1..]->(r:Role WHERE r.name CONTAINS "ADMIN"))
RETURN p

Here, we see seven users who have been granted USAGE of a role with the string “ADMIN” in its name. While this is a good start, the string “ADMIN” does not necessarily mean that the role has administrative privileges, and its absence does not mean that the role does not have administrative privileges. Instead, I recommend searching for admins based on their effective privileges.

This second query considers that admin privileges can be granted to custom roles. For example, the MANAGE_GRANTS privilege, shown below, “grants the ability to grant or revoke privileges on any object as if the invoking role were the owner of the object.” This means that if a user has this privilege, they can grant themselves or anyone access to any object they want.

MATCH p=((n:User WHERE n.ext_authn_duo = "false")-[:USAGE*1..]->(r:Role)-[:MANAGE_GRANTS]->(a:Account))
RETURN p

Here, we see five users not registered for MFA who have MANAGE_GRANTS over the Snowflake Account. Two users are granted USAGE of the ACCOUNTADMINS role, and the other three are granted USAGE of a custom role. Both ACCOUNTADMINS and the custom role are granted USAGE of the SECURITYADMINS role, which is granted MANAGE_GRANTS on the account.

Restated in familiar terms, two users are members of the ACCOUNTADMINS group, which is nested inside the SECURITYADMINS group, which has SetDACL right on the Domain Head.

User Access to a Database

According to Mandiant, most of the attacker’s actions focused on data contained within database tables. While my graph does not currently support schema or table entities, it is important to point out that the documentation states that “operating on a table also requires the USAGE privilege on the parent database and schema.” This means that we can use the graph to understand which users have access to which database and then infer that they likely have access to the schema and tables within the database.

MATCH p=((u:User)-[:USAGE*1..]->(r:Role)-[:OWNERSHIP]->(d:Database WHERE d.name = "<DATABASE NAME GOES HERE>"))
RETURN p

Here, the Jared and SNOWFLAKE users have OWNERSHIP of the SNOWFLAKE_SAMPLE_DATA database via the ACCOUNTADMIN role.

This query shows all users that have access to a specified databases. If you would like to check access to all databases you can run this query:

MATCH p=((u:User)-[:USAGE*1..]->(r:Role)-[]->(d:Database))
RETURN p

Stale User Accounts

Another simple example is identifying users that have never been used (logged in to). Pruning unused users might reduce the overall attack surface area.

MATCH (n:User WHERE n.last_success_login = "")
RETURN n

Conclusion

I hope you found this overview and will find this graph capability useful. I’m looking forward to your feedback regarding the graph! If you write a useful query, please share it, and I will put it in the post with credit. Additionally, if you think of extending the graph, please let me know, and I’ll do my best to facilitate it.

Before I go, I want to comment on Snowflake’s recommendations in the aftermath of this campaign. As I mentioned, Snowflake’s primary recommendation is to enable MFA on all accounts. It is worth mentioning, in their defense, that Snowflake has always (at least since before this incident) recommended that MFA be enabled on any user granted the ACCOUNTADMIN role (the equivalent of Domain Admin).

That being said, the nature of web-based platforms means that if an attacker compromises a system with a Snowflake session, they likely can steal the session token and reuse it even if the user has MFA enabled. Austin Baker, who goes by @BakedSec on Twitter, pointed this out.

This indicates that we must look beyond how we stop attackers from getting access. We must understand the access landscape within our information systems. Ask yourself, “Can you answer which users can use the DATASCIENCE Database in your Snowflake deployment?” With this graph, that question is trivial to answer, but without one, we find that most organizations cannot answer these questions accurately. When nested groups (roles in this case) are involved, it is very easy for there to be a divergence between intended access and effective access. This only gets worse over time. I think of it as entropy.

We must use a similar approach for cloud accounts as on-prem administration. You don’t browse the web with your Domain Administrator account. No, you have two accounts, one for administration and one for day-to-day usage. You might even have a system that is dedicated to administrative tasks. These same ideas should apply to cloud solutions like Snowflake. Are you analyzing the data in a table? Great, use your Database Reader account. Now you need to grant Luke a role so he can access a warehouse? Okay, hop on your Privileged Access Workstation and use your SECURITYADMIN account. The same Tier 0 concept applies in this context. I look forward to hearing your feedback!

UPDATE: Luke Jennings from Push Security added a new technique to the SaaS Attack Matrix called Session Cookie Theft. This technique shows one way that attackers, specifically if they have access to the SaaS user’s workstation, can steal relevant browser cookies in order to bypass MFA. This does not mean that organizations should not strive to enable MFA on their users, especially admin accounts, however it does demonstrate the importance of reducing attack paths within the SaaS application’s access control model. One way to think of it is that MFA is meant to make it more difficult for attackers to get in, but once they’re in it is all about Attack Paths. The graph approach I demonstrate in this post is the first step to getting a handle of these Attack Paths to reduce the blast radius of a compromise.

Mapping Snowflake’s Access Landscape was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Mapping Snowflake’s Access Landscape appeared first on Security Boulevard.

Location tracking service leaks PII, because—incompetence? Seems almost TOO easy.

The post Tile/Life360 Breach: ‘Millions’ of Users’ Data at Risk appeared first on Security Boulevard.

Check Point has issued an alert regarding a critical zero-day vulnerability identified in its Network Security gateway products. As per the Check Point warning This vulnerability, tracked as CVE-2024-24919 with a CVSS score of 8.6, has been actively exploited by threat actors in the wild. The affected products include CloudGuard Network, Quantum Maestro, Quantum Scalable […]

The post Check Point Warning: VPN Gateway Products’ Zero-Day Attack appeared first on TuxCare.

The post Check Point Warning: VPN Gateway Products’ Zero-Day Attack appeared first on Security Boulevard.

When considering the most significant cyber threats to the public sector, many immediately think of foreign adversaries breaching federal agencies. This perception is understandable, as nation-state cyber attacks often dominate headlines. However, the real threat might be closer to home. Imagine if the breach originated from within the agency itself – if a nation-state or … Continued

The post “Mission Possible”: How DTEX is Supporting National Security from the Inside Out appeared first on DTEX Systems Inc.

The post “Mission Possible”: How DTEX is Supporting National Security from the Inside Out appeared first on Security Boulevard.

It’s June 2024 Patch Tuesday. Microsoft is addressing 51 vulnerabilities today, and has evidence of public disclosure for just a single one of those. At time of writing, none of the vulnerabilities published today are listed on CISA KEV, although this is always subject to change. Microsoft is patching a single critical remote code execution (RCE) vulnerability today. Seven browser vulnerabilities were published separately this month, and are not included in the total.

MSMQ: critical RCE

The sole critical RCE patched today is CVE-2024-30080 for all current versions of Windows. Exploitation requires that an attacker send a specially crafted malicious packet to an MSMQ server, which Patch Tuesday watchers will know as a perennial source of vulnerabilities. As usual, Microsoft points out that the Windows message queuing service is not enabled by default; as usual, Rapid7 notes that a number of applications – including Microsoft Exchange – quietly introduce MSMQ as part of their own installation routine. As is typical of MSMQ RCE vulnerabilities, CVE-2024-30080 receives a high CVSSv3 base score due to the network attack vector, low attack complexity, and lack of required privileges. Code execution is presumably in a SYSTEM context, although the advisory does not specify.

Office: malicious file RCEs

Microsoft Office receives patches for a pair of RCE-via-malicious-file vulnerabilities. CVE-2024-30101 is a vulnerability in Outlook; although the Preview Pane is a vector, the user must subsequently perform unspecified specific actions to trigger the vulnerability and the attacker must win a race condition. On the other hand, CVE-2024-30104 does not have the Preview Pane as a vector, but nevertheless ends up with a slightly higher CVSS base score of 7.8, since exploitation relies solely on the user opening a malicious file.

SharePoint: RCE

This month also brings a patch for SharePoint RCE CVE-2024-30100. The advisory is sparing on details, and the context of code exploitation is not clear. The weakness is described as CWE-426: Untrusted Search Path; many (but not all) vulnerabilities associated with CWE-426 lead to elevation of privilege.

DNSSEC NSEC3: CPU exhaustion DoS

And now for something completely different: ​​CVE-2023-50868, which describes a denial of service vulnerability in DNSSEC. This vulnerability is present in the DNSSEC spec itself, and the CVE was assigned by MITRE on behalf of DNSSEC. Microsoft’s implementation of DNSSEC is thus subject to the same attack as other implementations. An attacker can exhaust CPU resources on a DNSSEC-validating DNS resolver by demanding responses from a DNSSEC-signed zone, if the resolver uses NSEC3 to respond to the request. NSEC3 is designed to provide a safe way for a DNSSEC-validating DNS resolver to indicate that a requested resource does not exist. Under certain circumstances, the DNS resolver must perform thousands of iterations of a hash function to calculate an NSEC3 response, and this is the foundation on which this DoS exploit rests. All current versions of Windows Server receive a patch today.

Typically, when Microsoft publishes a security advisory and describes the vulnerability as publicly disclosed, that public disclosure will have been recent. However, in the case of CVE-2023-50868, the flaw in DNSSEC was first publicly disclosed on 2024-02-13. The advisory acknowledges four academics from the German National Research Centre for Applied Cybersecurity (ATHENE), which is perhaps of interest since these same researchers are authors on a March 2024 academic paper that downplays the DoS potential of CVE-2023-50868. Those same researchers published another DNSSEC flaw CVE-2023-50387 (also known as KeyTrap) in January 2024, which they describe as having potentially serious implications; Microsoft patched that one at the next scheduled opportunity in February. The CVE-2023-50868 advisory published today does not provide further insight as to why this vulnerability wasn’t patched sooner; a reasonable assumption might be that Microsoft assesses CVE-2023-50868 as less urgent/critical than CVE-2023-50387, although both receive a rating of Important on Microsoft’s proprietary severity ranking scale. It’s also possible that Microsoft does not wish to be the only major server OS vendor without a patch.

Lifecycle update

There are no significant changes to the lifecycle phase of Microsoft products this month. In July, Microsoft SQL Server 2014 will move past the end of extended support. From August onwards, Microsoft only guarantees to provide SQL Server 2014 security updates to customers who choose to participate in the paid Extended Security Updates program.

Summary Charts

Summary Tables

Azure vulnerabilities

Browser vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

Microsoft Dynamics vulnerabilities

Microsoft Office vulnerabilities

Windows vulnerabilities

Windows ESU vulnerabilities

Updates

• 2024-06-12: Corrected a typo in a reference to CVE-2023-50868.

On June 5, 2024, SolarWinds disclosed CVE-2024-28995, a high-severity directory traversal vulnerability affecting their Serv-U file transfer server, which comes in two editions (Serv-U FTP and Serv-U MFT). Successful exploitation of the vulnerability allows unauthenticated attackers to read sensitive files on the target server. Rapid7’s vulnerability research team has reproduced the vulnerability and confirmed that it’s trivially exploitable and allows an external unauthenticated attacker to read any file on disk, including binary files, so long as they know the path and the file is not locked (i.e., opened exclusively by something else).

CVE-2024-28995 is not known to be exploited in the wild as of 9 AM ET on June 11. We expect this to change; Rapid7 recommends installing the vendor-provided hotfix (Serv-U 15.4.2 HF 2) immediately, without waiting for a regular patch cycle to occur.

High-severity information disclosure issues like CVE-2024-28995 can be used in smash-and-grab attacks where adversaries gain access to and attempt to quickly exfiltrate data from file transfer solutions with the goal of extorting victims. File transfer products have been targeted by a wide range of adversaries the past several years, including ransomware groups.

Internet exposure estimates for SolarWinds Serv-U vary substantially based on the query used — e.g., 9,470 Serv-U instances by one count vs. 5,434 using a different query. (Note that exposed does not automatically mean vulnerable, however.)

Mitigation guidance

SolarWinds Serv-U 15.4.2 HF 1 and previous versions are vulnerable to CVE-2024-28995, per the vendor advisory. The vulnerability is fixed in SolarWinds Serv-U 15.4.2 HF 2. SolarWinds Serv-U customers should apply the vendor-provided hotfix immediately.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2024-28995 with an unauthenticated vulnerability check available as of the Monday, June 10 content release.

InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and may alert on post-exploitation behavior related to this vulnerability:

• Suspicious Web Server Request - Successful Path Traversal Attack

Not our fault, says CISO: “UNC5537” breached at least 165 Snowflake instances, including Ticketmaster, LendingTree and, allegedly, Advance Auto Parts.

The post Ticketmaster is Tip of Iceberg: 165+ Snowflake Customers Hacked appeared first on Security Boulevard.

Ghostwriter v4.2: Project Documents & Reporting Enhancements

After April’s massive Ghostwriter v4.1 release, we received some great feedback and ideas. We got a little carried away working on these and created a release so big we had to call it v4.2. This release contains some fantastic changes and additions to the features introduced in April’s release. Let’s get to the highlights!

Improving Customizable Fields

Ghostwriter v4.1 introduced custom fields, and seeing the community use them so creatively was awesome. What we saw gave us some ideas for a few big improvements.

The rich text fields support the Jinja2 templating language, so loops quickly became a talking point. Looping over project objectives, findings, hosts, and other things to create dynamic lists, table rows, or sections is incredibly powerful, so we had to do it.

You can now use Jinja2-style expressions with the new li, tr, and p tags to create list items, table rows, and text sections. Here is an example of building a dynamic list inside Ghostwriter’s WYSIWYG editor.

This screenshot includes examples of a few notable features. We’re using the new li tag with a for loop to create a bulleted list of findings. We have access to Jinja2 filters, including Ghostwriter’s custom filters, so we use the filter_severity filter to limit the loop to findings with a severity rating matching critical, high, or medium. The first and last bullets won’t be in the list in the final Word document.

The middle bullet will repeat for each finding to create our list. It includes the title and severity and uses the regex_search filter to pull the first sentence of the finding’s description. The use of severity_rt here is also worth a call-out. Some community members asked about nesting rich text fields inside of other rich text fields, like the pre-formatted severity_rt text for a finding. Not only can we use severity_rt inside this field, but we can also add formatting, like changing the text to bold.

Here is the above list rendered in a Word document. The pre-formatted finding.severity_rt appears with the proper color formatting and the bold formatting added in the WYSIWYG editor.

These additions introduced some complexity. A typo or syntax mistake could break the Jinja2 templating and prevent a report from generating, and the resulting error message wasn’t always helpful for tracking down the offending line of text. To help with this, Ghostwriter v4.2 validates your Jinja2 when you save your work, so you don’t need to worry about accidentally saving any invalid Jinja2 and causing a headache later on.

Validating the Jinja2 didn’t cover every possible issue, though. Even valid Jinja2 can fail to render if the report data causes an error (e.g., trying to divide by zero or referencing a non-existent value). To help with that, we significantly improved error handling to catch Jinja2 syntax and template errors at render time and surface more helpful information about them. When content prevents a report from generating, error messages point to the report’s section containing the problem.

In this example, a field called exec_summ contains this Jinja2 statement: {{ 100/0 }}. That’s valid Jinja2, but you can’t actually divide by zero, so rendering will always fail. With Ghostwriter v4.2’s error handling enhancements, the error message will direct us to the field name and include information we can use to track down the problem.

More Reporting Improvements

Ghostwriter v4.2 also includes enhancements to the reporting engine. The most significant change is the introduction of project documents. You don’t always need to generate a full report with findings. You may need to generate other project-related documents before or after the assessment is done, like rules of engagement, statement of work, or attestation of testing documents. You could technically do this with older versions of Ghostwriter by generating a report with a different template, but that was not intuitive.

The project dashboard’s Reports tab is now called Reporting and contains an option to generate JSON, docx, or pptx reports with your project’s data. This works like the reports you’re familiar with but uses only the project data (e.g., no findings or report-specific values).

We wanted to make it easier to generate project documents like this because custom fields open up many possibilities. For example, at SpecterOps, we provide clients with daily status reports after each day of testing. We can accomplish this task with a Daily Status Report field added to projects and the new project reporting feature. Consultants can now easily collaborate on updates to the daily status and then generate their daily status document from the same dashboard.

That’s not all, though. We realized one globally configured report filename would never apply to every possible document or report you might want to generate, so we made some changes. The biggest change is that your filename can now be configured using Jinja2-style templating with access to your project data, familiar filters, and a few additional values (e.g., `now` to include the current date and time). That means you can configure a filename like this that dynamically includes information about your project, client, and more:

{{now|format_datetime(“Y-m-d”)}} {{company_name}} — {{client.name}} {{project.project_type}} Report

That template would produce a filename like 2024–06–05 Acme Corp — SpecterOps Red Team Report.docx. That’s great for a default, but you’d probably be renaming documents often as you expanded the types of documents generated with Ghostwriter. To help with that, we made it possible to configure separate global defaults for reports and project documents.

We also added the option to override the filename per template! To revisit the daily status report example, your Word template for such a report can override the global filename template with a filename template like {{now|format_datetime(“Y-m-d”)}} {{company_name}} Daily Status Report.

Another enhancement for this feature is a third template type, Project DOCX. You can use this to flag Microsoft Word templates that are intended only for project documents. Templates flagged with this type will only appear in the dropdown menu on the project dashboard. This will keep them out of the list of templates for your reports.

Finally, Ghostwriter v4.2 also includes a feature proposed by community member Dominic Whewell, support for templating the document properties in your Word templates. If you set values like the document title, author(s), and company, you can now do that in your templates and let Ghostwriter fill in that information for you.

Background Tasks with Cron

Ghostwriter v4.2 also contains various bug fixes and quality-of-life improvements. There are too many details here, but one worth mentioning is support for cron expressions with scheduled background tasks. Previously, you could schedule tasks to run at certain time intervals, but you couldn’t control some of the finer points, like the day of the week.

You can now use cron to schedule a task on a more refined schedule, like only on a specific day of the week or weekdays. When scheduling a task, select Cron for the Schedule Type and provide a cron expression–e.g., 00 12 * * 1–5 to run the task every weekday at 12:00.

Check out the full CHANGELOG for all the details on this release.

Release Ghostwriter v4.2.0 · GhostManager/Ghostwriter

Ghostwriter v4.2 was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Ghostwriter v4.2 appeared first on Security Boulevard.

In a recent webinar with Verizon, we discussed how organizations measure and prioritize their vulnerabilities. We reviewed insights from Verizon’s 2024 Data Breach Investigations Report, and double-clicked on data to answer several other key questions, such as: Is the Common Vulnerability Scoring System (CVSS) sufficient for prioritization? Does Exploit Prediction Scoring Systems (EPSS) with CVSS …

Read More

The post Is CVSS Alone Failing Us? Insights From Our Webinar With Verizon appeared first on Security Boulevard.

In today's fast-paced digital landscape, conducting a cyber risk assessment is crucial for organizations to safeguard their assets and maintain a robust security posture. A cyber risk assessment evaluates potential threats and vulnerabilities, providing actionable insights to mitigate risks and protect sensitive information. As the control environment evolves rapidly, it is essential to regularly update these reports to reflect the latest changes and trends, ensuring that security professionals have accurate and current data to guide their decisions.

The post How to Create a Cyber Risk Assessment Report appeared first on Security Boulevard.

It remembers everything you do on your PC. Security experts are raging at Redmond to recall Recall.

The post Microsoft Recall is a Privacy Disaster appeared first on Security Boulevard.

Automated patch management is one important way to reduce the barrage of cyberattacks and guard against vulnerabilities.

The post Automation Takes Off: A New Dawn for Enterprises to Guard Against the Cyberattack Barrage appeared first on Security Boulevard.

Maintaining a robust and efficient Public Key Infrastructure (PKI) has never been more important for digital security. PKI is not only used to protect public-facing websites and applications but also to secure machine-to-machine communications across a wide range of enterprise use cases, ensuring data privacy and integrity. As the application of PKI expands, there is […]

The post 7 Reasons Why You Need To Replace Your Microsoft CA appeared first on Security Boulevard.

San Mateo, Calif. – JUNE 6, 2024 – Symmetry Systems, the data+AI security company, today announced it has been named...

The post Symmetry Systems Recognized as a Strong Performer in the 2024 Gartner® Peer Insights™ Voice of the Customer for Data Security Posture Management report appeared first on Symmetry Systems.

The post Symmetry Systems Recognized as a Strong Performer in the 2024 Gartner® Peer Insights™ Voice of the Customer for Data Security Posture Management report appeared first on Security Boulevard.

Snowflake, Inc. says NO, threatening legal action against those who say it was. But reports are coming in of several more massive leaks from other Snowflake customers.

The post Was the Ticketmaster Leak Snowflake’s Fault? appeared first on Security Boulevard.

Artificial intelligence (AI) in cybersecurity presents a complex picture of risks and rewards. According to Hyperproof’s 5th annual benchmark report, AI technologies are at the forefront of both enabling sophisticated cyberattacks and bolstering defenses against them. This duality underscores the critical need for nuanced application and vigilant management of AI in cybersecurity risk management practices....

The post The Dual Edges of AI in Cybersecurity: Insights from the 2024 Benchmark Survey Report appeared first on Hyperproof.

The post The Dual Edges of AI in Cybersecurity: Insights from the 2024 Benchmark Survey Report appeared first on Security Boulevard.

Rapid7 recently released our 2024 Attack Intelligence Report, a 14-month deep dive into the vulnerability and attacker landscape. The spiritual successor to our annual Vulnerability Intelligence Report, the AIR includes data from the Rapid7 research team combined with our detection and response and threat intelligence teams. It is designed to provide the clearest view yet into what security professionals face day to day.

In this blog, we would like to focus on one area of research the AIR highlights: network edge technologies. In 2023 (and early 2024) Rapid7 found some startling information about the vulnerability of these critical devices. Essentially, of the mass compromise events we studied, exploitation of network edge tech increased significantly over the 14 months the report covers — something we will cover in detail shortly.

But first, some background. Way back in 2020, Rapid7 created a new attacker utility category for vulnerabilities that functioned as network pivots. These are vulnerabilities that give external attackers internal network access. Think VPNs, firewalls, security gateways, etc. They serve an important function in any network but visibility into these devices can be challenging, making them prime targets for attackers.

In 2023 we saw a surge in attacks on these network appliances. Mass compromise events stemming from exploitation of network edge tech nearly doubled over the period studied — with 36% of all widely exploited vulnerabilities occurring within network perimeter technology. Looking back over the previous reports, we determined some 60% of all of the vulnerabilities Rapid7 analyzed in network edge devices over a three year period were exploited as zero-days, a disproportionate number when looking at the entirety of the vulnerabilities studied.

Over the four years Rapid7 has been categorizing this type of vulnerability, network edge devices have comprised 24% of exploited vulnerabilities and a quarter of all widespread threats.

State-sponsored groups and ransomware groups like Cl0p, Inc, Bl00dy, Akira, Play, LockBit, and more went after network edge tech in 2023. Network edge devices are essential for modern network operations, but they also represent a major weak spot in cybersecurity defenses — one that these organized groups took advantage of in 2023.

There are a number of reasons for this. It can be difficult to detect intrusions on these types of devices as the capabilities for logging and threat detection vary depending on the specific devices used. Some do not log key events, they use a variety of firmware and (often proprietary) operating systems, and in some cases the firmware itself may be encrypted or obfuscated. This makes monitoring and detecting intrusions troublesome across different devices and developing a strategy for the entire spectrum of devices complex.

For more information about network edge technology vulnerabilities, as well as the latest data on ransomware, attacker utilities, widespread threats, file transfer vulns, and more, download the 2024 Attack Intelligence Report.

The post A Step-by-Step Video Guide to Using Fortra VM- Series #3 appeared first on Digital Defense.

The post A Step-by-Step Video Guide to Using Fortra VM- Series #3 appeared first on Security Boulevard.

Three-quarters of SMBs fear that a cyberattack could put them out of business. For good reason: 96% of them have already been the victims of a cyberattack.

The post Cyberattack Risks Keep Small Business Security Teams on Edge appeared first on Security Boulevard.

May brought a fresh batch of security headaches. This month, we’re focusing on critical vulnerabilities in widely used software like Apache, Gitlab, and Github. These flaws could allow attackers to...

The post Top 5 CVEs and Vulnerabilities of May 2024 appeared first on Strobes Security.

The post Top 5 CVEs and Vulnerabilities of May 2024 appeared first on Security Boulevard.

Daft name, serious risk: Kit from ActionTec and Sagemcom remotely ruined and required replacement.

The post ‘Pumpkin Eclipse’ — 600,000+ Rural ISP Routers Bricked Beyond Repair appeared first on Security Boulevard.

On May 28, 2024, Check Point published an advisory for CVE-2024-24919, a high-severity information disclosure vulnerability affecting Check Point Security Gateway devices configured with either the “IPSec VPN” or “Mobile Access” software blade.

On May 29, 2024, security firm mnemonic published a blog reporting that they have observed in-the-wild exploitation of CVE-2024-24919 since April 30, 2024, with threat actors leveraging the vulnerability to enumerate and extract password hashes for all local accounts, including accounts used to connect to Active Directory. They’ve also observed adversaries moving laterally and extracting the “ntds.dit” file from compromised customers' Active Directory servers, within hours of an initial attack against a vulnerable Check Point Gateway.

On May 30, 2024, watchTowr published technical details of CVE-2024-24919 including a PoC.

On May 31, 2024, Check Point updated their advisory to state that further analysis has revealed that the first exploitation attempts actually began on April 7, 2024, and not April 30 as previously thought.

The vulnerability allows an unauthenticated remote attacker to read the contents of an arbitrary file located on the affected appliance. For example, this allows an attacker to read the appliances /etc/shadow file, disclosing the password hashes for local accounts. The attacker is not limited to reading this file and may read other files that contain sensitive information. An attacker may be able to crack the password hashes for these local accounts, and if the Security Gateway allows password only authentication, the attacker may use the cracked passwords to authenticate.

Mitigation Guidance

According to the vendor advisory, the following products are vulnerable to CVE-2024-24919:

• CloudGuard Network
• Quantum Maestro
• Quantum Scalable Chassis
• Quantum Security Gateways
• Quantum Spark Appliances
  

Check Point has advised that a Security Gateway is vulnerable if one of the following configuration is applied:

• If the “IPSec VPN” blade has been enabled and the Security Gateway device is part of the “Remote Access” VPN community.
• If the “Mobile Access” blade has been enabled.
  

Check Point has released hotfixes for Quantum Security Gateway, Quantum Maestro, Quantum Scalable Chassis, and Quantum Spark Appliances. We advise customers to refer to the Check Point advisory for the most current information on affected versions and hotfixes.

Notably, the vendor advisory now calls out a non-default “CCCD” feature, stating “Customers who use CCCD must disable this functionality for the Hotfix to be effective.” All organizations should manually confirm that the CCCD feature is disabled on every patched Check Point device. Per the vendor advisory, the command vpn cccd status should be executed in “Expert Mode” on appliances to confirm that CCCD is disabled.

The vendor supplied hotfixes should be applied immediately. Rapid7 strongly recommends that Check Point Security Gateway customers examine their environments for signs of compromise and reset local account credentials in addition to applying vendor-provided fixes.

Check Point notes that exploit attempts their team has observed “focus on remote access scenarios with old local accounts with unrecommended password-only authentication.” The company recommends that customers check for local account usage, disable any unused local accounts, and add certificate-based authentication rather than password-only authentication. More information and recommendations on user and client authentication for remote access is available here.

IOCs

No reliable method of identifying arbitrary file read exploitation was identified. However, successful web administration panel and SSH logins will be logged in /var/log/messages, /var/log/audit/audit.log, and /var/log/auth.

Contents of /var/log/audit/audit.log after web administration panel login as the user ‘admin’ from ‘192.168.181.1’ with local PAM authentication:
type=USER_AUTH msg=audit(1717085193.706:656): pid=65484 uid=99 auid=4294967295 ses=4294967295 subj=kernel msg='op=PAM:authentication grantors=pam_dof_tally,cp_pam_tally,pam_unix acct="admin" exe="/usr/sbin/httpauth" hostname=192.168.181.1 addr=192.168.181.1 terminal=? res=success'

Contents of /var/log/messages after web administration panel login as the user ‘admin’ from ‘192.168.181.1’ with local PAM authentication:
May 30 08:30:25 2024 gw-6f7361 httpd2: HTTP login from 192.168.181.1 as admin

Contents of /var/log/auth after web administration panel login as the user ‘admin’ from ‘192.168.181.1’ with local PAM authentication:
May 30 08:30:31 2024 gw-6f7361 httpd2: HTTP login from 192.168.181.1 as admin

Contents of /var/log/messages after SSH login as the user ‘admin’ from ‘192.168.181.1’ with local PAM authentication:
May 30 08:34:24 2024 gw-6f7361 xpand[176227]: admin localhost t +volatile:clish:admin:66699 t
May 30 08:34:24 2024 gw-6f7361 xpand[176227]: User admin logged in with ReadWrite permission

Contents of /var/log/secure after SSH login as the user ‘admin’ from ‘192.168.181.1’ with local PAM authentication:
May 30 08:30:31 2024 gw-6f7361 sshd[66690]: Accepted password for admin from 192.168.181.1 port 62487 ssh2

Rapid7 Customers

InsightVM and Nexpose customers will be able to assess their exposure to CVE-2024-24919 with an unauthenticated vulnerability check shipping in today's (Thursday, May 30) content release.

InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on post-exploitation behavior related to this vulnerability:

• Suspicious Web Server Request - Successful Path Traversal Attack
• Suspicious Web Request - Possible Check Point VPN (CVE-2024-24919) Exploitation

Updates

May 30, 2024: Added IOC section. CVE-2024-24919 has been added to the U.S. Cybersecurity and Infrastructure Agency's (CISA) Known Exploited Vulnerabilities (KEV) list on May 30, 2024.

May 31, 2024: Added updated Check Point advisory that has revealed that the first exploitation attempts actually began on April 7, 2024, and not April 30 as previously thought.

June 3, 2024: Updated the Mitigation Section with new information from Check Point's updated advisory on the CCCD feature that is disabled by default. It must be disabled for the Hotfix to be effective on some versions of the software.

Source: www.govinfosecurity.com – Author: 1 An enterprise has many different types of technology in its estate – including software, hardware and infrastructure – and historically each type has been managed in silos through software asset management, hardware asset management and infrastructure asset management solutions. But now, there is “a unified system of process” called enterprise […]

La entrada Enterprise Technology Management: No Asset Management Silos – Source: www.govinfosecurity.com se publicó primero en CISO2CISO.COM & CYBER SECURITY GROUP.

BeyondTrust and Delinea are some of the most popular privileged access management (PAM) products on the market. They each offer a sophisticated range of tools for managing access, identities, and endpoints. But like all security tools, they’re not for everybody. The right PAM solution for you will depend on your specific IT environment, budget, internal […]

The post BeyondTrust vs. Delinea: Which Is Best for Privileged Access Management? appeared first on Heimdal Security Blog.

Privileged access management (PAM) tools have changed a lot over the last few years. Once, you could rely on a fairly standard set of features across all providers. Now, the unique security challenges of cloud technology have ushered in a whole range of new tools and acronyms. From PASM to PEDM, CIEM, secrets management, and […]

The post BeyondTrust vs. CyberArk: Pros, Cons, and Alternatives for Privileged Access Management appeared first on Heimdal Security Blog.

A recent  study by Cybersecurity Dive shows that nearly all companies (98%) use software integrations with third-party vendors that have suffered breaches in the past two years. Since not a single company can maintain ops integrity by solely relying on in-house developed software, the stakes are higher than ever. In this article, we’re going to […]

The post Guide to Third Party Risk Management: Dealing with Vendor Vulnerabilities appeared first on Heimdal Security Blog.

Microsoft is addressing 61 vulnerabilities this May 2024 Patch Tuesday. Microsoft has evidence of in-the-wild exploitation and/or public disclosure for three of the vulnerabilities published today. At time of writing, two of the vulnerabilities patched today are listed on CISA KEV. Microsoft is also patching a single critical remote code execution (RCE) vulnerability today. Six browser vulnerabilities were published separately this month, and are not included in the total.

Windows DWM: zero-day EoP

The first of today’s zero-day vulnerabilities is CVE-2024-30051, an elevation of privilege (EoP) vulnerability in the Windows Desktop Windows Manager (DWM) Core Library which is listed on the CISA KEV list. Successful exploitation grants SYSTEM privileges. First introduced as part of Windows Vista, DWM is responsible for drawing everything on the display of a Windows system.

Reporters Securelist have linked exploitation of CVE-2024-30051 with deployment of QakBot malware, and the vulnerability while investigating a partial proof-of-concept contained within an unusual file originally submitted to VirusTotal by an unknown party. Securelist further notes that the exploitation method for CVE-2024-30051 is identical to a previous DWM zero-day vulnerability CVE-2023-36033, which Microsoft patched back in November 2023.

Courtesy of Microsoft’s recent enhancement of their security advisories to include Common Weakness Enumeration (CWE) data, the mechanism of exploitation is listed as CVE-122: Heap-based Buffer Overflow, which is just the sort of defect which recent US federal government calls for memory safe software development are designed to address.

MSHTML: zero-day security feature bypass

The Windows MSHTML platform receives a patch for CVE-2024-30040, a security feature bypass vulnerability for which Microsoft has evidence of exploitation in the wild, and which CISA has also listed on KEV.

The advisory states that an attacker would have to convince a user to open a malicious file; successful exploitation bypasses COM/OLE protections in Microsoft 365 and Microsoft Office to achieve code execution in the context of the user.

As Rapid7 has previously noted, MSHTML (also known as Trident) is still fully present in Windows — and unpatched assets are thus vulnerable to CVE-2024-30040 — regardless of whether or not a Windows asset has Internet Explorer 11 fully disabled.

Visual Studio: zero-day DoS

Rounding out today’s trio of zero-day vulnerabilities: a denial of service (DoS) vulnerability in Visual Studio.

Microsoft describes CVE-2024-30046 as requiring a highly complex attack to win a race condition through “[the investment of] time in repeated exploitation attempts through sending constant or intermittent data”. Since all data sent anywhere is transmitted either constantly or intermittently, and the rest of the advisory is short on detail, the potential impact of exploitation remains unclear.

Only Visual Studio 2022 receives an update, so older supported versions of Visual Studio are presumably unaffected.

SharePoint: critical post-auth RCE

SharePoint admins are no strangers to patches for critical RCE vulnerabilities. CVE-2024-30044 allows an authenticated attacker with Site Owner permissions or higher to achieve code execution in the context of SharePoint Server via upload of a specially crafted file, followed by specific API calls to trigger deserialization of the file’s parameters.

Microsoft considers exploitation of CVE-2024-30044 more likely. The original version of the advisory had the "privileges required" CVSS vector component as low, which was debatable given the Site Owner authentication requirement for exploitation; Microsoft has now updated the advisory so that "privileges required" is now correctly specified as high. Some slight confusion remains in the wording of the advisory FAQ, but the correction to the CVSS vector itself is welcome. The low attack complexity and network attack contribute to a CVSS 3.1 base score of 7.2, which is reduced from the original base score of 8.8 prior to the CVSS vector correction.

Microsoft has previously published an accessible introduction to deserialization vulnerabilities and the risks of assuming data to be trustworthy, aimed at .NET developers.

Excel: arbitrary code execution

Microsoft Excel receives a patch for CVE-2024-30042. Successful exploitation requires that an attacker convince the user to open a malicious file, which leads to code execution, presumably in the context of the user.

Remote Access Connection Manager: last month’s vulns repatched

Also of interest today: Microsoft is releasing updated patches for three Windows Remote Access Connection Manager information disclosure vulnerabilities originally published in April 2024: CVE-2024-26207, CVE-2024-26217, and CVE-2024-28902. Microsoft states that an unspecified regression introduced by the April patches is resolved by installation of the May patches.

Mobile Broadband driver: 11 local USB RCEs

The Windows Mobile Broadband driver receives patches for no fewer than 11 vulnerabilities; for example, CVE-2024-29997. All 11 vulnerabilities appear very similar based on the advisories. In each case, the relatively low CVSS base score of 6.8 reflects that an attacker must be physically present and insert a malicious USB device into the target host.

Third-party open source patches

Back in 2021, Microsoft started publishing the Assigning CNA (CVE Numbering Authority) field on advisories. A welcome trend of publishing advisories for third-party software included in Microsoft products continues this month with two vulnerabilities in MinGit patched as part of the May 2024 Windows security updates. MinGit is published by GitHub and consumed by Visual Studio. CVE-2024-32002 describes a RCE vulnerability on case-insensitive filesystems that support symlinks — macOS APFS comes to mind — and CVE-2024-32004 describes RCE while cloning specially-crafted local repositories.

Lifecycle update

There are no significant changes to the lifecycle phase of Microsoft products this month.

Summary Charts

Summary Tables

Apps vulnerabilities

Azure vulnerabilities

Browser vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

ESU Windows vulnerabilities

Microsoft Dynamics vulnerabilities

Microsoft Office vulnerabilities

SQL Server vulnerabilities

Windows vulnerabilities

Updates

• 2024-05-16: Updated SharePoint vulnerability CVE-2024-30044 to reflect Microsoft's correction to the CVSS vector, as suggested by the original version of this blog post.

Picking the right cybersecurity system for your business can be tricky, especially when you have options like Tenable and Qualys. In this article, we’ll check two popular solutions: Nessus by Tenable and VMDR by Qualys. We’ll analyze both solutions, see what are their strong points, touch on their weaknesses, check if there are other suitable […]

The post Tenable vs. Qualys: Comparing Nessus and VMDR (Are There Other Alternatives?) appeared first on Heimdal Security Blog.

Patching is the second most challenging and resource-consuming task of a System Administrator. That’s what Alex Panait told me when I wanted to know his opinion on the benefits and hurdles of patching.  Alex has been a System Administrator in Internal IT at Heimdal for the last 8 years. He’s seen the company developing and […]

The post A System Administrator’s Challenges in Patch Management appeared first on Heimdal Security Blog.

Rapid7 vulnerability researcher Ryan Emmons contributed to this blog.

On Friday, April 19, 2024, managed file transfer vendor CrushFTP released information to a private mailing list on a new zero-day vulnerability affecting versions below 10.7.1 and 11.1.0 (as well as legacy 9.x versions) across all platforms. No CVE was assigned by the vendor, but a third-party CVE Numbering Authority (CNA) assigned CVE-2024-4040 as of Monday, April 22. According to a public-facing vendor advisory, the vulnerability is ostensibly a VFS sandbox escape in CrushFTP managed file transfer software that allows “remote attackers with low privileges to read files from the filesystem outside of VFS Sandbox.”

Rapid7’s vulnerability research team analyzed CVE-2024-4040 and determined that it is fully unauthenticated and trivially exploitable; successful exploitation allows for not only arbitrary file read as root, but also authentication bypass for administrator account access and full remote code execution. Successful exploitation allows a remote, unauthenticated attacker to access and potentially exfiltrate all files stored on the CrushFTP instance. See Rapid7's full technical analysis of CVE-2024-4040 in AttackerKB for additional details.

Code that triggers the vulnerability is publicly available as of April 23. CVE-2024-4040 was added to the U.S. Cybersecurity and Infrastructure Agency's (CISA) Known Exploited Vulnerabilities (KEV) list on April 24.

Although the vulnerability has been formally described as an arbitrary file read, Rapid7 believes that it can be more accurately categorized as a server-side template injection (SSTI). CVE-2024-4040 was exploited in the wild as a zero-day vulnerability, per private customer communications from the vendor and a public Reddit post from security firm CrowdStrike. Using a query that looks for a specific JavaScript file in the web interface, there appear to be roughly 5,200 instances of CrushFTP exposed to the public internet.

Mitigation guidance

According to the advisory, CrushFTP versions below 11.1 are vulnerable to CVE-2024-4040. The following versions of CrushFTP are vulnerable as of April 23:

• All legacy CrushFTP 9 installations
• CrushFTP 10 before v10.7.1
• CrushFTP 11 before v11.1.0

The vulnerability has been patched in version 11.1.0 for the 11.x version stream, and in version 10.7.1 for the 10.x version stream. Our research team has validated that the vendor-supplied patch effectively remediates CVE-2024-4040.

The vendor advisory emphasizes the importance of updating to a fixed version of CrushFTP on an urgent basis. Rapid7 echoes this guidance, particularly given our team’s findings on the true impact of the issue, and urges organizations to apply the vendor-supplied patch on an emergency basis, without waiting for a typical patch cycle to occur.

While the vendor guidance as of April 22 says that “customers using a DMZ in front of their main CrushFTP instance are partially protected,” it’s unclear whether this is actually an effective barrier to exploitation. Out of an abundance of caution, Rapid7 advises against relying on a DMZ as a mitigation strategy.

Detection challenges

During the course of vulnerability analysis, Rapid7 observed several factors that make it difficult to effectively detect exploitation of CVE-2024-4040. Payloads for CVE-2024-4040 can be delivered in many different forms. When certain evasive techniques are leveraged, payloads will be redacted from logs and request history, and malicious requests will be difficult to discern from legitimate traffic. CrushFTP instances behind a standard reverse proxy, such as NGINX or Apache, are partially defended against these techniques, but our team has found that evasive tactics are still possible.

CrushFTP customers can harden their servers against administrator-level remote code execution attacks by enabling Limited Server mode with the most restrictive configuration possible. Organizations should also use firewalls wherever possible to aggressively restrict which IP addresses are permitted to access CrushFTP services.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2024-4040 with an authenticated vulnerability check available in the April 24 content release. Customers can also use Query Builder (asset.software.product CONTAINS 'CrushFTP') or a Filtered Asset Search (Software Name contains CrushFTP) to find assets in their environment with CrushFTP installed.

InsightIDR and managed detection and response (MDR) customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on post-exploitation behavior related to this zero-day vulnerability for both InsightIDR and Rapid7 MDR customers:

• Suspicious Web Request - Possible CrushFTP (CVE-2024-4040) Exploitation

Updates

April 23, 2024: Added Detection challenges section. Noted that our team tested the vendor-supplied patch and found that it successfully remediates CVE-2024-4040. Added detection rule deployed and alerting for InsightIDR and Rapid7 MDR customers. Added Query Builder information to assist InsightVM and Nexpose customers in identifying CrushFTP installations in their environments. Added link to Airbus CERT proof-of-concept code.

April 24, 2024: CVE-2024-4040 has been added to CISA KEV. A vulnerability check is now available to InsightVM and Nexpose customers. Rapid7's full technical analysis of CVE-2024-4040 is now available in AttackerKB.

Patch management is one of the most effective, yet overlooked cybersecurity practices to keep your operations safe. And it’s not just me saying it, statistics do too. For example, were you aware that 80% of cyberattacks happen due to unpatched vulnerabilities? With 84% of companies and online businesses reporting suffering at least one cyberattack in […]

The post Your All-In Guide to MSP Patch Management Software in 2024 [Template Included] appeared first on Heimdal Security Blog.

On Friday, April 12, Palo Alto Networks published an advisory on CVE-2024-3400, a CVSS 10 zero-day vulnerability in several versions of PAN-OS, the operating system that runs on the company’s firewalls. According to the vendor advisory, if conditions for exploitability are met, the vulnerability may enable an unauthenticated attacker to execute arbitrary code with root privileges on the firewall. Patches are available for some versions as of Sunday, April 14, 2024.

Note: Initially, Palo Alto Networks's advisory indicated that customers were only vulnerable if they were using PAN-OS 10.2, PAN-OS 11.0, and/or PAN-OS 11.1 firewalls with the configurations for both GlobalProtect gateway (or GlobalProtect portal) and device telemetry enabled. As of Tuesday, April 16, the advisory has been updated to say, "Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability."

Palo Alto Networks’ advisory indicates that CVE-2024-3400 has been exploited in the wild in “a limited number of attacks.” The company has given the vulnerability their highest urgency rating. Palo Alto Networks has released an in-depth blog on the scope of the attack, indicators of compromise, and adversary behavior observations. We highly recommend reviewing it. Security firm Volexity, who discovered the zero-day vulnerability, also has a blog available here with extensive analysis, indicators of compromise, and observed attacker behavior.

Mitigation guidance

CVE-2024-3400 was unpatched at time of disclosure, but patches are available for some versions of PAN-OS as of Sunday, April 14. CVE-2024-3400 affects the following versions of PAN-OS when GlobalProtect (gateway or portal) is enabled:

• PAN-OS 11.1 (before 11.1.2-h3)
• PAN-OS 11.0 (before 11.0.4-h1)
• PAN-OS 10.2 (before 10.2.7-h8, before 10.2.8-h3, before 10.2.9-h1)
• Additional versions have been added to the advisory since initial publication

The vendor has updated their advisory as of April 16 to note that device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability. Palo Alto Networks’ Cloud NGFW and Prisma Access solutions are not affected; nor are earlier versions of PAN-OS (10.1, 10.0, 9.1, and 9.0).

Important: Palo Alto Networks has been continually updating their advisory, which now has an extensive list of affected versions and when fixes are expected. For additional information and the latest remediation guidance, please refer to the vendor advisory as the source of truth.

Patches for the CVE-2024-3400 were released on Sunday, April 14. Rapid7 recommends applying the vendor-provided patch immediately, without waiting for a typical patch cycle to occur. If you are unable to patch, apply one of the below vendor-provided mitigations:

• Customers with a Threat Prevention subscription can block attacks for this vulnerability by enabling Threat ID 95187 (introduced in Applications and Threats content version 8833-8682). In addition to enabling Threat ID 95187, customers should ensure vulnerability protection has been applied to their GlobalProtect interface to prevent exploitation of this issue on their device. More information here.
• Note: While disabling device telemetry was initially mentioned as a temporary workaround, Palo Alto Networks has said as of April 16 that disabling device telemetry is no longer an effective mitigation.

Palo Alto Networks has a knowledge base article here with their recommended steps for remediating exploited devices. We also recommend reviewing indicators of compromise in Palo Alto Networks's blog and Volexity's blog.

Rapid7 customers

Authenticated vulnerability checks are available to InsightVM and Nexpose customers as of the Friday, April 12 content release. Since the vendor added more vulnerable versions to their advisory after it was originally published, our engineering team has updated our vulnerability checks as of the Wednesday, April 17 content release to be able to detect additional vulnerable versions of PAN-OS.

Per the vendor advisory, organizations that are running vulnerable firewalls and are concerned about potential exploitation in their environments can open a support case with Palo Alto Networks to determine if their device logs match known indicators of compromise (IoCs) for this vulnerability.

InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7's expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on post-exploitation behavior related to this zero-day vulnerability:

• Attacker Technique - NTDS File Access
• Attacker Technique: Renamed AnyDesk Binary in Non-Standard Location
• Attacker Technique: Renamed EWSProxy in Non-Standard Location
• Attacker Technique: Renamed AvastBrowserUpdate in Non-Standard Location
• Attacker Tool - Unknown Raw File Copy Utility For Credential Dumping
• Credential Access - Copying Credential Files with Esenutil
• Suspicious Process: A Single Character Executable in Root Intel Directory
• Suspicious Process - Avast Executable NOT in Program Files directory

Updates

Friday, April 12, 2024: Updated with link to Volexity blog on exploitation in the wild and indicators of compromise and Palo Alto Networks blog on the incident. Updated to note availability of VM content.

Monday, April 15, 2024: Updated to note that patches were available Sunday, April 14. Updated to note that GlobalProtect portal is also a vulnerable configuration (in addition to GlobalProtect gateway).

Tuesday, April 16, 2024: Added more vulnerable versions of the PAN-OS 10.2.x version stream per the updated vendor advisory. Patches are available for some versions, but not all, as of April 16. The advisory has ETAs on in-flight fixes. Rapid7 vulnerability checks will be updated on April 17 to detect newly listed vulnerable versions of PAN-OS.

Tuesday, April 16, 2024: Updated to note that disabling device telemetry is no longer considered an effective mitigation; Palo Alto Networks has now indicated that "device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability."

Wednesday, April 17, 2024: For InsightVM and Nexpose customers, vulnerability checks have been updated to detect additional vulnerable versions of PAN-OS. See the vendor advisory for the latest information.

Monday, April 22, 2024: Added list of (non-exhaustive) detection rules alerting for InsightIDR and Rapid7 MDR customers.

Monday, April 29, 2024: Added link to Palo Alto Networks KB article with recommendations on remediating exploited devices at different levels of compromise the vendor has defined.

COPENHAGEN, Denmark, April 9, 2024 – Heimdal®, the world’s widest cybersecurity platform with 13 products, is thrilled to announce the launch of its latest innovation, the Privileged Account and Session Management (PASM) solution.  Designed to elevate the security of privileged accounts, Heimdal’s PASM grants organizations the ability to meticulously monitor, record, and manage all privileged […]

The post Heimdal® Adds PASM to the World’s Widest Cybersecurity Platform appeared first on Heimdal Security Blog.

Microsoft is addressing 149 vulnerabilities this April 2024 Patch Tuesday, which is significantly more than usual. For the second month in a row, Microsoft indicated that they weren't aware of prior public disclosure or exploitation in the wild for any of the vulnerabilities patched today. However, later in the day, Microsoft subsequently updated the advisory for CVE-2024-26234 to acknowledge in-the-wild exploitation and public disclosure of the exploit. There are no new additions to CISA KEV at time of writing.

Despite the large number of vulnerabilities published today, Microsoft has ranked only three as critical under its proprietary severity scale. Five browser vulnerabilities were published separately this month, and are not included in the total.

Microsoft is now including two additional data points on advisories: Common Weakness Enumeration (CWE) and Vector String Source assessments.

Windows Proxy Driver: late-breaking zero-day spoofing vulnerability

When originally published, the advisory for CVE-2024-26234 did not indicate that Microsoft was aware of in-the-wild exploitation or public exploit disclosure. However, late on the day of publication, Microsoft updated the advisory to acknowledge awareness of both in-the-wild exploitation and public disclosure.

The advisory provides almost no detail about the nature of the exploit itself, beyond the basic facts: it's a proxy spoofing vulnerability, and patches are available for supported versions of Windows.

Defender for IoT: three critical RCEs

Microsoft Defender for IoT receives patches for three critical remote code execution (RCE) vulnerabilities. Microsoft describes Defender for IoT as an Azure-deployable agentless monitoring solution for Internet of Things (IoT) and Operational Technology (OT) devices.

The advisory for CVE-2024-21322 is light on detail, but notes that exploitation requires the attacker to have existing administrative access to the Defender for IoT web application; this limits the attacker value in isolation, although the potential for insider threat or use as part of an exploit chain remains.

CVE-2024-21323 describes an update-based attack and requires prior authentication; an attacker with the ability to control how a Defender for IoT sensor receives updates could cause the sensor device to apply a malicious update package, overwriting arbitrary files on the sensor filesystem via a path traversal weakness.

Exploitation of CVE-2024-29053 allows arbitrary file upload for any authenticated user, also via a path traversal weakness, although the advisory does not specify what the target is other than “the server”.

The Defender for IoT 24.1.3 release notes do not call out these security fixes and describe only improvements to clock drift detection and unspecified stability improvements; this omission highlights the evergreen value of timely patching.

SharePoint: XSS spoofing

SharePoint receives a patch for CVE-2024-26251, a spoofing vulnerability which abuses cross-site scripting (XSS) and affects SharePoint Server 2016, 2019, and Subscription Edition. Exploitation requires multiple conditions to be met, including but not limited to a reliance on user actions, token impersonation, and specific application configuration. On that basis, although Microsoft is in possession of mature exploit code, exploitation is rated less likely.

Excel: arbitrary file execution

Microsoft is patching a single Office vulnerability today. CVE-2024-26257 describes a RCE vulnerability in Excel; exploitation requires that the attacker convinces the user to open a specially-crafted malicious file.

Patches for Windows-based click-to-run (C2R) Office deployments and Microsoft 365 Apps for Enterprise are available immediately. Not for the first time, a patch for Office for Mac is unavailable at time of writing, and will follow at some unspecified point in the future.

SQL Server OLE DB driver: dozens of RCE

The Microsoft OLE DB Driver for SQL Server receives patches for no fewer than 38 separate RCE vulnerabilities today, which might be a record for a single component. The common theme here is that an attacker could trick a user into connecting to a malicious SQL server to achieve code execution in the context of the client.

All quiet on the Exchange front

There are no security patches for Exchange this month.

Microsoft advisory metadata: CWE and Vector String Source

The addition of CWE assessments to Microsoft security advisories helps pinpoint the generic root cause of a vulnerability; e.g., CVE-2024-21322 is assigned “CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').” By embracing CWE taxonomy, Microsoft is moving away from its own proprietary system to describe root cause. The CWE program has recently updated its guidance on mapping CVEs to a CWE Root Cause.

Analysis of CWE trends can help developers reduce future occurrences through improved Software Development Life Cycle (SDLC) workflows and testing, as well as helping defenders understand where to direct defense-in-depth and deployment-hardening efforts for best return on investment. At time of writing, the addition of CWE assessments does not appear to be retroactive.

The Common Vulnerability Scoring System (CVSS) is a widely-used standard for evaluation of vulnerability severity, and Microsoft has helpfully provided CVSS data for each vulnerability for a long time. The CVSS vector describes the variables which comprise the overall CVSS severity score for a vulnerability. The addition of Vector String Source — typically, the entity providing the CVSS assessment on a Microsoft vulnerability will be Microsoft — provides further welcome clarity, at least for vulnerabilities where Microsoft is the CVE Numbering Authority (CNA). It may not be a coincidence that Microsoft is choosing to start explicitly describing the source of the CVSS vector during the ongoing uncertainty around the future of the NVD program.

Lifecycle update

Several Microsoft products move past the end of mainstream support after today:

• Azure DevOps Server 2019.
• System Center 2019.
• Visual Studio 2019.

Additionally, some older products move past the end of extended support, including:

• Microsoft Deployment Agent 2013.
• Microsoft Diagnostics and Recovery Toolset 8.1.
• Visual Studio 2013.

Summary Charts

Summary Tables

Azure vulnerabilities

Browser vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

Microsoft Office vulnerabilities

Other vulnerabilities

SQL Server vulnerabilities

SQL Server Developer Tools vulnerabilities

System Center vulnerabilities

Windows vulnerabilities

Windows ESU vulnerabilities

Updates

• 2024-04-09: Updated discussion of vuln diclosure prior to publication to reflect Microsoft's update to the advisory for CVE-2024-26234.

Recently, the US National Institute of Standards and Technology (NIST) announced on the National Vulnerability Database (NVD) site that there would be delays in adding information on newly published CVEs. NVD enriches CVEs with basic details about a vulnerability like the vulnerability’s CVSS score, software products impacted by a CVE, information on the bug, patching status, etc. Since February 12th, 2024, NVD has largely stopped enriching vulnerabilities.

Given the broad usage and visibility into the NVD, the delays are sure to have a widespread impact on security operations that rely on timely and effective vulnerability information to prioritize and respond to risk introduced by software vulnerabilities.

We want to assure our customers that this does not impact Rapid7’s ability to provide coverage and checks for vulnerabilities in our products. At Rapid7, we believe in a multi-layered approach to vulnerability detection creation and risk scoring, which means that our products are not completely reliant on any single source of information, NVD included.

In fact, for vulnerability creation, we largely use vendor advisories, and as such our customers will continue to see new vulnerability detections made available without interruption. For vulnerability prioritization, our vulnerability researchers aggregate vulnerability intelligence from multiple sources, including our own research, to provide accurate information and risk scoring. Example areas of our coverage that are currently unaffected by the NVD delays include:

• Microsoft vulnerabilities - CVSS information is pulled directly from Microsoft advisory,
• Vulnerabilities with coverage that are present on the CISA KEV list, and,
• Any vulnerabilities that qualify for our Emergent Threat Response process - our researchers manually analyze and enrich these vulnerabilities as part of our ETR process

Below is an example of a latest vulnerability for Microsoft CVE-2024-26166 with the CVSS and Active Risk scores unaffected by NVD:

However, there are portions of Rapid7’s vulnerability detection database that do rely on NVD data for enrichment to populate fields such as CVSS scores. These vulnerabilities will continue to be supplemented by our proprietary risk scoring algorithm, Active Risk and will be updated as soon as enrichment information becomes available from the NVD.

Active Risk leverages intelligence from multiple threat feeds, in addition to CVSS score, like AttackerKB, Metasploit, ExploitDB, Project Heisenberg, CISA KEV list, and other third-party dark web sources to provide security teams with threat-aware vulnerability risk scores on scale of 0-1000. This approach ensures customers can continue to prioritize and remediate the most important risks despite the NVD delays.

First and foremost, we want to assure our customers that they will continue to have coverage and checks across emergent and active vulnerabilities across our products. Our teams will continue to invest in diverse vulnerability enrichment information, and we are actively working on new updates that will ensure there is no additional impact to CVSS scoring. We will continue to monitor the situation, share relevant information as it becomes available, and offer additional guidance for customers via our support channels.

Microsoft is addressing 60 vulnerabilities this March 2024 Patch Tuesday. Microsoft indicated that they aren’t aware of prior public disclosure or exploitation in the wild for any of the vulnerabilities patched today, which means no new additions to CISA KEV at time of writing. Microsoft is patching a single critical remote code execution (RCE) in Windows, which could allow virtual machine escape from a Hyper-V guest. Four browser vulnerabilities were published separately this month, and are not included in the total.

Windows Hyper-V: critical RCE VM escape

Attackers hoping to escape from a Hyper-V guest virtual machine (VM) and achieve RCE on the Hyper-V host will be interested in CVE-2024-21407. Microsoft describes attack complexity as high: an attacker must first gather information specific to the environment and carry out unspecified preparatory work. Exploitation is via specially crafted file operation requests on the VM to hardware resources on the VM. Every supported version of Windows receives a patch. The advisory describes that no privileges are required for exploitation of the Hyper-V host, although an attacker will presumably need an existing foothold on a guest VM.

Exchange: RCE

A single Exchange vulnerability receives a patch this month. Microsoft describes CVE-2024-26198 as a RCE vulnerability for Exchange, where an attacker places a specially-crafted DLL file into a network share or other file-sharing resource, and convinces the user to open it. Although the FAQ on the advisory asks: “What is the target context of the remote code execution?”, the answer boils down to ”[exploitation] results in loading a malicious DLL”. Since the context of the user opening the malicious file is not specified — an Exchange admin? a user running a mail client connecting to Exchange? something else altogether? — it remains unclear what an attacker might be able to achieve.

It remains vitally important to patch any on-premises instances of Exchange, a perennial attacker favourite. Exchange 2016 admins who were dismayed by the lack of patch for last month’s CVE-2024-21410 may feel somewhat reassured that Microsoft has issued a patch which claims to fully remediate this month’s CVE-2024-26198, but in the absence of any explicit advice to the contrary, a fully-patched Exchange 2016 remains unprotected against CVE-2024-21410 unless the guidance on that advisory is followed.

SharePoint: arbitrary code execution

SharePoint receives a patch for CVE-2024-21426, which Microsoft describes as RCE via the attacker convincing a user to open a malicious file. Although the context of code execution isn’t stated in the advisory, exploitation is local to the user, and could lead to a total loss of confidentiality, integrity, and availability, including downtime for the affected environment.

Azure Kubernetes Service Confidential Containers: confidentiality impact

Azure Kubernetes admins should take note of CVE-2024-21400, which allows an unauthenticated attacker to take over confidential guests and containers, with other outcomes including credential theft and resource impact beyond the scope managed by the Azure Kubernetes Service Confidential Containers (AKSCC). Microsoft describes AKSCC as providing a set of features and capabilities to further secure standard container workloads when working with sensitive data such as PII. The advisory describes additional steps for remediation beyond merely patching AKSCC, including upgrading to the latest version of the az confcom Azure CLI confidential computing extension and Kata Image.

Windows 11: compressed folder tampering

Defenders responsible for Windows 11 assets can protect assets against exploitation of CVE-2024-26185, which Microsoft describes as a compressed folder tampering vulnerability. The advisory is sparse on detail, so while we know that an attacker must convince the user to open a specially crafted file, it’s not clear what the outcome of successful exploitation might be. Since the only impact appears to be to integrity, it’s possible that an attacker could modify a compressed folder but not necessarily read from it. Microsoft expects that exploitation is more likely.

Windows Print Spooler: elevation to SYSTEM

Another site of “exploitation more likely” vulnerabilities this month: the Windows Print Spooler service. A local attacker who successfully exploits CVE-2024-21433 via winning a race condition could elevate themselves to SYSTEM privileges.

Exploitation in the wild: status updates

In the days following February 2024 Patch Tuesday, Microsoft announced several updates where the known exploited status of more than one vulnerability changed, as noted by Rapid7. It remains to be seen if those changes were exceptional or the start of a pattern.

Microsoft products lifecycle review

There are no significant changes to the lifecycle phase of Microsoft products this month.

Summary Charts

Summary Tables

Apps vulnerabilities

Azure vulnerabilities

Azure System Center vulnerabilities

Browser vulnerabilities

Developer Tools vulnerabilities

Developer Tools Windows vulnerabilities

ESU Windows vulnerabilities

Exchange Server vulnerabilities

Microsoft Dynamics vulnerabilities

Microsoft Office vulnerabilities

SQL Server vulnerabilities

System Center vulnerabilities

Windows vulnerabilities