Penetration Testing mailing list archives
Re: Nmap/netwag problem.
From: Kaj Huisman <kaj.huisman () gmail com>
Date: Thu, 11 Aug 2005 19:02:21 +0200
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 rawdata 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 aboveThere 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,xminutesWe 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 pointAll 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 -------------------------------------------------------------------------------
Current thread:
- Re: Nmap/netwag problem., (continued)
- Re: Nmap/netwag problem. Daniel Miessler (Aug 12)
- Re: Nmap/netwag problem. Pete Herzog (Aug 12)
- RE: Nmap/netwag problem. Omar Herrera (Aug 11)
- Re: Nmap/netwag problem. Martin Mačok (Aug 11)
- Re: Nmap/netwag problem. Josh Zlatin-Amishav (Aug 10)
- RE: Nmap/netwag problem. Drage, Nick (Aug 10)
- Re: Nmap/netwag problem. eliudgarcia (Aug 10)
- RE: Nmap/netwag problem. Irene Abezgauz (Aug 11)
- RE: Nmap/netwag problem. laurent . constantin (Aug 11)
- RE: Nmap/netwag problem. Paul J Docherty (Aug 11)
- Re: Nmap/netwag problem. Kaj Huisman (Aug 12)
- Re: Nmap/netwag problem. Fyodor (Aug 12)
- RE: Nmap/netwag problem. ankush.kapoor (Aug 12)
- Re: Nmap/netwag problem. ilaiy (Aug 12)
- RE: Nmap/netwag problem. Paul J Docherty (Aug 15)
- Re: Nmap/netwag problem. Kaj Huisman (Aug 15)