Good afternoon,

There is an error in the impmelentation of the mIRC 
DCC server protocol.

This venerability allows an attacker to obtain:
1) The victim's nickname.
2) Whether or not the victim is ignoring the attackers 
requests for a direct connection.
3) Information regarding the number of IRC servers a 
user is connected to.

The protocol itself can be found in mIRC's help file so 
I won't go into it here, but the problem is..

1) Make a connection to the open DCC server.

2) Type: 100 testing

3) From this point on, there is nothing that the user 
can do to prevent you from obtaining his or her nick. 
Regardless of whether they 
select "Accept", "Cancel", "Ignore", or click on the "X" 
to close the chat request completely, the server will 
*ALWAYS* respond with their nick in the form:

151 <their_nick>

This clearly shouldn't be the case. Even if they wait 
until the DCC Server times out, a default of 300 
seconds, the server still replies with their nick.

As for determining if someone is "ignoring" the 
request... you just have to time to see how fast the 
server replies with the information. If the timings are 
ever different, someone is sitting there and clicking 
on things.

Now for finding out if they are on another server - 
compare the returned nick, to the nick that they have 
on the local IRC server you are on them with. If it's 
different, they are on another server with this other 
nick. I *think*, there may be exceptions to this. Also, 
this is all dependant if you are on an IRC server with 
them, but it is still a possible attack.

Solutions:
1) Simply have the server return the nick if, and only 
if, the "victim" accepts the connection - NEVER when 
they select "Cancel", and definitely not when they 
select "Ignore".

2) Have an option to not close the connection for a 
set amount of seconds, even after the "victim" 
makes their choice of ignoring the chat.

3) I suggest the possibility of having a DCC Server 
Nick, which is always the same for DCC Chats 
made through the server.

4) It would also be nice to have the ability of:
a) Seeing when people connect to this port, even if 
the request fails.
b) Having some sort of port filtering, so that you can 
accept/deny IPs, without the need for a 3rd party 
firewall.

Of course, this all falls apart if you do not know what 
port the DCC Server is running on. But it seems the 
majority of users leave it to the default settings - 
hopefully this will teach some people to be a little 
more careful, and not use default port numbers for 
services such as this. As we know though, this 
information could of course be scanned for rather 
simply, so even changing the port upon which this 
service listens will not solve all of the problems.

This is definately an error in the coding of it because 
the help file documents a 150 and 151 reply, and they 
are used for some responses but not all of them.

-James Evans