Insecure Deserialization on Azure

Insecure deserialization in Azure environments typically occurs when applications accept serialized data from untrusted sources and deserialize it without proper validation. Azure's platform-agnostic nature means this vulnerability can appear across various Azure services, from web apps to functions and storage solutions.

The most common attack pattern involves an attacker crafting a malicious serialized payload that, when deserialized by an Azure-hosted application, executes arbitrary code or manipulates application logic. For example, an Azure Function that accepts serialized objects via HTTP triggers could be exploited if it uses unsafe deserialization libraries.

Azure's distributed architecture creates unique attack surfaces. When applications use Azure Storage queues or Service Bus to pass serialized objects between components, an attacker who compromises one component can inject malicious payloads that propagate through the messaging system. Similarly, Azure Cache for Redis instances storing serialized session data become targets if applications don't validate cached objects before deserialization.

A specific Azure vulnerability pattern emerged in 2022 when researchers discovered that .NET applications running on Azure App Service could be exploited through insecure deserialization of objects stored in Azure Table Storage. Attackers could craft malicious table entities that, when deserialized by the application, led to remote code execution. This affected applications using the Azure Storage SDK without proper type validation.

Azure Functions present another attack vector. When functions accept serialized data in blob triggers or HTTP requests, they may inadvertently deserialize untrusted content. A function processing uploaded files might deserialize metadata without validation, allowing attackers to execute arbitrary code within the function's sandboxed environment.

Real-world exploitation often follows this pattern: an attacker identifies an Azure-hosted application that accepts serialized data (often through API endpoints or file uploads), crafts a malicious payload using known deserialization gadget chains, and submits it to the application. If the application uses vulnerable libraries like older versions of Newtonsoft.Json or System.Text.Json without proper safeguards, the payload executes.

The distributed nature of Azure microservices architectures amplifies this risk. When services communicate through serialized messages in Azure Service Bus or Event Grid, a single vulnerable service can compromise the entire message flow, affecting downstream services that process the malicious payloads.

Detecting insecure deserialization in Azure requires both static analysis of your codebase and dynamic scanning of running applications. middleBrick's Azure-specific scanning capabilities identify deserialization vulnerabilities by examining API endpoints for risky patterns and testing them with malicious payloads.

When scanning Azure-hosted APIs, middleBrick tests for common deserialization endpoints by sending serialized payloads crafted to trigger known gadget chains. The scanner examines HTTP responses for signs of successful exploitation, such as error messages revealing stack traces or unexpected behavior indicating code execution.

For Azure Functions, middleBrick can scan the function's HTTP-triggered endpoints directly. The scanner tests for deserialization vulnerabilities by submitting payloads through the function's URL, mimicking how an attacker would target the function. This approach works because Azure Functions expose HTTP endpoints that can be scanned without special credentials.

Azure App Service applications benefit from middleBrick's ability to scan web APIs without requiring access to the underlying infrastructure. The scanner tests all exposed endpoints, looking for those that might accept serialized data through request bodies, query parameters, or headers. It specifically targets endpoints that might process JSON, XML, or binary serialized formats.

middleBrick's scanning process for Azure environments includes testing for framework-specific vulnerabilities. For .NET applications on Azure, the scanner tests for vulnerabilities in common deserialization libraries like Newtonsoft.Json, System.Text.Json, and BinaryFormatter. It also checks for unsafe usage patterns in Azure-specific SDKs and libraries.

The scanner's 12 security checks include specific tests for deserialization vulnerabilities across different categories. Property Authorization checks verify that serialized objects don't expose sensitive properties, while Input Validation tests ensure that deserialized data undergoes proper sanitization before use.

For applications using Azure Storage or Service Bus, middleBrick can test the deserialization of objects stored in these services by simulating how an attacker might craft malicious storage entities or messages. This helps identify vulnerabilities that might not be apparent from just scanning HTTP endpoints.

middleBrick's LLM/AI Security checks also become relevant when Azure applications use AI services. If an application serializes and deserializes AI model configurations or prompts, the scanner tests for prompt injection vulnerabilities that could lead to arbitrary code execution through deserialization of malicious AI-related data.

The scanner provides detailed findings with severity levels, showing exactly which endpoints are vulnerable and what types of deserialization attacks they're susceptible to. This helps Azure developers prioritize fixes based on the actual risk to their specific deployment.

Remediating insecure deserialization in Azure applications requires a multi-layered approach that combines safe coding practices with Azure's built-in security features. The most effective strategy is to avoid deserialization of untrusted data entirely, but when this isn't possible, implement strict controls.

For .NET applications on Azure App Service or Functions, replace unsafe deserialization libraries with secure alternatives. Instead of BinaryFormatter or older Newtonsoft.Json versions, use System.Text.Json with strict type constraints:

using System.Text.Json;

public class SafeDeserializer
{
    public static T DeserializeSafe<T>(string json)
    {
        var options = new JsonSerializerOptions
        {
            AllowTrailingCommas = false,
            MaxDepth = 64,
            ReadCommentHandling = JsonCommentHandling.Disallow
        };
        
        return JsonSerializer.Deserialize<T>(json, options);
    }
}

This code enforces strict parsing rules that prevent many deserialization attacks. For Azure Functions specifically, validate all incoming data before processing:

[Function("SecureFunction")]
public static async Task<HttpResponseData> Run(
    [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequestData req,
    FunctionContext context)
{
    try
    {
        var json = await new StreamReader(req.Body).ReadToEndAsync();
        
        // Validate JSON structure before deserialization
        if (!IsValidJsonStructure(json))
            return req.CreateResponse(HttpStatusCode.BadRequest);
            
        var safeObject = SafeDeserializer.DeserializeSafe<MySafeType>(json);
        
        // Process the object
        return req.CreateResponse(HttpStatusCode.OK);
    }
    catch (JsonException)
    {
        return req.CreateResponse(HttpStatusCode.BadRequest);
    }
}

Azure's App Service provides additional security layers. Enable the built-in Web Application Firewall (WAF) to block known deserialization attack patterns at the network level. Configure WAF rules to inspect and block suspicious serialized payloads before they reach your application.

For Azure Functions, implement input validation using Azure's built-in bindings and triggers. When using queue triggers, validate the message content before processing:

public static class QueueFunction
{
    [Function("QueueProcessor")]
    public static void Run(
        [QueueTrigger("myqueue-items", Connection = "AzureWebJobsStorage")] string myQueueItem,
        FunctionContext context)
    {
        if (!IsValidSerializedData(myQueueItem))
        {
            // Log and discard malicious payload
            var logger = context.GetLogger("QueueProcessor");
            logger.LogWarning("Discarded potentially malicious queue item");
            return;
        }
        
        // Safe to process
        ProcessQueueItem(myQueueItem);
    }
}

Azure Security Center provides continuous monitoring for deserialization vulnerabilities. Enable Defender for App Service to receive alerts about potential deserialization attacks targeting your Azure applications. The service monitors for suspicious patterns and can automatically block malicious requests.

For applications using Azure Storage, implement strict access controls and validate all data read from storage. Never deserialize objects from untrusted storage sources without validation:

public class SecureStorageService
{
    private readonly BlobServiceClient _blobClient;
    
    public async Task<MySafeType> GetValidatedObjectAsync(string containerName, string blobName)
    {
        var container = _blobClient.GetBlobContainerClient(containerName);
        var blob = container.GetBlobClient(blobName);
        
        // Download and validate before deserialization
        var downloadInfo = await blob.DownloadContentAsync();
        var content = downloadInfo.Content.ToString();
        
        if (!IsValidContent(content))
            throw new SecurityException("Invalid content detected");
            
        return SafeDeserializer.DeserializeSafe<MySafeType>(content);
    }
}

Implement Azure AD authentication and authorization to ensure only trusted components can submit serialized data to your services. Use managed identities for Azure resources to eliminate the need for storing credentials that could be used to craft malicious payloads.

Finally, integrate middleBrick's continuous scanning into your Azure DevOps pipeline. Configure the GitHub Action to scan your Azure-hosted APIs before deployment, ensuring that deserialization vulnerabilities are caught early in the development lifecycle.