Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nmap -sV does not take -g src port into account #2796

Open
liquidpele opened this issue Mar 11, 2024 · 0 comments
Open

nmap -sV does not take -g src port into account #2796

liquidpele opened this issue Mar 11, 2024 · 0 comments
Labels

Comments

@liquidpele
Copy link

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):

% nmap --version
Nmap version 7.94 ( https://nmap.org )
Platform: x86_64-apple-darwin22.6.0
Compiled with: liblua-5.4.6 openssl-3.2.0 libssh2-1.11.0 libz-1.2.11 libpcre2-10.42 libpcap-1.10.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: kqueue poll select
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant