stack trace on site down

digininja commented 8 years ago

I don't know what caused the problem as the site was still up when I checked straight after this happened. The run seemed to recover enough to close properly as you can see from the last line but I don't think it should have dumped the stack trace in the middle of the output.

Running the latest from Github with fully updated plugins.

[+] Enumerating installed plugins (only ones marked as popular) ...

  : |=========================================================================================/opt/tools/web/wpscan/lib/wpscan/wpscan_helper.rb:127:in `block in <top (required)>': The target seems to be down (RuntimeError)
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/callbacks.rb:128:in `call'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/callbacks.rb:128:in `block in execute_callbacks'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/callbacks.rb:127:in `each'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/callbacks.rb:127:in `execute_callbacks'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/operations.rb:35:in `finish'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/easy_factory.rb:159:in `block in set_callback'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/easy/response_callbacks.rb:65:in `call'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/easy/response_callbacks.rb:65:in `block in complete'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/easy/response_callbacks.rb:65:in `each'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/easy/response_callbacks.rb:65:in `complete'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/multi/operations.rb:151:in `check'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/multi/operations.rb:164:in `run'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/multi/operations.rb:43:in `perform'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/hydra/runnable.rb:15:in `run'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/hydra/memoizable.rb:51:in `run'
        from ./wpscan.rb:470:in `ensure in main'
        from ./wpscan.rb:470:in `main'
        from ./wpscan.rb:474:in `<main>'

[!] The target seems to be down

digininja commented 8 years ago

Gone down again on the same site but with a different scan type

  : |==================================================================/opt/tools/web/wpscan/lib/wpscan/wpscan_helper.rb:127:in `block in <top (required)>': The target seems to be down (RuntimeError)
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/callbacks.rb:128:in `call'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/callbacks.rb:128:in `block in execute_callbacks'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/callbacks.rb:127:in `each'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/callbacks.rb:127:in `execute_callbacks'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/request/operations.rb:35:in `finish'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/easy_factory.rb:159:in `block in set_callback'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/easy/response_callbacks.rb:65:in `call'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/easy/response_callbacks.rb:65:in `block in complete'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/easy/response_callbacks.rb:65:in `each'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/easy/response_callbacks.rb:65:in `complete'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/multi/operations.rb:151:in `check'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/multi/operations.rb:164:in `run'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/ethon-0.9.0/lib/ethon/multi/operations.rb:43:in `perform'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/hydra/runnable.rb:15:in `run'
        from /usr/local/rvm/gems/ruby-2.2.1/gems/typhoeus-1.0.2/lib/typhoeus/hydra/memoizable.rb:51:in `run'
        from ./wpscan.rb:470:in `ensure in main'
        from ./wpscan.rb:470:in `main'
        from ./wpscan.rb:474:in `<main>'
./wpscan.rb: [BUG] Segmentation fault at 0x007fda34b795c7
ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0001 p:0000 s:0002 E:002330 TOP    [FINISH]

-- Machine register context ------------------------------------------------
 RIP: 0x00007fda34b795c7 RBP: 0x0000000002d454e8 RSP: 0x00007fda28df2ea0
 RAX: 0x0000000000000000 RBX: 0x0000000002d454e8 RCX: 0x00007fda28df2eb0
 RDX: 0x0000000000000000 RDI: 0x0000000000000000 RSI: 0x0000000000000000
  R8: 0x0000000000000003  R9: 0x00007fda28df2c70 R10: 0x0000000000000000
 R11: 0x0000000002d45510 R12: 0x0000000002d454d0 R13: 0x00007fda39cf0060
 R14: 0x0000000002d454d0 R15: 0x00007fda28df3700 EFL: 0x0000000000010202

-- C level backtrace information -------------------------------------------

[!] The target seems to be down

ethicalhack3r commented 8 years ago

Could the site be not responding to some requests due to load (flakey server)? It might be worth decreasing the number of threads WPScan uses, I think the default is 10. Option is --threads

digininja commented 8 years ago

Its more the fact you are crashing out in such a messy way that I'm reporting. Trying with a single thread now though.

ethicalhack3r commented 8 years ago

Good point, we should probably not show stack traces for this particular error as the information is not very useful here

digininja commented 8 years ago

what type of retry mechanism do you have? I hit the site with curl straight after the failure and it replied so if wpscan had retried a couple of times it would probably have been able to continue

digininja commented 8 years ago

And single threading worked for themes, trying plugins now.

ethicalhack3r commented 8 years ago

You could try proxy through Burp, then you could see if/when the server doesn't respond

digininja commented 8 years ago

Single thread worked on plugins as well. Dodgy site

digininja commented 8 years ago

might give the proxy a try later and see.

firefart commented 8 years ago

@digininja any update on this one?

ghost commented 8 years ago

This might not be interesting, but just to report that I can reproduce the same issue; it's unrelated to to server load.

backtrace

wpscan_helper.rb:127:in `block in <top (required)>': The target seems to be down (RuntimeError)
...

example.org.access.log

93.184.216.34 - - [11/Nov/2016:15:47:56 +0000] TLSv1.2/ECDHE-ECDSA-AES256-GCM-SHA384 "GET /wp-content/themes/abstract/lib/custom/thumb.php HTTP/1.1" 444 0 "https://example.org/" "WPScan v2.9.1 (http://wpscan.org)" "-"
93.184.216.34 - - [11/Nov/2016:15:47:56 +0000] TLSv1.2/ECDHE-ECDSA-AES256-GCM-SHA384 "GET /wp-content/themes/abstract/lib/custom/timthumb.php HTTP/1.1" 444 0 "https://example.org/" "WPScan v2.9.1 (http://wpscan.org)" "-"
and >100 more like that

The server returns 444s to .php$ not required to be directly accessed.

eg. here, a location block prevents direct access to .php$ below wp-content and wp-includes

example.org.conf

     location ~* (wp\-content|wp\-includes)/.*\.php$ {
         deny all;
         return 444;
     }

The scan completes successfully if 204s are sent instead. The repeated closed connections seem to be the cause which would be inline with your comments above.

The "target seems to be down" output of WPScan is right (chromium developers agree with you: "might be temporarily down")

WPScan is a lovely tool, thank you 🤓 :)

ps. WPScan header has @erwan_lr should it be @erwanlr?

.

wpscanteam / wpscan

stack trace on site down #964