Bugtraq mailing list archives
Re: analysis of auditable port scanning techniques
From: dethy <dethwork () SYNNERGY NET>
Date: Sat, 6 Jan 2001 04:30:08 +0100
Using this grammar applied to the data we send to an arbitrary host piped to the ident/auth port will reveal the process owner running on a given port, even though we initiated the connection.
Dan Harkness writes:
Uh, no. With properly-written ident daemons, such as pidentd, the daemon will only respond for connections initiated on the machine on which it's running, and with a destination of the machine querying the daemon. Do you have examples of ident daemons that don't enforce this?
This is exactly the process that is described in the paper. We create a connection to establish itself on an identd port, now we grab our socket descriptor using getsockname() and using unpack() (in PERL) to grab the port for our client specifics to enable the reverse query to take place. Once all is in check, the query is sent to an identd port, and because the grammar used in the query is RFC compliant the daemon will return the process UID/name (depending on server configuration). As you mentioned pidentd is a properly-written ident daemon but that does not exclude it from being a player in this scanning method. Afterall pidentd is RFC compliant. Let me show you an example: Using a self made reverse ident scanner based in perl I issued the following parameters to test pidentd (too if it answers our replies how i've mentioned) perl id.pl -d XXX.XXX.XXX.XXX -p 20-25 port service owner 21 21 root 22 22 root 23 23 root 25 25 root okay, what we have here is: ports 21 - 25 were open and the PID owner was returned. I quickly tried it on 3 servers, all answered the query. Pidentd, version 3.0.10 (compiled for Linux 2.2.5-22smp) Pidentd, version 3.0.10 (compiled for Linux 2.2.16) in.identd, version 2.8.5 FreeBSD 4.2 So which versions don't answer to this request ? To my knowledge any RFC compliant identd will answer to this request, since the data used in the query is correct use of the EBNF described by the RFC. Regards, dethy dethy () synnergy net
Current thread:
- analysis of auditable port scanning techniques Guido Bakker (Jan 04)
- Re: analysis of auditable port scanning techniques Guido Bakker (Jan 05)
- Re: analysis of auditable port scanning techniques Dan Harkless (Jan 05)
- Re: analysis of auditable port scanning techniques Rainer Weikusat (Jan 08)
- Re: analysis of auditable port scanning techniques Dan Harkless (Jan 08)
- Re: analysis of auditable port scanning techniques Henrik Nordstrom (Jan 09)
- Message not available
- Message not available
- Re: analysis of auditable port scanning techniques D. J. Bernstein (Jan 16)
- Re: analysis of auditable port scanning techniques Rainer Weikusat (Jan 08)
- <Possible follow-ups>
- Re: analysis of auditable port scanning techniques dethy (Jan 08)
- Re: analysis of auditable port scanning techniques Michael Bacarella (Jan 08)
- Re: analysis of auditable port scanning techniques Michael S Soukup (Jan 08)