ENOSUCHBLOG

Programming, philosophy, pedaling.

Identifying and Enumerating IRC bots with IBIP

Mar 20, 2015 Tags: irc, programming, security

This post is at least a year old.

If you’ve been on IRC for any substantial period of time, you will have encountered an IRC bot. Whether it was NickServ or ChanServ or your favorite channel’s operator’s pet bot, you will have interacted with an automated client designed to ease and simplify your IRC experience.

This should come as no surprise. Constructing and running an IRC bot has been a programming rite of passage for decades, and isn’t going away anytime soon. As a consequence of this there are tens of thousands of unique IRC bots, many of which are still running unused and undetected.

This isn’t a huge problem in and of itself (apart from bugs and security holes in the bots themselves), but it would be nice if channel operators and users alike had a way to easily identify bots in their channel(s).

IBIP makes that possible.

What is IBIP?

IBIP, or the IRC Bot Identification Protocol, is exactly what it sounds like: a protocol for identifying IRC bots.

It standardizes two things: a trigger, listened for by all IBIP-compliant bots, and a PRIVMSG sent by all IBIP-compliant bots in response to the trigger.

The trigger is simple:

.bots

Or, as a complete PRIVMSG:

PRIVMSG target :.bots

Where target is a channel or nickname.

In response, IBIP-compliant bots are expected to send a response like this:

Reporting in! [language] information

Once again as a complete PRIVMSG:

PRIVMSG target :Reporting in! [language] information

Where:

target is the channel the trigger was sent to, or the nick of the sender if the message was direct.
Reporting in! is a static message, the baseline for IBIP compliance. This is the sole mandatory component of the protocol on the bot side.
[language] is the language the bot was written in. Two examples would be [C] and [Perl]. This section is purely optional. If multiple languages are used by the bot, they should be slash-separated.
information is any additional information the bot’s author wishes to make known. A good example would be a hint for using the bot. Like the language section, this too is optional.

The two optional sections may be used without their partner, but the information section may not be surrounded by brackets in any circumstance.

Therefore, a complete response would look like this:

Reporting in! [Ruby] See my !help command for a list of commands.

Usage and rationale

These two simple rules quickly become very useful for finding and enumerating bots. A sample session might look like this:

Talking on #channel.
<john_doe> .bots
<bot1> Reporting in! [C]
<bot2> Reporting in!
<bot3> Reporting in! [Java] http://example.com
<bot4> Reporting in! Version 2.8.56 running on Debian GNU/Linux x86_64

Each of those responses was valid, making each bot IBIP-compliant.

Although this might seem like a source of spam, it can be very useful for channel operators and users alike. If an operator would like to keep a cap on the number of IRC bots in the channel at any given point, they can simply issue the .bots command and manage all enumerated bots with a script that matches “Reporting in!”.

Similarly, channel users will be able to issue .bots and ascertain which (if any) bots can be used to perform channel tasks.

Drawbacks and conclusions

There are two large drawbacks to IBIP’s modus operandi:

There are no protections against false positives. A malicious user can easily script their IRC client to answer the .bots trigger with a contrived response, like Reporting in! [Human] Th1s ch4nn3l suX0rs!. It’s a matter of opinion whether or not this type of scripted response actually constitutes an IRC bot itself.
There are no protections against response floods. A malicious user seeking to spam a channel can issue the .bots trigger over and over, resulting in a deluge of useless messages. The best way to prevent this is to institute a cooldown period within each bot, although simply auto-kicking or muting users who spam the trigger would also suffice.

With an administrative bot and occasional intervention by human operators, both of these pitfalls can be avoided.

In summary, IBIP can be a very good thing for the Wild West of IRC and IRC bots. If enough large frameworks/bot authors add compliance (a very simple affair, by any measure), every user will be just one message away from accessing otherwise hidden services.

If you are an IRC bot author, please consider adding it to your bot. It’ll make me very happy.

- William

Previously

Newer