[38346] in Kerberos
Re: security implications of ignore_acceptor_hostname
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Sep 28 19:24:54 2018
To: Ben Gooley <bgooley@cloudera.com>, kerberos@mit.edu
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <2bf33b64-80c2-a796-bfbd-8b5201f0f6cf@mit.edu>
Date: Fri, 28 Sep 2018 19:24:41 -0400
MIME-Version: 1.0
In-Reply-To: <CAP9ATsJZsy9AaeDhEmsSS8eaQfZCN6j+cvqjC2=fxAcoMyzffA@mail.gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 09/28/2018 07:13 PM, Ben Gooley wrote:
> Could someone explain a possible threat due to enabling
> "ignore_acceptor_hostname=true" with an example? I am trying to assess the
> risk in using that configuration.
If you have keys in the keytab file for multiple hostnames, and the
application asks for a specific one of them, a client could authenticate
to the other one instead. An attack might look something like:
* root's keytab has host/machine-hostname and host/service-name,
service-name being an alias for the web service.
* www's keytab has host/service-name.
* sshd asks for an acceptor cred for host@machine-hostname, but the
library ignores the @machine-hostname part because
ignore_acceptor_hostname is set to true.
* An attacker compromises the web service and gains read access to www's
keytab.
* The attacker uses the key for host/service-name to print a ticket from
admin-user to host/service-name.
* The attacker authenticates to sshd with this ticket and gains root access.
The requirements for this attack are (1) a keytab containing keys of
mixed privilege levels, (2) a compromise of the key for a lower
privilege level, and (3) a service which is only intended for use with a
higher privilege level.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos