search

projectdiscovery / nuclei

Fast and customizable vulnerability scanner based on simple YAML based DSL.
https://docs.projectdiscovery.io/tools/nuclei
MIT License
18.89k stars 2.38k forks source link

Can't use openvpn tunnel to scan #5183

Closed TiregeRRR closed 2 months ago

TiregeRRR commented 2 months ago

Nuclei version: v3.2.7

Current Behavior:

I'm creating a tunnel interface from openvpn config with route-nopull option specified. After running nuclei with this command: nuclei -t ~/nuclei-templates/network/detection/pgsql-detect.yaml -i test0 -u ip:port -j -vv -stats -debug and long wait, get this error: [WRN] [pgsql-detect] Could not make network request for (ip:port) : could not connect to server: [:RUNTIME] ztls fallback failed <- dial tcp my_ip:0->ip:port: connect: connection timed out Although scanning without interface specified will result in psgql detection

Expected Behavior:

Getting same result as scanning without tun interface

Steps To Reproduce:

  1. Create openvpn tun interface from config with route-nopull option specified
  2. After that run nuclei -t ~/nuclei-templates/network/detection/pgsql-detect.yaml -i test0 -u ip:port -j -vv -stats -debug
  3. Will result in mentioned error

    Anything else:

    Specifying resolve conf or -sr flag doesn't help Thanks for any help

Mzack9999 commented 2 months ago

@TiregeRRR Just to exclude connectivity/routing issues, would it be possible to check if nmap/ncat with connect scan can reach the target through the tun interface?

$ sudo -u nonrootuser nmap -e test0 scanme.sh -p 80 -vvv
TiregeRRR commented 2 months ago

@Mzack9999 Surely, 

nmap -e test0 target_ip -p 5432 -vvv
Starting Nmap 7.94 ( https://nmap.org ) at 2024-05-15 08:49 UTC
Initiating Ping Scan at 08:49
Scanning target_ip [4 ports]
Completed Ping Scan at 08:49, 0.22s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 08:49
Completed Parallel DNS resolution of 1 host. at 08:49, 13.00s elapsed
DNS resolution of 1 IPs took 13.00s. Mode: Async [#: 1, OK: 0, NX: 0, DR: 1, SF: 0, TR: 3, CN: 0]
Initiating SYN Stealth Scan at 08:49
Scanning target_ip [1 port]
Discovered open port 5432/tcp on target_ip
Completed SYN Stealth Scan at 08:49, 0.23s elapsed (1 total ports)
Nmap scan report for target_ip
Host is up, received echo-reply ttl 49 (0.20s latency).
Scanned at 2024-05-15 08:49:15 UTC for 0s

PORT     STATE SERVICE    REASON
5432/tcp open  postgresql syn-ack ttl 47

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 13.56 seconds
           Raw packets sent: 5 (196B) | Rcvd: 2 (72B)
Mzack9999 commented 2 months ago

@TiregeRRR I was able to reproduce the issue in case a network interface has multiple address with the relevant ones being first in the list, and I believe the issue is related to a bug in the ip selection logic that instead at the first one, iterated till the end. This should be fixed with https://github.com/projectdiscovery/nuclei/pull/5186

Along with the interface you can also override the souce ip with the one of the interface directly with -sip xxx.xxx.xxx.xxx with (xxx.xxx.xxx.xxx being client assigned by the openvpn server)