Vulnerability Development mailing list archives

Shadow


From: kjkotas () EOS NCSU EDU (kjkotas)
Date: Tue, 25 Jan 2000 01:11:53 -0500


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

On Mon, 24 Jan 2000 lamont () icopyright 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.


Current thread: