Re: .: 14x :: Generic Vuln - Many Vendors & Operating Systems :.

[Nick Summy <playboy () NETINS NET>]

How would sometihng like this work with windows,  or macos?  anyone
know? It should work with windows,  i dont know enough about macos to
make an educated guess though

Erik Tayler wrote:

> Ok, I am going to try to make this as short and simple as possible. A
> simple "exploit/dos tool" was written quite a while ago named "octo"
> or "octopus". Here is a short description of octopus... <snip>*  This
> little program opens as many sockets with a remote
> *  host as can be supported by both.</snap><snip> * Often, a remote
> workstation can be brought
>  *  to its knees by saturating its process table via multiple
>  *  invocations of sendmail.</snap> If you really want to read the
> entire description, pick up a copy from
> ftp.technotronic.com/denial Not a whole lot of attention has been
> brought upon this, so maybe I could give another stab at it. I have
> tested octo on one of my old servers, which is a Cyrix 166+ - 46mb
> RAM, running xf86, sendmail, a pop3 server, ssh1/2, etc, with kernel
> 2.0.36. From a reasonably fast connection [DSL / T1], I used octo
> against my server... # ./octo [myip] 6000 Attacking from a T1 with
> fair system specs, I was able to lock up the older machine's xf86,
> rendering the mouse useless, and obviously keyboard as well, making
> the only escape a reboot [reset button]. So I brought the server back
> up for another test. # ./octo [myip] 25 I was on the console on the
> old server, continuously typing `uptime`, to check out what was
> happening. The load was skyrocketing [ I can't remember the exact
> figures ], and it took quite a long amount of time to get the load
> information back. Within moments, the whole system was locked, and a
> reboot was necessary again. So I brought it back  up. # ./octo [myip]
> 23 Different results this time. The older server slowed considerably
> yet again, but this time, it simple shut down my telnet service all
> together. So I restarted inetd. # ./octo [myip] 22 Again, load
> increased dramatically, and system halted. Reboot again. Ok, instead
> of boring you, let me get to the point. Attacks such as this are
> extremely successful, harmful, and annoying. The system halting attack
> that was performed on ports 22, 25 & 6000 are now basically rendered
> harmless if the system being attacked runs anything newer than 2.0.36.
> However, using octo or similar tools against newer, faster servers
> still works.... By working, I mean that it has the ability to shut
> down services remotely. octo can halt many systems [ let me try to
> list all that I have tested it on... ]. RedHat Linux 5.2    - Halt +
> Service ClosureRedHat Linux 6.0    - Service ClosureRedHat Linux
> 6.1    - Service ClosureRedHat Linux 6.2    - Service ClosureSolaris
> 2.6             - Halt + Service ClosureSunOS < 5.7          - Halt +
> Service ClosureSunOS 5.7             - Service ClosureSuSE Linux
> 5.2      - Halt + Service ClosureSuSE Linux 5.3      - Halt + Service
> ClosureSuSE Linux 6.3      - Service ClosureSuSE Linux 6.4      -
> Service ClosureSlackware < 7        - Halt + Service ClosureMisc [
> System V, Digital Unix, AIX, IRIX ] - Varied Results Obviously there
> are ways to prevent this, such as setting limits on number of
> connections, tools such as portsentry, et cetera. But it seems that
> nobody has made any great strides to stop this sort of thing, and I
> believe it would be a good idea to do so. If anybody has any
> comments/ideas/feedback/flames, please e-mail me. Thank you. Erik
> Tayler14x Network Securityhttp://www.14x.net

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature