Forums Bug Reports DCC spoofing and mIRC problem with the dialog

The main problem is that the _real ip_ mIRC will try to connect to is not shown
uppon DCC CHAT or SEND request. This is pretty serious since anyone can spoof a DCC send
or chat request.
I don't understand why there is an IP parameter at all for DCC. Because of NAT?

Example (also done with mIRC :-) )
//quote privmsg fic :
DCC CHAT CHAT $longip(127.0.0.1) 31337

That weird character is ASCII 1 (read the CTCP draft).

Now fic just sees that some user wants to DCC CHAT with him.

Nick: nick
Address: [email]ident@host[/email]

But that host is the real host of nick. There is not written anywhere that mIRC
will connect to 127.0.0.1 on port 31337. It is pretty probable that the user will now press
'accept' since he thinks nick just wants to chat with him. After he decides to accept
he will see where he has connected. But it is already too late now.

mIRC should display the ip and port and aditionaly a warning if the port is not in
the usual range of 1024-5000 (or maybe even if the users' ip on IRC doesn't match
the 'destination ip').

'DCC spoofing' could be abused in many ways. Let's say a drone sending tons of
dcc chat requests which would result in a huge DoS attack as soon as the 'dumb' users
press 'accept' and lots of connections will be established to the destination.
Or making somebody connect to www.fbi.gov:22 a few times to get him busted.

I better don't think about those lusers who have auto accept turned on...

Regards,
Grega "fiction" Pogacnik

mIRC should display the ip and port and aditionaly a warning if the port is not in
the usual range of 1024-5000 (or maybe even if the users' ip on IRC doesn't match
the 'destination ip').

Good idea (but make the warning range configurable perhaps?)

Users ip doesnt have to match destination ip - plus it would mean that mIRC would have to wait for a DNS responce...
I know that some clients do that when u try to dcc chat, but I'm not sure myself that its a good idea...
A situation where realip would not be the same as the users ip is if they were using a bouncer of any kind - so if there is a warning, perhaps that should be explained
(I guess there are more bouncers than "spoofers")

Well you are able to change the port range you will be using.
So maybe the 'unusual port' warning should also depend on that setting.

Indeed, resolving or doing /stats L (as on ircnet) is a quite 'expensive'
operation, so it should definitely be configurable somehow.

Ah bouncers, yes. Totally forgot about that crap.
Still it would be nicer if you couldn't specify the IP in DCC.
The bouncer should be able to forward DCC CHAT or SEND somehow.
In the same way as it handles IRC connections.

c'ya,
fiction

Recently a server I frequent used a compile option to replace any ip field in DCC sends or chats to that of the connections IP. While it may help those that cant be bothered finding their real IP, and stop the nuisance spoofs to unsuspecting targets, it also crippled anyone that had to use a bnc, http proxy or socks4 proxy or bind sockets to a different IP, and has thankfully been removed. As your post suggests sanity checking should be the clients responsibility.

mIRC should also provide some *noticable* warning, alert etc. to tell the user that a send is coming from the DCC Server and not IRC, so hopefully users won't assume the nick sent by the dcc server (usually 'NickServ') belongs to the nick on IRC and blindly accept files/reveal info in chats.

Heh, I've played around with this. Dcc spoofing is also quite useful. And to actually verify that the ip and port is valid might take a little more doing on the ircd's that mask the actual ip address and host name of their users. The only info on where it really is is what the dcc send sends. I have actually written a couple scripts that use this.

http://web.dreamsoft.com/tat/reflector.mrc
For example, uses dcc spoofing to redirect files to other users. Such that the file sent to the client is redirected and info is handed off to a third party who actually recieves the file. Although, there are several avenues for abuse, it is very very useful and akin to fxp'ing with ftp servers. Plus side uses are cross-network sends, redirects of large files to faster downloading friends, and perhaps returning a dcc session full of worthless control characters and lag back to wence it came.