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

Cannot connect to wpvulndb API when using CF-Connecting-IP header #1451

Closed
GottemHams opened this issue Feb 9, 2020 · 3 comments
Closed

Comments

@GottemHams
Copy link

Subject of the issue

When you wanna test a website that is protected by CloudFlare, you may sometimes need to pass a CF-Connecting-IP header. The WPVulnDB API itself also seems to be behind CF and wpscan is using the value from the header for that connection as well. Since CF doesn't know my server's IP as a "trusted proxy IP" for wpvulndb.com and returns a 403 instead.

Your environment

  • Version of WPScan: 3.7.7 (installed with the recommended gem install wpscan method)
  • Version of Ruby: ruby 2.6.3p62 (2019-04-16 revision 67580)
  • Operating System (OS): Debian 9 (Stretch)

Steps to reproduce

Simply add --headers 'CF-Connecting-IP: 123.123.123.123' to the wpscan call, this triggers the bug even when you're testing a site not behind CloudFlare.

Expected behavior

wpscan should probably use the --headers argument only for the connection to the actual website and not also for the API calls.

Actual behavior

Scan Aborted: HTTP Error: https://wpvulndb.com/api/v3/status?version=3.7.7 (status: 403)
Trace: /usr/local/lib/ruby/gems/2.6.0/gems/wpscan-3.7.7/lib/wpscan/db/vuln_api.rb:31:in `get'
/usr/local/lib/ruby/gems/2.6.0/gems/wpscan-3.7.7/lib/wpscan/db/vuln_api.rb:60:in `status'
/usr/local/lib/ruby/gems/2.6.0/gems/wpscan-3.7.7/app/controllers/vuln_api.rb:18:in `before_scan'
/usr/local/lib/ruby/gems/2.6.0/gems/cms_scanner-0.8.1/lib/cms_scanner/controllers.rb:46:in `each'
/usr/local/lib/ruby/gems/2.6.0/gems/cms_scanner-0.8.1/lib/cms_scanner/controllers.rb:46:in `block in run'
/usr/local/lib/ruby/2.6.0/timeout.rb:76:in `timeout'
/usr/local/lib/ruby/gems/2.6.0/gems/cms_scanner-0.8.1/lib/cms_scanner/controllers.rb:45:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/cms_scanner-0.8.1/lib/cms_scanner/scan.rb:24:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/wpscan-3.7.7/bin/wpscan:17:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/cms_scanner-0.8.1/lib/cms_scanner/scan.rb:15:in `initialize'
/usr/local/lib/ruby/gems/2.6.0/gems/wpscan-3.7.7/bin/wpscan:6:in `new'
/usr/local/lib/ruby/gems/2.6.0/gems/wpscan-3.7.7/bin/wpscan:6:in `<top (required)>'
/usr/local/bin/wpscan:23:in `load'
/usr/local/bin/wpscan:23:in `<main>'

What have you already tried

  • Update WPScan to the latest version [Y]
  • Update Ruby to the latest version [N/A (no update available)]
  • Ensure you can reach the target site using cURL [Y]
  • Proxied WPScan through a HTTP proxy to view the raw traffic [N]
  • Ensure you are using a supported Operating System (Linux and macOS) [Y]

Manual curl output:

{"success":true,"plan":"free","requests_remaining":50}
@erwanlr erwanlr closed this as completed in fb82538 Feb 9, 2020
@erwanlr
Copy link
Member

erwanlr commented Feb 9, 2020

Thanks for the report, it's fixed in master (and will be available in a bit via docker).

Once the specs are finished running, I will release a new minor version (3.7.8) with the fix.

@erwanlr
Copy link
Member

erwanlr commented Feb 9, 2020

3.7.8 released!

@GottemHams
Copy link
Author

Can confirm that it works again, thanks. =]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants