OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Vuln-Dev Archives: Shadow

Shadow


Subject: Shadow
From: kjkotas (kjkotasEOS.NCSU.EDU)
Date: Tue Jan 25 2000 - 00:11:53 CST


Just a little correspondence for the rest of you all to catch up on..
-kjk

On Mon, 24 Jan 2000 lamonticopyright.com wrote:
>
> If someone can access your analysis machine and run these scripts with
> their own parameters, then you've got a huge problem above and beyond any
> vulnerabilities in these scripts.
>

kjk:
Do you mean to say that it is insignificant and should be ignored? I will
not speculate on how the analyzer would be reached, but plainly present a
vulnerability which a security administrator using the system would like
to know and defend against.

lamont replies:
>Well, the thing is that you probably shouldn't let anyone have access to
>your analysis machine or the scripts. The httpd should at least have
>username/password access and should ideally be only accessable from a
list
>of trusted IPs, and probably be behind NAT and only accessable
>internally. Attackers just shouldn't have access to mess with stuff like
>that.

kjk:
So there is a point of access. Ideally, the analyzer should not be
remotely accessible and the ID information viewed locally.

kjk:
If you are thinking of the weakness as an initial entry point, likely it
will not be if the proposed design of the system is followed. But since
the analyzer does present ID information to the administrator, it could be
worth while for a cracker to compromise the host with the purpose of
masking his or her presence.

Also, a compromise of the analyzer presents another problem. From
docs/INSTALL on version 1.6:

6. Using SSH on the analyzer, set up a link to the sensor(s) such that the
   non-privileged user process on the analyzer can connect as root to the
   sensor without a password. This can be accomplished by using "--with-rhosts"
   on the SSH configure command or by putting a blank passphrase on the
   user's private SSH key. In addition, the public SSH key of the user on
   the analysis station must be placed in the .ssh/authorized_keys file
   for root on the sensor.

Which opens up other possibilities.

lamont replies:
>Yes, but if the cracker has compromised the host which is connecting to
>the analyzer, then you could also attack it just by backdooring ssh and
>capturing the username/password pairs which are used to connect to the
>analysis machine. There's probably lots of attacks.

kjk:
Well, the analyzer connects to its sensors as root and without a
password as stated above. Still, I see your point if it was not the
sensor.



This archive was generated by hypermail 2b27 : Tue Jan 25 2000 - 01:32:06 CST