1. Introduction
The Microsoft IIS bdir.htr Arbitrary Directory Listing vulnerability is an information disclosure issue affecting Internet Information Services web servers. A default file, ‘bdir.htr’, can expose unnecessary details about the server’s filesystem to attackers. This could allow them to escalate privileges and gain Administrator access. Confidentiality, integrity, and availability may be impacted if system files are accessed or modified.
2. Technical Explanation
The vulnerability occurs because the ‘bdir.htr’ script is present by default in IIS installations and allows browsing and file creation on the hard drive. An attacker can use this to view sensitive system files, potentially leading to privilege escalation. The exploit requires access to a web server running IIS with the bdir.htr file enabled.
- Root cause: The default configuration includes a script that allows unrestricted filesystem access.
- Exploit mechanism: An attacker sends requests to the ‘bdir.htr’ script to list directories and files, then potentially create or modify them. For example, an attacker could request
http://example.com/bdir.htrto view directory contents. - Scope: Affected platforms are servers running Microsoft IIS. Specific versions were not provided in the context.
3. Detection and Assessment
You can confirm a system is vulnerable by checking for the presence of the ‘bdir.htr’ file. A thorough method involves reviewing access control lists on this file.
- Quick checks: Use PowerShell to check if the file exists in the IIS installation directory, typically
C:inetpubwwwroot. - Scanning: Nessus plugin ID 30198 can identify this vulnerability as an example.
- Logs and evidence: Check IIS logs for requests accessing ‘bdir.htr’. The exact log path depends on your IIS configuration, but is often found in
%SystemDrive%inetpublogsLogFiles.
Get-ChildItem -Path "C:inetpubwwwroot" -Filter "bdir.htr"4. Solution / Remediation Steps
To fix this issue, either delete the ‘bdir.htr’ file if it is not required or restrict access using appropriate security settings.
4.1 Preparation
- Ensure you have administrator privileges to modify IIS settings. A roll back plan is to restore the IIS configuration from backup.
- A change window may be required depending on your organisation’s policies, with approval from a system owner.
4.2 Implementation
- Step 1: Delete the ‘bdir.htr’ file if it is not needed. Use PowerShell or File Explorer to remove the file from the IIS installation directory (e.g.,
C:inetpubwwwroot). - Step 2: If you need to keep the file, configure access control lists (ACLs) to restrict read access to only authorized users and groups. Use IIS Manager or icacls command-line tool.
4.3 Config or Code Example
Before
icacls "C:inetpubwwwrootbdir.htr" /grant Everyone:(F)After
icacls "C:inetpubwwwrootbdir.htr" /remove:g Everyone /grant Administrators:(F) /grant IIS_IUSRS:(RX)4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this type of issue. Least privilege reduces the impact if exploited, and safe defaults minimise unnecessary exposure. Regular patch cadence ensures timely fixes for known vulnerabilities.
- Practice 1: Implement least privilege by granting only necessary permissions to users and groups accessing IIS resources.
- Practice 2: Use safe defaults when configuring IIS, avoiding unnecessary features or files like ‘bdir.htr’.
4.5 Automation (Optional)
A PowerShell script can automate the ACL modification process.
# Caution: Test thoroughly before deploying to production!
$path = "C:inetpubwwwrootbdir.htr"
icacls $path /remove:g Everyone
icacls $path /grant Administrators:(F)
icacls $path /grant IIS_IUSRS:(RX)5. Verification / Validation
Confirm the fix by checking the ACLs on ‘bdir.htr’ and attempting to access it anonymously. A smoke test should verify basic web server functionality.
- Post-fix check: Use
icacls "C:inetpubwwwrootbdir.htr"and confirm that ‘Everyone’ no longer has full control (F) permissions. - Re-test: Re-run the quick check from section 3 to ensure the file is not world-readable.
- Smoke test: Verify you can still access a standard web page hosted on the server.
- Monitoring: Monitor IIS logs for any unexpected access attempts to ‘bdir.htr’.
icacls "C:inetpubwwwrootbdir.htr"6. Preventive Measures and Monitoring
Update security baselines to include restrictions on the ‘bdir.htr’ file. Add checks in your deployment pipeline to prevent its inclusion or ensure secure configuration. Implement a regular patch review cycle for IIS components.
- Baselines: Update your server security baseline to reflect the removal or restricted access of ‘bdir.htr’.
- Pipelines: Include static code analysis (SCA) in your CI/CD pipeline to identify insecure configurations like open permissions on sensitive files.
7. Risks, Side Effects, and Roll Back
Deleting ‘bdir.htr’ may break functionality if it is used by other applications (unlikely). Restricting access could impact legitimate users if not configured correctly. Restore the IIS configuration from backup to roll back changes.
- Risk or side effect 1: Deleting the file might cause unexpected errors in rarely-used features.
- Risk or side effect 2: Incorrect ACLs may prevent authorized users from accessing necessary resources.
- Roll back: Restore the IIS configuration from the backup created in step 4.1.
8. References and Resources
- Vendor advisory or bulletin: SecurityFocus BID 2280
- NVD or CVE entry: No CVE was provided in the context.
- Product or platform documentation relevant to the fix: Microsoft IIS File Permissions