You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When using the -g option to specify a src port, this is only taken into account for port-open verification... the following probes from the -sV option then do NOT use the specified src port. This results in a scenario where if the target is only accessible from a given port (e.g. they misconfigured their firewall to allow 443 both ways) you can see the port is open, but it's not possible to determine what the service data is.
To Reproduce
Use both -g and -sV together with a target that blocks all incoming packets that aren't from your port.
Example: finding ssh open where src port 443 is incorrectly allowed through to any other port:
sudo nmap -p 22 -Pn -n -g 443 -sV 1.1.1.1
Example tcpdump from such a sample:
% sudo tcpdump host 1.1.1.1
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
09:16:52.084031 IP 10.0.0.18.https > 1.1.1.1.22: Flags [S], seq 3712202745, win 1024, options [mss 1460], length 0
09:16:52.162773 IP 1.1.1.1.22 > 10.0.0.18.https: Flags [S.], seq 3297769002, ack 3712202746, win 64240, options [mss 1460], length 0
09:16:52.162799 IP 10.0.0.18.https > 1.1.1.1.22: Flags [R], seq 3712202746, win 0, length 0
09:16:52.239892 IP 10.0.0.18.50973 > 1.1.1.1.22: Flags [S], seq 4087613889, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1507505645 ecr 0,sackOK,eol], length 0
09:16:53.240317 IP 10.0.0.18.50973 > 1.1.1.1.22: Flags [S], seq 4087613889, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1507506646 ecr 0,sackOK,eol], length 0
09:16:54.240998 IP 10.0.0.18.50973 > 1.1.1.1.22: Flags [S], seq 4087613889, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1507507646 ecr 0,sackOK,eol], length 0
09:16:55.240515 IP 10.0.0.18.50973 > 1.1.1.1.22: Flags [S], seq 4087613889, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1507508646 ecr 0,sackOK,eol], length 0
09:16:56.240848 IP 10.0.0.18.50973 > 1.1.1.1.22: Flags [S], seq 4087613889, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1507509646 ecr 0,sackOK,eol], length 0
09:16:57.245321 IP 10.0.0.18.50977 > 1.1.1.1.22: Flags [S], seq 194809477, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2930627271 ecr 0,sackOK,eol], length 0
09:16:58.245103 IP 10.0.0.18.50977 > 1.1.1.1.22: Flags [S], seq 194809477, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2930628271 ecr 0,sackOK,eol], length 0
Interestingly, the -sV option re-checks the port is open with a quick handshake using the specified src port, but then the probes all use different src ports.
Expected behavior
That the src port is taken into account by the service probes so that they can correctly connect to the port.
Version info (please complete the following information):
Describe the bug
When using the -g option to specify a src port, this is only taken into account for port-open verification... the following probes from the -sV option then do NOT use the specified src port. This results in a scenario where if the target is only accessible from a given port (e.g. they misconfigured their firewall to allow 443 both ways) you can see the port is open, but it's not possible to determine what the service data is.
To Reproduce
Use both -g and -sV together with a target that blocks all incoming packets that aren't from your port.
Example: finding ssh open where src port 443 is incorrectly allowed through to any other port:
Example tcpdump from such a sample:
Interestingly, the -sV option re-checks the port is open with a quick handshake using the specified src port, but then the probes all use different src ports.
Expected behavior
That the src port is taken into account by the service probes so that they can correctly connect to the port.
Version info (please complete the following information):
The text was updated successfully, but these errors were encountered: