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:
- Re: things to break.., (continued)
- Re: things to break.. Jordan Ritter (Jan 25)
- Re: things to break.. Matt Conover (Jan 24)
- Re: things to break.. John Galt (Jan 24)
- Re: things to break.. Matt Conover (Jan 25)
- Re: things to break.. Simple Nomad (Jan 25)
- Re: things to break.. Jordan Ritter (Jan 25)
- ICQ Pass Cracker. WolF Knox (Jan 26)
- Re: ICQ Pass Cracker. Blue Boar (Jan 26)
- Re: ICQ Pass Cracker. Usman (Jan 26)
- Re: ICQ Pass Cracker. Vladimir Dubrovin (Jan 27)
- Shadow kjkotas (Jan 24)
- Re: Secure coding in C (was Re: Administrivia #4883) Marc Slemko (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Warner Losh (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Blue Boar (Jan 15)
- Re: Secure coding in C (was Re: Administrivia #4883) Brian Kifiak (Jan 16)
- Re: Administrivia #4883 Blue Boar (Jan 15)
- ICQ (Was Re: Administrivia #4883) Imran Ghory (Jan 16)