Eggdropping
by Tempest
Internet Relay Chat (IRC) is an illusion, a metaphor.
The reality of the technology is that there are many, many small computers communicating with others across a vast geographical expanse in a typical server-client relationship.
Individual clients (people's home computers, for instance) connect to server machines (computers at universities, ISPs, or other locations that run special IRC server programs called IRCd), which are themselves often connected to other server machines, creating a complex network. The illusion is that there is only one huge supercomputer hosting all of this, and the metaphor is of a huge building (the super server) with thousands of infinitely large rooms (channels) of people having conversations or doing other things within them.
Of these "people" in the channels on this imaginary super server, there exist bots - small tidbits of software that run on a computer somewhere and continuously listen on a given port.
Anytime a group of people of any size conglomerate and exchange ideas, there will be disagreement. This inevitably leads to dissent, competition, rivalry, and out-right fighting. An integral part of IRC is the existence of channel operators (those users with the @ in front of their names) to help control the chaos that often ensues. But even this method of control eventually falls prey to the power-play, and the channel once again can fall into chaos.
Bots Save the Day... Sort Of
To help remedy these problems, some creative individual designed the bot (short for robot) to silently lurk on the channel for the purpose of giving channel ops to those who ask (usually with a password), kick offenders (criteria for "offender" being totally up to the bot-owners), and thus "protect" the channel from those who might otherwise take control for their own diabolical purposes. Of course, the original intention of the first bot programmer more likely was the "immediate" purpose of simply controlling a channel or channels for his or her own personal reasons. But the overall outcome has been for general channel protection, and many have reaped the benefits of this remedy.
An increasingly favorite type of bot that has proven very, very useful and quite configurable is the Eggdrop. Whereas some bots are merely open-end clients running cleverly written scripts, the Eggdrop bot is a compiled executable employing the Tcl language, and runs as a background task on most types of UNIX. They are almost perfectly self-maintaining and self-sufficient (notice I said "almost").
Once started, they attempt to connect with IRC server machines via the standard IRC TCP port (usually 6667 or 6668, but there are others), and also listen on their own Telnet ports, which can be just about any port number the bot-owner chooses.
In this way, the owner can go to IRC and DCC chat to his/her own bot and utilize the Eggdrop bot's other feature: the console. (DCC means "Direct Client Connection," which is simply connecting one client to another via a given TCP port.)
From the bot's console (sometimes called the "party line"), users with proper access can set channel bans, move around from server to server, and see the channel activity through the "eyes" of the bot. Further, because of the bot's listening capability, it can connect via Telnet to other bots, creating a "botnet." Some of these bots may even share a common set of userfiles, so that several bots can protect a high-traffic or very hostile channel.
There exist botnets that contain hundreds of individual Eggdrop bots spanning many IRC networks. The possibilities here are endless, and the "power" from such cooperation is formidable.
Yes, Eggdrop bots are the salvation of IRC and are perfectly bug-free and fool-proof. Not. Such configurability comes with a price. As with any complex, sophisticated set of options or variables, the bots can be poorly configured and the small amount of maintenance required for their optimal performance is often neglected. Examples here are:
Known default values may be left unchanged in the config files.
Simple passwords may be used, or common passwords on many bots.
Bots neglect to get passwords for other bots (more on this later).
Default listening ports fail to be changed.
Bonehead channel ops "automate" their op-begging scripts.
crontabs poorly configured.
Known bugs fail to be remedied (nick-flood bug, etc.).
Bot may be poorly hidden, making it an easy IRCOP target.
As you can see, all of those problems are the fault of the human who set up the bot and the humans who use it. As we all know from the glorious past and the evolution of the UNIX system, most security holes are due to laziness, ignorance, and those other silly low-tech characteristics monopolized only by people.
The Nitty Gritty
As a user of these interesting programs, I can speak from my direct experience with the many Eggdrop bots I have configured and run, and so I will start with my first exposure to the downside of the Eggdrop code. This is not a flame of the code itself, but the scenario that inevitably rises from the Eggdrop's method of control: Password-mediated channel opping.
Password Harvesting via Automated OP Begging
I use the nickname Tempest- on EFnet, the largest IRC network that I know.
Notice the character after my nickname. I had to have the hyphen there because someone else used the nickname Tempest, and that someone seemed to always be connected. Since no person can stay on IRC as much as this entity, I made an assumption that it must have been a bot.
I had a sinister plan...
Now, before I continue, I'll need to talk a little bit about floods. Specifically, "avalanche" floods.
"Flooding" is a term widely used by nearly everyone on IRC, including the IRCOPs, the server admins, the implementors, etc. When a client connected to an IRC server sends over a certain amount of data to the server within a given frame of time, they satisfy the server's "flood" criteria, and are immediately disconnected from the server. This is a server flood, and itself has many implementations and uses to the typical IRC wannabe channel hacker.
Another type of flood is the avalanche, which really only sends a fair amount of control characters (I use Ctrl-I) to the channel. This used to have the strange effect of disrupting the older versions of IrcII clients to the point that the user had to terminate the process from another shell and start over. Today it's quite useless, but the Eggdrop bot still responded quickly to a large progression of printable control characters, and simply KICKed the offending user off the channel, and would eventually set a ban if the problem continued.
So anyway, I joined the channel where this alleged bot using the nickname Tempest lurked, and promptly sent something like twenty Ctrl-I, one right after the other... Looks pretty on most clients, but the bot didn't like this activity, and immediately kicked me with the words, "Avalanche flood detected." Bingo! Now I knew I was dealing with an Eggdrop bot. (There are other ways to find bots that want to be hidden, but, until recently, this was the most reliable, since the detection code was hard-wired directly into the bot code and not readily user configurable.)
The next step was to imitate the bot, and to do this I would need to secure the nickname the bot used, Tempest. Of course, not even the most secure, stable connections last forever, and so the Tempest bot eventually lost its connection and had to establish a new one. Fortunately for me, I had configured three other bots to try their damnedest to use the nickname Tempest, and so the odds were in my favor that I would eventually get it the next time the Tempest-bot had to reconnect.
It turns out that I did.
Once one of my bots inevitably secured the nickname for me, I killed them off and gave it to my own client. This is when the fun started. Within ten minutes, I began getting lots of private messages from unknown users that contained simple one-line phrases such as op hosehead, or op 152 34. People were joining IRC and, as part of their start-up, their clients were set to automatically send a /msg to Tempest with the words op hosehead (for example). This is the method used to beg channel operator status from an Eggdrop bot, and they were sending it to me instead. Bingo!
But what good is this? Stray passwords do you no good unless the bot knows your specific identification (your ident), right? The Eggdrop bot contains provisions for users who change their ident (their hostname, address, domain, etc.). Thus, if someone goes on vacation to grandma's house, they can logon to IRC, give a certain command to the bot, and the bot will recognize their new location.
I did precisely that.
After relinquishing the Tempest nickname back to the bot (to avoid suspicion), I used the newly acquired password of hosehead to identify myself to the bot as the channel operator who messaged me in the first place, by using the following format: /msg tempest ident hosehead lamer1
(Assume that lamer1 was the nick of the lame channel operator who erroneously messaged me with op hosehead)
This added my current host.domain to the Tempest bot under lamer1 list of valid hosts he can use. In effect, as far as the bot was concerned, I was lamer1. All I had to do now was join the channel, get ops, and then do whatever I wished. But I had plans. I DCC chatted the bot, used hosehead as the password, and was allowed onto the party line. For fun, I set nickname-only bans for all of the other channel operators and then joined the channel to watch the fun. A major kick/banfest was underway, but eventually, they all were kicked, and the Tempest bot prevailed as the only operator. At this point, I issued the op command to the Tempest bot: /msg tempest op hosehead or .op {my nick} from within the bot's party line.
Once I had channel ops, I deopped the Tempest bot, removed the bans for the other operators and bots that were kicked, set the channel mode to +m (moderated speech only), and left it. My intent was to prove a point, not to do any real damage. But had I had the good fortune of getting the password to someone with "master" access to the bot, I could have gone further, screwing with the userlist, DIEing the bot, and possibly even accessing the UNIX shell account that hosts the bot, since many bot-owners seem to use the same password there as they do on their bot(s). That is a definite no-no.
How to Avoid This Problem
People using an Eggdrop bot should be taught not to automate their client to beg the bot for channel operator status. This will keep them from inadvertently falling prey to people posing as the bot and harvesting passwords. Of course, it only takes one idiot to spoil your day, so...
Modify or have someone modify your bot code, replacing the ident command with another word. Perhaps "LEARN" or "ADD_ID", or something similar. It's amazing how effective such a simple modification can be. Even if someone finds a valid password, they cannot identify their host.domain to the bot if they don't know the appropriate command.
In the bot's config file, make sure their "alternate nick," the nickname the bot uses if the primary nickname is in use, is something strikingly different from the main nick it desires. For instance, if your bot's nick is Foolbot, make sure its alternate nickname is something like FewL-bawt- or F001BOt or something like that. If an idiot sees the "strange" nickname on the channel and notices that it is the bot, he might actually put one of his few brain cells to work and realize that the bot's primary nickname is in use and not run his op-begging script. Of course, someone out there will still run one of those ON-CONNECT scripts that begs the bot.
Make sure the bots know not to ban those idents that belong to fellow bots.
Make Sure All Bot Records Have Passwords
It's a simple enough problem. Somewhere in the midst of all the userfile transferring, the manual bot-record adding and editing, and other situations where the bot users (and their associated careless mistakes) communicate and modify the bot data directly, a bot gets ahold of a channel record for another bot, but no password is ever assigned.
For example, you have an Eggdrop bot called Pollux, and one called Castor that you are setting up for the first time. You want to connect them to a botnet that contains other Eggdrop bots, such as Procyon, Deneb, Sirius, and Bellatrix. When you transfer the userfile of Pollux to Castor, Castor will get a user record for all of the bots Pollux knows, but unlike regular user records, no password will be automatically assigned to the bot records.
So, Castor could end up with a bot record or records with no password set, and the record will have the channel-op flag. This seems like no big deal, but what happens if Castor is running from a machine that hosts many IRC users, and probably many other bots? If Castor sees its own user record for itself as something like *!*castor@botmachine.host.domain, then anyone logging onto IRC with the username of castor, and using botmachine.host.domain UNIX shell would be recognized by Castor as itself. All they have to do now is issue the PASS command in the form of: /msg {targetbot} PASS {new password} and then join the channel and beg the bot for operator status. The bot, thinking another valid bot is online, will obediently give operator status as per the request.
And bingo! The bad guys have operator status. The channel is vanquished.
Exercise - Become One With The Bot
Alternately, suppose you have the means to spoof a certain ident, say, botmachine.lame-site.net, and suppose someone there named idiotbot is in need of a good screwing. So, their complete ident on IRC is:
They run an IRC channel that does nothing but spread poisonous lies about your mother, and so you want it closed down immediately.
1.) Get your own bot ready to monitor the channel, enforcing channel mode +i (invite-only). Make sure it has the +bitch and +stop-nethack flags set. There are also a few decent "takeover" scripts available on the net for eggdrops. They do nothing but deop/kick anyone not on the bot's userlist. Use one of those if needed. It will take care of anyone who tries to liberate that terrible channel by riding in on an IRC netsplit.
2.) Choose a time when you think the human bot-users and bot-masters are asleep, and spoof the ident so that you are seen on IRC as idiotbot@botmachine.lamesite.net. (Sorry, no help here. This discussion is about Eggdrops, not IP spoofing.)
Now there is no guarantee that idiotbot can be overcome as described above, since its owner may already either be savvy to the bot-password security hole, or have a password set purely by chance. But chances are very good that you'll be able to fool the bot as described above, and the unfair, mean-spirited channel will be closed-down.
3.) Run your bot and let it join the channel. If it gets kick/banned, that's no big deal.
4.) Message idiotbot with the PASS command: /msg idiotbot PASS {newpassword}
Since idiotbot thinks you are idiotbot (you spoofed its ident), it will very likely, for the first time, set a password for itself.
5.) Join the channel and beg ops from idiotbot, using your new password.
6.) If many bots exist in that channel, it may be necessary to use idiotbot to ban them out of the channel so that a bot power-struggle doesn't ensue. You can either use the bot's console (discussed above) to set bans for the bots, or you can do it with your own client if there are only a couple. If idiotbot sets the bans, they will be strictly enforced (+dynamicbans) until the channel-ban information is removed from the bot entirely.
7.) Once idiotbot and you are the only channel operators left, kick and ban idiotbot. Then, unban your bot and make it a channel operator. It will immediately set the channel mode to +i (invite-only). This effectively closes down the channel entirely. An alternate method is to simply have the bot enforce channel mode +m (moderated speech only), instead of mode +i, so that the regulars can join the channel but not be allowed to talk.
8.) Expect retribution in the form of various TCP nukes, ICMP floods, etc. The channel regulars will want "their" channel back, of course, and so you and/or your bot's shell may feel the pain of various attacks. Use firewalls. Pray to your God. Whatever you think will work, do it.
Of course, in the long run, even if you manage to hold the channel closed, the ex-regulars of that channel will probably just create another channel and continue their diabolical campaign against your sweet mother. An IRCOP, a sort of playground monitor, will sometimes act as a gun-for-hire and /KILL you and/or your bot(s) from the channel if they know some of the channel regulars or listen to their whining.
There's not much you can do to get around this except to start from scratch and try again. But you can be sure that the bot-owners will be wise to your methods, so it may not work; you might only have one shot, so make it a good one.
How to Prevent This Attack From Occurring on Your Own Bots
The simplest way to avoid this kind of attack is to make sure your bot(s) all have passwords set for other bots within its userlist. From the console, type the following: match +b
This will cause the bot to show you all user/bot records that have the +b (bot) flag. In the list that is provided, make sure that all of them have passwords set. Use anything.
Do this for all the bots. When it comes time to link various bots, simply .chpass both bots to a common password, and they will be able to forge the link.
Good luck and shouts to Bernie S.
Glossary
Avalanche: A sudden uncontrolled and potentially dangerous movement of snow down a slope, embankment, or other steep incline; potential-to-kinetic energy conversion at its finest. Within the context of IRC, a "flood" of unprintable characters to certain clients that [used to] result in a crash.
Ban: A way of telling a server to deny a certain ident's access to a channel. Within the metaphor of IRC, a way of banishing a user from a channel.
Botnet: A network of Eggdrop bots, connecting through a given TCP port for each bot. Botnets can span IRC netsplits and even entire IRC networks.
Bot-owner: That person who compiled and now runs a bot.
Bot-record: An entry within the bot's userlist.
Client: A computer that connects to, and requests data from a server machine.
Ident: A user's internet identification. Within IRC, a complete ident takes the form of: nick!user@machine.host.domain
Invite-only: The state of a channel where only users who are invited (/invite command) by a channel op are allowed to join. (channel mode +i) Within the context of this text file, it is a way of "closing" a channel.
IRC network: A host of IRC server machines all connecting and sharing data. Several large networks exist, such as EFnet (the largest), Undernet, DALnet, and more.
IRCOP (IRC Operator): Certain users who have the added ability to request /KILL lines for certain types of connections, such as problem users, zombie processes, etc.
Lamer: An unfortunate entity oblivious to readily available and useful knowledge.
Moderated: The state of a channel where only "voiced" (mode +v) users and channel operators are able to send text to the channel for all to see. This is channel mode +m. Within the context of this text file, it is a way of "closing" a channel.
Netsplit: Loss of inter-server connectivity. Within the metaphor of IRC, mass-QUITs occur corresponding to everyone who was on other servers. When the server reconnects to the network at large, mass-JOINs are seen within the channel and servers are seen giving operator status to certain users.
OP-begging: Act of sending a certain message (with a password) to an Eggdrop bot to gain channel operator status.
Server: A computer that sends requested data to a client or client(s) on a per-request basis.
Takeover: The process of shifting channel operator status from one group of users to another, against the wishes of the original users. On EFnet, there is no real recognition of this term since no one "owns," or has express rights to, a channel.
Userfile: A list of information about users the bot is supposed to know. Eggdrop userfiles are totally independent of IRC servers and are known to the bot only.
Use the following Tcl to change your bot's ident and op commands to learn and opme, respectively.