An adversarial perspective of the Windows supplicant settings

in Posts / Wi-Fi on Wi-Fi
An adversarial perspective of the Windows supplicant settings

Understanding the various Windows supplicant settings and their security implications

TL;DR - Understanding the perfect storm of default settings

Windows devices remain vulnerable to an adversary’s evil twin attack, when left with the default wireless supplicant settings:

  • the “Verify the Server’s identity by validating the certificate” setting, ticked by default, tells the supplicant not to accept a self-signed certificate from a RADIUS server as validation,
  • the “Connect to these servers” setting, blank by default, is telling the supplicant the specific name of the RADIUS server to use for authentication,
  • the “Trusted Root Certification Authorities” list, none selected by default, is used to specify the trusted root certificate authorities (CA) certificate used to validate the RADIUS server’s presented certificate.

All of which accumulates in a condition in which a supplicant will use ANY trusted root CA to validate ANY RADIUS server for authentication. The advance Evil Twin EAP-PEAP attack technique demonstrates how an adversary could exploit the default settings to coerce user credentials from their target, without ANY notification, leaving the user none the wiser that they have just connected to a malicious WLAN.

Introduction

The Microsoft Extensible Authentication Protocol (EAP) Settings for Network Access article is a great tool to understanding all the various settings and purpose, however it does lack the adversarial implication context (simply because was not meant to serve such purpose). This article is aimed to overlay that context to help readers understand the risks and the ideal configuration. However, before applying the adversarial context in this blogpost, this article will summarise the settings and their purpose.

Windows Supplicant Properties

The following image is a macro-level view of the Windows supplicant Protected EAP (PEAP) properties with a brief explanation based on the Microsoft documentation:

Protected EAP Properties Window

Verify the Server’s identity by validating the certificate

This setting is used to specify whether the device will attempt to validate the RADIUS server’s identity or not.

Default State: Enabled.

Connect to these servers

This setting is used to explicitly specify the name of the RADIUS server that the device will use to authenticate itself to the WLAN. If no named RADIUS server is specified, the device will use the WLAN supplied RADIUS server (essentially meaning ANY RADIUS server).

Default State: Not enabled, blank.

Trusted Root Certification Authorities

List of all installed trusted root certificate authority (CA) certificates. An explicit CA can be selected to use in validating the identity of the RADIUS server.

Default State: None explicitly selected.

Notification before connecting

Specifies whether the user is notified if the server name or root certificate is not specified, or whether the server’s identity cannot be verified. There are three options:

  1. “Do not ask user to authorize new servers or trusted CAs”: This option has the following logic gates and behaviour:
    • The server name is not in the “Connect to these servers” list
    • or the root certificate is found but is not selected in the list of Trusted Root Certification Authorities in PEAP Properties
    • or the root certificate is not found on the computer then the user is not notified, and the connection attempt fails.
  2. “Tell user if the server name or root certificate is not specified”: This option has the following logic gates and behaviour:
    • The server name is not in the “Connect to these servers” list
    • or the root certificate is found but is not selected in the list of Trusted Root Certification Authorities in PEAP Properties then the user is prompted whether to accept the root certificate. If the user accepts the certificate, authentication proceeds. If the user rejects the certificate, the connection attempt fails.
  3. “Tell user if the server’s identity cannot be verified”: This option has the following logic gates and behaviour:
    • the server name is not in the “Connect to these servers” list
    • or the root certificate is found but is not selected in the list of Trusted Root Certification Authorities in PEAP Properties
    • or the root certificate is not found on the computer then the user is prompted whether to accept the root certificate. If the user accepts the certificate, authentication proceeds. If the user rejects the certificate, the connection attempt fails.

Default State: “Tell user if the server’s identity cannot be verified”

Select Authentication Method

Specifies the inner authentication mode (Phase 2) for the PEAP connection. There are two options:

  1. Secure password (EAP-MSCHAP v2) Properties configuration items, referred to as (EAP-PEAP-MSCHAP or EAP/PEAP/MSCHAP)
  2. Smart Card or other Certificate Properties configuration items, referred to as (EAP-PEAP-TLS or EAP/TLS)

Default State: “Secured password (EAP-MSCHAP v2)”

Enable Identity Privacy

Specifies whether the client is to not include the identity in Phase 1 of the PEAP authentication workflow.

Default State: Not enabled

Advanced settings Window

Specify authentication mode

This setting allows an organisation to toggle between what type of credentials will be supplied by the device to the RADIUS server, this is not to say that the RADIUS server is expecting that type of credentials. There are three modes to choose from:

  1. “User or computer authentication”: This mode allows the wireless client to authenticate with the authentication server using either the user’s credentials or the computer’s credentials.

  2. “User authentication”: This mode only allows the wireless client to authenticate using the user’s credentials. The computer’s credentials are not used for authentication.

  3. “Computer authentication”: This mode only allows the wireless client to authenticate using the computer’s credentials. The user’s credentials are not used for authentication.

Default State: “User or computer authentication”

Difference between user authentication and computer authentication

  • User authentication: user credentials, such as username and password will be for authentication. However, this does not mean that an user certificate can’t be used for authentication, such as when the “Select Authentication Method” setting has been set to “Smart Card or other certificate”.
  • Computer authentication: Also known as machine authentication, means that a certificate loaded into the device will be used for authentication

Supplicant Behaviour

EAP identity leakage

The default EAP privacy settings will mean that the EAP identity of the device will also be leaked in Phase 1. However the identity with vary between usernames (if the supplicant is authenticating using user credentials), or hostnames (if the supplicant is authentication using computer credentials). Tools such as identityATTACK can monitor for leaked identities to the fire automated brute force attacks against the WLAN in other to breach the perimeter, regardless of whether the device connected to the any Evil Twin infrastructure that might be deployed within the vicinity.

Through the identity leakage, an adversary can determine whether or not it would be possible to use tools such as rogue to capture network credentials. This would be achieved by inferring whether the “Select Authentication Method” setting is set to “Secured password (EAP-MSCHAP v2)” or not, based on whether the adversary sees usernames instead of hostnames. If they see usernames, then they know that there are user credentials to be captured.

At which point, the step for the adversary is determining which version of the Evil Twin EAP-PEAP attack is needed based on understanding whether the supplicant will attempt to validate the RADIUS server’s identity, see below.

When will the supplicant not attempt to validate the RADIUS server identity

If the “Verify the Server’s identity by validating the certificate” setting is unticked (therefore disabled), the supplicant will NOT attempt to validate the RADIUS server’s identity before transmitting credentials. The basic Evil Twin EAP-PEAP attack technique can be used to exploit this condition as the supplicant will not reject the self-signed certificate that would be presented by rogue.

If the “Verify the Server’s identity by validating the certificate” setting is ticked (therefore enabled), the supplicant WILL attempt to validate the RADIUS server’s identity before transmitting credentials. The advance Evil Twin EAP-PEAP attack technique can be used to exploit this condition, however successfulness will vary depending on the following conditions:

  • Has a specific trusted root CA been selected
  • Is the RADIUS server’s certificate signed by the appropriate trusted root CA

How does a supplicant decide which RADIUS server to use

Ultimately, based on the “Connect to these servers” setting. If the setting is blank, the supplicant will use ANY RADIUS server presented by the WLAN for authentication.

How does a supplicant decide if a RADIUS server identity is trusted

Ultimately, based on the “Trusted Root Certification Authorities” the supplicant will check to see if the presented RADIUS server certificate has been by the selected trusted root CA(s). If none has been selected, then it will check to see if the certificate has been signed by ANY of the trusted root CA(s).

This ANY trusted root CA(s) logic builds upon the How does a supplicant decide which RADIUS server to use logic to create a default condition; where as no RADIUS server is listed, and no specific trusted root CA is selected, means the supplicant will connect to a WLAN that uses ANY RADIUS server that presents a certificate signed by ANY trusted root CA.

If the server’s certificate is not issued by a trusted CA or the RADIUS server name does not match the expected value, the authentication process will fail, and the client will not be able to access the WLAN.

When will the user be notified that the RADIUS server validation failed

The below table breaks down all the different conditions in which the “Connect to these servers” setting and the “Trusted Root Certification Authorities” list can be configured, and their validation workflow result when an adversary is performing an advance Evil Twin EAP-PEAP attack. In the advance attack, the adversary has a certificate that has a legitimate chain that can be traced back to a trusted root CA. The condition in which an adversary has a self-signed certificate is being ignored because the default the “Verify the Server’s identity by validating the certificate” setting will result in a validation failure.

It is assumed in the below table that the malicious RADIUS server’s name will not match the specified server name in the “Connect to these servers” setting list.

No.Notification Setting Value“Connect to these servers” field“Trusted Root Certification Authorities” listAdversary CertificateResult
1“Do not ask user to authorize new servers or trusted CAs”BlankNone SelectedCertificate signed by arbitrary trusted root CAvalidation passes, the supplicant will connect to the malicious WLAN without notifying the user
2“Do not ask user to authorize new servers or trusted CAs”Not BlankNone SelectedCertificate signed by arbitrary trusted root CAvalidation fails, due to the assumed RADIUS server name mismatch. The supplicant will reject, without notifying the user, the attempted connection to the malicious WLAN.
3“Do not ask user to authorize new servers or trusted CAs”BlankSelectedCertificate signed by non-selected trusted root CAvalidation fails, due to the certificate not being signed by trusted root CA. The supplicant will reject, without notifying the user, the attempted connection to the malicious WLAN.
4“Do not ask user to authorize new servers or trusted CAs”BlankSelectedCertificate signed by selected trusted root CAvalidation passes, the supplicant will connect as the certificate can be used to validate any RADIUS server.
5“Tell user if the server name or root certificate is not specified”BlankNone SelectedCertificate signed by arbitrary trusted root CAvalidation passes, the supplicant will connect to the malicious WLAN without notifying the user as the setting does not affect the behavior when a trusted root CA is used.
6“Tell user if the server name or root certificate is not specified”Not BlankNone SelectedCertificate signed by arbitrary trusted root CAvalidation fails, due to the assumed RADIUS server name mismatch. The supplicant will notify the user the validation has failed; the user will be given the option to proceed with the connection or reject the connection.
7“Tell user if the server name or root certificate is not specified”BlankSelectedCertificate signed by non-selected trusted root CAvalidation fails, due to the certificate not being signed by trusted root CA. The supplicant will notify the user the validation has failed; the user will be given the option to proceed with the connection or reject the connection.
8“Tell user if the server name or root certificate is not specified”BlankSelectedCertificate signed by selected trusted root CAvalidation passes, the supplicant will connect as the certificate can be used to validate any RADIUS server.
9“Tell user if the server’s identity cannot be verified”BlankNone SelectedCertificate signed by arbitrary trusted root CAvalidation passes, the supplicant will connect to the malicious WLAN without notifying the user as the setting does not affect the behavior when a trusted root CA is used.
10“Tell user if the server’s identity cannot be verified”Not BlankNone SelectedCertificate signed by arbitrary trusted root CAvalidation fails, due to the assumed RADIUS server name mismatch. The supplicant will notify the user the validation has failed; the user will be given the option to proceed with the connection or reject the connection.
11“Tell user if the server’s identity cannot be verified”BlankSelectedCertificate signed by non-selected trusted root CAvalidation fails, due to the certificate not being signed by trusted root CA. The supplicant will notify the user the validation has failed; the user will be given the option to proceed with the connection or reject the connection.
12“Tell user if the server’s identity cannot be verified”BlankSelectedCertificate signed by selected trusted root CAvalidation passes, the supplicant will connect as the certificate can be used to validate any RADIUS server.

The above option behaviour would be triggered based on the outcome of the When will the supplicant not attempt to validate the RADIUS server identity section.

Conclusion for the blue

The takeaway for the blue team is that when a Windows supplicant has been partially configured, as described in the above table, there are still 6 different failed verification conditions which allow an adversary to successfully deploy an evil twin and coerce credentials. This begs the question of ‘well ok, then what does the most hardened configuration look like then?’; simply it is:

  • the “Verify the Server’s identity by validating the certificate” setting, ticked by default,
  • the “Connect to these servers” setting has the organisation’s RADIUS server specified by name,
  • the “Trusted Root Certification Authorities” list, the organisation has specified a specific trusted root CA to validate the RADIUS server’s identity (*),
  • the “Notifications before connecting:” setting is set to “Do not ask user to authorize new servers or trusted CAs”.

(*) The selected trusted root CA cannot be the ISRG Root X1 certificate and still maintain hardened configuration. Adversaries would be free to use the Let’s Encrypt service to generate valid certificate that would pass validation.

With this configuration, if the adversary cannot deploy an evil twin with a RADIUS server by the name as specified AND cannot provide validation of the RADIUS server’s identity with correct trusted CA certificate, then the validation will fail. At which point, the “Do not ask user to authorize new servers or trusted CAs” setting will prevent the user from being prompted to accept the identity anyways; which would of had resulted in the credentials being coerced still.

Conclusion for the red

While there are 6 different conditions which would result in a failed verification, there are also 6 conditions which would allow the adversary to successfully pass verification to coerce the credentials. To exploit the 6 different passable verification conditions, the advance Evil Twin EAP-PEAP attack technique will yield the credentials when using a tools such as rogue.

However, this is not to say that this is the only technique that could get by the verification process. Watch closely for more future technique drops…

© 2021. All rights reserved.

Powered by Hydejack v9.1.6