[24580] in bugtraq
mIRC DCC Server Security Flaw
daemon@ATHENA.MIT.EDU (James Evans)
Thu Mar 7 19:23:01 2002
Date: 6 Mar 2002 22:40:34 -0000
Message-ID: <20020306224034.24011.qmail@mail.securityfocus.com>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
From: James Evans <jae7@lehigh.edu>
To: bugtraq@securityfocus.com
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
