Citrix ADC (Netscaler ADC) Multi-Factor Bypass

While working with a client, VDA engineers encountered an interesting circumstance that allowed for the bypassing of Multi-factor Authentication for users who had already set this up on their accounts. This particular misconfiguration/vulnerability was possible due to the way Citrix ADC (formerly NetScaler ADC) handles user authentication.

How does it work?

Upon initial login attempts a user is greeted with a prompt only for a username, upon entering the username the system checks back with AD to confirm the user exists and to check for a specific attribute in AD called userParameters. This parameter is filled when an account completes the enrollment process for the OTP (One Time Passcode) utilized by Citrix ADC. Here is what an account that has this parameter set looks like after passing the username check:

After reaching this step, a normal user would enter their password, check their authenticator app for their OTP, and be successfully logged in. This mitigates many password guessing, phishing, and social engineering attacks by providing another step of authentication, however, this is what an account that does not have MFA set up looks like when passing the username check:

Looks normal enough, and since there is no userParameters AD attribute set, the MFA check is met as there is no requirement. Where things start to get interesting is the fact that a curious or malicious user can change the username at this stage in the authentication, effectively bypassing existing MFA for any user. This does appear to be Citrix ADC/Netscaler ADC specific as other instances of Citrix were not compatible with this type of attack.

How does it work, and how do you protect yourself from this security loophole?

First, you must understand that this vulnerability exists by the failing open upon the lack of an OTP device being set up. As far as Active Directory goes, all it checks for is anything that exists in the userParameters attribute. A very simple workaround for this is to populate this field with dummy data until needed at a later time. This can be done on a domain-wide scale via Power Shell.

userParameters will by default be populated with simply an #@, VDA recommends adding a reset value to indicate to technicians that this value needs to be reset to accommodate accounts that now require this OTP attribute. A normal setting for this attribute would look something like this with an iPhone setup: #@iphone=XYZXYZXYZX12312.

Secondly, you must apply the above workaround to every account as service accounts will likely still work for this attack and were used with a great deal of success by VDA engineers on jobs where this was applicable.

VDA labs