[Freeipa-users] minimise impact compromised host

[Stijn De Weirdt]

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 at REALM' in the 'Service principal' column. for the (user,host)
>> combo i expected to see a userlogin/fqdn at 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 at 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.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
> 
>