Date: Sat, 21 Jul 2001 18:27:11 +0200 From: "Jeroen Massar" <jeroen@unfix.org> To: "'Brian Somers'" <brian@Awfulhak.org>, "'Richard A. Steenbergen'" <ras@e-gerbil.net> Cc: "'Peter Pentchev'" <roam@orbitel.bg>, <freebsd-security@FreeBSD.org>, <freebsd-gnats-submit@FreeBSD.org> Subject: RE: bin/22595: telnetd tricked into using arbitrary peer ip (was: telnetd suckage) Message-ID: <000f01c11201$ffefafd0$420d640a@HELL> In-Reply-To: <200107211337.f6LDbag72093@hak.lan.Awfulhak.org>
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 :) 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 That's the problem reported in the 22595 PR... 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. 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... 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... - 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. _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... And like Richard says: THAT REALLY SUCKS. Greets, Jeroen 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?000f01c11201$ffefafd0$420d640a>