Summary
Vulnerabilities were discovered with Radiator’s AuthBy LDAP2 authentication when used with Extended Authentication Protocol (EAP) and certain Radiator and LDAP configurations.
Affected Radiator versions
The vulnerability affects Radiator versions up to 4.16.
Affected Radiator configurations
Three different cases were discovered. They all affect certain AuthBy LDAP2 and LDAP server configurations that are used to authenticate EAP. Non-EAP AuthBy LDAP2 configurations are not affected.
Some EAP methods, such as EAP-MSCHAPv2, do not always reject the authentication correctly with the following configurations:
1. When AuthBy LDAP2 is configured to check passwords with LDAP bind operation. In this case, some other EAP methods, such as EAP-GTC, always fail to check the password. LDAP bind password check is enabled with AuthBy LDAP2 ServerChecksPassword configuration parameter. See questions and answers below for more about ServerChecksPasword with EAP methods.
2. When AuthBy LDAP2 is configured to fetch an LDAP password attribute, but this attribute is not returned when the user is found from LDAP. See below for mitigation.
3. When AuthBy LDAP2 is configured to use eDirectory as the LDAP server, GetNovellUP is set, and the user is found but UP fetch returns a failure.
Recommended action
OSC recommends upgrading to Radiator 4.17.
- Download and upgrade to Radiator 4.17
- Restart Radiator after the upgrade
Mitigation
If you cannot upgrade at this time, you can mitigate case 2 with a configuration change. Configure AuthBy LDAP2 with a PostSearchHook that checks that the configured PasswordAttr or EncryptedPasswordAttr is returned with the LDAP result. If the attribute is not returned, the hook triggers an authentication failure.
- Check AuthBy LDAP2 configuration and note the LDAP attribute name configured with PasswordAttr or EncryptedPasswordAttr.
- Create a PostSearchHook that verifies that the LDAP attribute is present in the reply. Here is one example:
PostSearchHook sub {my $attr = $_[4]->get_value('userPassword'); \ return if $attr; $_[3]->get_check->add_attr('Auth-Type', 'Reject:No userPassword in LDAP'); } - The above hook checks for userPassword. Use LDAP attribute name that your AuthBy LDAP2 configuration uses.
- Restart Radiator after the configuration change.
Questions and Answers
How can an attacker use these vulnerabilities?
The attacker may gain authenticated access.
What is required to exploit these vulnerabilities?
The attacker must send a suitable EAP authentication request when the conditions for the cases 1-3 listed above are met.
Is ServerChecksPassword compatible with EAP?
Most EAP methods, such as EAP-MSCHAPv2, are not compatible with LDAP bind based password checking and cause a reject because they do not provide a password that can be used with LDAP bind.
Case 1 described above, AuthBy LDAP2 with EAP and ServerChecksPasssword, is often an incorrect configuration that gets noticed when Radiator configuration is tested. However, some EAP methods did always succeed regardless of the password, and some EAP methods that appeared to always return a reject might have sometimes incorrectly succeeded. This is now fixed in Radiator.
OSC recommends configuring Radiator’s EAP authentication with just those EAP methods that are known to be required.
How were these vulnerabilities discovered?
A partner company notifed OSC about case 1 that they found while testing a configuration. Further investigation of case 1 and the discovery of cases 2 and 3 were done by OSC’s development team.
OSC is not aware of public use of these vulnerabilities.