IRC Anonymity Guide

From Hidden Wiki
Jump to navigation Jump to search

The obvious "don't"s

  • Don't enter/use information that can be associated with your real identity. This includes passwords, nicknames, full names, idents, etc.
  • Never accept a DCC request unless you know what you are doing.
  • Don't follow unknown/suspicious links. Always use an anonymizing HTTP proxy when following links.
  • Do not connect to unknown IRC servers. The majority of IRC clients' security holes can be exploited only by the server administrators.
  • You shouldn't act suspicious or nosy, as this will decrease the level of trust people have in you. Don't try to send CTCP/DCC requests.

The obvious "avoid"s

  • Avoid being connected to any IRC server anonymously at the same time as being connected to the same or any other IRC server non-anonymously for any extended period of time if both connections come from clients/sessions running on the same machine or local network, just in case this common link fails/recovers repeatedly, and especially if you are visiting a public channel on each/the IRC server. (Instead operate either of them from a remote bouncer.)

General issues

Hostname

Many IRC clients send the computer's hostname to the IRC server while connecting. This is especially dangerous on *NIX operating systems where the FQDN may be leaked (myserver.example.com).

CTCP

CTCP stands for Client To Client Protocol, it's a method for exchanging information between two IRC clients. The most common CTCP commands (requests) include ACTION, VERSION, PING, CLIENTINFO, USERINFO, etc.

CTCPs are bad, because they they can potentially reveal information about you, your IRC client, the OS you are using, etc.

Even though the most popular CTCP command, ACTION, is not harmful, it's probably the only one. CTCP ACTION will be issued with the /me command in most IRC clients. Also, the majority of IRC clients will not block CTCP ACTION when you ignore all CTCPs. (Which is good)

Most notably, CTCP VERSION can be used to get the name and version number of the IRC client you're using. For example, mIRC might reply with "mIRC v6.16 Khaled Mardam-Bey", and some IRC clients even go as far as revealing the kernel version, CPU and more ("xchat 2.0.10 Linux 2.6.8-1-686-smp [i686/2.79GHz/SMP]"). Fortunately, many IRC clients provide a way to fake the VERSION reply. However this is out of the scope of this guide. On the contrary, mIRC even includes protections that keep you from hex editing the VERSION reply (however, see below).

CTCP TIME can be used to find out the timezone you live in, CLIENTINFO can be used to find out about the commands your IRC client supports, etc.

CTCP PING can be used to determine the round-trip time between two cliens, through the IRC server. This can potentially be used to find out the tunnel length of other users, but ping times through I2P are generally random enough. On the contrary, most clients send a timestamp when requesting CTCP PING, so if you ping anybody they'll probably be able to determine the timezone you're in.

Note that "lag meters" typically involve pinging the IRC server.

DCC

DCC stands for Direct Client-to-Client, it is a protocol for establishing direct connections between two users, either for private chats or file transfers. Since these connections are direct (they don't go through the IRC server), the participants would need to know each other's IP address, which is obviously bad. More specifically only the recipient needs to know the sender's IP address which cannot be provided when the sender is behind Tor (as is the case with a primitive NAT or an HTTP proxy). However, even as a recipient behind Tor, most IRC clients do not have native support for piping outbound DCC traffic through a proxy, which is also obviously bad given any absence of transparent proxying.

Technically, DCC uses CTCP for the handshake, but most IRC clients won't block DCC when you tell them to ignore CTCPs.

Client notes

ii

  • With the anonymity patch applied, ii does not reveal your username.
  • There is no support for the privacy-leaking CTCP/DCC commands.
  • SASL PLAIN authentication is easy to implement.

irssi

  • Reports your hostname to the server by default. /set hostname hidden.i2p (Sets your hostname to hidden.i2p)
  • /ignore * CTCPS (Ignores everything but ACTION and DCC)
  • /ignore * DCC (Ignores all DCC commands)

mIRC

  • The use of mIRC is discouraged. However, in case you absolutely want to use mIRC, you should always keep the version up to date. This is because of the fact that mIRC has had a history of critical remote exploits. Also, as it's the most popular IRC client for Windows, it probably gets the most attention from hackers/crackers.
  • Avoid using suspicious mIRC scripts, as many of them include backdoors.
  • mIRC supports three types of proxies: SOCKS4, SOCKS5, and "PROXY" (HTTP CONNECT). SOCKS4 does not support proxy-based DNS resolution. SOCKS5 does, but mIRC attempts to resolve hostnames first directly, and then only through your SOCKS5 proxy if direct resolution fails. This means you will leak all DNS requests through mIRC if using either SOCKS4 or SOCKS5. Therefore, Tor users of mIRC are advised to use only the "PROXY" method and then point mIRC at an HTTP CONNECT -> SOCKS middleman such as Privoxy.

To ignore CTCP:

  • /ignore -wt *
  • /ignore -wd *

Disabling mIRC CTCP Client Information Queries

Responses to CTCP FINGER, CTCP TIME, and CTCP PING requests made against your mIRC client can be disabled by adding the following lines to your Remote script (press ALT-R and select the [Remote] tab):

 ctcp 1:FINGER:*:echo 4 -se [ $+ $nick FINGER] denied | halt
 ctcp 1:TIME:*:echo 4 -se [ $+ $nick TIME] denied | halt
 ctcp 1:PING:*:echo 4 -se [ $+ $nick PING] denied | halt

With these scripting commands added to your Remote script, other IRC users will simply receive no response whatsoever from your mIRC client upon attempting to gather information about you from it using any of these commands. You will additionally be alerted to all such failed attempts in your status window (the "denied" messages).

To additionally prevent mIRC from sending CTCP VERSION responses, the mirc.exe executable must be hex edited. For version 6.35 of mIRC (the latest as of this writing), make the following changes with a hex editor:

 Offset    Old    New
 0006354C  85h -> B0h
 0006354D  C0h -> 00h
 -
 Offset    Old    New
 000E6BEF  74h -> 90h
 000E6BF0  27h -> 90h
 -
 Offset    Old    New
 000E74FA  74h -> 90h
 000E74FB  36h -> 90h
 -
 Offset    Old    New
 001F6FA4  56h -> 00h
 001F6FA5  45h -> 00h
 001F6FA6  52h -> 00h
 001F6FA7  53h -> 00h
 001F6FA8  49h -> 00h
 001F6FA9  4Fh -> 00h
 001F6FAA  4Eh -> 00h

Again, these patches apply only to mIRC 6.35. Once these binary patches are made, you may then add the following line to your Remote script so that, as with the other CTCP commands above, you will receive alerts when others have attempted (and failed) to retrieve your client version information:

 ctcp 1:VERSION:*:echo 4 -se [ $+ $nick VERSION] denied | halt

Note: Adding the above line to your Remote script without also applying the binary patches will not prevent mIRC from sending your VERSION information. Specifically, mIRC is internally boobytrapped to ignore "halt" commands issued by Remote scripts during CTCP VERSION scripting events, and that is why the additional binary patching is necessary to "re-enable" sensitivity to "halt" during CTCP VERSION scripting events. No such internal boobytrapping exists for CTCP FINGER, CTCP TIME, and CTCP PING events in remote scripting, and thus issuing "halt" upon them in Remote scripting is all that's necessary to completely disable them.)

XChat

XChat before version 2.6.x sends your hostname every time it connects to an IRC server, on UNIX-like OSs it is your host name and on Windows machines it is your machine name (See uname -n for the value sent). In order to fix this behavior, you need to either use an IRC bouncer (like BNC) or apply a patch:

 --- proto-irc.c 2004-10-26 04:17:09.000000000 +0000
 +++ proto-irc_hacked.c  2005-03-05 17:11:37.140000000 +0000
 @@ -61,7 +61,7 @@
         tcp_sendf (serv,
                                   "NICK %s\r\n"
                                   "USER %s %s %s :%s\r\n",
 -                                 serv->nick, user, hostname, serv->servername, realname);
 +                                 serv->nick, user, "myhost", serv->servername, realname);
 }
 
 static void

CTCP

There are a few options for disabling CTCP:

  1. /ignore * CTCP DCC (Note: This also ignores CTCP ACTION from all users.)
  2. Empty ctcpreply.conf (make sure XChat isn't running when you do this or it will be overwritten)
  3. Deleting everything in Settings -> Advanced -> CTCP Replies

This disables everything exception version replies. To do that, make sure XChat is closed and edit xchat.conf and set irc_hide_version = 1.

ViRC

  • ViRC (and ViRC 2.00): (This hack is necessary, because the built-in ignore command will also block CTCP ACTION)
    1. Choose File → 'Script editor...' from the menu.
    2. Choose 'local.lib' from the drop-down box.
    3. Copy-paste following lines to the header section, below the comments:
 //Halts all CTCP requests from being processed, except ACTIONs
 if [$strtrim($3)] != [ACTION]
 AbortEvents
 endif
4. Click on the 'Save & Rehash' button. That should do it.
(Thanks to DrWoo for the information about ViRC)

Encryption

  • For total freaky Anonymity of your speech, use Fish Encryption for your communication with your partners
  • FiSH can be found for most common irc-clients on http://fish.secure.la/


See Also