ticket steal possibility - Kerberos

This is a discussion on ticket steal possibility - Kerberos ; Hi everyone, I need some help or information source, to resolve one big (for me) problem with MIT Kerberos. Software: CentOS 4.4 Kerberos 1.3.4 OpenSSH 3.9p1 The Network Description: Used realm is @EXAMPLE.NET Two servers from same realm and two ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: ticket steal possibility

  1. ticket steal possibility

    Hi everyone,
    I need some help or information source, to resolve one big (for me) problem
    with MIT Kerberos.

    Software:
    CentOS 4.4
    Kerberos 1.3.4
    OpenSSH 3.9p1

    The Network Description:

    Used realm is @EXAMPLE.NET
    Two servers from same realm and two clients from same realm but different
    instances.

    Server one has a host ticket host/server1.example.net@EXAMPLE.NET
    Server two has a host ticket host/server2.example.net@EXAMPLE.NET
    Client one has a client ticket client1/support@EXAMPLE.NET
    Client two has a client ticket client2/developer@EXAMPLE.NET

    On server one (server1) in krb5.conf I have a record:

    auth_to_local = {
    RULE:[2:$2](support)s/^.*$/root/
    }

    On server two (server2) in krb5.conf I have a record:

    auth_to_local = {
    RULE:[2:$2](support)s/^.*$/root/
    RULE:[2:$2](developer)s/^.*$/root/
    }

    Both clients use ssh to conect to remote servers from their workstations.
    According this client2 with realm client2/developer@EXAMPLE.NET can do login
    as root on server2 but can not to do login on server1. Other user client1
    with realm client1/support@EXAMPLE.NET can do login as root on both servers.
    At this time everything is OK, and work as I expect.

    The problem:

    When client1 is logged in from his workstation1 as root on server2, the ticket
    of client1 is forwarded and stored in file /tmp/krb5cc_0_r10108 owned by root
    (root:root) and chmoded 600. But if in same time client2 make connection from
    his workstation2 to server2 as root, he can read/copy ticket file
    (/tmp/krb5cc_0_r10108 ) of client1 locally on his workstation2 and after that
    is easy to represent self as client1 to server1 and grant root access before
    ticket of client1 expire.

    I search in Google for information how to resolve this problem and find three
    common type of solutions.

    1) To lock clients ticket by IP. Disadvantage is that some of users use their
    laptops remotely from different networks, and they need addressless tickets.

    2) To not forward tickets from client to server. This solution works, but for
    now most of users use ssh-agent to forward their private keys from one
    session to another (in example client1 make ssh to server1 and the from
    server1 copy data to server2 via scp with his own ssh key). It's not good to
    drop this possibility for them on condition that they find it as usable. But
    supporting hundred ssh public keys on great number of servers is little hell
    that I hope to resolve with kerberos.

    3) One "alternative" solution is to make ticket available for a short-short
    time (something about 2-3 seconds). But this not sound good enough to me.
    Even if our corporate network speed allow this solution, we can not be sure
    for others network. And even if the speed and times are perfect, if someone
    know about this system weakness, he can find way to catch the ticket and make
    ssh connection to another remote server with ticket that is steal. When ssh
    connection is established, even if ticket expire, connection not drop.

    Does anyone have some idea how to resolve this, or just link to useful
    documentation ?

    Thanks in advance !


    --

    Nikolai Tenev
    Hosting Systems Support Engineer
    Orbitel EAD - office Sofia
    ---------------------------------
    Orbitel - Next Generation Telecom

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: ticket steal possibility



    On Wednesday, March 21, 2007 01:25:26 PM +0200 Nikolai Tenev
    wrote:

    > On server one (server1) in krb5.conf I have a record:
    >
    > auth_to_local = {
    > RULE:[2:$2](support)s/^.*$/root/
    > }
    >
    > On server two (server2) in krb5.conf I have a record:
    >
    > auth_to_local = {
    > RULE:[2:$2](support)s/^.*$/root/
    > RULE:[2:$2](developer)s/^.*$/root/
    > }


    Doing authorization this way is dangerous, because it effectively grants
    privileges based on the mere existance of a principal, and assumes that no
    principal will ever be created that should not have these privileges. A
    better approach is to distribute lists of authorized developers and support
    staff which can be used in constructing a .k5login file for root.


    > When client1 is logged in from his workstation1 as root on server2, the
    > ticket of client1 is forwarded


    If you don't trust the machine you're connecting to, including all the
    people who have privileged access to it, then don't do that. Whenever you
    type a password on a machine, or forward credentials, agent connections, or
    X11 connections, you are granting that machine, and whoever controls it,
    the power to act as you. Giving your credentials to an untrusted machine
    is inherently unsafe; there are no tricks to get around that fact.

    Most ssh clients can be configured to forward credentials, agent
    connections, and X11 connections only to specific hosts. Your support
    staff should forward these only to trusted machines; that is, only to
    machines where only trusted staff have privileged access. They should also
    only ever type passwords at such machines, and never at an untrusted
    machine where some other person has root access.

    In our facility we go a step further; privileged users are not allowed to
    type passwords on or forward credentials to any machine where an untrusted
    person has any access, privileged or not.

    -- Jeffrey T. Hutzelman (N3NHS)
    Sr. Research Systems Programmer
    School of Computer Science - Research Computing Facility
    Carnegie Mellon University - Pittsburgh, PA

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. RE: ticket steal possibility

    I assume that all priviledged users have non-priviledged accounts as
    well. Is that correct?


    Jason Edgecombe
    Solaris & Linux Administrator
    Mosaic Computing Group, College of Engineering
    UNC-Charlotte
    Phone: (704) 687-3514


    -----Original Message-----
    From: kerberos-bounces@mit.edu [mailto:kerberos-bounces@mit.edu] On
    Behalf Of Jeffrey Hutzelman
    Sent: Monday, March 26, 2007 5:59 PM
    To: Nikolai Tenev; kerberos@mit.edu
    Cc: Jeffrey Hutzelman
    Subject: Re: ticket steal possibility



    On Wednesday, March 21, 2007 01:25:26 PM +0200 Nikolai Tenev
    wrote:

    > On server one (server1) in krb5.conf I have a record:
    >
    > auth_to_local = {
    > RULE:[2:$2](support)s/^.*$/root/
    > }
    >
    > On server two (server2) in krb5.conf I have a record:
    >
    > auth_to_local = {
    > RULE:[2:$2](support)s/^.*$/root/
    > RULE:[2:$2](developer)s/^.*$/root/
    > }


    Doing authorization this way is dangerous, because it effectively grants

    privileges based on the mere existance of a principal, and assumes that
    no
    principal will ever be created that should not have these privileges. A

    better approach is to distribute lists of authorized developers and
    support
    staff which can be used in constructing a .k5login file for root.


    > When client1 is logged in from his workstation1 as root on server2,

    the
    > ticket of client1 is forwarded


    If you don't trust the machine you're connecting to, including all the
    people who have privileged access to it, then don't do that. Whenever
    you
    type a password on a machine, or forward credentials, agent connections,
    or
    X11 connections, you are granting that machine, and whoever controls it,

    the power to act as you. Giving your credentials to an untrusted
    machine
    is inherently unsafe; there are no tricks to get around that fact.

    Most ssh clients can be configured to forward credentials, agent
    connections, and X11 connections only to specific hosts. Your support
    staff should forward these only to trusted machines; that is, only to
    machines where only trusted staff have privileged access. They should
    also
    only ever type passwords at such machines, and never at an untrusted
    machine where some other person has root access.

    In our facility we go a step further; privileged users are not allowed
    to
    type passwords on or forward credentials to any machine where an
    untrusted
    person has any access, privileged or not.

    -- Jeffrey T. Hutzelman (N3NHS)
    Sr. Research Systems Programmer
    School of Computer Science - Research Computing Facility
    Carnegie Mellon University - Pittsburgh, PA

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread