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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:22:19 PDT