[NEWS] mIRC DCC Server Security Flaw
From: support@securiteam.comDate: 03/13/02
- Previous message: support@securiteam.com: "[NT] Various Vulnerabilities in Norton Anti-Virus 2002"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Wed, 13 Mar 2002 09:10:44 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
mIRC DCC Server Security Flaw
------------------------------------------------------------------------
SUMMARY
There is an error in the implementation 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 attacker's requests for a
direct connection.
3) Information regarding the number of IRC servers a user is connected to.
DETAILS
The protocol itself can be found in mIRC's help file. The specific problem
can be recreated as follows:
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
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.
There may be exceptions to this. Also, this depends on whether 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 - not 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) The author suggests 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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:jae7@lehigh.edu> James
Evans.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[NT] Various Vulnerabilities in Norton Anti-Virus 2002"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
