Re: Port identification methodology

["Chris Winter" <cwinter () mentortech com>]

When trying to determine what an is actually running on an unknown port,
everyone first relies on their /etc/services file.  You can get fairly up to
date and complete ones which help a great deal (from apps like NMAP, or
downloadable from www.portsdb.org, don't rely on the stock ones from
Microsoft, most UNIX vendors or from RFC 1700.)

I am assuming you are referring to ports that don't have a listing in
services, or do, but the description is poor, incomplete, or just doesn't
make sense.  In this case, you have to start poking at the port to see how
it responds when you send it data.  The most important this to remember
here, is that this type of scanning may very easily crash/kill/hang/reset a
poorly written daemon or service.

You will get some testers that say a good pen test will always require
identifying unknown ports.  I would agree, but I let my clients know up
front what the risks are.  Nothing spoils a relationship quicker than
crashing an important system.

With that said, you can start out quick and easy with a few small scripts
wrapped around netcat or Perl + IO::Socket.  As Yonatan Bokovza recommended,
good strings to send are: QUIT\n or GET /\n.  One thing you may want to use
instead of \n is \x0d\x0a , which is the ASCII hex representation of
carriage return then newline.  This should cover a wider range of systems
(YMMV.)  Using these two strings, you will get a fair amount of feedback,
usually in the form of error messages, which you can then try and hunt down
from various resources.  It becomes tricky when the daemon/service you are
querying doesn't return error messages or responds to a binary protocol.

You will get a lot more information by running something Like Saurik's
NMAP+V patch, which was already mentioned, as it sends many more types of
query strings, including a some binary stuff.  Although this adds more risk
to the test, because there is a greater chance that the daemon/service will
choke on the greater amount of input.  I am not sure about it's continued
development status.

HTH,


Chris

-------------------------------------------------------------------
  Chris Winter
  Consultant
  Security Practice
  cwinter () mentortech com
  Cell: 410 258-4817

  Mentor Technologies-- innovators of vLab(r) technology, provides:
   ** high-end internetworking, skills-based learning services and
      solutions.
   ** high-end internetworking design, management, and security
      consulting.
  We're high tech, high touch, high performance; the total
  internetworking solutions company.  Visit us at www.mentortech.com
--------------------------------------------------------------------
----- Original Message -----
From: "Erik Norman" <erik.norman () ccnox com>
To: "pen test" <pen-test () securityfocus com>
Sent: Monday, July 02, 2001 6:13 AM
Subject: Port identification methodology


> Hi all,
>
> I have a question regarding methodology while performing a
> PT. It concerns identifying programs/services.
>
> Imagine a full nmap scan has been performed. A handfull
> of open ports was found on a particular server. The
> usual 25, 53, 80 etc are identified, but one or two ports
> stand out from the crowd. Looking in various 'common ports'
> files does not provide a hint what the port is used for.
>
> Connecting with telnet yields no text, and a tcpdump
> dump does not provide any text (in clear anyway).
>
>
> Now what!???
>
> How should one approach this?
>
>
> /Erik
>
> --------------------------------------------------------------------------
------------
> This list is provided by the SecurityFocus Security Intelligence Alert
(SIA) Service
> For more information on SecurityFocus' SIA service which automatically
alerts you to
> the latest security vulnerabilities please see:
>
> https://alerts.securityfocus.com/


--------------------------------------------------------------------------------------

This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service
For more information on SecurityFocus' SIA service which automatically alerts you to 
the latest security vulnerabilities please see:

https://alerts.securityfocus.com/