Poodle Attack on Azure

The POODLE vulnerability (CVE-2014-3566) exploits a flaw in SSL 3.0’s CBC mode cipher suites, allowing an attacker to decrypt secret cookies by forcing a protocol downgrade. In Azure environments, the issue typically appears when services inadvertently allow SSL 3.0 as a fallback TLS version. Common Azure‑hosted workloads that can expose this surface include:

• Azure App Service web apps or API apps that have not explicitly disabled SSL 3.0 in the platform TLS settings.
• Azure API Management instances where the backend protocol is configured to allow SSL 3.0.
• Azure Functions or Azure Container Apps that rely on the underlying OS TLS stack without enforcing a minimum version.

An attacker can trigger the downgrade by injecting a TLS alert that forces the client and server to renegotiate down to SSL 3.0, then perform the POODLE CBC‑mode attack to steal authentication tokens, API keys, or session cookies transmitted over the channel. Because many Azure services terminate TLS at the platform layer (e.g., App Service front‑door or API Management gateway), a misconfiguration that leaves SSL 3.0 enabled on the front‑end creates a viable attack vector even if the application code itself uses modern TLS.

For example, a .NET 6 API deployed to Azure App Service that calls ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls; will still inherit the platform’s TLS settings. If the App Service is configured to allow SSL 3.0, the negotiated protocol may fall back to SSL 3.0 despite the code’s preference, making the POODLE attack feasible.

Detecting POODLE in Azure requires checking the actual TLS versions offered by the service endpoint, not just the application configuration. middleBrick’s unauthenticated black‑box scan performs a TLS handshake probe and reports whether SSL 3.0 is accepted. When you submit an Azure‑hosted API URL (e.g., https://myapi.azurewebsites.net), middleBrick:

• Initiates a TLS ClientHello with SSL 3.0 offered.
• Observes the ServerHello response; if the server selects SSL 3.0, the scan flags an Encryption finding with severity high.
• Provides the exact cipher suite and TLS version negotiated, allowing you to confirm the downgrade.

Because middleBrick does not require agents or credentials, you can run the scan from the CLI, GitHub Action, or the Web Dashboard against any Azure endpoint—App Service, API Management, Functions, or even a managed Azure Front Door.

Example CLI command:

middlebrick scan https://myapi.azurewebsites.net --format json

The resulting JSON includes a section like:

{
  "category": "Encryption",
  "finding": "SSL 3.0 (POODLE) accepted",
  "severity": "high",
  "remediation": "Disable SSL 3.0 and enforce TLS 1.2 or higher on the Azure service."
}

This output can be parsed in CI pipelines to fail a build when the finding appears, ensuring that any regression that re‑enables SSL 3.0 is caught early.

Remediating POODLE in Azure involves disabling SSL 3.0 at the platform level and ensuring that the application prefers modern TLS versions. The steps differ slightly by service.

Azure App Service

Set the minimum TLS version to 1.2 (or 1.1 if you must support older clients) using Azure CLI or the portal:

az webapp config set \
  --resource-group MyGroup \
  --name MyApp \
  --min-tls-version 1.2

Alternatively, add a web.config transformation that removes SSL 3.0 from the supported protocols (though the platform setting overrides this).

Azure API Management

In the API Management instance, navigate to Custom domains → TLS settings and set Minimum TLS version to 1.2. You can also automate this via an ARM template:

{
  "type": "Microsoft.ApiManagement/service/gateways",
  "apiVersion": "2021-08-01",
  "name": "[parameters('serviceName')]/gateway",
  "properties": {
    "minTlsVersion": "1.2"
  }
}

Azure Functions (Consumption & Premium)

Functions inherit the TLS settings of the underlying App Service plan. Apply the same az functionapp config set command:

az functionapp config set \
  --resource-group MyGroup \
  --name MyFunctionApp \
  --min-tls-version 1.2

Application‑level enforcement (defense in depth)

Even after platform hardening, enforce TLS 1.2+ in code to guard against misconfiguration drift:

// .NET 6+
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
// Java (Spring Boot)
server.ssl.enabled-protocols=TLSv1.2,TLSv1.3
// Node.js
const tls = require('tls');
tls.DEFAULT_MIN_VERSION = 'TLSv1.2';

After applying the changes, re‑run middleBrick to confirm that SSL 3.0 is no longer accepted. Continuous monitoring (available in the Pro plan) will automatically rescan the endpoint on a schedule and alert you if SSL 3.0 ever reappears.