Date: Sat, 21 Jul 2001 19:38:23 +0100 From: Brian Somers <brian@Awfulhak.org> To: "Jeroen Massar" <jeroen@unfix.org> Cc: "'Brian Somers'" <brian@Awfulhak.org>, "'Richard A. Steenbergen'" <ras@e-gerbil.net>, "'Peter Pentchev'" <roam@orbitel.bg>, freebsd-security@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, brian@Awfulhak.org Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip (was: telnetd suckage) Message-ID: <200107211838.f6LIcNg76517@hak.lan.Awfulhak.org> In-Reply-To: Message from "Jeroen Massar" <jeroen@unfix.org> of "Sat, 21 Jul 2001 18:27:11 %2B0200." <000f01c11201$ffefafd0$420d640a@HELL>
next in thread | previous in thread | raw e-mail | index | archive | help
> Brian Somers wrote: > > > > On Fri, Jul 20, 2001 at 03:58:09PM -0400, Richard A. > > Steenbergen wrote: > > > > Speaking of telnetd sucking, did anyone ever get around to fixing > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=22595 > > > > > > > > Doesn't look like it. > > > > > > Do you have any actual suggestions on how to 'make realhostname*() > > > not suck', as you have so helpfully suggested as a fix? > > > > I don't understand this PR. What's the problem ? realhostname*() > > takes the connecting IP, turns it into a name and resolves that name. > > If the *original* IP isn't in the list (or if a name couldn't be > > found from the IP), it puts the *original* ip in utmp/wtmp. If the > > *original* IP is in the list, it uses the name that the IP was turned > > into. > > $ host -t ptr 10.0.0.1 > 1.0.0.10.IN-ADDR.ARPA domain name pointer www.fbi.gov > > $ host -t a www.fbi.gov > www.fbi.gov has address 32.96.111.130 > > And then your average dumb admin does a 'who' and oooooh... That dude is > leet he/she/it logs in from www.fbi.gov > It's also great for your logs... "My box got hacked from www.fbi.gov, > the feds are on to me" nice quotes :) If you log in from 10.0.0.1 and the above resolutions are in effect, realhostname_sa() will put 10.0.0.1 in utmp. Why are you assuming it doesn't ? > IRCd and many more (even PuTTY > (www.chiark.greenend.org.uk/~sgtatham/putty/) :) do a: > - Resolve IP -> hostname > - resolve hostname -> IP2 > - if IP1 != IP2 then hostname = IP1 Which is exactly what realhostname() and realhostname_sa() do. > That's the problem reported in the 22595 PR... What is ? > But it get's even worse (evil grin :), this is a nice trick you can do > to fool your ssh which IMHO should be a nice PR on it's own: > > 8<----------- > jeroen@purgatory:~$ w > 6:08PM up 93 days, 9:58, 1 user, load averages: 0.19, 0.13, 0.14 > USER TTY FROM LOGIN@ IDLE WHAT > jeroen p1 hell.unfix.org 10:16AM - w > jeroen@purgatory:~$ w -n > 6:08PM up 93 days, 9:58, 1 user, load averages: 0.16, 0.12, 0.13 > USER TTY FROM LOGIN@ IDLE WHAT > jeroen p1 10.100.13.66 10:16AM - w -n > ------------>8 > > And guess what: > 8<----------- > jeroen@purgatory:~$ netstat -an | grep \.22 | less > tcp6 0 0 3ffe:8114:2000:2.22 3ffe:8114:2000:2.1628 > ESTABLISHED > tcp4 0 0 *.22 *.* > LISTEN > tcp46 0 0 *.22 *.* > LISTEN > ------------>8 > > Now I wonder... why the peep doesn't the wtmp log an IP (either IPv4 or > IPv6) alongside a hostname... > As you see ... Hell.unfix.org resolves nicely to 10.100.13.66 (an IPv4 > address) even when I am connected over IPv6... > If that isn't one kind of security risk.... Simply change your reverse > to something nice and wh0ppa... > No-one will even notice thaty you're coming from a remote network far > far away... > With this nice IPv4/IPv6 trick you could even set a forward IPv4 lookup > to make a local IPv4 IP. So that it looks like you logged in from a > local system. But this doesn't happen either. On my machine, 3ffe:8114:2000:2 is recorded. In fact, I've just fixed realhostname_sa() so that it records the hostname if it fits in the utmp field and the forward/ reverse lookup ends up with the same ipv6 number, but even before the fix, the IPv6 number was what's recorded. Ah, wait, I see what the problem is. It's ``w'' that's getting it wrong. It's assuming that it knows the address family of the name in utmp -- and mucks about with name resolutions whether you say -n or not. ``who'' gives the right answer. > If that isn't enough 'proof' that the whole utmp/wtmp concept is > wrong.... -> YES, I accuse utmp/wtmp not telnetd as you might notice ssh > has the same problem :) > Telnetd simply does what it _can_ do ... log the hostname to utmp/wtmp, > 'w' and friends simply use that info to show it to us... All daemon programs that log you in and are part of the base system will display this behaviour, but I don't agree that there's any problem with realhostname*(). w(1) is flawed. > So we basically have the following list of problems: > - wtmp/utmp should have hostname and IPv4 or IPv6 or ... > one could choose IPv4 mapped IP's.. eg: ::ffff:10.100.13.66 (but this > could become a prob in the future again... > IMHO adding an extra field containing the ascii representation of the > IP/address whatever should do... Which also would be able to log the IPX > addy or whatever :) > And the hostname field should contain either nothing (empty) or > should contain the ascii representation of the address, that's what > forward&reverse resolve is for... The extra field should hold the address family. > - utmp/wtmp-"client"-programs (readers) show the wrong info when > 'showing network numbered' because they don't have the full/correct info > because they don't have it. Agreed. > _if/when_ these get fixed even "dumb admins/users" won't go around > telling that they got hacked by the FBI or the CIA simply because some > kiddy with reverse access, > which currently is quite easy to obtain with all those IPv6 > tunnelbrokers around who don't give anything about (possible) abuse from > their clients. > And the same goes for IPv4 ofcourse.... Simply insert a PTR record... > and tada... you're now coming from a NASA host... how 1337 or whatever > spelling those people/things/... prefer... I don't agree. A dumb admin/user will do dumb things no matter what the operating system that they're working with does. If realhostname*() doesn't see the PTR record pointing at a name that resolves back to the IP, it records the IP. > And like Richard says: THAT REALLY SUCKS. Which is a pretty useless statement. > Greets, > Jeroen I'll have a look at fixing ``w'' -- probably by tearing the -n option out as it's evil. I won't add the extra field to utmp however. This has been discussed before and it would break too much. Programs should simply not attempt to muck about with things when they don't have enough information. -- Brian <brian@freebsd-services.com> <brian@Awfulhak.org> http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org> Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107211838.f6LIcNg76517>