Vulnerable to Zanarotti attack

[stupidpupil]

As the MIT Kerberos docs say

Whenever a program grants access to a resource (such as a local login session on a desktop computer) based on a user successfully getting initial Kerberos credentials, it must verify those credentials against a secure shared secret (e.g., a host keytab) to ensure that the user credentials actually originate from a legitimate KDC. Failure to perform this verification is a critical vulnerability, because a malicious user can execute the “Zanarotti attack”: the user constructs a fake response that appears to come from the legitimate KDC, but whose contents come from an attacker-controlled KDC.

[wied03]

@stupidpupil - I know this is an abandoned project but doesn't the GSS API take in the keytab file as a parameter and validate that, which would prevent the attack you mention? https://github.com/wied03/rack-auth-krb/blob/master/lib/basic_and_nego/auth/gss.rb#L16 ?

Perhaps you were talking about the basic auth scheme and not negotiate?

[wied03]

Although the basic auth scheme uses that keytab as well

[stupidpupil]

I think that you're right that when a Kerberos authentication takes place via Negotiate that this isn't vulnerable.

However, I do believe that when Basic is used, that the actual act of authentication is found just in these lines:
https://github.com/wied03/rack-auth-krb/blob/master/lib/basic_and_nego/auth/krb.rb#L16-L23

As you can see, all that does is create a new Kerberos context and, within this, call krb5_get_init_creds_password() to obtain initial credentials for the given username and password. It doesn't verify that those credentials have been obtained from a trusted KDC. It doesn't seem to do anything with the keytab that the Krb object is initialised with.

I have since written a gem for the purpose of authenticating a user with their principal and password.

[wied03]

Ahh you're right. I didn't notice that the keytab parameter in the initializer wasn't being used (like it is in the negotiate class with GSS)