Re: Dynamic DNS "Spoofing" & IRC

[c4 <c4 () jolt nu>]

Well you dont even have to have dyndns... just control over the over the 
domain is sufficient.
Just connect and change the dns afterwards...

This dosn't have anything to do with dns & irc really... it just utilizes 
the fact that your ircclient performs a dns check seperatly.

The problem with rechecking dns is that for a pretty large network such as 
ircnet or efnet it would take some resources to do this check, thus 
allowing a denial attack being made more easily against one server.

At 23:47 2003-05-01, you wrote:
> This is a trivial "feature/flaw" I've been holding onto for a bit, and it's
> probably commonly known, but I haven't seen it posted anywhere, more of a
> neat little thing in taking advantage of IRC and it's treatment of dyndns
> within DNS if reverse lookup is possible.
>
> IRC (Internet Relay Chat) servers being a common ground for chat, have some
> annoyances such as the username@ipaddress or username@domainname, some
> people don't like that etc, being that they have to use a bouncer to avoid
> showing their own ip address or hostname to other users if they want to
> maintain some sort of privacy.
>
> Well here's a pseudo-privacy trick that can be reasonably easy to perform
> given one has control of a dns server that performs reverse and forward
> lookups, support for dyndns scripts, and a domain-name registered to you.
> You can optionally use a bouncer if you want.
>
> In my example, I will use the host name spooftest.domain.com, a port
> forwarding tool, a zoneedit account with my dyndns script that forward
> resolves, and a friend's server (he/she runs an isp) that allows for me to
> have an PTR record to the ip address "10.1.1.1" (<-- this is a private
> address for demo purposes) on his server as spooftest.domain.com
>
> Step 1) I have zoneedit script set up to tell it that my dyndns address is
> to spooftest.domain.com is 10.1.1.1, which it updates immediately and the
> 10.1.1.1 server has PTR record for 10.1.1.1 as spooftest.domain.com (thus
> allowing reverse and forward lookup of spooftest.domain.com)
> My portforward (say we're using datapipe.c on the 10.1.1.1 box)
> settings are datapipe 10.1.1.1 6667 irc.whateverserver.net 6667
>
> Step 2) Log into irc server on your local machine by doing a /server
> spooftest.domain.com 6667, make sure the irc server has resolved you as
> username () spooftest domain com
>
> Step 3) Run your dyndns script for zoneedit to assign your ip address as
> whatever ip you want (in this case I'll use 127.0.0.1), then wait about a
> minute before joining a channel.
>
> By this time, your dyndns should have updated and changed your ip address to
> 127.0.0.1, and irc servers don't re-check after you've connected (so anyone
> resolving your hostname will come up with 127.0.0.1).
>
> I don't know if this is categorized as a flaw in dns or irc, or just merely
> exploiting a feature, and this is a rather trivial trick (surely can't be
> original and I apologize if it's been posted before).
>
> A fix I think would have ircd recheck after a certain amount of time for
> resolving properties of their dns, and I was going to say dnssec, but I
> can't really see that fixing the problem unless ircd re-checks as well
> there.
>
> This "feature/flaw" could probably apply to other application protocols as
> well that do not recheck dns properties, but I haven't taken the time to
> come up for other practical uses for it.
>
> This has been tested on most ircd server versions and all so far are victim
> to this "hack".
>
> 0x90
> www.invisiblenet.net