Dangling Dns in Aspnet
How Dangling Dns Manifests in Aspnet
Dangling DNS in ASP.NET applications typically occurs when DNS records point to infrastructure that has been decommissioned or when CNAME records reference external services that have been removed. In ASP.NET contexts, this often manifests through several specific attack vectors:
- Azure App Service Subdomains: When an Azure App Service is deleted but its DNS CNAME record remains pointing to a now-defunct azurewebsites.net subdomain, attackers can register a new App Service with that exact name and intercept traffic.
- Azure Blob Storage: Similar to App Services, if a blob storage account is deleted but DNS records still point to <account>.blob.core.windows.net, an attacker can recreate the storage account and capture requests.
- API Gateway Endpoints: ASP.NET APIs deployed behind Azure API Management or AWS API Gateway can be vulnerable if the gateway endpoint is removed but DNS records persist.
The ASP.NET-specific risk emerges because these applications often handle authentication, session management, and sensitive data processing. When traffic is redirected to an attacker-controlled endpoint, they can:
- Capture authentication tokens and session cookies
- Intercept API keys and other credentials
- Perform business logic abuse on behalf of legitimate users
- Extract PII from API responses
A concrete example: Consider an e-commerce ASP.NET application with a payment processing endpoint at api.poweredby.com that was originally configured to point to an Azure App Service. If the App Service is deleted but the DNS record remains, an attacker could recreate an App Service with the same name and intercept payment processing requests, potentially capturing credit card data or manipulating order totals.
ASP.NET-Specific Detection
Detecting dangling DNS in ASP.NET applications requires both infrastructure scanning and runtime validation. Here are ASP.NET-specific approaches:
Infrastructure Scanning
Start by auditing your DNS records for any that point to Azure services:
using System.Net;
using System.Net.NetworkInformation;
public class DnsAuditService
{
public async Task
Runtime Validation with middleBrick
middleBrick's black-box scanning approach is particularly effective for detecting dangling DNS in ASP.NET applications. The scanner tests the actual runtime behavior of your endpoints without requiring credentials or access to source code.
When middleBrick scans an ASP.NET API endpoint, it performs several critical checks:
- Authentication Bypass Testing: Attempts to access protected endpoints without credentials to identify if authentication mechanisms are properly configured
- Property Authorization Checks: Tests whether sensitive properties in API responses are properly protected
- SSRF Detection: Identifies if the application is vulnerable to Server-Side Request Forgery, which could be exploited if DNS records point to attacker-controlled infrastructure
For example, if your ASP.NET API at https://api.yourservice.com/v1/orders has dangling DNS records pointing to decommissioned Azure infrastructure, middleBrick will detect that the endpoint is accessible but may be returning unexpected responses or error patterns consistent with infrastructure that's no longer properly configured.
The scanner's 12 parallel security checks include specific validation for ASP.NET patterns like:
- Model binding vulnerabilities that could be exploited if DNS records point to malicious infrastructure
- CORS misconfigurations that might allow unauthorized cross-origin requests
- Session management weaknesses that could be compromised through DNS hijacking
ASP.NET-Specific Remediation
Remediating dangling DNS in ASP.NET applications requires both infrastructure changes and application-level safeguards. Here are ASP.NET-specific remediation strategies:
Infrastructure-Level Fixes
// DNS Record Validation Service
public class DnsRecordValidator
{
private readonly HttpClient _httpClient;
private readonly ILogger<DnsRecordValidator> _logger;
public DnsRecordValidator(HttpClient httpClient, ILogger<DnsRecordValidator> logger)
{
_httpClient = httpClient;
_logger = logger;
}
public async Task<bool> ValidateDnsRecordAsync(string domain)
{
try
{
// Check if the domain resolves to active infrastructure
var addresses = await Dns.GetHostAddressesAsync(domain);
foreach (var address in addresses)
{
// For Azure services, we can check the certificate to verify the service is legitimate
var request = new HttpRequestMessage(HttpMethod.Head, $"https://{domain}");
var response = await _httpClient.SendAsync(request);
if (response.IsSuccessStatusCode)
{
// Verify SSL certificate matches expected service
var cert = await GetCertificateAsync(domain);
if (IsValidAzureCertificate(cert))
{
return true;
}
}
}
}
catch (Exception ex)
{
_logger.LogWarning(ex, "DNS validation failed for {Domain}", domain);
return false;
}
return false;
}
}
ASP.NET Application Safeguards
Implement application-level validation to detect when requests are being routed through unexpected infrastructure:
public class InfrastructureValidationMiddleware
{
private readonly RequestDelegate _next;
private readonly IConfiguration _configuration;
public InfrastructureValidationMiddleware(RequestDelegate next, IConfiguration configuration)
{
_next = next;
_configuration = configuration;
}
public async Task InvokeAsync(HttpContext context)
{
// Validate that the request is coming from expected infrastructure
var expectedHost = _configuration["ExpectedHost"];
var actualHost = context.Request.Host.ToString();
if (!string.Equals(expectedHost, actualHost, StringComparison.OrdinalIgnoreCase))
{
// Unexpected infrastructure - potential DNS hijacking
var ip = context.Connection.RemoteIpAddress?.ToString();
var userAgent = context.Request.Headers["User-Agent"].ToString();
// Log the suspicious request
var logger = context.RequestServices.GetRequiredService<ILogger<InfrastructureValidationMiddleware>>();
logger.LogWarning("Suspicious request from unexpected infrastructure: {Host} from {IP} UserAgent: {UserAgent}",
actualHost, ip, userAgent);
// Optionally reject the request
context.Response.StatusCode = StatusCodes.Status403Forbidden;
await context.Response.WriteAsync("Infrastructure validation failed");
return;
}
await _next(context);
}
}
Startup Configuration
Add the middleware to your ASP.NET application:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
// Add infrastructure validation early in the pipeline
app.UseMiddleware<InfrastructureValidationMiddleware>();
// Other middleware
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
Azure-Specific Safeguards
For ASP.NET applications deployed on Azure, implement additional validation:
public class AzureInfrastructureValidator
{
private readonly IConfiguration _configuration;
public AzureInfrastructureValidator(IConfiguration configuration)
{
_configuration = configuration;
}
public bool IsRunningOnExpectedAzureInfrastructure()
{
// Check for expected Azure headers or metadata
var expectedRegion = _configuration["Azure:Region"];
var actualRegion = GetAzureRegionFromMetadata();
if (!string.Equals(expectedRegion, actualRegion, StringComparison.OrdinalIgnoreCase))
{
return false;
}
// Verify Azure instance metadata
var instanceId = GetAzureInstanceId();
var expectedInstanceId = _configuration["Azure:InstanceId"];
return string.Equals(instanceId, expectedInstanceId, StringComparison.OrdinalIgnoreCase);
}
private string GetAzureRegionFromMetadata()
{
try
{
using var httpClient = new HttpClient();
httpClient.BaseAddress = new Uri("http://169.254.169.254/metadata/instance/compute/location?api-version=2021-01-01&format=text");
httpClient.DefaultRequestHeaders.Add("Metadata", "true");
var response = httpClient.GetStringAsync().Result;
return response;
}
catch
{
return null;
}
}
private string GetAzureInstanceId()
{
try
{
using var httpClient = new HttpClient();
httpClient.BaseAddress = new Uri("http://169.254.169.254/metadata/instance/compute/name?api-version=2021-01-01&format=text");
httpClient.DefaultRequestHeaders.Add("Metadata", "true");
var response = httpClient.GetStringAsync().Result;
return response;
}
catch
{
return null;
}
}
}
Integration with middleBrick
middleBrick can be integrated into your ASP.NET CI/CD pipeline to automatically scan for dangling DNS vulnerabilities:
// GitHub Action workflow for ASP.NET API
name: API Security Scan
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run middleBrick Scan
run: |
npm install -g middlebrick
middlebrick scan https://api.yourservice.com --format json > security-report.json
# Check if any critical issues found
ISSUES=$(jq '.issues | map(select(.severity == "critical" or .severity == "high")) | length' security-report.json)
if [ $ISSUES -gt 0 ]; then
echo "Security scan failed: $ISSUES critical/high issues found"
exit 1
fi
This approach ensures that any dangling DNS issues affecting your ASP.NET API are caught before deployment, preventing the scenario where decommissioned infrastructure could be exploited by attackers.