Network Vigilantism Using Port 113

by Tokachu

If you've ever been on an IRC server, you've probably received an attempted connection to port 113, and probably gotten a "Please install identd" soon afterwards.

For those who are not familiar with Internet Relay Chat (IRC), identd is a network service that runs on port 113 to identify which user is on which TCP connection.

Here's how a typical session would work:

  1. Client connects to the identd server on port 113.
  2. Client gives the server the remote port used for connecting and the local port connected to.
  3. Server responds with a username.

An example of a session might look like this:

  1. Client sends the text 1025, 6667, where 1025 is the port on the server (the identd server) and 6667 is the port on the client (the one making the identd request).
  2. Server sends 6667, 1025 : USERID: UNIX : myusername, where myusername is the supposed login.

The purpose for such a protocol was to provide a way for machines on trustworthy multi-user networks to automatically allow people to login from their machines.

Soon after the original protocol specifications were released, people realized how much of a joke identd was.  Subsequently, nobody uses it for its original purpose.

Enter IRC

While identd is not used in any serious manner, it has found a use on IRC servers.

For the longest time, IRC operators were concerned that users would try to abuse their systems while hiding behind open proxies.  Nearly all the open proxies available were not breached systems, but poorly configured machines.

As the abusers had no real access to those systems beyond using them as proxies, many IRC servers began requiring that every client run identd on their machine to "identify" them.

If the IRC server couldn't connect to the client's machine on port 113, they would assume the machine was an open proxy and would terminate the connection from there.

Not too long ago computer virus writers began writing their own proxy software, including identd servers with them so they could both connect to IRC channels anonymously as well as to allow the victims' computers, or "zombies," to connect to a hidden IRC channel for mass remote controlling of machines.

Nowadays it's practically useless to rely on identd for any kind of authentication whatsoever.

Patrolling Your Network

If you're as lucky as I am, you've gotten yourself a nice job looking after a network, or perhaps you've got a small LAN set up at home.

Either way, if you are the administrator of any network connecting Windows XP computers together, you know how terrible things can get and, unless you've got full control of every machine and run Windows Update religiously, odds are you've had to take a machine offline at least once to "clean it up."

But let's say that you run a very large network, one with at least a few hundred computers, nearly all of which run Windows XP.  You don't have the time to look at each and every one of those computers and make sure none of them have been "zombified."  So what can you do?

Scanning the Network

First, download the latest version of Nmap.

Compile it and run it with the following options:

$ nmap -sT -p 113 -P0 -v -T 4 -oG ident.txt 192.168.1.0/24

Here's a breakdown of the command-line options:

-sT  - Scan using full TCP connections.

-p 113  - Specifies to only scan port 113 (identd).

-P0/-Pn  - Don't send out pings (most software firewalls block ping requests anyway).

-v  - Be verbose (print out open ports as they are found).

-T 4  - Very fast timing, no delay between connections.

-oG ident.txt  - Log everything in the file ident.txt.

192.168.1.0/24  - Scan every host in that subnet.  This is the only option you'll have to change.

Once you've scanned your network, go through the file ident.txt and find each line that has the word "open" in it.

In UNIX, at a command line, type: grep open ident.txt

In Windows, at the command prompt (CMD.EXE), type: FIND open IDENT.TXT

Testing the Open Machines

Although identd should not be running full-time on a legitimate IRC client, there is still that possibility.

Here are a few "acid tests" that can be run on the server:

Null Test  - Send a completely blank query.  This should either return nothing or return the error: UNKNOWN-ERROR

Zero Test  - Send a query with both the client port and server port set to 0 (zero).  This should return the error: INVALID-PORT

Private Port Test  - Send a query with the client port set to 113 and a random server port.  It should return an error with either: HIDDENUSER or NO-USER

Multiple-User Test  - Send a valid query twice in a row.  The two usernames returned should match.

If any of the servers found does not pass three or all of these tests, it's more than likely been infected with a virus and is possibly receiving commands from a remote IRC server to either relay junk e-mail, flood websites with garbage, or infect more machines.

Luckily most of the exploits used for them to self-propagate have patches against them, and probably use the same shellcode that came with the original proof-of-concept exploit posted!

Based on that, you'll probably find yourself dealing with FTP commands piped to a command line, rather than shellcode that utilizes the WinINet library.

In other words, the code can easily be found by up-to-date anti-virus software, even if the virus has been reconfigured and recompiled for another person to control.

Peeking into the Virus

While the executable itself might be encrypted, worms that connect to a central IRC server rarely establish encrypted connections.

If you can sniff the network traffic on any of the infected machines you found, you can easily find where the server is connecting, and possibly the passwords used by the script kiddie who is controlling all the machines.

From there you can send a standard "abuse" e-mail to the network administrator responsible for the IRC server's network.  If you're more daring, you could take over the "bot network" and shut it down yourself, although this could result in getting an "abuse" e-mail yourself!

Conclusion

I suppose the only thing I could tell you to keep the Windows machines on your network secure would be to treat them as if they were your own UNIX boxes: don't give your clients administrative access, keep all of them updated, and filter the ports that are known to be exploited, such as the ones for WINS, DCOM, and NetBIOS.

And, of course, it doesn't hurt to scan yourself - it's better than someone from the outside doing it for you!

Return to $2600 Index