HIGH privilege escalationaspnetmutual tls

Privilege Escalation in Aspnet with Mutual Tls

Privilege Escalation in Aspnet with Mutual Tls — how this specific combination creates or exposes the vulnerability

In an ASP.NET application, mutual TLS (mTLS) is used to authenticate both the client and the server by requiring each party to present a valid certificate. When mTLS is implemented, the server validates the client certificate chain, issuer, and potentially custom claims before authorizing access. Privilege escalation can occur if the authorization logic does not correctly interpret the certificate claims to enforce role-based or permission-based access controls. Even when the TLS handshake succeeds, an attacker may exploit missing or weak authorization checks to gain higher privileges than intended.

For example, consider an endpoint that should be restricted to administrators. If the server only verifies that a certificate is valid and trusted, but does not validate a specific Enhanced Key Usage (EKU) or a custom claim such as roles=admin, an attacker who possesses any valid client certificate can access the endpoint. This is a common misconfiguration when teams assume mTLS alone is sufficient for authorization. The server must explicitly map certificate attributes to application roles or permissions.

Another scenario involves certificate mapping in ASP.NET Identity. If the application maps certificates to users but does not enforce authorization policies based on claims, a user may escalate privileges by using a certificate that contains broader permissions than intended. The risk is compounded when the application merges certificate-based identity with other schemes (e.g., cookies or tokens) without properly validating the merged principal.

Additionally, if the server does not validate the certificate revocation list (CRL) or use OCSP stapling, an attacker could present a revoked certificate that is still accepted due to incomplete validation. This can allow a previously compromised certificate to retain elevated access. Insecure fallback behavior, such as allowing unauthenticated requests when certificate validation fails, can also inadvertently grant access to unauthenticated users.

During a black-box scan, middleBrick tests for these authorization gaps by sending requests with various client certificates and inspecting whether authorization is correctly enforced. It checks whether role or claim checks are applied after successful mTLS authentication and whether missing validations enable privilege escalation via certificate manipulation.

Mutual Tls-Specific Remediation in Aspnet — concrete code fixes

To securely implement mutual TLS in ASP.NET and prevent privilege escalation, you must combine strict certificate validation with explicit authorization based on certificate claims. Below are concrete code examples and configurations.

1. Enforce Client Certificate Validation

Configure Kestrel to require and validate client certificates. This ensures only certificates trusted by the server are accepted.

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            httpsOptions.ServerCertificate = new X509Certificate2("server.pfx", "password");
            httpsOptions.ClientCertificateValidation = (cert, chain, errors) =>
            {
                // Validate certificate chain
                if (errors != SslPolicyErrors.None)
                {
                    return false;
                }

                // Optionally validate issuer or thumbprint
                if (cert.Issuer != "CN=Trusted CA")
                {
                    return false;
                }

                // Ensure enhanced key usage includes client authentication
                var eku = cert.Extensions.OfType()
                    .SelectMany(e => e.EnhancedKeyUsages)
                    .Select(oid => oid.Value);
                if (!eku.Contains("1.3.6.1.5.5.7.3.2")) // Client Authentication OID
                {
                    return false;
                }

                return true;
            };
        });
    });
});

var app = builder.Build();
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapGet("/secure", () => "Secure data");
app.Run();

2. Map Certificate Claims and Enforce Authorization

After validating the certificate, map its claims and enforce role-based or policy-based authorization.

// Startup.cs or Program.cs
services.AddAuthentication(CertificateAuthenticationDefaults.AuthenticationScheme)
    .AddCertificate(options =>
    {
        options.AllowedCertificateTypes = CertificateTypes.All;
        options.RevocationMode = X509RevocationMode.Online;
        options.RoleClaimType = ClaimTypes.Role;
        options.NameClaimType = Claim.Name;
    });

services.AddAuthorization(options =>
{
    options.AddPolicy("RequireAdmin", policy =>
    {
        policy.RequireAuthenticatedUser();
        policy.RequireClaim(ClaimTypes.Role, "admin");
    });
});

// In a controller or minimal API
app.MapGet("/admin", () => "Admin data")
    .RequireAuthorization("RequireAdmin");

3. Validate Custom Claims for Fine-Grained Access

If roles are encoded as custom claims in the certificate, ensure they are validated explicitly.

services.AddAuthorization(options =>
{
    options.AddPolicy("CanManageUsers", policy =>
    {
        policy.RequireAuthenticatedUser();
        policy.RequireClaim("permissions", "manage_users");
    });
});

4. Avoid Mixing Authentication Schemes Without Proper Validation

If you combine certificate authentication with other schemes, ensure the merged principal is correctly validated and does not allow privilege escalation through weaker schemes.

services.AddAuthentication()
    .AddCertificate()
    .AddCookie();

// In a minimal API, explicitly require certificate authentication for sensitive endpoints
app.MapGet("/sensitive", () => "Sensitive")
    .RequireAuthorization()
    .RequireAssertion(context =>
        context.User.Identity is { IsAuthenticated: true } &&
        context.User.HasClaim(c => c.Type == "role" && c.Value == "admin"));

5. Use Middleware to Enforce Claims Early

Add middleware to validate critical claims before the request reaches sensitive handlers.

app.Use(async (context, next) =>
{
    if (context.User.Identity is { IsAuthenticated: true } &&
        !context.User.HasClaim(c => c.Type == "role" && c.Value == "admin"))
    {
        context.Response.StatusCode = 403;
        return;
    }
    await next();
});

By combining strict mTLS validation with explicit claim and role checks, you reduce the risk of privilege escalation in ASP.NET applications. middleBrick scans for missing claim validations and weak certificate mappings to highlight these issues during security assessments.

Frequently Asked Questions

Can mTLS alone prevent privilege escalation in ASP.NET?

No. Mutual TLS authenticates the client but does not enforce authorization. You must validate certificate claims and apply role-based or policy-based authorization to prevent privilege escalation.

How does middleBrick detect privilege escalation risks with mTLS?

middleBrick checks whether authorization is applied after successful mTLS authentication and whether certificate claims are validated to enforce least privilege. It tests endpoints with different client certificates to identify missing or weak authorization logic.

Privilege Escalation in Aspnet with Mutual Tls