|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Jonathan Rickman (jonathan
XCORPS.NET)Date: Mon Apr 02 2001 - 08:22:32 CDT
On Mon, 2 Apr 2001, Philip Stoev wrote:
> To repeat, my question is: Is there a tool, or can there be a tool that can
> create filesystem damage when being a remote, non-privileged user? Let's
> assume that you can not power down the machine at will, so the tool should
> be autonomous, that is, not relying on a shutdown or power-failure to do the
> exact damage (the tool just creating the hard drive activity required to
> make this damage more probable). Instead, the tool must create the damage
> itself, even if the machine is perfectly powered and not overloaded.
>
> It seems that my previous posts were unclear. I am talking about a remote,
> non-privileged DoS. No local console, no root access, no floppy access, no
> power-switch access, no hammer handy.
I think you may be thinking along the lines of the recently publicized
Stick DoS attack (whether theory or reality is of no consequence here)
against IDS systems. As it has been said before, once you get that
far...the admin has much more important things to be concerned with than
whether or not the machine boots unattended. Maybe I'm not following you
here, but this idea seems to be the DoS equivalent of logging in as root
from a remote location and then trying to spawn a root shell on port 12345
so you can get root access. If you have the ability to launch a DoS attack
of this nature, it's irrelevant that the admin has to drive across town to
reboot. You could always just unleash the beast again once he reboots. If
an attacker is that focused on completely wrecking a system, he'll just
wait for the next Lion/Ramen/<insert l33t w0rm> and toss that at it...get
a root shell and rm -rf /
That'll keep the admin busy for hours.
-- Jonathan Rickman X Corps Security http://www.xcorps.net
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]