1. Introduction
ActivityPub Username Enumeration is a vulnerability where usernames on an ActivityPub server can be discovered through wildcard searches in the WebFinger API. This could allow attackers to gather information about users, potentially exposing personal profile addresses and other details. Confidentiality may be impacted by revealing user identities and associated data.
2. Technical Explanation
The vulnerability occurs because some ActivityPub implementations do not properly restrict wildcard character (*) usage in WebFinger queries. An attacker can use these wildcards to systematically request information about different usernames, effectively enumerating valid accounts on the server. This is possible even if user listings are disabled.
- Root cause: Lack of input validation on the /.well-known/webfinger endpoint allowing wildcard characters in requests.
- Exploit mechanism: An attacker sends a series of WebFinger requests with different wildcard patterns to identify valid usernames. For example, requesting “acct:*@example.com” could reveal all users at that domain.
- Scope: ActivityPub servers using vulnerable WebFinger implementations are affected.
3. Detection and Assessment
To confirm vulnerability, check if the server responds to requests containing wildcard characters in the WebFinger endpoint. A thorough method involves attempting to enumerate usernames by sending multiple requests with varying wildcards.
- Quick checks: Use a tool like curl to send a request to the /.well-known/webfinger endpoint with a wildcard character.
- Scanning: Nessus plugin ID 16829 can identify this vulnerability, but results should be verified manually.
- Logs and evidence: Examine server logs for WebFinger requests containing wildcard characters (*).
curl "https://example.com/.well-known/webfinger?q=acct:*@example.com"4. Solution / Remediation Steps
Block requests to the /.well-known/webfinger endpoint containing wildcard characters (*) at the server using a WAF or similar security measure. This prevents attackers from enumerating usernames.
4.1 Preparation
- Ensure you have access to configure your Web Application Firewall (WAF) or equivalent security device. Change windows may be needed depending on your organization’s policies.
4.2 Implementation
- Step 1: Configure your WAF to block requests containing wildcard characters (*) in the query parameter of URLs matching /.well-known/webfinger.
- Step 2: Test the rule by attempting a WebFinger request with a wildcard character to confirm it is blocked.
4.3 Config or Code Example
Before
# No rule blocking wildcard characters in WebFinger requestsAfter
# WAF Rule Example (syntax varies by vendor)
# Block requests to /.well-known/webfinger containing '*' in the query string.
# Example using ModSecurity:
SecRule REQUEST_URI "/.well-known/webfinger" "REQUEST_ARGS|contains:%{TX:wildcard}" "id:9001,phase:2,deny,status:403,logdata:"4.4 Security Practices Relevant to This Vulnerability
Input validation is key to preventing this issue. Blocking unexpected characters in requests prevents attackers from manipulating the system and discovering information. Least privilege can limit the impact if an attacker does manage to enumerate usernames.
- Practice 1: Input Validation – Validate all user-supplied input to ensure it conforms to expected formats and doesn’t contain malicious characters.
- Practice 2: Least Privilege – Ensure that services have only the necessary permissions to function, limiting potential damage from exploitation.
4.5 Automation (Optional)
# Example Ansible task to update a WAF rule (syntax varies by vendor)
- name: Update WAF Rule for ActivityPub Username Enumeration
ansible.builtin.copy:
dest: /etc/waf/rules/activitypub_rule.conf
content: |
SecRule REQUEST_URI "/.well-known/webfinger" "REQUEST_ARGS|contains:%{TX:wildcard}" "id:9001,phase:2,deny,status:403,logdata:"
notify: Restart WAF Service5. Verification / Validation
Confirm the fix by attempting a WebFinger request with a wildcard character and verifying it is blocked. A negative test involves checking that legitimate requests without wildcards still function correctly.
- Post-fix check: Use curl to send a request with a wildcard, expecting a 403 Forbidden error or similar block response.
- Re-test: Repeat the initial detection method (curl with wildcard) and confirm it no longer returns valid usernames.
- Monitoring: Monitor server logs for blocked WebFinger requests containing wildcards to detect potential attacks or misconfigurations.
curl -v "https://example.com/.well-known/webfinger?q=acct:*@example.com" # Expect 403 Forbidden6. Preventive Measures and Monitoring
Regularly update security baselines to include rules for blocking malicious patterns like wildcard characters in WebFinger requests. Incorporate vulnerability scanning into CI/CD pipelines to identify similar issues early in the development process.
- Baselines: Update your web server or WAF baseline configuration with a rule to block wildcard characters in WebFinger requests.
- Pipelines: Add SAST and DAST tools to your CI/CD pipeline to scan for input validation vulnerabilities like this one.
- Asset and patch process: Review security advisories regularly and apply patches promptly, especially for critical services like web servers.
7. Risks, Side Effects, and Roll Back
Blocking all wildcard characters in WebFinger requests might interfere with legitimate applications that rely on them (though this is rare). If issues occur, roll back the WAF rule to allow normal operation.
- Risk or side effect 1: Potential disruption of legitimate services using WebFinger. Monitor logs for false positives and adjust rules if necessary.
- Roll back: Remove the WAF rule blocking wildcard characters in WebFinger requests. Restart your WAF service to apply changes.
8. References and Resources
- Vendor advisory or bulletin: https://docs.joinmastodon.org/spec/webfinger/
- NVD or CVE entry: No specific CVE is associated with this general vulnerability pattern.
- Product or platform documentation relevant to the fix: https://webfinger.net/