[GRLUG] Linux Systems Compromised

[Greg Folkert]

On Mon, 2008-08-18 at 22:38 -0400, Michael Mol wrote:
> On Mon, Aug 18, 2008 at 4:47 PM, Casey DuBois <casey at grlug.org> wrote:
> > Hey GRLUG,
> > I received the attached information and thought it may be useful to
> > some on the list.
> >
> > -------- Original Message --------
> >
> > linux rootkit in a wild...confirmed cases from our friends from other
> > universities...
> >
> > check your boxes...
> >
> > -------- Original Message --------
> >
> > -------------------------------------------------------------------------
> > DFN-CERT is the emergency response team of the German Research network.
> > We are currently handling compromises of linux based grid-clusters at
[snip]
> Very interesting, but rootkits are nothing new.  They've existed for
> well over ten years now; What's interesting about this is the breaking
> of the web of trust.  One rooted system gave access to SSH keys that
> gave access to more systems, which garnered more SSH keys.  It's worth
> noting that a properly-setup
> 
> This makes me wonder about the wisdom of using ssh keys to bypass
> password restrictions.  It's obviously safer to use ssh keys with
> passwords tied to them.

Stop assuming that they implemented it the proper way. Evidence shown
and provided indicates they did not.

Okay guys... here is the lesson *I* tried to pass on before but I see
that no-one caught it.

PASSWORDLESS Private keys are of ZERO use for security. Once you crack
to hard outershell, the gooey fluffy inside is there for the taking *IF*
you setup keys with passwordless private keys for use as "identity"

It is the cheap and easy way to make passwords unneeded, by using a
mechanism the wrong way. This needs to be addressed by policy or other
non-computer means.

The proper setup is not the use of passwordless key_auth. But the use of
Authentication forwarding from a trusted location.

So the explanation:

I have my private part of my SSH Key, in my encrypted store, which has
an initial password and the key has a passphrase.

The key then gets loaded into my "ssh-agent".

I have a couple of login hosts for work, they ONLY have my public part
of my SSH Key pair. The other hosts I login to from them also only have
my public part of my key.

You have to turn on authentication forwarding, either in
the /etc/ssh/ssh_config or setting up an alias for "ssh -A", I also have
X forwarding setup... so I use and alias on my private machines with
"ssh" actually is "ssh -X -A " as I do not prefer the "global enabling"
of authentication forwarding. I'd like to think that *IF YOU* know how
to do it from the command line, you should make a private alias for it
rather then enabling laziness of your userbase.

I also have this on my login hosts, setup as an alias (again vs the
ssh_config). But I do not have any further auth forwarding aliases.
Keeps me from just using an open terminal and "ssh host" to get to the
machine I need/want to get to.

Keeps me honest and allows me to have the first two hosts be key_auth,
which is 95% of my needs. Also, logs my logins and access times and so
on with more granularity.

I still have to enter my password for "sudo" and for any further steps
beyond the first host after the login hosts, or any SCP transfers or
other fun stuff.

So, you see Mike, its not about key_auth being insecure... its about
using passwordless private keys on any hosts inside a firewall.


Now, given that, I have a nagios user on my nagios machine that uses
passwordless keys to do remote commands on remote hosts. But it is a
restricted shell and can only run the allowed commands for the checks
needed. That also means you'll need to break into my monitoring host (as
the nagios user can only login from that host IP and only with
key_auth), to get into the nagios account and then use the non-standard
identity location and be able to see which hosts its valid on (with
"HashKnownHosts yes" on). The part that I have setup on the remote
hosts, if you try to do something not allowed, you get an error return
of 255 with no helpful text. If you run an allowed command, they are all
set to return "<whatever> - OK" with error 0, or "<whatever> - Critical"
with error 1.

So, the key (hah! I "kill -9 $PPID") here is to never use passwordless
key_auth from inside the firewall/trusted network unless it is for a
very well locked down account on the remote host. Second, passwordless
anything for a person's account is something done out of laziness and
needs to be addressed and perhaps remove the ability... but then you end
up with sticky notes all over the monitor.

So, education is the "key" to making this work.

As far as this issue: Never mind the rootkit, as it was only the tool to
get access.
-- 
greg at gregfolkert.net
PGP key 1024D/B524687C 2003-08-05
Fingerprint: E1D3 E3D7 5850 957E FED0  2B3A ED66 6971 B524 687C
Alternate Fingerprint: 09F9 1102 9D74  E35B D841 56C5 6356 88C0
Alternate Fingerprint: 455F E104 22CA  29C4 933F 9505 2B79 2AB2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://shinobu.grlug.org/pipermail/grlug/attachments/20080819/cee23e70/attachment.pgp