Beast Attack in Aspnet

The Beast Attack (Browser Exploit Against SSL/TLS) is a chosen-plaintext attack that exploits CBC-mode encryption in SSL 3.0 and TLS 1.0. In ASP.NET applications, this manifests through the server's TLS configuration—not application code—but the impact directly compromises session security. When an ASP.NET app runs on IIS or Kestrel with vulnerable protocol settings, an attacker can decrypt HTTP cookies (like ASP.NET_SessionId or .ASPXAUTH) by injecting malicious JavaScript into a user's browser and exploiting predictable IVs in CBC.

ASP.NET's default TLS settings on older Windows Server versions (e.g., Server 2012 R2) often enable SSL 3.0/TLS 1.0 for compatibility. For example, an ASP.NET MVC app hosted on IIS 8.5 with default SCHANNEL settings supports TLS 1.0 and AES-CBC, creating an attack surface. Similarly, ASP.NET Core apps on Kestrel may inherit weak OpenSSL defaults on Linux distributions if not explicitly configured. The attack works by:

1. Forcing the browser to make many HTTPS requests with attacker-controlled plaintext prefixes (via JavaScript).
2. Exploiting the CBC padding oracle to recover the encryption of cookies one byte at a time.
3. Hijacking sessions once the cookie is decrypted.

Real-world impact: CVE-2011-3389 documents this vulnerability in various TLS implementations. An ASP.NET Web API returning authentication tokens in cookies is particularly at risk if TLS 1.0 is enabled.

Detecting Beast Attack vulnerabilities requires testing the TLS configuration of your ASP.NET endpoint. The Encryption check in middleBrick actively probes for SSL 3.0/TLS 1.0 support and CBC cipher suites. Submit your API URL to middleBrick; if the report flags weak protocols or ciphers under the Encryption category, your ASP.NET deployment is vulnerable.

You can also verify manually using testssl.sh:

testssl.sh --protocols https://your-aspnet-api.com

Look for SSLv3 or TLSv1.0 in the output. For cipher-specific checks:

testssl.sh --cipher https://your-aspnet-api.com

If ciphers like AES128-SHA (CBC) appear, the server uses block ciphers vulnerable to Beast. For ASP.NET Core on Kestrel, ensure your environment's OpenSSL version disables TLS 1.0 by default (OpenSSL 1.1.1+ does). On Windows/IIS, check the registry at HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols for enabled protocols.

Note: middleBrick's scan takes 5–15 seconds and requires no credentials, making it suitable for quick validation of staging or production ASP.NET endpoints.

Remediation involves disabling SSL 3.0/TLS 1.0 and preferring TLS 1.2+ with AEAD ciphers (e.g., AES-GCM). The fix is applied at the server level, not in ASP.NET code, but configuration differs between IIS and Kestrel.

IIS (Classic ASP.NET)

Use PowerShell to update SCHANNEL settings. Run as Administrator:

# Disable SSL 3.0 and TLS 1.0
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -Force | Out-Null
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -Name 'Enabled' -Value 0
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Force | Out-Null
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name 'Enabled' -Value 0

# Enable TLS 1.2
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'Enabled' -Value 1

# Set cipher suite order (prioritize AES-GCM)
$cipherOrder = @('TLS_AEAD_AES_128_GCM_SHA256','TLS_AEAD_AES_256_GCM_SHA384','TLS_AES_128_GCM_SHA256','TLS_AES_256_GCM_SHA384')
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers' -Name 'CipherSuites' -Value $cipherOrder

Restart IIS (iisreset) after changes. Alternatively, use the IIS Crypto tool for a GUI.

ASP.NET Core (Kestrel)

In Program.cs, configure Kestrel's HTTPS options to require TLS 1.2+ and set cipher suites (Windows only; Linux requires OpenSSL config):

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(options =>
{
    options.ConfigureHttpsDefaults(httpsOptions =>
    {
        // Require TLS 1.2 or 1.3
        httpsOptions.SslProtocols = System.Security.Authentication.SslProtocols.Tls12 | System.Security.Authentication.SslProtocols.Tls13;
        
        // Windows: set cipher suite policy (requires .NET 5+)
        if (OperatingSystem.IsWindows())
        {
            httpsOptions.CipherSuitesPolicy = new System.Net.Security.CipherSuitesPolicy(new[]
            {
                System.Security.Authentication.CipherSuiteType.TLS_AEAD_AES_128_GCM_SHA256,
                System.Security.Authentication.CipherSuiteType.TLS_AEAD_AES_256_GCM_SHA384
            });
        }
    });
});

var app = builder.Build();
// ... rest of pipeline

On Linux, edit /etc/ssl/openssl.cnf to set CipherString = DEFAULT@SECLEVEL=2 and disable TLS 1.0/1.1 in the [system_default_sect]. Restart the app. Verify with testssl.sh or a middleBrick scan to confirm only TLS 1.2+ and AEAD ciphers are offered.