various *lame* DoS attacks

[owner-bugtraq () netspace org (Conrad Juleff)]

Aleph,

None of this is as cool as finding buffer overflows in sshd, but it may be
of interest to some people.

1)  DoS attack against people using AOL

This DoS attack comes from a poor implementation of AOL Instant Messenger's
warn "feature."  You'll need to have AIM to create this DoS attack against
someone using AOL.

How it works:

AOL's Instant Messenger has an option that allows you to "warn" other
users.  If you warn someone who is using Instant Messenger, they are
notified that they've been warned by another user.  What's interesting is
that you can warn people using AOL, and they will not be notified that
they've been warned.  The warning system is based on percentage, and you
can only get someone to a maximum of 35%.  However, if you sign off the
Instant Messenger service, and then sign back on, you'll be able to start
warning them again. (70%)  Repeat the log on/off trick, and continue to
warn your buddy on AOL until they're at 100%.  What happens then is that
they'll be disconnected from AOL if they send more than 1 instant message
every 10-15 seconds.  The AOL person has no idea what has happened to them,
and when they're booted from the service, the message they receive isn't
very informative.  Lots of fun to be had with this one.  (note: you can
only send as many warnings as messages you receive from a person, so you
must engage your target in some type of conversation.)

Fix:

1) Don't use AOL
2) If you use AOL, don't talk to people using Instant Messenger

Has AOL been notified:

Yes, but they didn't sound too interested since all I got back was a
generic letter.


2) CPU DoS against NukeNabber (NT only?)

I haven't tested this on anything other than Windows NT 4.0 SP3
(Workstation & Server)

How it works:

NukeNabber listens on several ports for connections.  You can configure it
to listen on any port, but the standards are 1080, etc.
If you telnet to the port of a machine that NukeNabber is listening on,
NukeNabber apparently spawns a process called Report.exe.  This process
lasts anywhere from 30-90 seconds, and consumes ~100% CPU.  The problem
with this is fairly obvious.  (note: when connecting to a port that
NukeNabber is listening on, it's important that you don't type anything.
Just let the connection sit and time out.)

Fix:

Unsure

Has the author been notified?

Yes, about 6 weeks ago.  I received no reply.


While we're on the subject of NukeNabber, I'll point something else out.
NukeNabber has a nifty feature that establishes a DDE link with an IRC
client. (mIRC or pirch)  There are scripts written for both clients that
have the option to kick/ban any host found to be "nuking" from all the
channels that you're oped in, and can also /ignore them.  This can become
interesting when someone has a version of WinNuke that can spoof a source
IP.  If a person has the kick/ban/ignore feature active, you can turn them
against the people in their channels quite easily.  Again, lots of fun to
be had here. (I believe the only "nuke" that NukeNabber listens for is a
WinNuke.)


I'm very aware that all the info presented here is rather lame. :)


s1