How to remediate – SMTP Host Information in NTLM SSP

1. Introduction

2. Technical Explanation

Nessus extracts host information from the NTLM SSP challenge response exchanged during an NTLM handshake over SMTP. This occurs when a client authenticates to an SMTP server using NTLM. The vulnerability exists because the NTLM SSP message isn’t adequately protected, allowing passive observation of this data. There is no specific CVE currently associated with this issue, but it relates to weaknesses in the NTLM protocol (CWE-261). An attacker could use Nessus or a similar tool to passively monitor SMTP traffic and identify hostnames and other details from the NTLM exchange.

• Root cause: The NTLM SSP challenge message contains unencrypted host information.
• Exploit mechanism: An attacker captures network traffic during an NTLM authentication over SMTP, then parses the NTLM SSP message to extract host data. For example, using a packet capture tool like Wireshark and analysing the NTLM handshake.
• Scope: Windows systems utilising NTLM authentication with SMTP services are affected. Specific versions aren’t identified in this report.

3. Detection and Assessment

Confirming vulnerability involves checking for NTLM usage over SMTP, and verifying information is exposed during the handshake. A quick check can identify if NTLM is enabled. Thorough assessment requires network traffic analysis.

• Quick checks: Use PowerShell to view authentication protocols in use on a Windows system.
• Scanning: Nessus identifies this issue with plugin ID 13926, but results should be verified manually.
• Logs and evidence: SMTP server logs may show NTLM authentication attempts. Event IDs will vary depending on the mail server software used.

Get-WmiObject -Class Win32_AuthenticationSetting | Where-Object {$_.Name -like "*NTLM*"}

4. Solution / Remediation Steps

The best solution is to disable NTLM authentication where possible and use more secure protocols like Kerberos or TLS mutual authentication. If NTLM is required, restrict its usage.

4.1 Preparation

• Ensure you have a tested fallback plan in case disabling NTLM causes compatibility issues. A roll back plan is to restore the original SMTP configuration.
• Change windows may be required, and approval from system owners should be obtained.

4.2 Implementation

1. Step 1: Disable NTLM authentication on your SMTP server if possible. The method varies depending on the mail server software (e.g., Exchange, Postfix).
2. Step 2: If disabling NTLM is not feasible, restrict its usage to specific IP addresses or services.
3. Step 3: Enable Kerberos authentication where supported.

4.3 Config or Code Example

Before

#Example Exchange configuration - NTLM enabled
Set-AuthProtocolConfig -Identity "Default Frontend " -NTLM $true

After

#Example Exchange configuration - NTLM disabled
Set-AuthProtocolConfig -Identity "Default Frontend " -NTLM $false

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue and similar vulnerabilities. Least privilege reduces the impact of exploitation, while secure defaults minimise exposure.

• Practice 1: Implement least privilege access controls to limit which accounts and services use NTLM authentication.
• Practice 2: Use strong authentication protocols like Kerberos or TLS mutual authentication instead of NTLM where possible.

4.5 Automation (Optional)

PowerShell can be used to automate the disabling of NTLM on Exchange servers, but caution is advised as incorrect configuration could disrupt mail flow.

#Example PowerShell script - disable NTLM on all Exchange frontends
Get-AuthProtocolConfig | Where-Object {$_.NTLM -eq $true} | Set-AuthProtocolConfig -NTLM $false

5. Verification / Validation

Confirm the fix by checking that NTLM authentication is no longer in use over SMTP, and verifying that host information is not exposed during handshakes.

• Post-fix check: Run `Get-WmiObject -Class Win32_AuthenticationSetting | Where-Object {$_.Name -like “*NTLM*”}`. The output should show NTLM disabled or restricted.
• Re-test: Re-run the Nessus scan (plugin ID 13926). It should no longer report the vulnerability.
• Smoke test: Verify that users can still send and receive emails using supported authentication methods like Kerberos or TLS.
• Monitoring: Monitor SMTP server logs for any unexpected NTLM authentication attempts.

Get-WmiObject -Class Win32_AuthenticationSetting | Where-Object {$_.Name -like "*NTLM*"}`

6. Preventive Measures and Monitoring

Regularly update security baselines to reflect current best practices, and incorporate checks into CI/CD pipelines to prevent the reintroduction of NTLM vulnerabilities.

• Baselines: Update your security baseline or group policy to disable NTLM authentication by default.
• Pipelines: Add static analysis tools to your CI/CD pipeline that check for insecure configurations like enabled NTLM.
• Asset and patch process: Review configuration changes regularly, especially those related to authentication protocols. A quarterly review is recommended.

7. Risks, Side Effects, and Roll Back

Disabling NTLM may cause compatibility issues with older clients or applications that do not support more secure protocols. Ensure you have a tested roll back plan.

• Roll back: Restore the original SMTP server configuration from your backup. Re-enable NTLM authentication if necessary.

8. References and Resources

• Vendor advisory or bulletin: [https://learn.microsoft.com/en-us/windows-server/security/ntlm-authentication](https://learn.microsoft.com/en-us/windows-server/security/ntlm-authentication)
• NVD or CVE entry: No specific CVE is associated with this issue, but information on NTLM weaknesses can be found at [https://cwe.mitre.org/data/definitions/261.html](https://cwe.mitre.org/data/definitions/261.html)
• Product or platform documentation relevant to the fix: [https://learn.microsoft.com/en-us/exchange/security/authentication/ntlm-authentication](https://learn.microsoft.com/en-us/exchange/security/authentication/ntlm-authentication)