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