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-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 May 2003 18:26:24 +0300 (EEST)
From: Markus Kovero <muikku@...kkuverkko.net>
To: Intel Nop <0x90@...isiblenet.net>
Subject: Re: Dynamic DNS "Spoofing" & IRC


We have in Darkmyst ( http://www.darkmyst.org ) this thing called hostname
verification or smthin:

21:36 [nla] !xx.xx.xx.darkmyst.org *** Notice -- IP# Mismatch:
24.xxx.177.xxx != wv-xxx-ubr-b-xxx-196-xxx-130.charterwv.net[82b19f18]

Don't know exactly how it works, probably kills user with fake hostname.
We're using somekind modified darkhex ircd atm and we're coding new one
which is in beta-stage now.

cheers and happy "vappu"-holidays; Markus Kovero

On Thu, 1 May 2003, Intel Nop 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@...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