1. Introduction
Well-Known URIs are used by websites to store metadata and make it available for web protocols needing policy discovery or host information retrieval. These URIs use the `/.well-known` path prefix, which is standardised to prevent naming conflicts. This vulnerability indicates their presence on a system; while not directly exploitable, they can be misused in attacks like content spoofing or credential phishing. A compromise could affect confidentiality, integrity and availability of web services.
2. Technical Explanation
Well-known URIs themselves aren’t the vulnerability but their presence indicates a potential attack surface. Attackers may exploit these locations to host malicious content that appears legitimate. The main risk is misconfiguration allowing unintended data exposure or manipulation. No specific CVE currently exists for simply *detecting* well-known URIs, however RFC8615 defines the standard and its use. An attacker could create a fake login page at `/.well-known/openid-configuration` to steal user credentials if the server isn’t properly secured.
- Root cause: The presence of publicly accessible well-known URI paths without sufficient security controls.
- Exploit mechanism: An attacker could place malicious files in these directories, potentially redirecting users or serving harmful content.
- Scope: All web servers and applications that implement well-known URIs are affected. This includes Apache, Nginx, IIS, and any custom web application frameworks.
3. Detection and Assessment
- Quick checks: Use `curl` to list the contents of the /.well-known directory. For example:
curl -s https://example.com/.well-known - Scanning: Nessus plugin ID 16394 can identify exposed well-known URI paths, but results should be manually verified.
- Logs and evidence: Web server access logs may show requests to the /.well-known directory. Look for unusual activity or unexpected file accesses.
curl -s https://example.com/.well-known4. Solution / Remediation Steps
Secure well-known URI paths by restricting access and validating content.
4.1 Preparation
- Ensure you have access to modify the web server configuration files. A roll back plan involves restoring the original configuration file.
- Changes may require a short maintenance window, depending on the complexity of your setup and approval processes.
4.2 Implementation
- Step 1: Restrict access to the /.well-known directory using web server configuration rules (e.g., allow only specific IP addresses or user agents).
- Step 2: Implement input validation on any files served from the /.well-known directory to prevent malicious content uploads.
- Step 3: Regularly review the contents of the /.well-known directory for unexpected changes.
4.3 Config or Code Example
Before
# Apache - Allow access from any IP address
<Directory /var/www/html/.well-known>
Require all granted
</Directory>After
# Apache - Restrict access to specific IPs
<Directory /var/www/html/.well-known>
Require ip 192.168.1.0/24
</Directory>4.4 Security Practices Relevant to This Vulnerability
Practices that directly address this vulnerability type include least privilege and input validation.
- Practice 1: Least privilege reduces the impact if a well-known URI is compromised by limiting access to only necessary users or services.
- Practice 2: Input validation prevents malicious content from being uploaded or served through the /.well-known directory, mitigating potential attacks.
4.5 Automation (Optional)
No automation script is provided as configuration varies widely.
5. Verification / Validation
Confirm that access to the /.well-known directory is restricted and content validation is working correctly.
- Post-fix check: Use `curl` from an unauthorized IP address; you should receive a 403 Forbidden error.
- Re-test: Re-run the earlier detection using `curl -s https://example.com/.well-known`. The output should show no accessible files or directories.
- Smoke test: Verify that any legitimate services relying on well-known URIs (e.g., OpenID Connect) continue to function correctly.
- Monitoring: Monitor web server access logs for failed requests to the /.well-known directory, which could indicate attempted unauthorized access.
curl -s https://example.com/.well-known6. Preventive Measures and Monitoring
Update security baselines and implement checks in CI/CD pipelines to prevent similar issues.
- Baselines: Update your web server security baseline to include restrictions on access to the /.well-known directory.
- Pipelines: Add static analysis (SAST) or dynamic application security testing (DAST) tools to your CI/CD pipeline to identify potential vulnerabilities in well-known URI configurations.
- Asset and patch process: Review web server configurations regularly as part of a standard asset management and patching cycle.
7. Risks, Side Effects, and Roll Back
Restricting access to the /.well-known directory could break legitimate services relying on it.
- Roll back: Restore the original web server configuration file from your backup. Restart the web service.
8. References and Resources
Link only to sources that match this exact vulnerability.
- Vendor advisory or bulletin: N/A – This is a general security practice, not a specific vendor issue.
- NVD or CVE entry: N/A – No specific CVE for detecting well-known URIs.
- Product or platform documentation relevant to the fix: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml