Sysmon v14.0, AccessEnum v1.34, and Coreinfo v3.53

This article is contributed. See the original author and article here.


Sysmon v14.0


This major update to Sysmon, an advanced host monitoring tool, adds a new event type, FileBlockExecutable that prevents processes from creating executable files in specified locations. It also includes several performance improvements and bug fixes.

 

AccessEnum v1.34


AccessEnum, a tool for enumerating file system and registry permissions, now supports paths longer than MAX_PATH characters.

 

Coreinfo v3.53


This update to Coreinfo, a utility that reports system CPU, memory and cache topology and information, now handles NUMA nodes with more than 64 processors.

 

Threat Actors Exploiting Multiple CVEs Against Zimbra Collaboration Suite

This article is contributed. See the original author and article here.

Actions for ZCS administrators to take today to mitigate malicious cyber activity:
• Patch all systems and prioritize patching known exploited vulnerabilities.
• Deploy detection signatures and hunt for indicators of compromise (IOCs).
• If ZCS was compromised, remediate malicious activity.

The Cybersecurity and Infrastructure Security Agency (CISA) and the Multi-State Information Sharing & Analysis Center (MS-ISAC) are publishing this joint Cybersecurity Advisory (CSA) in response to active exploitation of multiple Common Vulnerabilities and Exposures (CVEs) against Zimbra Collaboration Suite (ZCS), an enterprise cloud-hosted collaboration software and email platform. CVEs currently being exploited against ZCS include: 

  • CVE-2022-24682 
  • CVE-2022-27924 
  • CVE-2022-27925 chained with CVE-2022-37042 
  • CVE-2022-30333

Cyber threat actors may be targeting unpatched ZCS instances in both government and private sector networks. CISA and the MS-ISAC strongly urge users and administrators to apply the guidance in the Recommendations section of this CSA to help secure their organization’s systems against malicious cyber activity. CISA and the MS-ISAC encourage organizations who did not immediately update their ZCS instances upon patch release, or whose ZCS instances were exposed to the internet, to assume compromise and hunt for malicious activity using the third-party detection signatures in the Detection Methods section of this CSA. Organizations that detect potential compromise should apply the steps in the Incident Response section of this CSA.

Download the PDF version of this report: pdf, 355 kb

CVE-2022-27924

CVE-2022-27924 is a high-severity vulnerability enabling an unauthenticated malicious actor to inject arbitrary memcache commands into a targeted ZCS instance and cause an overwrite of arbitrary cached entries. The actor can then steal ZCS email account credentials in cleartext form without any user interaction. With valid email account credentials in an organization not enforcing multifactor authentication (MFA), a malicious actor can use spear phishing, social engineering, and business email compromise (BEC) attacks against the compromised organization. Additionally, malicious actors could use the valid account credentials to open webshells and maintain persistent access.

On March 11, 2022, researchers from SonarSource announced the discovery of this ZCS vulnerability. Zimbra issued fixes for releases 8.8.15 and 9.0 on May 10, 2022. In June 2022, SonarSource publicly released proof-of-concept (POC) exploits for this vulnerability.[1][2] Based on evidence of active exploitation, CISA added this vulnerability to the Known Exploited Vulnerabilities Catalog on August 4, 2022. Due to the POC and ease of exploitation, CISA and the MS-ISAC expect to see widespread exploitation of unpatched ZCS instances in government and private networks.

CVE-2022-27925 and CVE-2022-37042

CVE-2022-27925 is a high severity vulnerability in ZCS releases 8.8.15 and 9.0 that have mboximport functionality to receive a ZIP archive and extract files from it. An authenticated user has the ability to upload arbitrary files to the system thereby leading to directory traversal.[3] On August 10, 2022, researchers from Volexity reported widespread exploitation—against over 1,000 ZCS instances—of CVE-2022-27925 in conjunction with CVE-2022-37042.[4] CISA added both CVEs to the Known Exploited Vulnerabilities Catalog on August 11, 2022. 

CVE-2022-37042 is an authentication bypass vulnerability that affects ZCS releases 8.8.15 and 9.0. CVE-2022-37042 could allow an unauthenticated malicious actor access to a vulnerable ZCS instance. According to Zimbra, CVE-2022-37042 is found in the MailboxImportServlet function.[5][6] Zimbra issued fixes in late July 2022.

CVE-2022-30333

CVE-2022-30333 is a high-severity directory traversal vulnerability in RARLAB UnRAR on Linux and UNIX allowing a malicious actor to write to files during an extract (unpack) operation. A malicious actor can exploit CVE-2022-30333 against a ZCS server by sending an email with a malicious RAR file. Upon email receipt, the ZCS server would automatically extract the RAR file to check for spam or malware.[7] Any ZCS instance with unrar installed is vulnerable to CVE-2022-30333.

Researchers from SonarSource shared details about this vulnerability in June 2022.[8] Zimbra made configuration changes to use the 7zip program instead of unrar.[9] CISA added CVE-2022-3033 to the Known Exploited Vulnerabilities Catalog on August 9, 2022. Based on industry reporting, a malicious cyber actor is selling a cross-site scripting (XSS) exploit kit for the ZCS vulnerability to CVE 2022 30333. A Metasploit module is also available that creates a RAR file that can be emailed to a ZCS server to exploit CVE-2022-30333.[10]

CVE-2022-24682

CVE-2022-24682 is a medium-severity vulnerability that impacts ZCS webmail clients running releases before 8.8.15 patch 30 (update 1), which contain a cross-site scripting (XSS) vulnerability allowing malicious actors to steal session cookie files. Researchers from Volexity shared this vulnerability on February 3, 2022[11], and Zimbra issued a fix on February 4, 2022.[12] CISA added this vulnerability to the Known Exploited Vulnerabilities Catalog on February 25, 2022. 

DETECTION METHODS

Note: CISA and the MS-ISAC will update this section with additional IOCs and signatures as further information becomes available. 
CISA recommends administrators, especially at organizations that did not immediately update their ZCS instances upon patch release, to hunt for malicious activity using the following third-party detection signatures:

  • Hunt for IOCs including:
    • 207.148.76[.]235 – a Cobalt Strike command and control (C2) domain
  • Deploy third-party YARA rules to detect malicious activity:

CISA and the MS-ISAC recommend organizations upgrade to the latest ZCS releases as noted on Zimbra Security – News & Alerts and Zimbra Security Advisories.

See Volexity’s Mass Exploitation of (Un)authenticated Zimbra RCE: CVE-2022-27925 for mitigation steps.

Additionally, CISA and the MS-ISAC recommend organizations apply the following best practices to reduce risk of compromise:

  • Maintain and test an incident response plan.
  • Ensure your organization has a vulnerability management program in place and that it prioritizes patch management and vulnerability scanning of known exploited vulnerabilities. Note: CISA’s Cyber Hygiene Services (CyHy) are free to all state, local, tribal, and territorial (SLTT) organizations, as well as public and private sector critical infrastructure organizations: cisa.gov/cyber-hygiene-services
  • Properly configure and secure internet-facing network devices.
    • Do not expose management interfaces to the internet.
    • Disable unused or unnecessary network ports and protocols.
    • Disable/remove unused network services and devices.
  • Adopt zero-trust principles and architecture, including:
    • Micro-segmenting networks and functions to limit or block lateral movements.
    • Enforcing phishing-resistant multifactor authentication (MFA) for all users and VPN connections.
    • Restricting access to trusted devices and users on the networks.

INCIDENT RESPONSE

If an organization’s system has been compromised by active or recently active threat actors in their environment, CISA and the MS-ISAC recommend the following initial steps:

  1. Collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.
  2. Quarantine or take offline potentially affected hosts.
  3. Reimage compromised hosts.
  4. Provision new account credentials.
  5. Report the compromise to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870). SLTT government entities can also report to the MS-ISAC (SOC@cisecurity.org or 866-787-4722).

See the joint CSA from the cybersecurity authorities of Australia, Canada, New Zealand, the United Kingdom, and the United States on Technical Approaches to Uncovering and Remediating Malicious Activity for additional guidance on hunting or investigating a network, and for common mistakes in incident handling. CISA and the MS-ISAC also encourage government network administrators to see CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. Although tailored to federal civilian branch agencies, these playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail steps for both incident and vulnerability response. 

ACKNOWLEDGEMENTS

CISA and the MS-ISAC would like to thank Volexity and Secureworks for their contributions to this advisory.

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. CISA and the MS-ISAC do not provide any warranties of any kind regarding this information. CISA and the MS-ISAC do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring.

Azure Maps Authentication the right way

Azure Maps Authentication the right way

This article is contributed. See the original author and article here.


One of the requirements when building a business application is that only authenticated users can access it. So how do you use Azure Maps in combination with authentication and authorization? When you are reading our Azure Maps docs, you find that we support many different authentication scenarios, which makes it hard for some developers to implement. This blogpost will focus on the most requested scenario for Azure Maps: Have a .NET web application with an embedded Azure Maps web control where only authenticated users can see the website and use the map. Follow me step by step.


 



In this article, we make use of .NET 6.0 and the C# programming language, download, and install the latest version of .NET from https://dot.net/.


 


To make it easier to edit source code, we also recommend installing Visual Studio Code, which is a lightweight but powerful source code editor from Microsoft https://code.visualstudio.com/.


 


Before you can use Azure Maps, you need to sign up for a free Azure subscription, what you can do here https://azure.microsoft.com/free.


And as last, install the Azure Command-Line Interface (CLI) tools. Read here How to install the Azure CLI.


 



First, we start with a basic .NET web application and Azure Maps. No authentication yet, that will come in the next paragraph. This first step will use an Azure Maps Key (a ‘shared Key authentication’ or subscription key) that should not be used in production. An Azure Maps Key has complete control over your Azure Maps resource. In the next paragraph, we will remove this key and replace this with managed identities for Azure resources.


 


We start by creating a folder and adding a new web application to it, and we then open the newly created web application in Visual Studio Code. Start PowerShell (or any other terminal) and enter the following commands:


 

mkdir AzureMapsDemo
cd .AzureMapsDemo
dotnet new mvc
code .

 


 


Next, we need to add the Azure Maps web control to the Home view, open the file Views/Home/index.cshtml, and replace all the content with:



@{
    ViewData["Title"] = "Home Page";
}

<div class="text-center">
    <h1 class="display-4">Azure Maps</h1>
    <p>Learn about <a href="https://docs.microsoft.com/azure/azure-maps/">building Azure Maps apps with ASP.NET Core</a>.</p>
</div>

<div id="myMap" style="width:100%;min-width:290px;height:600px;"></div>

@section Scripts
{
    <link rel="stylesheet" href="https://atlas.microsoft.com/sdk/javascript/mapcontrol/2/atlas.min.css" />
    https://atlas.microsoft.com/sdk/javascript/mapcontrol/2/atlas.min.js

    <script>
        var map;

        // Initialize a map instance.
        map = new atlas.Map('myMap', {
            center: [-122.33, 47.6],
            zoom: 12,
            style: 'satellite_road_labels',
            view: 'Auto',

            // Add authentication details for connecting to Azure Maps.
            authOptions: {
                authType: 'subscriptionKey',
                subscriptionKey: '[YOUR_AZURE_MAPS_KEY]'
            }
        });

        // Wait until the map resources are ready.
        map.events.add('ready', function() {
            // Add your post map load code here.
        });
    </script>
}

As you can see, we need a subscription key for Azure Maps before starting the web application and using the map. In the next step, we are creating an Azure resource group and adding a new Azure Maps Account. Then we extract the Azure Maps Primary Key from this Azure Maps Account, which we use in our Home view.

 



1.1 Login into your Azure subscription and save the Azure subscription Id, we need this for later.



az login

 



1.2 (Optional) Select the subscription where you would like to create the Azure Maps Account.


 

az account set --subscription "<your subscription>"

 


 


1.3 Create a resource group, and change the name and the location for your needs.


 

az group create -l westeurope -n rg-azuremaps

 


 


1.4 Create the Azure Maps Account, and accept the terms and conditions. Save the uniqueId for later.


 

az maps account create -n map-azuremaps -g rg-azuremaps -s "G2" --kind "Gen2"

 


 


1.5 Now we can extract the Azure Maps Primary Key and add it to the Home view in our web application.


 

az maps account keys list -n map-azuremaps -g rg-azuremaps

 


 


1.6 Replace the [YOUR_AZURE_MAPS_KEY] in the file Views/Home/index.cshtml with the Azure Maps Primary Key we just listed in step 1.5.


 


1.7 Now we can run and test our AzureMapsDemo web application.




dotnet run​

 


azure_maps_key.png



In this paragraph, we are removing the ‘shared Key authentication’ (the Azure Maps subscription key) and replacing this with a more secure and production ready managed identities for Azure Maps.


 



Managed identities for Azure resources provide Azure services with an automatically managed application-based security principal that can authenticate with Azure AD. With Azure role-based access control (Azure RBAC), the managed identity security principal can be authorized to access Azure Maps services.



This means that the web application can request a short-lived token to get access to Azure Maps from Azure Active Directory (AAD). Because this is managed, we do not need to know any passwords or create users. However, to get this token back to the client (the Azure Maps Web Controls runs in the users’ browser), we need to create a simple token proxy API in our web application to forward this token.


We start by creating an Azure Web App where our web application will be hosted and running. This Azure Web App then needs to have rights to get a token for Azure Maps, which we will forward using the token proxy API we create in the below steps.


 


2.1 Create an app service plan and web app, and change the unique name and the location for your needs.

az appservice plan create -g rg-azuremaps -n plan-azuremaps -l westeurope

az webapp create -g rg-azuremaps -p plan-azuremaps -n web-azuremaps -r "dotnet:6"



 



2.2 Next, we create a system-assigned identity for this web app. When finished, we are presented with the principalId, we need this in the next step. To make it simple, you can see the system-assigned identity as an account Azure manages.

az webapp identity assign -n web-azuremaps -g rg-azuremaps



 



2.3 Now that we have the principalId (use this in the below command) for this system-assigned identity, we can assign the role (what can this system-assigned identity do and access). In this step, we assign the role of Azure Maps Data Reader to this system-assigned identity, which means that this system-assigned identity can only read and not modify or delete data from your Azure Maps account. You already see this is way more secure than the plain Azure Maps key, which has all the rights to do everything. We also need the [YOUR_AZURE_SUBSCRIPTION_ID] from the first step.

az role assignment create --assignee "[PRINCIPAL_ID]" --role "Azure Maps Data Reader" --scope "/subscriptions/[YOUR_AZURE_SUBSCRIPTION_ID]/resourceGroups/rg-azuremaps/providers/Microsoft.Maps/accounts/map-azuremaps"



 




Hint to get your Azure subscription Id use the following command: az account subscription list



2.4 To get the access token from Azure Active Directory (AAD) back to the client (the web browser), we will create a simple proxy API forwarding this access token. We start by creating an API controller in our web application and adding the GetAzureMapsToken() method.


 


2.5 First, we must add the Azure Identity NuGet package to our web application.

dotnet add package Azure.Identity



 



2.6 Next, we create a new ApiController.cs file under the folder Controllers. This new ApiController.cs file will have a method GetAzureMapsToken() that is acting like a proxy for our access token. Read here more about Controllers in a MVC web application.

using Azure.Core;
using Azure.Identity;
using Microsoft.AspNetCore.Mvc;

namespace AzureMapsDemo.Controllers;

public class ApiController : Controller
{
    private static readonly DefaultAzureCredential tokenProvider = new();

    public async Task<IActionResult> GetAzureMapsToken()
    {
        var accessToken = await tokenProvider.GetTokenAsync(
            new TokenRequestContext(new[] { "https://atlas.microsoft.com/.default" })
        );

        return new OkObjectResult(accessToken.Token);
    }
}



 

2.7 Now that we have our token API proxy, we only need to change the authentication options for the Azure Maps Web Control. Replace in the file Views/Home/index.cshtml the authOptions with the following:


// Add authentication details for connecting to Azure Maps.
authOptions: {
    // Use Azure Active Directory authentication.
    authType: 'anonymous',
    // Your Azure Maps client id for accessing your Azure Maps account.
    clientId: '[YOUR_AZUREMAPS_CLIENT_ID]',
    getToken: function(resolve, reject, map) {
        // URL to your authentication service that retrieves
        // an Azure Active Directory Token.
        var tokenServiceUrl = "/api/GetAzureMapsToken";

        fetch(tokenServiceUrl).then(r => r.text()).then(token => resolve(token));
    }
}



 

managed_identity.png

 



2.8 We also need to update the clientId we saved when we created the Azure Maps account. (Optional) To get the Azure Maps Client Id again, use the value of uniqueId from:




az maps account show -n map-azuremaps -g rg-azuremaps




 


2.9 Now we can build and deploy our web application that uses managed identities for Azure Maps. We first build and create a release package.

dotnet publish --configuration Release

Compress-Archive -Path binReleasenet6.0publish* -DestinationPath release1.zip



 



2.10 Then we publish our release package to the Azure Web App.

az webapp deployment source config-zip -g rg-azuremaps -n web-azuremaps --src release1.zip



 

2.11 Open a web browser and navigate to the https://web-azuremaps.azurewebsites.net/ where the web-azuremaps subdomain is your unique name when creating the Azure Web App. The application looks like this:



 


demo.png


2.12. (Optional) We can also navigate to the token proxy API https://web-azuremaps.azurewebsites.net/api/GetAzureMapsToken, copy the token, and past this in the https://jwt.ms/ tool to decode and inspect the token.


 



The web application we built in the last paragraph uses managed identities, and the Azure Maps Web Control uses the access token. Unfortunately, the web application and token proxy API are still accessible to everybody. Therefore, in this paragraph, we are adding the Azure Active Directory (AAD) Authentication to the web application and the token proxy API, so that only authenticated users can view the web application and use the Azure Maps Web Control in a secure way.


 


3.1 We start by registering an application in the Azure Active Directory, and we need this application registration later to give access to the web application and token proxy API.

az ad app create --display-name "Azure Maps Demo App" --web-redirect-uris https://web-azuremaps.azurewebsites.net/signin-oidc --enable-access-token-issuance true --enable-id-token-issuance true --sign-in-audience AzureADMyOrg



 



3.2 We need to add four Identity and Authentication NuGet packages to our web application.

dotnet add package Microsoft.Identity.Web
dotnet add package Microsoft.Identity.Web.UI
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer
dotnet add package Microsoft.AspNetCore.Authentication.OpenIdConnect



 



3.3 Next, we need to add the [Authorize] attribute to every controller in our web application. Below is our token API proxy controller as an example. Do not forget to do this also for the Home controller!

using Azure.Core;
using Azure.Identity;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Authorization;

namespace AzureMapsDemo.Controllers;

[Authorize]
public class ApiController : Controller
{



 



3.4 In the program startup file Program.cs we need to add the Authentication and Authentication logic. Replace all the default code in the Program.cs file with the following:

using Microsoft.AspNetCore.Authentication;
using Microsoft.AspNetCore.Authentication.OpenIdConnect;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc.Authorization;
using Microsoft.Identity.Web;
using Microsoft.Identity.Web.UI;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});

builder.Services.AddControllersWithViews(options =>
{
    var policy = new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser()
        .Build();
    options.Filters.Add(new AuthorizeFilter(policy));
});
builder.Services.AddRazorPages()
    .AddMicrosoftIdentityUI();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");
app.MapRazorPages();
app.MapControllers();

app.Run();



 



3.5 The last step before redeploying our secure web application is to add the details from our registered application in the Azure Active Directory into the configuration file. Open the appsettings.json file and replace this with:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "[PUBLISHER_DOMAIN]",
    "TenantId": "[AAD_TENANT_ID]",
    "ClientId": "[APP_ID]",
    "CallbackPath": "/signin-oidc"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}



 

azure_active_directory.png

 

3.6 Replace the [PUBLISHER_DOMAIN] and [APP_ID] with the values we saved in step 1 when we registered the application. Your Azure Active Directory Tenant ID [AAD_TENANT_ID], you can get with the following command:





az account tenant list


 



3.7 Now we can build and deploy our web application that uses Azure Active Directory to login. We first build and create a release package.

dotnet publish --configuration Release

Compress-Archive -Path binReleasenet6.0publish* -DestinationPath release2.zip



 



3.8 Then we publish our release package to the Azure Web App.

az webapp deployment source config-zip -g rg-azuremaps -n web-azuremaps --src release2.zip



 



3.9 Open a web browser and navigate to the https://web-azuremaps.azurewebsites.net/ where the web-azuremaps subdomain is your unique name when creating the Azure Web App. You are now prompted to log in with your work or school account (AAD) and give permissions.


login_permissions.png


3.10 A recommended last step is to disable the use of the Azure Maps Key authentication.

az maps account update -n map-azuremaps -g rg-azuremaps --disable-local-auth true -s "G2"



 




When we have done all the steps in this step-by-step article, you have a protected web application in combination with Azure Maps that uses of Azure Active Directory, Azure role-based access control (Azure RBAC), and Azure Maps tokens. I recommend that you read our Authentication best practices and Azure Maps documentation. As an example, the Azure Maps Samples website uses most of the steps described in this article. Happy coding.