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
