WPScan fails to resolve .onion hostnames via SOCKS5 proxy (Tor)

[quaxalber]

Description

WPScan (v3.8.28) appears unable to scan WordPress sites hosted on .onion addresses when using Tor as a SOCKS5 proxy. The scan consistently fails early with a "Could not resolve hostname" error, even when using wrappers like proxychains4 or torsocks. This suggests WPScan attempts local DNS resolution for the .onion address instead of delegating it to the SOCKS proxy, which is required for .onion domains.

Environment

• WPScan Version: 3.8.28
• Ruby Version: 3.3.0
• OS: Manjaro Linux (also tested on Kali)
• Proxy Setup: Tor SOCKS5 proxy running on 127.0.0.1:9050
• Wrappers Tested: proxychains-ng 4.17-2, torsocks2.4.0-1

Steps to Reproduce

1. Set up Tor to provide a SOCKS5 proxy on 127.0.0.1:9050.
2. Identify a target .onion address (e.g., https://y7yea4pmqqtznb33qiugvysyn2bob5v62e4pvoadoibrwkq3tsddjeyd.onion/).
3. Confirm Tor proxy and target reachability using curl:

   # This fails as expected due to curl's RFC 7686 handling (curl >= 8.1.0)
   curl --socks5 127.0.0.1:9050 https://y7yea4pmqqtznb33qiugvysyn2bob5v62e4pvoadoibrwkq3tsddjeyd.onion/
   # Output: curl: (97) Not resolving .onion address (RFC 7686)
   
   # This SUCCEEDS, proving Tor proxy and target are functional
   curl --socks5-hostname 127.0.0.1:9050 https://y7yea4pmqqtznb33qiugvysyn2bob5v62e4pvoadoibrwkq3tsddjeyd.onion/
   # Output: HTML content of the site
   

4. Attempt to scan with wpscan using its built-in proxy flag:

   wpscan --url https://y7yea4pmqqtznb33qiugvysyn2bob5v62e4pvoadoibrwkq3tsddjeyd.onion/ -e p,vt,u --proxy socks5://127.0.0.1:9050 --random-user-agent --disable-tls-checks
   # Output: Scan Aborted: The url supplied '...' seems to be down (proxy handshake error)
   

5. Attempt to scan using proxychains4 :

   proxychains4 wpscan --url https://y7yea4pmqqtznb33qiugvysyn2bob5v62e4pvoadoibrwkq3tsddjeyd.onion/ -e p,vt,u --random-user-agent --disable-tls-checks -vvv
   # Output: Scan Aborted: The url supplied '...' seems to be down (Could not resolve hostname)
   # Traceback:
   # Trace: /opt/wpscan/vendor/bundle/ruby/3.3.0/gems/cms_scanner-0.15.0/app/controllers/core.rb:42:in `check_target_availability'
   # /opt/wpscan/app/controllers/core.rb:59:in `before_scan'
   # ... (rest of traceback)
   

6. Attempt to scan using torsocks:

   torsocks wpscan --url https://y7yea4pmqqtznb33qiugvysyn2bob5v62e4pvoadoibrwkq3tsddjeyd.onion/ -e p,vt,u --random-user-agent --disable-tls-checks
   # Output: Scan Aborted: The url supplied '...' seems to be down (Could not resolve hostname)
   

Expected Behavior

When using --proxy socks5://..., proxychains4, or torsocks, WPScan should delegate the resolution of the .onion hostname to the Tor SOCKS5 proxy (similar to how curl --socks5-hostname works) and then proceed with the scan over the Tor network.

Actual Behavior

WPScan fails immediately with a "Could not resolve hostname" error (when using wrappers) or a "proxy handshake error" (when using --proxy), indicating it cannot resolve or correctly initiate the connection for the .onion address via the proxy. The verbose traceback confirms the failure occurs during the initial check_target_availability due to the inability to resolve the hostname.

Possible Cause

It appears WPScan (or its underlying Ruby networking libraries/libcurl usage) attempts standard DNS resolution before or instead of passing the hostname to the SOCKS5 proxy for resolution. This standard resolution fails for .onion addresses. Wrappers like proxychains4 and torsocks are not successfully intercepting or forcing the correct resolution behavior for WPScan in this specific scenario, potentially due to the way WPScan performs its initial network checks. The behavior differs from curl --socks5-hostname, which explicitly handles this correctly.