Ubuntu documentation for sssd/kerberos does not authenticate authentication server

[Andrew Conway]

There is a security flaw in the Ubuntu documentation for using sssd with kerberos. It leaves out authentication of the authentication server. This is easy to fix.

Following the documentation will result in a system that seems to work (apart from known bug https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350) in the sense that someone can log in, but it would be easy for an attacker to impersonate the authentication server, and thus gain unauthorised access to any computer set up according the documentation.

Solution:
 (1) When creating the file /etc/sssd/sssd.conf, add the line "krb5_validate = true"
 (2) Make sure that /etc/krb5.keytab is valid.

Step (1) is missing from all documentation. Step (2) is present in some, but not all, pages.

This affects (that I found) the following pages:

https://help.ubuntu.com/community/SingleSignOn (has valid /etc/krb5.keytab already)
https://wiki.ubuntu.com/Enterprise/Authentication/sssd (no mention of /etc/krb5.keytab)

I believe it also affects the following, but I do not use active directory and cannot check.

https://help.ubuntu.com/lts/serverguide/sssd-ad.html.en

I believe one should probably also add in /etc/sssd/sssd.conf a line to set krb5_use_fast for security reasons, although I do not understand this option well enough to comment definitively.

This applies to all versions, including 18.04.

[Andreas Hasenack (ahasenack)]

Any idea why upstream sets krb5_validate to false by default? I presume because this would require the extra step of creating a service ticket for the host where the login happened, if I understood it correctly?

[Andreas Hasenack (ahasenack)]

And, is sssd's krb5_validate option overriding krb5 library's verify_ap_req_nofail?

If this flag is true, then an attempt to verify initial credentials will fail if the client machine does not have a keytab. The default value is false.

[Andrew Conway (acubuntuone)]

I don't know why krb5_validate is false by default. I thought it was historical or to (dubiously) to make setting up easier, but I did some tests and found, to my surprise, that even with it not set, I could not log in without an /etc/krb5.keytab file.

In particular, I tried all 6 combinations of krb5_validate {set or not set} and /etc/krb5.keytab being { empty, valid, valid but for a different kdc }. I found that I could never log in without some /etc/krb5.keytab. With a valid (but inconsistent with the actual responding kerberos server) key, it required the flag be not set in order to log in (this is the scenario for an attacker). With the correct /etc/krb5.keytab you could log in regardless of krb5_validate.

So it sounds as if sssd overrides verify_ap_req_nofail to true even if krb5_validate is false, which is surprising.

So the only breaking case I see of having krb5_validate default on would be if the system has an /etc/krb5.conf from a different kerberos system, which seems unlikely.

[Marc Deslauriers (mdeslaur)]

Has there been any progress on this issue? Thanks!

[Andreas Hasenack (ahasenack)]

Hi Andrew, I'm back on this bug since I'm updating the server guide for the 20.04 release.

Again I didn't add krb5_validate to the guide, mostly because I had forgotten about this bug here. The new guide is at https://discourse.ubuntu.com/t/service-sssd/11579

Let me see if I got the attack scenario right, please correct me where needed.

I know a certain workstation has a user called <email address hidden>, and I want to login as that user. That workstation has no host principal on the KDC.

I setup a kdc of my own with a laptop, create <email address hidden> on it, and get ready to spoof the real KDC.

I attempt to login as <email address hidden>, with a password of my choosing. Since I setup the fake KDC with the fake account, I can use any password I want. If the fake KDC responds to the login request before the real one, and krb5_validate is false on the workstation, no host keytab verification is done, and alice can login.

Is the above the scenario?

[Andreas Hasenack (ahasenack)]

I updated the guide at https://discourse.ubuntu.com/t/service-sssd/11579/ with a section on KDC spoofing, please take a look.

[Andrew Conway (acubuntuone)]

Thanks Andreas,

I am not an expert either on kerberos or on security - I know enough to be able to spot and verify a problem, but not enough to verify a sufficient solution, so take what I way with that caveat in mind.

The section you have written seems reasonable, and that is indeed the main attack model I had in mind, although I think that not including the krb5_validate flag in the example configurations above is dangerous. I presume (but don't have the setup to test) that AD setups have the same problem, and it is not obvious to someone doing the AD setup that this section applies to them too.

I don't think there is any scenario where someone would want to use kerberos, but would not want this flag set. One could say that it requires more setup because you have to have the keytab file, but there is no point in using kerberos in the first place if you are not going to use it for something other than local authentication (e.g. nfs), for which you will need the keytab file anyway (as far as I understand). So you remove a trivial to exploit vulnerability at basically no effort by including this flag.

Also, somewhat off-topic but probably very relavent for this sssd guide - bug 1723350 mentioned above means that the described configurations won't reliably survive rebooting the computer, so a reference to the workaround in that bug description could save people lots of time and frustration.

Also slightly off topic, in the section "SSL support is recommended, but not strictly necessary because authentication in this setup is being done via Kerberos, and not LDAP." I think ssl is needed as while user authentication is done through kerberos, group authentication is done based on what groups the user is in, which comes from LDAP, so an attacker on the local network could give themselves group permission for any group if the LDAP traffic is unencrypted. Or change the group for some other user to write as by default to some world readable group.