Different Types Of Channel Attacks

There are lots of different ways to takeover a channel or make it unusable for its users. The common known attack types as well as some examples are described here to help you to prepare yourself for those kinds of takeovers and DoS ("Denial of Service", e.g. opless channel, desynch, etc.) attacks.

Attack Types

There are four main categories that separate in different sub categories:

Takeover Examples

General Attacks

OP Attacks

When an op attacks his "own" channel, he usually starts to op someone else and/or deops your bots and users.
There's just one fix to this vulnerability: Choose your ops very carefully and don't allow them to "hand-op" anyone. Registered ops should only be oped by one of your bots.

Password Attacks

Password stealing is a very big problem, since you cannot really avoid it. There are three methods to steal passwords.
Sometimes people automatically message their password to ident or op themselves to the bots nick, without checking the identity of the nickname. Actually this can be very bad, since an attacker just has to gain the bot's nick to get lots of valid passwords.
Another way to get a users password is the sniffer-attack. This attack is based on the theory that the intruder is on the same network or machine as your user or bot and sniffs everything that's being sent and received from the Internet.
There's also the possibility to brute force hack the passwords of your users on the bot, but with appropriate flood settings, different binds or a regular look at the logs such attacks can be easily avoided.

IP Attacks

An attacker could theoretically interfere the communication between the client and the irc server. He could insert some commands or error messages, which would result in a disconnect.
There's also the possibility to get nuked by an attacker. The only protection against this kind of attack is to patch your machine and use non-standard and free (open source) software.

Eggdrop Exploitation

Hostmask Faking

On some irc servers it's possible to fake the own hostmask and therefore pretend to be another user. Therefore you shouldn't use the +autoop setting or the +a flag in your Eggdrop to avoid unauthorized oping.

Op Faking

There's a way to steal another user's op request by flooding him off during the get-op procedure. Some people on eggheads mailing list have observed this, so it's not a product of a paranoid brain :-)
I'll explain this attack with a scheme:

User: /MSG botname op mypass
** Bot receives request for op and checks it against his user file **
** Authentification complete, op user **
Bot: /MODE #channel +o user

This is the normal procedure when a user asks a bot for op.
The op fake attack brakes this chain now after the bot validated the user and sent out the mode command:

User1: /MSG botname op mypass
** Bot receives request for op and checks it against his user file **
** Authentification complete, op user **
User2 floods User1 off
User2 -> User1
Bot: /MODE #channel +o User1

Notice that this procedure requires a lagged bot since the part of the user will be noticed.

Bugs & Backdoors

Backdoors and exploits giving a person owner flag or op have never been seen in Eggdrop and it's unlikely such bugs will ever occur. But it's not unusual that scripts are trojans and contain backdoors, so advice your ops and choose your tcl script and modules very carefully (always take a look through the source).

Shell Attacks

Unless you're your own admin you have to trust the administrator of your shell to look after the server. You have to delink the bot from the botnet and change all passwords very quickly if the server or your shell gets hacked, because access to the bots binaries and data files can't be prohibited then.
There's no way to secure a bot if the shell is hacked once.

Userfile Decryption

You should always chmod your directory to 700 to avoid someone to read your user file and start decrypting your user file. If an attacker has enough CPU power, he can decrypt an Eggdrop user file in a day or two.
Another way of decrypting a user file is by brute force, the checking of blowfish salts against a wordlist. Tools for this like Egghack (12kb, md5sum: 7a9cebcbb60683da2aeb7c769fc7b784) aren't popular, though they can also be used for checking against weak passwords in your user file. You should check your user file every 3 or so months against weak passwords with this user file.
If you're using netbots, you could try my passwd components which checks each entered password against come criterions.

Netsplit Modes

If your bot allows users to set bans/exempts/invites on your channel, any given user can set bans/exempts/invites on a split server that won't be removed on reconnect. This could lead so far that your bots can't kick a bot after a ban, since an appropriate exempt is set.
Another way in exploiting netsplit modes is to fill the mode list. IrcNET for example allows a total of bans/exempts/invites in one channel. If this limit is reached, no new modes will be allowed.
The solution for this kind of attack is a strict behavior of your bots towards Netsplit and user modes.

Mode List Filling

Every irc server has a limit over the maximum count of modes allowed in a channel. IRCNet's ircd for example allows a total of 30 b/e/I modes set on a channel. This limit can be reached easily using Wingates and open proxies or vhosts to trigger a ban from one of your bots. Since version 1.4.0 Eggdrop doesn't push more bans to the mode list if it's full (max-bans) and therefore ping timeouts, but it doesn't remove old bans if there's a need for new ones.
Therefore you should use a script like sentinel (distributed with your bot) from slennox to set your channel to +i on floods. This prevents more users from join and notifies you about it.

Shell Quota Overflow

If your bot is running on a box that has quota enabled, you have to watch carefully your space usage. If you reach your hard quota by any accident, Eggdrop can't write its user file correctly anymore and overwrites the old one with a 0 bytes file. If this happens for two days, your backup file will be set to 0 bytes, too. Because of this, just a .rehash or .restart is needed is required to make the bot crash. After such a crash, you have to setup the bot completely from the scratch.
You can avoid such a behavior if you set keep-all-logs to 0 and set max-logsize to a reasonable limit. Another possibility would be to write a script, which uses tar and gzip to compress the log files after being switched. If anyone has such a script available or plans to do so, please notify me, so I can put it here for download.
The problem is known to eggdev, take a look at Eggheads Bugzilla

Weak Passwords Login

There is a bug in the 1.4.x and 1.5.x series of eggdrop regarding weak password and login. If a user has set his password to for example "aaaaa" or "abcabc" any user can login to their account using "a" or "abc" as a password.
The problem is known to eggdev, take a look at Eggheads Bugzilla

Fake-Bot Link

If an intruder knows your botnet structure he can try to get a shell on a server where one of your bots sits on (public shell provider for example). In the next step the intruder somehow manages to get your bot down and connects as-your-bot to the botnet. Since one bot doesn't has a password set, both set a new password. A faked bot is in your botnet now. The situation can get even worse if the new/old bot is allowed to pass changed userdata to the other bots.
The same effect can be reached with spoofed IP adresses.
The problem is known to eggdev, take a look at Eggheads Bugzilla

TCL command execution exploit

In tcl every string enclosed by brackets is interpreted as a command, for example [lrange] or [jump]. Now some bad coded script don't check for nicks or strings which might contain such fake-commands resulting in very dangerous situations. Imagine, someone with nick "Ill[die]" joins your channel and all your bots die...
Please note that this behaviour is mostly experienced with timer, utimer, expr and eval commands and is not an eggdrop bug! You can avoid such bugs by using split and join.

k-Mode bot kill exploit

Some networks (as Galaxynet for example) support really long channel keys. Setting such a long channel key (longer then 32 characters) would crash any 1.5.x bot. A fix for this bug is included in the current cvs.

Flood Attacks

There are two ways to flood somebody off irc.
The first method abuses the limit on how much information a client can send at one time to a server. If this limit is exceeded, the irc server disconnects the user (excess flood). An attacker can flood you for example with various CTCP requests from different clients to which the victim answers...too much load. Please note that Eggdrop 1.5 does not 'Excess Flood' anymore since penalty calculation was included to limit responses by the bot to the server.
The other method uses the time limit in which a client has to send a life sign to the server in order not to get disconnected (ping timeout) from it. The attacker 'fills' the bandwidth of the victim.
For both attacks troublemakers can use different flood types, sometimes even some combined. I'll present the IRC Floods here, but there is also the PING Flood, Resolve DNS Flood or Port Flood.

IRC Flood

CTCP Flood

CTCP Floods are very successful, since you can make nearly every client respond to a large number of CTCP requests from different hosts. Those kinds of attacks are especially successful, if an attacker uses a 130byte ECHO CTCP request. The only protection against this attack is a very strict CTCP flood and answer setting.

Trigger Flood

Trigger floods are similar to CTCP Floods, since they make the bot send something back (e.g. !seen). Normally tcl scripts or modules open such triggers and coders often don't think about flood protection, so you have to code it manually in.
Don't forget about it, since it can be a serious danger for your bot.

Text Flood

Text floods are very difficult, since channel flood protection works most of time and flooder are ignored & banned from channel before they can do any damage.

Notice Flood

Due to the very good flood protection of Eggdrop, notice floods are ignored very quickly.

Nick Flood

Nick flood occur when a flood-net often changes its nicks. This kind of flood was very popular for some time, since Eggdrop didn't have any protection against it. Modern versions of Eggdrop can cope with it without problems.

Join/Part Flood

Join/Part floods are similar to nick floods, but since Eggdrop supports them nowadays, they're only annoying, but nothing more.

PING Flood

A ping flood is an attack on the machines of your bots or ops. The principle of this flood is easy; they try to fill the bots bandwidth so that he'll start to lag and finally exit irc with a ping timeout.

Resolve DNS Flood

Up to version 1.5.0 Eggdrop halted on dns lookups. This could lead to opless channels, since many dcc requests or ident / telnet connections could halt the Eggdrop completely or lead to a ping timeout.
An asynchronous dns module, which prevents the bot from hanging, was introduced in 1.5.0.

Port Flood

Port floods result in many connections to the telnet port of an Eggdrop. Too many connections at once can confuse Eggdrop in a way that it may loose incoming valid connections from users or bots. This bug was fixed in Eggdrop 1.5.2.

Server Attacks

Server OP

In original ircd code, there was a possibility to enter a channel with op using a splitted server. The offender just entered the channel and got automatically +o (since it was empty...). During the server reconnect, his +o was published through the net and he had full right.
Later on in ircd channels were re-opened only after a 30 minutes split to public again. Other network use things like TS or have found other ways to solve this server op problem.
Nonetheless, server op is still a problem in IRCNET, also there're already plans to change this in future (http://akson.sgh.waw.pl/~chopin/uniqueID.txt).
The only way to get around this problem is to have a bot on every irc server or at least on the server hubs.

Nick Collision

The availability of a nick during netsplit on both ends is delayed for about 30 minutes. After this time, the nick is available again. If it's taken on both sides of the split and the servers reconnect again, both nicks (clients) are disconnected from irc.
Sometimes nick collision and server op are combined on netsplit and your bots are kicked out from irc while a bot enters with server op. See the Nick Collision & Server OP attack example section for more details.


Desynch stands for desynchronization and is pretty self explaining. Two (ore more) servers don't think the same about a channel. Desynchs can be caused by mode collisions. For example, if A deops B and B deops A in the same time (or one server is lagging) on different servers, both servers will have other ops.
Desynch can't be really avoided, but sometimes you can synchronize the servers again (mass op, etc.). Really bad desynchs require a complete channel restart...(everybody has to part)

Takeover Examples

Nick Collision & Server OP

Scenario: GoodBotA, GoodBotB and GoodBotC are bots in #foo. BadBotA, BadBotB, BadBotC and BadBotD are evil takeover bots. There's a Netsplit between *.fi and the rest of the net. Bad bots A-C took nicks of Goodbots A-C. A net rejoin happens.

GoodBotA (GoodBotA@BotA@good.guys.net) left irc: Killed (irc.cs.hut.fi ((GoodBotA@good.guys.net)*.se <- (+BadBotA@bad.guys.net)ircd.funet.fi))
GoodBotB (GoodBotB@BotA@good.guys.net) left irc: Killed (irc.cs.hut.fi ((GoodBotA@good.guys.net)*.se <- (+BadBotC@bad.guys.net)ircd.funet.fi))
GoodBotC (GoodBotC@BotA@good.guys.net) left irc: Killed (irc.cs.hut.fi ((GoodBotC@good.guys.net)*.se <- (+BadBotB@bad.guys.net)ircd.funet.fi))

BadBotD (BadBotD@bad.guys.net) joined #foo
#foo: mode change '+o BadBotD' by irc.funet.fi

All three good bots were killed by nick collision and the fourth bad bot took #foo by server op. It can wait now for the other bots to return to irc and give them op.


Scenario: BotA on ServerA and BotB on ServerB, both bots in #foo

BotA sets mode: -o BotB      |   BotB sets mode: -o BotA
ServerA -> ServerB           |   ServerB -> ServerA

Time passes as information travels through cyberspace

ServerB rejects deop from    |   ServerA rejects deop from
BotA, since BotB deoped BotA |   BotB, since BotA deoped BotB

ServerA: @BotA, BotB
ServerB: BotA, @BotB
Since both bots send the deop at the same time and it takes a given amount of time to reach the other server, the appropriate deoping bot is already deoped at the respectively server. ServerA and ServerB have now two different views at #foo. Desynch is achieved mostly by mass modes which collide usually with the retaliatory action of other bots.
Desynchs can go that far that two Server don't agree on user count or channel modes.

Back to the main page

©1999, 2000, 2001 by Johoho@IrcNET, 30 July 2000. CONTACT