How to remediate – Microsoft IIS 6.0 PHP NTFS Stream Authentication Bypass

1. Introduction

Microsoft IIS 6.0 PHP NTFS Stream Authentication Bypass allows unauthenticated access to PHP files in protected web directories. This is a serious issue because it can lead to confidential data being exposed, websites defaced, and systems compromised. Systems running Microsoft Internet Information Services (IIS) version 6.0 with PHP enabled are usually affected. Impact on confidentiality is likely, integrity may be compromised, and availability could be disrupted.

2. Technical Explanation

The vulnerability occurs because IIS 6.0 incorrectly handles requests for PHP files when ‘::$INDEX_ALLOCATION’ is appended to the directory name in a URL. This bypasses normal authentication checks. An attacker can exploit this by directly requesting these files, gaining access without valid credentials. There is no known Common Vulnerabilities and Exposures (CVE) identifier currently associated with this specific issue.

• Root cause: Missing input validation on directory names allows the ‘::$INDEX_ALLOCATION’ string to be processed as part of a legitimate file path, bypassing authentication.
• Exploit mechanism: An attacker appends ‘::$INDEX_ALLOCATION’ to a protected directory name in a web request. For example, requesting http://example.com/protectedfolder::$INDEX_ALLOCATION might return the contents of a PHP file within that folder without requiring login.
• Scope: Microsoft IIS 6.0 with PHP enabled is affected. Other versions of IIS are not known to be impacted.

3. Detection and Assessment

Confirming vulnerability requires checking the installed IIS version and testing access to protected files. A quick check can identify if IIS 6.0 is running, while a thorough method involves attempting the bypass directly.

• Quick checks: Use PowerShell to view the IIS version.
• Scanning: Nessus plugin ID 38925 may detect this vulnerability as an example only.
• Logs and evidence: Examine IIS logs for requests containing ‘::$INDEX_ALLOCATION’. Look in the default log directory, typically located at %SystemDrive%inetpublogsLogFiles.

powershell Get-WmiObject Win32_WebServer | Select ProductName, Version

4. Solution / Remediation Steps

Currently, there is no known official patch or solution for this vulnerability. Mitigation focuses on restricting access and monitoring for exploitation attempts.

4.1 Preparation

• Dependencies: Ensure you have administrative privileges to modify IIS settings. Roll back plan: Restore the IIS configuration from backup if issues occur.

4.2 Implementation

1. Step 1: Configure URL Authorization in IIS to deny access to files containing ‘::$INDEX_ALLOCATION’. Open IIS Manager.
2. Step 2: Navigate to the website affected. Double-click “Request Filtering”.
3. Step 3: In the Request Filtering section, select “Hidden Segments” in the Features View.
4. Step 4: Add ‘::$INDEX_ALLOCATION’ to the list of hidden segments.
5. Step 5: Restart IIS for changes to take effect.

4.3 Config or Code Example

Before

No hidden segments configured in IIS Request Filtering.

After

::$INDEX_ALLOCATION added as a hidden segment in IIS Request Filtering.

4.4 Security Practices Relevant to This Vulnerability

Practices that improve overall security posture can help mitigate this vulnerability type. Least privilege reduces the impact of successful exploitation, and input validation prevents malicious data from being processed.

• Practice 1: Implement least privilege principles for web server accounts to limit access to sensitive files and resources.
• Practice 2: Employ robust input validation on all user-supplied data to prevent injection attacks and bypass attempts.

4.5 Automation (Optional)

Automation is not recommended due to the potential for misconfiguration. Manual configuration is preferred in this case.

5. Verification / Validation

Confirming the fix involves re-attempting the bypass and verifying access is denied. A service smoke test should also be performed.

• Post-fix check: Attempt to access a protected PHP file with ‘::$INDEX_ALLOCATION’ appended. Expected output: 403 Forbidden error.
• Re-test: Re-run the earlier detection method (attempting the bypass) to confirm it no longer works.
• Smoke test: Verify core website functionality remains operational, such as accessing public pages and submitting forms.
• Monitoring: Monitor IIS logs for 403 errors related to requests containing ‘::$INDEX_ALLOCATION’. This can indicate ongoing exploitation attempts.

Attempting access via browser or curl should return a 403 Forbidden error.

6. Preventive Measures and Monitoring

Regular security baselines and patch management are crucial for preventing this type of vulnerability. Consider adding checks in CI/CD pipelines to identify similar issues during development.

• Baselines: Update your IIS security baseline to include the configuration change described above (hidden segments).
• Pipelines: Implement Static Application Security Testing (SAST) tools to scan code for potential vulnerabilities, including input validation flaws.
• Asset and patch process: Establish a regular schedule for reviewing and applying security patches to all systems, including IIS.

7. Risks, Side Effects, and Roll Back

Configuring hidden segments may inadvertently block legitimate requests if not carefully implemented. Rolling back involves removing the ‘::$INDEX_ALLOCATION’ segment from Request Filtering.

• Risk or side effect 2: Restarting IIS may cause temporary service downtime. Mitigation: Schedule changes during off-peak hours.
• Roll back: Remove ‘::$INDEX_ALLOCATION’ from the Hidden Segments list in IIS Request Filtering and restart IIS.

8. References and Resources

• Vendor advisory or bulletin: https://packetstormsecurity.com/files/113497/iis-bypass.txt
• NVD or CVE entry: No current NVD or CVE entry available for this specific issue.
• Product or platform documentation relevant to the fix: https://msdn.microsoft.com/en-us/library/ff469210.aspx