Re: [Freeipa-users] minimise impact compromised host
hi petr, i reread the links and some other info. it should indeed not be possible to abuse those. i thought i was once able to abuse these, but i've tried to reproduce what i did and failed (probably some ssh forwarding was mixed at that time). stijn On 11/16/2016 06:58 PM, Petr Spacek wrote: > On 16.11.2016 18:26, Stijn De Weirdt wrote: >> hi petr, >> >> this is a different question: what can we do such that compromised host >> can do a little as possible if the admin doesn't (yet) know the host is >> compromised. >> >> the default policy allows way too much. > > For any useful advice we need more details. > > What are the operations you want to disable? at the very least, "kvno userlogin" should fail (i.e. access to a host keytab shouldn't permit retrieval of arbitrary user token). >>> >>> I think that this is misunderstanding. >> i'll spend some more time rereading and getting a better understanding >> (again ;) >> >>> >>> "kvno userlogin" does not allow the attacker to do anything. The result of >>> kvno command is a service ticket for particular principal (user, host). >>> >>> The attacker can use this service ticket *for authentication to the >>> particular >>> principal* (user, host). >>> >>> So the only thing the attacker can do is to prove its identity to given >>> (user, >>> host). This exactly matches capabilities the attacker already has - the full >>> control over the host. >> hhmm, ok. is there a way to let e.g. klist show this? it now says >> 'userlogin@REALM' in the 'Service principal' column. for the (user,host) >> combo i expected to see a userlogin/fqdn@REALM, like other service tokens. >> >> anyway, clearly i'm missing something here. > > The important field is 'Default principal:' which is above the list of > tickets. It contains name of the principal "who you are". > > Rest of the list shows just service tickets which are used to authenticate you > to the services listed in the list. It just means that you tried to contact > them some time ago (or called kvno explicitly). > > Please go and read some articles about Kerberos protocol, e.g. the Wikipedia > article I linked below. It will explain a lot of things. > > Petr^2 Spacek > >> >> >> stijn >> >>> >>> Please see >>> https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request >>> for further details on this. >>> >>> Does it explain the situation? >>> >>> Petr^2 Spacek >>> i'm assuming that retrieval of service tokens for another host is already not possible? (ie if you have keyatb of fqdn1, you shouldn't be able to retrieve a token for SERVICE/fqdn2@REALM). stijn > > Petr^2 Spacek > > >> >> how to clean it up once you know the host is compromised is the subject >> of the other thread. >> >> stijn >> >>> >>> In the case that the host is compromised/stolen/hijacked, you can >>> host-disable it to invalidate the keytab stored there but this does not >>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>> trying to guess their Kerberos keys by repeated kinit. >>> >> > > >>> >>> > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
On 16.11.2016 18:26, Stijn De Weirdt wrote: > hi petr, > > this is a different question: what can we do such that compromised host > can do a little as possible if the admin doesn't (yet) know the host is > compromised. > > the default policy allows way too much. For any useful advice we need more details. What are the operations you want to disable? >>> at the very least, "kvno userlogin" should fail (i.e. access to a host >>> keytab shouldn't permit retrieval of arbitrary user token). >> >> I think that this is misunderstanding. > i'll spend some more time rereading and getting a better understanding > (again ;) > >> >> "kvno userlogin" does not allow the attacker to do anything. The result of >> kvno command is a service ticket for particular principal (user, host). >> >> The attacker can use this service ticket *for authentication to the >> particular >> principal* (user, host). >> >> So the only thing the attacker can do is to prove its identity to given >> (user, >> host). This exactly matches capabilities the attacker already has - the full >> control over the host. > hhmm, ok. is there a way to let e.g. klist show this? it now says > 'userlogin@REALM' in the 'Service principal' column. for the (user,host) > combo i expected to see a userlogin/fqdn@REALM, like other service tokens. > > anyway, clearly i'm missing something here. The important field is 'Default principal:' which is above the list of tickets. It contains name of the principal "who you are". Rest of the list shows just service tickets which are used to authenticate you to the services listed in the list. It just means that you tried to contact them some time ago (or called kvno explicitly). Please go and read some articles about Kerberos protocol, e.g. the Wikipedia article I linked below. It will explain a lot of things. Petr^2 Spacek > > > stijn > >> >> Please see >> https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request >> for further details on this. >> >> Does it explain the situation? >> >> Petr^2 Spacek >> >>> >>> i'm assuming that retrieval of service tokens for another host is >>> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be >>> able to retrieve a token for SERVICE/fqdn2@REALM). >>> >>> stijn >>> Petr^2 Spacek > > how to clean it up once you know the host is compromised is the subject > of the other thread. > > stijn > >> >> In the case that the host is compromised/stolen/hijacked, you can >> host-disable it to invalidate the keytab stored there but this does not >> prevent anyone logged on that host to bruteforce/DOS user accounts by >> trying to guess their Kerberos keys by repeated kinit. >> > >>> >> >> -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
hi petr, this is a different question: what can we do such that compromised host can do a little as possible if the admin doesn't (yet) know the host is compromised. the default policy allows way too much. >>> >>> For any useful advice we need more details. >>> >>> What are the operations you want to disable? >> at the very least, "kvno userlogin" should fail (i.e. access to a host >> keytab shouldn't permit retrieval of arbitrary user token). > > I think that this is misunderstanding. i'll spend some more time rereading and getting a better understanding (again ;) > > "kvno userlogin" does not allow the attacker to do anything. The result of > kvno command is a service ticket for particular principal (user, host). > > The attacker can use this service ticket *for authentication to the particular > principal* (user, host). > > So the only thing the attacker can do is to prove its identity to given (user, > host). This exactly matches capabilities the attacker already has - the full > control over the host. hhmm, ok. is there a way to let e.g. klist show this? it now says 'userlogin@REALM' in the 'Service principal' column. for the (user,host) combo i expected to see a userlogin/fqdn@REALM, like other service tokens. anyway, clearly i'm missing something here. stijn > > Please see > https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request > for further details on this. > > Does it explain the situation? > > Petr^2 Spacek > >> >> i'm assuming that retrieval of service tokens for another host is >> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be >> able to retrieve a token for SERVICE/fqdn2@REALM). >> >> stijn >> >>> >>> Petr^2 Spacek >>> >>> how to clean it up once you know the host is compromised is the subject of the other thread. stijn > > In the case that the host is compromised/stolen/hijacked, you can > host-disable it to invalidate the keytab stored there but this does not > prevent anyone logged on that host to bruteforce/DOS user accounts by > trying to guess their Kerberos keys by repeated kinit. > >>> >>> >> > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
On 16.11.2016 17:47, Stijn De Weirdt wrote: >>> this is a different question: what can we do such that compromised host >>> can do a little as possible if the admin doesn't (yet) know the host is >>> compromised. >>> >>> the default policy allows way too much. >> >> For any useful advice we need more details. >> >> What are the operations you want to disable? > at the very least, "kvno userlogin" should fail (i.e. access to a host > keytab shouldn't permit retrieval of arbitrary user token). I think that this is misunderstanding. "kvno userlogin" does not allow the attacker to do anything. The result of kvno command is a service ticket for particular principal (user, host). The attacker can use this service ticket *for authentication to the particular principal* (user, host). So the only thing the attacker can do is to prove its identity to given (user, host). This exactly matches capabilities the attacker already has - the full control over the host. Please see https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request for further details on this. Does it explain the situation? Petr^2 Spacek > > i'm assuming that retrieval of service tokens for another host is > already not possible? (ie if you have keyatb of fqdn1, you shouldn't be > able to retrieve a token for SERVICE/fqdn2@REALM). > > stijn > >> >> Petr^2 Spacek >> >> >>> >>> how to clean it up once you know the host is compromised is the subject >>> of the other thread. >>> >>> stijn >>> In the case that the host is compromised/stolen/hijacked, you can host-disable it to invalidate the keytab stored there but this does not prevent anyone logged on that host to bruteforce/DOS user accounts by trying to guess their Kerberos keys by repeated kinit. >>> >> >> > -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
Stijn De Weirdt wrote: >>> this is a different question: what can we do such that compromised host >>> can do a little as possible if the admin doesn't (yet) know the host is >>> compromised. >>> >>> the default policy allows way too much. >> >> For any useful advice we need more details. >> >> What are the operations you want to disable? > at the very least, "kvno userlogin" should fail (i.e. access to a host > keytab shouldn't permit retrieval of arbitrary user token). > > i'm assuming that retrieval of service tokens for another host is > already not possible? (ie if you have keyatb of fqdn1, you shouldn't be > able to retrieve a token for SERVICE/fqdn2@REALM). To be more precise you get a service ticket. I'm not sure what the exposure is here. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
>> this is a different question: what can we do such that compromised host >> can do a little as possible if the admin doesn't (yet) know the host is >> compromised. >> >> the default policy allows way too much. > > For any useful advice we need more details. > > What are the operations you want to disable? at the very least, "kvno userlogin" should fail (i.e. access to a host keytab shouldn't permit retrieval of arbitrary user token). i'm assuming that retrieval of service tokens for another host is already not possible? (ie if you have keyatb of fqdn1, you shouldn't be able to retrieve a token for SERVICE/fqdn2@REALM). stijn > > Petr^2 Spacek > > >> >> how to clean it up once you know the host is compromised is the subject >> of the other thread. >> >> stijn >> >>> >>> In the case that the host is compromised/stolen/hijacked, you can >>> host-disable it to invalidate the keytab stored there but this does not >>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>> trying to guess their Kerberos keys by repeated kinit. >>> >> > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
On 16.11.2016 15:33, Stijn De Weirdt wrote: > hi martin, > we are looking how to configure whatever relevant policy to minimise the impact of compromised IPA hosts (ie servers with a valid host keytab). in particular, it looks like it possible to retrieve any user token once you have access to a valid host keytab. we're aware that the default IPA policies are wide open, but we are looking how to limit this. for us, there's no need that a hostkeytab can retrieve tokens for anything except the services on that host. >>> >>> What "token" do you have in mind? >>> >> We discussed this in another thread. > this is a different question: what can we do such that compromised host > can do a little as possible if the admin doesn't (yet) know the host is > compromised. > > the default policy allows way too much. For any useful advice we need more details. What are the operations you want to disable? Petr^2 Spacek > > how to clean it up once you know the host is compromised is the subject > of the other thread. > > stijn > >> >> In the case that the host is compromised/stolen/hijacked, you can >> host-disable it to invalidate the keytab stored there but this does not >> prevent anyone logged on that host to bruteforce/DOS user accounts by >> trying to guess their Kerberos keys by repeated kinit. >> > -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
hi martin, >>> we are looking how to configure whatever relevant policy to minimise the >>> impact of compromised IPA hosts (ie servers with a valid host keytab). >>> >>> in particular, it looks like it possible to retrieve any user token once >>> you have access to a valid host keytab. >>> >>> we're aware that the default IPA policies are wide open, but we are >>> looking how to limit this. for us, there's no need that a hostkeytab can >>> retrieve tokens for anything except the services on that host. >> >> What "token" do you have in mind? >> > We discussed this in another thread. this is a different question: what can we do such that compromised host can do a little as possible if the admin doesn't (yet) know the host is compromised. the default policy allows way too much. how to clean it up once you know the host is compromised is the subject of the other thread. stijn > > In the case that the host is compromised/stolen/hijacked, you can > host-disable it to invalidate the keytab stored there but this does not > prevent anyone logged on that host to bruteforce/DOS user accounts by > trying to guess their Kerberos keys by repeated kinit. > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
On 11/16/2016 03:10 PM, Sumit Bose wrote: On Wed, Nov 16, 2016 at 02:41:34PM +0100, Martin Babinsky wrote: On 11/16/2016 02:33 PM, Petr Spacek wrote: On 16.11.2016 14:01, Stijn De Weirdt wrote: hi all, we are looking how to configure whatever relevant policy to minimise the impact of compromised IPA hosts (ie servers with a valid host keytab). in particular, it looks like it possible to retrieve any user token once you have access to a valid host keytab. we're aware that the default IPA policies are wide open, but we are looking how to limit this. for us, there's no need that a hostkeytab can retrieve tokens for anything except the services on that host. What "token" do you have in mind? We discussed this in another thread. In the case that the host is compromised/stolen/hijacked, you can host-disable it to invalidate the keytab stored there but this does not prevent anyone logged on that host to bruteforce/DOS user accounts by trying to guess their Kerberos keys by repeated kinit. But the password policy should at least mitigate this by blocking the account for some time after a number of wrong password are used. bye, Sumit Yes after (by default 6 IIRC) failed attempts it should lock out the account making brute-forcing the credentials highly impractical. It will, however, prevent a legitimate authentication of that user against the IPA master where the lockout is in place. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
On Wed, Nov 16, 2016 at 02:41:34PM +0100, Martin Babinsky wrote: > On 11/16/2016 02:33 PM, Petr Spacek wrote: > > On 16.11.2016 14:01, Stijn De Weirdt wrote: > > > hi all, > > > > > > we are looking how to configure whatever relevant policy to minimise the > > > impact of compromised IPA hosts (ie servers with a valid host keytab). > > > > > > in particular, it looks like it possible to retrieve any user token once > > > you have access to a valid host keytab. > > > > > > we're aware that the default IPA policies are wide open, but we are > > > looking how to limit this. for us, there's no need that a hostkeytab can > > > retrieve tokens for anything except the services on that host. > > > > What "token" do you have in mind? > > > We discussed this in another thread. > > In the case that the host is compromised/stolen/hijacked, you can > host-disable it to invalidate the keytab stored there but this does not > prevent anyone logged on that host to bruteforce/DOS user accounts by trying > to guess their Kerberos keys by repeated kinit. But the password policy should at least mitigate this by blocking the account for some time after a number of wrong password are used. bye, Sumit > > -- > Martin^3 Babinsky > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
>> we are looking how to configure whatever relevant policy to minimise the >> impact of compromised IPA hosts (ie servers with a valid host keytab). >> >> in particular, it looks like it possible to retrieve any user token once >> you have access to a valid host keytab. >> >> we're aware that the default IPA policies are wide open, but we are >> looking how to limit this. for us, there's no need that a hostkeytab can >> retrieve tokens for anything except the services on that host. > > What "token" do you have in mind? > service tokens, like HTTP/fqdn@REALM should work, but i expect in the following example that the kvno part fails kinit -kt /etc/krb5.keytab kvno a_valid_user stijn -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
On 11/16/2016 02:33 PM, Petr Spacek wrote: On 16.11.2016 14:01, Stijn De Weirdt wrote: hi all, we are looking how to configure whatever relevant policy to minimise the impact of compromised IPA hosts (ie servers with a valid host keytab). in particular, it looks like it possible to retrieve any user token once you have access to a valid host keytab. we're aware that the default IPA policies are wide open, but we are looking how to limit this. for us, there's no need that a hostkeytab can retrieve tokens for anything except the services on that host. What "token" do you have in mind? We discussed this in another thread. In the case that the host is compromised/stolen/hijacked, you can host-disable it to invalidate the keytab stored there but this does not prevent anyone logged on that host to bruteforce/DOS user accounts by trying to guess their Kerberos keys by repeated kinit. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] minimise impact compromised host
On 16.11.2016 14:01, Stijn De Weirdt wrote: > hi all, > > we are looking how to configure whatever relevant policy to minimise the > impact of compromised IPA hosts (ie servers with a valid host keytab). > > in particular, it looks like it possible to retrieve any user token once > you have access to a valid host keytab. > > we're aware that the default IPA policies are wide open, but we are > looking how to limit this. for us, there's no need that a hostkeytab can > retrieve tokens for anything except the services on that host. What "token" do you have in mind? -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] minimise impact compromised host
hi all, we are looking how to configure whatever relevant policy to minimise the impact of compromised IPA hosts (ie servers with a valid host keytab). in particular, it looks like it possible to retrieve any user token once you have access to a valid host keytab. we're aware that the default IPA policies are wide open, but we are looking how to limit this. for us, there's no need that a hostkeytab can retrieve tokens for anything except the services on that host. stijn -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
