[8781] in bugtraq
Re: Ircii-epic: about dcc hijacking... (fwd)
daemon@ATHENA.MIT.EDU (Ben Winslow)
Wed Dec 23 01:22:28 1998
Date: Tue, 22 Dec 1998 15:41:26 -0500
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Ben Winslow <rain@INSANE.LOONYBIN.NET>
To: BUGTRAQ@NETSPACE.ORG
---------- Forwarded message ----------
Received: from BlackHole.RainNet.Org (rain@BlackHole.RainNet.Org [192.168.1.3])
by Portal.RainNet.Org (8.8.8/8.8.8/Debian/GNU) with ESMTP id LAA23199
for <rain@portal.RainNet.Org>; Tue, 22 Dec 1998 11:56:57 -0500
Received: from listopher.concentric.net (listopher.concentric.net
[206.173.119.117])
by BlackHole.RainNet.Org (8.8.5/8.8.5) with ESMTP id LAA16044
for <rain@insane.loonybin.net>; Tue, 22 Dec 1998 11:57:05 -0500
Received: (from majordom@localhost)
by listopher.concentric.net (8.8.3/8.8.5)
id LAA02046; Tue, 22 Dec 1998 11:31:37 -0500 (EST)
Message-ID: <199812221631.KAA03778@nemesis.acronet.net>
To: ircii-epic@concentric.net
Subject: Re: Ircii-epic: about dcc hijacking... (fwd)
In-Reply-To: Your message of "Mon, 21 Dec 1998 16:30:59 EST."
<Pine.LNX.4.03.9812211630450.22325-100000@Portal.RainNet.Org>
Date: Tue, 22 Dec 1998 10:31:31 -0600
From: Jeremy Nelson <jnelson@acronet.net>
Sender: owner-ircii-epic@concentric.net
Precedence: bulk
>Heya, I did not say that dcc-hijack.c is more than a simple tcp
>portscanner, so this is not so preposterous as you wrote.
What I thought was preposterous is that you presented this as some kind of
serious problem.
>Then if you read my post with attention you can't find anything absurde.
No comment.
>More, it could not be a `bug', anyway we can easly patch irc-client to
>bind random port.
This won't change the problem since you can still port-scan a wider range
to pick up the random ports. This kind of stuff is best left to the
operating system.
Your "exploit" only works when:
1) Someone either accepts or initiates a dcc transaction with an
untrusted party.
2) During the time that the untrusted party runs the port scanner, the
DCC transaction is the one and only transaction that is pending. If,
for example, someone is doing a FTP, then you could just as well pick up
one of their PORT commands rather than a DCC listen.
3) The untrusted party runs the port scanner between when the person
initiates the latter DCC CHAT and when the latter DCC CHAT is accepted.
(Race condition)
4) The person does not double-check the IP address on the latter DCC CHAT
to see if it is reasonable.
>Which is your point of view? hehe
My point of view is that one should write a script to hook /on dcc_offer,
dispatch a userhost or userip (depending on your network) to retrieve the
hostname of the person you are soliciting for a dcc transaction. When that
hostname information comes back, stash it in a variable. When the DCC is
accepted, if the hostname information has not come back, 'wait'. If it
has come back, then check $2 (or whatever) against the IP address of the
person you are interested in. If its not the same, chances are you have
a conflict to look at.
An alternative solution for those who are lazy is to keep a "moving" variable
that holds open a DCC RAW port over the last few DCC's you have offered.
Something that hooks /on dcc_offer and then does a $listen() to fool the
port scanner into connecting to the $listen() socket would be sufficient.
One must be careful to close their fd's though when theyre done.
I do not feel that the random binding of ports offers anything useful
above and beyond the current mechanism. If you are interested in
implementing either of the above, then i would be most appreciative and
interested in your work...
Jeremy
