How to remediate – ADFS Relying Party Trusts Disclosure

1. Introduction

ADFS Relying Party Trusts Disclosure is a vulnerability in Microsoft Active Directory Federation Services (ADFS) where the IdP-initiated sign on page, when enabled, reveals configured SAML applications. This allows attackers to gather information about an organization’s assets for further attacks. Affected systems are typically ADFS servers used for Single Sign On (SSO). The impact is primarily information disclosure, potentially leading to reconnaissance and increased risk of successful phishing or other targeted attacks.

2. Technical Explanation

The vulnerability occurs because the ADFS IdP-initiated sign on page displays a list of all configured SAML applications by default. An unauthenticated attacker can access this page and enumerate these applications, gaining insight into an organization’s internal systems and services. There is no CVE associated with this specific disclosure; however, it’s related to misconfiguration. A remote attacker could simply browse to the IdP endpoint to view the application list. Affected versions are those where IdP-initiated sign on is enabled.

• Root cause: The default configuration of ADFS exposes configured SAML applications via the IdP-initiated sign on page.
• Exploit mechanism: An attacker accesses the ADFS IdP endpoint to enumerate the list of relying party trusts (SAML applications).
• Scope: Microsoft Active Directory Federation Services (ADFS) servers with IdP-initiated sign on enabled.

3. Detection and Assessment

To confirm vulnerability, check if the IdP-initiated sign on page is accessible. A thorough method involves examining the ADFS configuration for enabled relying party trusts.

• Quick checks: Access the ADFS IdP endpoint in a web browser (e.g., https://yourADFSserver/adfs/ls/?wa=wsignin1.0). If a list of applications is displayed, the system is likely vulnerable.
• Scanning: Nessus plugin ID 139264 can identify this issue. This is an example only and may require updates.
• Logs and evidence: ADFS logs do not directly indicate this vulnerability; however, access logs to the IdP endpoint might show unauthenticated requests.

4. Solution / Remediation Steps

Disable the IdP-initiated sign on page to prevent information disclosure. This is the recommended solution as it removes the attack vector without impacting standard SSO functionality.

4.1 Preparation

• Ensure you have administrative access to the ADFS server. Roll back involves re-enabling IdP-initiated sign on.
• Change windows may be needed during peak hours. Approval from security or IT operations might be required.

4.2 Implementation

1. Step 1: Open PowerShell as an administrator on the ADFS server.
2. Step 2: Run the following command to disable IdP-initiated sign on: Set-AdfsProperties -EnableIdpInitiatedSignOn $false.
3. Step 3: Verify the change using Get-AdfsProperties | Select-Object EnableIdpInitiatedSignOn. The output should show `EnableIdpInitiatedSignOn : False`.

4.3 Config or Code Example

Before

Get-AdfsProperties | Select-Object EnableIdpInitiatedSignOn
EnableIdpInitiatedSignOn
------------------------
True

After

Set-AdfsProperties -EnableIdpInitiatedSignOn $false
Get-AdfsProperties | Select-Object EnableIdpInitiatedSignOn
EnableIdpInitiatedSignOn
------------------------
False

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact of information disclosure, while secure configuration management ensures systems are hardened by default.

• Practice 1: Implement least privilege access controls to limit the potential damage from exposed information.
• Practice 2: Follow a secure configuration baseline for ADFS servers to minimize unnecessary features and services.

4.5 Automation (Optional)

# Example PowerShell script to disable IdP-initiated sign on across multiple ADFS servers
$ADFSServers = @("server1", "server2") # Replace with your server names
foreach ($Server in $ADFSServers) {
    try {
        Invoke-Command -ComputerName $Server -ScriptBlock {
            Set-AdfsProperties -EnableIdpInitiatedSignOn $false
            Get-AdfsProperties | Select-Object EnableIdpInitiatedSignOn
        }
    } catch {
        Write-Host "Error disabling IdP-initiated sign on on $Server: $($_.Exception.Message)"
    }
}

5. Verification / Validation

Confirm the fix by verifying that the IdP-initiated sign on page is no longer accessible or displays an error message. A negative test involves attempting to access the page and confirming it’s blocked.

• Post-fix check: Access https://yourADFSserver/adfs/ls/?wa=wsignin1.0 in a web browser. You should receive an error message or be redirected to another page, not the application list.
• Re-test: Repeat the quick check from Section 3; it should no longer display the application list.
• Smoke test: Verify that standard SSO functionality (e.g., logging into corporate applications) continues to work as expected.
• Monitoring: Monitor ADFS access logs for any unusual activity related to the IdP endpoint.

Access https://yourADFSserver/adfs/ls/?wa=wsignin1.0 in a web browser - should return an error message or redirect.

6. Preventive Measures and Monitoring

Regular security baselines, pipeline checks, and patch management are key to preventing this vulnerability type. For example, update your ADFS server configuration baseline to disable IdP-initiated sign on by default.

• Baselines: Update a security baseline or policy to include the setting for disabling IdP-initiated sign on.
• Pipelines: Add checks in CI/CD pipelines to ensure that new ADFS servers are configured securely and do not have this vulnerability.
• Asset and patch process: Implement a regular review cycle for ADFS server configurations to identify and address any deviations from the security baseline.

7. Risks, Side Effects, and Roll Back

Disabling IdP-initiated sign on may impact certain applications or integrations that rely on this feature. The roll back steps involve re-enabling it.

• Risk or side effect 1: Some applications might require SP-initiated sign on instead of IdP-initiated sign on, requiring configuration changes in those apps.
• Risk or side effect 2: Users accustomed to IdP-initiated sign on may need to adjust their workflow.
• Roll back: Run the following command in PowerShell as an administrator: Set-AdfsProperties -EnableIdpInitiatedSignOn $true. Verify using