From: Kaj Huisman (kaj.huisman@gmail.com)
Date: Thu Aug 11 2005 - 13:02:21 EDT
Paul J Docherty wrote:
> Whilst the points you are making are correct once you have discovered
> open ports, I think you have raced ahead of the question, which was I
> think, "which port scanner is giving the correct results?" As many
> others have elegantly answered use a packet sniffer and look at the raw
> data to see what's going on.
I dont need to use any sniffer to _see_ what happens in the following
three states it might report. (nmap -sT <host>)
80: OPEN Here the following sequence took place
syn_to_server->_syn_ack_response_from_server->ack_to server
(iow full connection).
If it succeeds you _will_ have a point of entry.
Then you move on to find out what the possibilities of the point of
entry (or service) are. You might (at this stage) continue with scanning
(version scan, different scanners, sniffers loaded. all valid points)
but you will have allready the knowledge that you _are_ indeed able to
connect(); to the port.
80: CLOSED Here something like:
syn_to_server->no_service_here_from_server EOT *
Note that the dumps posted earlier show _filtered ports.
On a closed port it is unlikely that an aplication will send a sequence
of syns, if it gets the 'port_not_reachable' it will stop (telnet would
give you a 'connection refused' on a closed port, not a timeout(filtered
port).
*One poster validly pointed out that a closed port can send out
different responses (depending on stack implement) thus the results
CLOSED is not 100%. OPEN = 100 % reliable and a definite elevation.
80: FILTERED Any other case, would require more investigation.
If it is filtered then all the replies about using <name tool> are valid
(good replies).
If the -sT replies with either *closed or open then you have a
certainty, something that needs to be written into the rapport and more
closely investigated, but you _will_ have this certainty.
* see above
There is no use in using any tool at all if you cannot filter out the
results
Time is an issue in most pen-tests. I will now hypotheticly recreate the
situation:
Boss "dude, perform a blackbox test on that machine"
nmap -sS -vv -P0 -O -oN logfile.nmap x.x.x.x & netwag blah logile.nwox
x.x.x.x &
results:nmap
interesting ports on [..]
80 Filtered
1723 Filtered
Other ports are closed // <-- *note assumption
OSGuess: unreliable
results:nwag
80 Open
1723 Open
Other : ?? // closed ?
* the assumption is valid since if the ports were filtered they would be
listed and if they would all be reported open,... well.
// Note that a firm (or proper) pen-test at this point allready has the
sniffer/dumper running (imo atleast).
Based on the above results alone I extract the hypothesis that the
machine is some midrange business server, since the reports (wheter
filtered or open) report the well-known port numbers of a webserver (80)
and Point to Point tunneling protocol (1723). Making a note of that
allready.
We have different results so we need to weed them out here, most
reliable way to confirm wheter the port is open or not is to perform a
full-connect on the port. So we do. We could use a little handcrafted c
code that will :
socket();
connect();
close();
/* side note here, if you dont wrap connect within a alarm_timer(); here
, your app will try to connect untill infinity and will never reach the
the 'connection timed out' status */
But why go trough all the hassle when nmap (and most other scanners)
allready have the ability to do a 'void' connect ability built in.
nmap -sT -p 80,1723 -vv x.x.x.x
80 Open
1723 Open
:DD
WE HAVE THE ABILITY TO CONNECT (Loud Cheering Sounds)
Elevate
nmap -sT -vv -sV -O -p 80,6767
80 Open Apache 1.3.26
6767 Closed // Assumption with above explained logic
OsGuess: Red_Hat linux, kernel 2.x.x
Uptime: xdays,xminutes
We want to be sure so we will use _every_ other tool in out toolkit to
verify this as well as with manual inspection of packets and grabbing of
banners (which is the least reliable).
Then we fire up metasploit and gain a shell, from here on blah.. blah..
[Report box as vulnerable and move on from there (depending on the
clients need)]
(I know, this is a bit shortcutted, for explanatory purposes)
Note that the above sketched situtation is _invalid_ if the -sT reports
the port as closed (which we should write down as a *confirmed closed
which may later on in the process be used to bind a shell on perhaps).
If report is filtered, _then_ the whole other chain of events steps in.
* see above point
All other scantypes (excluding -sS which send back a syn_rst after the
syn_ack_from_server (preventing the server from logging a full
connection), and is therefore evenly reliable with -sT) rely on protocol
definitions vs vendor implemantations. Windows TCP stack functions
different as Linux' TCP stack, most scanners rely on guessability for
any other scan type, makeing them all sortof questionable (allthough
some tools are really good at guessing).
Thus indeed, if the port is filtered you would need to go more low
level, try FIN packets or Fragmented packets, perhaps a sombie scan to
find out if there is a trust relation with some other box somewhere else
on the net. My point was that you should not make something more
difficult then it is.
I hope this clears some confusion.
G'Day
Kaj
------------------------------------------------------------------------------
FREE WHITE PAPER - Wireless LAN Security: What Hackers Know That You Don't
Learn the hacker's secrets that compromise wireless LANs. Secure your
WLAN by understanding these threats, available hacking tools and proven
countermeasures. Defend your WLAN against man-in-the-Middle attacks and
session hijacking, denial-of-service, rogue access points, identity
thefts and MAC spoofing. Request your complimentary white paper at:
http://www.securityfocus.com/sponsor/AirDefense_pen-test_050801
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:44 EDT