How to remediate – ELMAH (Error Logging Modules and Handlers) Remotely Accessible

1. Introduction

ELMAH (Error Logging Modules and Handlers) is an error logging application used with ASP.NET web applications. A remotely accessible instance presents a security risk as it can expose detailed information about the web server’s internal workings to unauthenticated attackers. This could allow them to gather sensitive data for further attacks, potentially compromising confidentiality, integrity, and availability of the system.

2. Technical Explanation

The vulnerability occurs when the elmah.axd script is accessible remotely without authentication. Attackers can directly access this page via a web browser, revealing detailed error logs that may contain database connection strings, internal paths, and other sensitive information. This allows them to map out the application’s structure and identify potential attack vectors.

• Root cause: Missing or insufficient authentication on the elmah.axd script.
• Exploit mechanism: An attacker sends a standard HTTP GET request to the publicly accessible elmah.axd URL. For example, http://example.com/elmah.axd.
• Scope: ASP.NET web applications using ELMAH version 1.x and earlier are affected.

3. Detection and Assessment

To confirm vulnerability, check for remote accessibility of the elmah.axd script. A thorough method involves attempting to access error logs directly.

• Quick checks: Use a web browser to navigate to http://[target_host]/elmah.axd. If accessible without authentication, the system is likely vulnerable.
• Scanning: Nessus plugin ID 32869 can detect remotely accessible ELMAH instances. This is an example only and may require updates.
• Logs and evidence: Web server logs may show access attempts to elmah.axd from external IP addresses.

curl -I http://example.com/elmah.axd

4. Solution / Remediation Steps

Restrict access to the elmah.axd script to prevent unauthorized access to error logs.

4.1 Preparation

• Ensure you have administrative access to the web server and the ability to modify the web.config file. Change windows should be scheduled during off-peak hours.

4.2 Implementation

1. Step 1: Open the web.config file for your ASP.NET application.
2. Step 2: Add a configuration section to restrict access to elmah.axd using an IP address restriction or authentication.
3. Step 3: Save the changes to the web.config file.
4. Step 4: Restart the web service if it was stopped in step 1.

4.3 Config or Code Example

Before

<system.webServer>
  <handlers>
    <add name="ElmahHandler" type="Elmah.ErrorLogPageHandler, Elmah" path="elmah.axd" verb="*" />
  </handlers>
</system.webServer>

After

<system.webServer>
  <security>
    <ipSecurity allowUnlisted="false" ipRestrictMode="Deny">
      <add ipAddress="127.0.0.1" allowed="true"/> 
      <add ipAddress="::1" allowed="true"/> 
    </ipSecurity>
  </security>
  <handlers>
    <add name="ElmahHandler" type="Elmah.ErrorLogPageHandler, Elmah" path="elmah.axd" verb="*" preCondition="integratedMode,runtimeVersionv4.0"/>
  </handlers>
</system.webServer>

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Practice 1: Least privilege – restrict access to sensitive resources like error logs to only authorized personnel or systems.
• Practice 2: Secure configuration – ensure all application configurations are reviewed for unnecessary exposure of sensitive information.

4.5 Automation (Optional)

# Example PowerShell script to update web.config (use with caution!)
# Replace placeholders with your actual values
$webConfigPath = "C:inetpubwwwrootyour_appweb.config"
$ipAddress = "127.0.0.1"
(Get-Content $webConfigPath) | ForEach-Object {
  if ($_ -match "<system.webServer>") {
    $_ + "<security><ipSecurity allowUnlisted="false" ipRestrictMode="Deny"><add ipAddress="$ipAddress" allowed="true"/></ipSecurity></security>"
  } else {
    $_
  }
} | Set-Content $webConfigPath

5. Verification / Validation

Confirm the fix by attempting to access elmah.axd from a non-authorized IP address. Verify that access is denied. Also, confirm application functionality remains unaffected.

• Post-fix check: Navigate to http://[target_host]/elmah.axd from an unauthorized network. Expect a 403 Forbidden error or similar access denial message.
• Re-test: Repeat the quick check from section 3, ensuring that elmah.axd is no longer accessible without authentication.
• Monitoring: Monitor web server logs for access attempts to elmah.axd and alert on any unauthorized access.

curl -I http://example.com/elmah.axd

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.

• Baselines: Update security baselines or policies to include restrictions on access to error logging pages.
• Pipelines: Add static code analysis (SAST) checks in CI/CD pipelines to identify potential exposure of sensitive information in configuration files.
• Asset and patch process: Implement a regular review cycle for application configurations, ensuring adherence to security best practices.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 2: Changes to web.config