Preventing an attacker to steal credential and to compromise a whole kerberized network?

[greg@enjellic.com]

On Oct 11, 11:07am, Mike Spinzer wrote:
} Subject: Re: Preventing an attacker to steal credential and to compromise 

> Hello,

Hi, hope your day is going well.

> Thanks a lot for all your answers. Trying to limit the attack on the
> server itself seems to me difficult since by definition we consider
> that the server is owned by the attacker.  I was wondering if it
> would not be possible to instead put some restrictions on the ticket
> itself. For instance by including the IP address where it's valid.

> Basically the idea would be the following:
> - A user on a computer C get a ticket valid only a server S1 (IP1)
> - He uses ssh to login into S1, the ticket is copied there
> - He then cans use the ticket to either become root (with ksu) or
> connect to another server S2 without entering any password

> If an attacker compromises the server S1, he will be able to steal
> this ticket and to login into S2, but not to become root on this
> server.  However this has some limitation since if the user has too
> another session opened on S2, the attacker will be able to log there
> and steal this other ticket to become root on S2.

> Is there any way to generate on C a ticket valid only on S1 and to
> forward (copy) it automatically through SSH?

You may find the following directory useful:

	ftp://ftp.hurderos.org/pub/Hurdo

It doesn't address your authorization problem directly but provides
infrastructure which makes root escalation via Kerberos a bit safer.

The tar archives on that site have modifications to the OpenSSH server
and client which implement the ability to interactively forward
credentials from a client to a server.  It also includes a
modification to sudo which allows the forwarded credential to be used
to authenticate a sudo privilege escalation.

I've got a newer version, which isn't up on the FTP site, that uses
PAM for sudo authentication thus eliminating the need for a modified
sudo.

In order to authenticate the sudo transition the patches require the
maximum ticket lifetime to be under 20 seconds.  That enforces the
notion of user immediacy on the client, ie, someone needed to have
typed a password in the last 20 seconds.

All that would be available on a compromised server is a host specific
service ticket which wouldn't provide the intruder escalation beyond
what they currently have, ie. root privileges on the remote.  The
service ticket also wouldn't be useful as an escalation vector on
other platforms if it were stolen.

While it isn't authorization the use of a sudo/UID principal instance
is also supported.  This allows the ability to require system
administrators to have a separate 'root only' password since it is all
too common in many environments to not have the luxury of everything
being Kerberized.

The ssh infrastructure could readily be made extensible to use with
ksu probably with not much beyond a shell script wrapper for ksu.  I
share the sentiment of other responders, however, with respect to the
wisdom of forwarding any type of credential to a remote server which
would have escalation potential beyond the scope of that server
itself.

The PAM module is in production use but I haven't had time to formally
wrap it up and make it available.  I could certainly do that if there
was some interest.

> Thank you,
> 
> Mike

Good luck with your efforts.

Best wishes for a productive week.

}-- End of excerpt from Mike Spinzer

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"A mouse is a device used to point at the xterm you want to type in"
                                -- A.S.R