lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 May 2003 14:47:59 -0700
From: "Intel Nop" <0x90@...isiblenet.net>
To: <bugtraq@...urityfocus.com>
Subject: Dynamic DNS "Spoofing" & IRC


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@...ddress or username@...ainname, 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@...oftest.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






Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ