Container Escape in Aspnet

Container escape in Aspnet applications typically occurs when the application running inside a container gains unauthorized access to the host system or other containers. In Aspnet, this often manifests through insecure file handling, improper use of system resources, or exploitation of the runtime environment.

One common attack vector is through path traversal vulnerabilities in Aspnet file upload functionality. Consider this vulnerable Aspnet Core controller:

[HttpPost("")] public async Task<IActionResult> UploadFile([FromForm] IFormFile file) { var path = Path.Combine("/app/uploads", file.FileName); using var stream = System.IO.File.Create(path); await file.CopyToAsync(stream); return Ok(); }

An attacker can upload a file with a path like ../../../../etc/passwd, escaping the intended directory and accessing sensitive host files. This becomes particularly dangerous in containerized environments where the container might have mounted host directories.

Another Aspnet-specific container escape pattern involves exploiting the process execution capabilities. Aspnet applications might use System.Diagnostics.Process to run shell commands:

public IActionResult RunCommand([FromQuery] string cmd) { var escapedArgs = cmd.Replace(""", """"); var process = new Process() { StartInfo = new ProcessStartInfo { FileName = "/bin/bash", Arguments = $"-c ""{escapedArgs}""", RedirectStandardOutput = true, UseShellExecute = false, CreateNoWindow = true, } }; process.Start(); string result = process.StandardOutput.ReadToEnd(); process.WaitForExit(); return Ok(result); }

If an attacker can control the cmd parameter, they could execute commands like cat /proc/1/cgroup to determine they're in a container, then use docker exec or other container escape techniques to access the host.

Container escape can also occur through Aspnet's handling of environment variables and configuration files. If an application reads sensitive configuration from the host filesystem or exposes container metadata through API endpoints, attackers can leverage this information to craft escape attempts.

Detecting container escape vulnerabilities in Aspnet applications requires both static code analysis and runtime scanning. middleBrick's security scanning platform can identify these issues through its comprehensive API security assessment.

When scanning an Aspnet API endpoint, middleBrick examines the application's attack surface for container escape indicators. The scanner tests for path traversal by attempting to access files outside the intended directory structure using various traversal sequences like ../, ..\, and URL-encoded variants.

middleBrick's black-box scanning approach tests the unauthenticated endpoints for container escape patterns without requiring access credentials. The scanner attempts to:

• Upload files with path traversal payloads to test directory traversal vulnerabilities
• Execute system commands through API endpoints that accept user input
• Access container metadata endpoints like /proc/self/cgroup or /proc/1/cgroup
• Read from sensitive host paths like /etc/passwd, /proc, and mounted volumes
• Test for exposed Docker socket or other container runtime interfaces

The scanner provides a security risk score (A–F) with specific findings for each vulnerability category. For container escape, middleBrick reports on:

Container Escape Risk: F Severity: Critical Finding: Path Traversal in file upload endpoint /api/upload Description: The endpoint allows traversal outside the intended directory using ../ sequences. Recommendation: Validate and sanitize file paths, use a safe upload directory with proper permissions.

middleBrick also analyzes OpenAPI/Swagger specifications to identify endpoints that might be vulnerable to container escape based on their parameter definitions and security requirements. The scanner cross-references these specifications with runtime findings to provide comprehensive coverage.

For Aspnet applications specifically, middleBrick tests the common patterns where container escape manifests, including file upload endpoints, command execution interfaces, and configuration endpoints that might expose sensitive information.

Securing Aspnet applications against container escape requires implementing multiple defensive layers. Here are Aspnet-specific remediation strategies:

1. Secure File Upload Handling

Instead of directly using user-provided file names, implement a secure upload system:

public class SecureUploadService { private readonly string _uploadDirectory; public SecureUploadService(IWebHostEnvironment env) { _uploadDirectory = Path.Combine(env.ContentRootPath, "uploads"); if (!Directory.Exists(_uploadDirectory)) Directory.CreateDirectory(_uploadDirectory); } public async Task<string> SaveFileAsync(IFormFile file) { // Generate a safe, unique file name var safeFileName = string.Concat( Guid.NewGuid().ToString(), Path.GetExtension(file.FileName) ); var filePath = Path.Combine(_uploadDirectory, safeFileName); // Ensure the final path is within the upload directory if (!Path.GetFullPath(filePath).StartsWith(_uploadDirectory)) { throw new InvalidOperationException("Invalid file path"); } using var stream = System.IO.File.Create(filePath); await file.CopyToAsync(stream); return safeFileName; } }

2. Input Validation and Sanitization

Implement strict input validation for any user-controlled data:

public class SafePathValidator { private readonly string _baseDirectory; public SafePathValidator(string baseDirectory) { _baseDirectory = Path.GetFullPath(baseDirectory); } public bool IsSafePath(string userInputPath) { try { var fullPath = Path.GetFullPath(Path.Combine(_baseDirectory, userInputPath)); return fullPath.StartsWith(_baseDirectory); } catch { return false; } } }

3. Restrict Process Execution

Avoid using System.Diagnostics.Process with user input. If command execution is necessary, implement strict controls:

public class SafeProcessExecutor { private readonly HashSet<string> _allowedCommands; public SafeProcessExecutor() { _allowedCommands = new HashSet<string> { "ls", "dir", "echo" }; // Only allow specific, safe commands } public async Task<string> ExecuteCommandAsync(string commandName, string arguments) { if (!_allowedCommands.Contains(commandName)) { throw new UnauthorizedAccessException("Command not allowed"); } var escapedArgs = arguments.Replace(""", """"); var process = new Process() { StartInfo = new ProcessStartInfo { FileName = commandName, Arguments = escapedArgs, RedirectStandardOutput = true, UseShellExecute = false, CreateNoWindow = true, } }; process.Start(); string result = await process.StandardOutput.ReadToEndAsync(); process.WaitForExit(); return result; } }

4. Principle of Least Privilege

Configure container runtime with minimal privileges:

// In your Dockerfile USER appuser # Don't run as root RUN addgroup --system --gid 1001 dotnet && 
 adduser --system --uid 1001 aspnet # Create a non-privileged user # Drop capabilities and use read-only filesystems for sensitive areas # Use --cap-drop ALL and --cap-add if specific capabilities are needed

5. Runtime Security Monitoring

Integrate security monitoring into your Aspnet application:

public class SecurityMiddleware { private readonly RequestDelegate _next; public SecurityMiddleware(RequestDelegate next) { _next = next; } public async Task InvokeAsync(HttpContext context) { // Check for suspicious patterns if (context.Request.Method == HttpMethod.Post.Method && context.Request.HasFormContentType) { var form = await context.Request.ReadFormAsync(); foreach (var key in form.Keys) { var value = form[key]; if (IsSuspiciousContent(value)) { // Log and block the request await context.Response.WriteAsync("Invalid request"); return; } } } await _next(context); } private bool IsSuspiciousContent(string content) { // Check for path traversal, command injection patterns return content.Contains("../") || content.Contains("..\") || content.Contains("|") || content.Contains("`"); } }

By implementing these Aspnet-specific remediation strategies, you significantly reduce the risk of container escape vulnerabilities in your applications.