Do we check for /wp-content/debug.log?

As described here: http://codex.wordpress.org/Editing_wp-config.php#Configure_Error_Log

http://jannefi.blogspot.fi/2012/09/xss-vulnerability-in-multiple-premium.html

Hi,

I used "p!" to enumerate only vulnerable plugins and noticed two minor curiosities.

1. It is confusing that "count-per-day" is listed as the installed version is higher than the versions having vulnerabilities.
2. Why is slimbox listed but no reference given?

I expected that only vulnerable plugins would be listed in the result.
btw: the coloring is very nice =)

[+] Enumerating installed plugins (only vulnerable ones) ...

Checking for 270 total plugins... 100% complete.

[+] We found 3 plugins:

 | Name: count-per-day v3.2.4
 | Location: http://example.com/wp-content/plugins/count-per-day/
 | Readme: http://example.com/wp-content/plugins/count-per-day/readme.txt
 |
 | [!] Count Per Day 3.2.3 Cross Site Scripting
 | * Reference: http://packetstormsecurity.org/files/115904
 |
 | [!] Count Per Day 3.1.1 Cross Site Scripting
 | * Reference: http://packetstormsecurity.org/files/114787/SSCHADV2012-015.txt
 |
 | [!] Count Per Day plugin = 3.1.1 Multiple Vulnerabilities
 | * Reference: http://www.exploit-db.com/exploits/18355/
 |
 | [!] Count per Day plugin = 2.17 SQL Injection Vulnerability
 | * Reference: http://www.exploit-db.com/exploits/17857/

 | Name: nextgen-gallery
 | Location: http://example.com/wp-content/plugins/nextgen-gallery/
 | Readme: http://example.com/wp-content/plugins/nextgen-gallery/readme.txt
 | Changelog: http://example.com/wp-content/plugins/nextgen-gallery/changelog.txt
 |
 | [!] XSS in NextGEN Gallery = 1.5.1
 | * Reference: http://www.exploit-db.com/exploits/12098/

 | Name: slimbox v1.0.6
 | Location: http://example.com/wp-content/plugins/slimbox/
 | Readme: http://example.com/wp-content/plugins/slimbox/readme.txt

root@bt:/pentest/web/wpscan# ./wpscan.rb --url http://blog.mirrorbooks.com/wpmain/

\ \ / / __ \ / |
\ \ /\ / /| |**) | (** ___ __ _ _ __
\ / / / | **/ ** \ / |/ ` | ' \
\ /\ / | | __) | (**| (| | | | |
/ / || |/ _|**,|| |_| v2.0r6dc09e7

WordPress Security Scanner by the WPScan Team

Sponsored by the RandomStorm Open Source Initiative

[ERROR] invalid byte sequence in UTF-8
Trace : ["/pentest/web/wpscan/lib/wpscan/wp_target.rb:87:in []'", "/pentest/web/wpscan/lib/wpscan/wp_target.rb:87:inwp_content_dir'", "./wpscan.rb:83:in `

root@bt:/pentest/web/wpscan# ruby -v
ruby 1.9.2dev (2010-07-02) [i486-linux]

root@bt:/pentest/web/wpscan# gem -v
1.3.7

root@bt:/pentest/web/wpscan# gem list

*** LOCAL GEMS ***

abstract (1.0.0)
actionmailer (3.0.6)
actionpack (3.0.6)
activemodel (3.0.6)
activerecord (3.0.6)
activeresource (3.0.6)
activesupport (3.0.6)
addressable (2.2.8)
ansi (1.4.3)
arel (2.0.9)
bson (1.5.2)
bson_ext (1.5.2)
builder (2.1.2)
bundler (1.1.5, 1.0.13)
childprocess (0.3.3)
daemons (1.1.9)
data_objects (0.10.8)
diff-lcs (1.1.2)
dm-core (1.2.0)
dm-do-adapter (1.2.0)
dm-migrations (1.2.0)
dm-sqlite-adapter (1.2.0)
do_sqlite3 (0.10.8)
em-resolv-replace (1.1.2)
em-websocket (0.3.8)
erubis (2.7.0, 2.6.6)
eventmachine (0.12.10)
factory_girl (1.3.3)
ffi (1.0.11)
fxruby (1.6.25)
hpricot (0.8.6)
http_configuration (1.0.4)
i18n (0.5.0)
jsmin (1.0.1)
json (1.7.5, 1.7.4, 1.6.5)
librex (0.0.68)
libwebsocket (0.1.3)
mail (2.2.19)
mime-types (1.19, 1.17.2, 1.16)
mini_exiftool (1.3.1)
mongo (1.5.2)
msfrpc-client (1.0.1)
msgpack (0.4.7)
multi_json (1.3.6)
mysql (2.8.1)
nokogiri (1.5.5, 1.4.4)
parseconfig (1.0.2)
polyglot (0.3.1)
rack (1.4.1, 1.2.2)
rack-mount (0.6.14)
rack-protection (1.2.0)
rack-test (0.5.7)
rails (3.0.6)
railties (3.0.6)
rake (0.8.7)
rchardet (1.3)
RedCloth (4.2.5)
rspec (2.5.0)
rspec-core (2.5.2)
rspec-expectations (2.5.0)
rspec-mocks (2.5.0)
rspec-rails (2.5.0)
rubyzip (0.9.6.1)
selenium-webdriver (2.24.0)
sinatra (1.3.2)
spider (0.4.4)
sqlite3-ruby (1.2.5)
term-ansicolor (1.0.7)
thin (1.4.1)
thor (0.14.6)
tilt (1.3.3)
treetop (1.4.9)
typhoeus (0.4.2, 0.3.3, 0.2.4)
tzinfo (0.3.27)
watobo (0.9.8.724)
xml-simple (1.1.1, 1.1.0)
zip (2.0.2)
root@bt:/pentest/web/wpscan#

Some time ago, I discussed with @gbrindisi about the implementation of a wpscan detector for Wordpot. However, and he was right, it's not the goal of Wordpot to do that.

So, it could be nice to implement this in wpstools.

The aim is to, by giving the HTTP server log file to wpstools, be able to output the time and IP of each detected scan done by wpscan on the server

The passive plugin detection fails with this kind of url in the source (it should not be detected as a plugin)

<script type='text/javascript' src='http://www.target.com/wp-content/plugins/home/user/public_html/wp-content/themes/bigcity/easy-fancybox/fancybox/jquery.easing-1.3.pack.js'></script>

Would be great to have a tool to generate a full list of all wordpress plugins from http://plugins.svn.wordpress.org/ (instead of the top XXX Plugins)

Will have a look at this tomorrow

hello,

I am running wpscan.rb as follows to enumerate all the plugins on the target wordpress:

sudo ruby ./wpscan.rb --url http://target.com/ --enumerate p

Based on my understanding, if it shows the output as below:

Name: wp-table
Location: http://www.targetsite.com/wp-content/plugins/wp-table/

[!] plugin wp-Table = 1.43 (inc_dir) RFI Vulnerability

• Reference exploit link

Name: wp-table-reloaded
Location: http://targetsite.com/wp-content/plugins/wp-table-reloaded/

then it means,

It found the plugin wp-table (which may have an RFI Vulnerability) and it detected another plugin, wp-table-reloaded.

However, when I check the actual path of these plugins in the browser, I am redirected to the home page of the main site.

So, I guess, the script is detecting these as valid plugins because of the 200 Ok response detected?

But these are all false positives.

Reason being,

there was a passive detection performed by the script as well on the same target site which detected the plugin:

wp-contact-form7

path: http://targetsite.com/wp-content/plugins/wp-contact-form7/

Now, when I open this link in the browser, it shows a 403 forbidden message. This means the plugin does exist indeed.

So, the path of the plugins: /wp-content/plugins/ is correct.

To test it further, I opened the following path in Browser:

http://targetsite.com/wp-content/plugins/this-is-not-a-plugin/

and it returns a 200 Ok response and I am back at the main site.

So, I guess, we need a way to prevent these false positives.

It may not always return a 404 Not Found response if the plugin does not exist as can be seen in this case.

I wanted to test on my word press
and
after enter the code for brute it runs but for awhile it gives error:we revived an unknown response for 057124c34n
and unknown response for 0706124phic41

is this mean my wordpress is well protected?

I'm calling BS on this one [0] for two reasons:

1. The authors are notorious for releasing fake advisories.
2. The files they claim are vulnerable (topic.php, forum.php) do not exist [1].

[0] http://packetstormsecurity.org/files/116123
[1] http://plugins.svn.wordpress.org/bbpress/trunk/

Thoughts?

At this time, the variable replacement in url is done in the browser, however, in at least one case, the replacement can't be done like that because the url is just displayed (ie : 99b1fb2) and not called with the browser

There are 2 variables : $wp-content$ and $wp-plugin$

We must find a way to do it neatly.

Hi, this is really a great tool, thank you for developing it. I have two issues.

One, I used wpscan on virtual machine running latest BackTrack and everything was fine, but now I run it on vps with ubuntu, and when enumerating plugins, I get this error:
[ERROR] can't convert wpPlugin into String

How to fix that?

Second question/issue happened on both installations, when I use tool to fetch latest plugins list, I get the result, fetched xxxx plugins, but then what? It just sits there, and when I check plugins.txt list it's tstill the same. Should I wait more? Will there be a confirmation that it is done?

Thank you!

I'm unable to reproduce this vulnerability : http://www.exploit-db.com/exploits/18126/

Btw, it has not been verified on exploit-db

Should we remove it ?

I was looking for more places where we could get the WP version from.

The version is output within WP by calling the get_bloginfo() function with the 'version' argument.

After some greping it turns out that the 'wp-includes/general-template.php' file has quite a few of these:

switch ( $type ) {
                case 'html':
                        $gen = '<meta name="generator" content="WordPress ' . get_bloginfo( 'version' ) . '">';
                        break;
                case 'xhtml':
                        $gen = '<meta name="generator" content="WordPress ' . get_bloginfo( 'version' ) . '" />';
                        break;
                case 'atom':
                        $gen = '<generator uri="http://wordpress.org/" version="' . get_bloginfo_rss( 'version' ) . '">WordPress</generator>';
                        break;
                case 'rss2':
                        $gen = '<generator>http://wordpress.org/?v=' . get_bloginfo_rss( 'version' ) . '</generator>';
                        break;
                case 'rdf':
                        $gen = '<admin:generatorAgent rdf:resource="http://wordpress.org/?v=' . get_bloginfo_rss( 'version' ) . '" />';
                        break;
                case 'comment':
                        $gen = '<!-- generator="WordPress/' . get_bloginfo( 'version' ) . '" -->';
                        break;
                case 'export':
                        $gen = '<!-- generator="WordPress/' . get_bloginfo_rss('version') . '" created="'. date('Y-m-d H:i') . '" -->';
                        break;
        }

Some of these are what look like different types of 'feeds'. To get the feed URLs with the following functions:

<?php bloginfo('rdf_url'); ?>
<?php bloginfo('rss_url'); ?>
<?php bloginfo('rss2_url'); ?>
<?php bloginfo('atom_url'); ?>
<?php bloginfo('comments_rss2_url'); ?>

Which output on my blog as:

http://www.ethicalhack3r.co.uk/feed/rdf/
http://www.ethicalhack3r.co.uk/feed/rss/
http://www.ethicalhack3r.co.uk/feed/
http://www.ethicalhack3r.co.uk/feed/atom/
http://www.ethicalhack3r.co.uk/comments/feed/

So we now have more places to get versions from! :D

Backtrack still have an old version of Wordpress installed with svn, we should point out a basic step-by-step on how to do the upgrade to git and point it out on our homepage.

I am not sure on the step-by-step, I think just wipe and clone the repo again in the actual wpscan dir should do the trick but I don't have Backtrack around to test right now.

(I received a mail asking help about this very issue)

[ERROR] cannot load such file -- readline
[TIP] Try to run 'gem install readline' or 'gem install --user-install readline'. If you still get an error, Please see README file or https://github.com/wpscanteam/wpscan

should read:

[TIP] Try to run 'gem install rb-readline' or 'gem install --user-install rb-readline'. If you still get an error, Please see README file or https://github.com/wpscanteam/wpscan

To better understand the load of traffic we should expect from the web api we are building it would be great to have some stats about our updating mechanism.

I would be more than happy to know simple things like update requests per day and nothing more.
For example by just making a request to a stat script before pulling from our git repository:

def update
  Typhoeus::Request.new('http://wpscan.org/dummy_hit_counter')
  %x[git #{repo_directory_arguments()} pull]
end

But while talking about this @ethicalhack3r pointed out (rightfully) that even a basic tracker might be perceived badly by our users.

So the questions are:

• What do you think?
• Can you suggest a better way to handle this?

Implement a feature similar to the enumerate plugins to enumerate currently installed themes.

SVN Repo of Wordpress Themes:
http://themes.svn.wordpress.org/

It appears that the proxy support only works for HTTP proxies, not for SOCKS proxies, like privoxy and Tor combined. It would be nice/useful to have SOCKS proxy support added

Since most Plugins provide the Files "readme.txt" and "changelog.txt" in their Plugin root, it would be great if wpscan can detect these (in passive and in enumerating mode).
By reading these files it is possible to determine the currently used plugin version. This feature is great to verify the reported plugin vulns. Although this step must be done manually.

I've tried both gem install nokogiri and gem install --user-install nokogiri, but I still get the "cannot load such file -- nokogiri

Any thoughts on how to fix this? Running Ubuntu 12.04.1, ruby 1.9.3p0 Thank you.

Version detection fails on this readme because of some curious line breaks:

http://plugins.svn.wordpress.org/configurable-tag-cloud-widget/trunk/readme.txt

Need to adapt the Regex

Hello.
I´m having issues. When I type in Terminal (without quotes):" ruby ./wpscan.rb --url www.example.com "
I get this: " ruby: No such file or directory -- ./wpscan.rb (LoadError) "

I try different:
localhost:~ tatolc$ sudo ./wpscan.rb
Password:
sudo: ./wpscan.rb: command not found
localhost:~ tatolc$ sudo ./wpscan.rb
sudo: ./wpscan.rb: command not found
localhost:~ tatolc$ ruby wpscan.rb
ruby: No such file or directory -- wpscan.rb (LoadError)
localhost:~ tatolc$ sudo ruby wpsacn.rb

ruby: No such file or directory -- wpsacn.rb (LoadError)

I´m on a mac 10.7.4 and this is my information:

ruby -v

ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.4.0]

gem -v

1.8.24

*** LOCAL GEMS ***
actionmailer (3.2.6)
actionpack (3.2.6)
activemodel (3.2.6)
activerecord (3.2.6)
activeresource (3.2.6)
activesupport (3.2.6)
arel (3.0.2)
builder (3.0.0)
bundler (1.1.5)
erubis (2.7.0)
ffi (1.1.0)
hike (1.2.1)
i18n (0.6.0)
journey (1.0.4)
json (1.7.3)
mail (2.4.4)
mime-types (1.19)
minitest (3.2.0)
multi_json (1.3.6)
nokogiri (1.5.5)
polyglot (0.3.3)
rack (1.4.1)
rack-cache (1.2)
rack-ssl (1.3.2)
rack-test (0.6.1)
rails (3.2.6)
railties (3.2.6)
rake (0.9.2.2)
rdoc (3.12)
sprockets (2.1.3)
thor (0.15.4)
tilt (1.3.3)
treetop (1.4.10)
typhoeus (0.4.2)
tzinfo (0.3.33)

xml-simple (1.1.1)

gem env
RubyGems Environment:

• RUBYGEMS VERSION: 1.8.24
• RUBY VERSION: 1.9.3 (2012-04-20 patchlevel 194) [x86_64-darwin11.4.0]
• INSTALLATION DIRECTORY: /Users/xxx/.rvm/gems/ruby-1.9.3-p194
• RUBY EXECUTABLE: /Users/xxx/.rvm/rubies/ruby-1.9.3-p194/bin/ruby
• EXECUTABLE DIRECTORY: /Users/xxx/.rvm/gems/ruby-1.9.3-p194/bin
• RUBYGEMS PLATFORMS:
  • ruby
  • x86_64-darwin-11
• GEM PATHS:
  • /Users/xxx/.rvm/gems/ruby-1.9.3-p194
  • /Users/xxx/.rvm/gems/ruby-1.9.3-p194@global
• GEM CONFIGURATION:
  • :update_sources => true
  • :verbose => true
  • :benchmark => false
  • :backtrace => false
  • :bulk_threshold => 1000
• REMOTE SOURCES:
  • http://rubygems.org/

Well, I hope you can help me. Thanks for your time!

The current suggestion is to rewrite the order of parameters to prevent the "event not found" error, but this won´t work when using p! and T! simultaneously.

A workaround is to escape the exclamation marks: "--enumerate p!T!"

But perhaps it´s even better to use "P" for all plugins and "p" for the vulnerable ones?

Some pages return a HTTP 200 with a specific error page on 404 and 403 errors.
There should be an option to test for this error page to filter out false positives.

Example:
plugins.txt contains a url with "plugin/admin.php" and "admin.php" is blocked with custom error page and http 200 by some IDS/IPS --> Many false positives

Sometimes there are self-written wordpress plugins on a blog (mostly commercial sites). When this plugin is included in a subpage, it is not detected by passive plugin enumeration, because passive plugin detection only scans the start page.

So i thought about a new option "advanced plugin enumeration" that fetches a sitemap, feed or another source with links and does a passive detection on this sites too.

What do you think about this idea?

Links can be gathered from:
sitemap.xml (seperate plugin)
/feed/

other locations where to search for urls??? (i do not want to use a crawler for this)

output a line if the wp instance is a multisite enabled installation
Maybe there are better ways to check but found this hint:

wp-signup.php is always used when multisite is enabled. If you call this site on a not multisite, you will be redirected to wp-login.php?action=register

so if there is a redirect wo wp-login.php when calling wp-signup --> no multisite, otherwise multisite

A site I'm testing has the following in the /feed dir:

http://wordpress.org/?v=458

Which is causing a false positive as 458 is not a valid WordPress version.

I've noticed that we're using "WpVersion.version_pattern" in:

find_from_readme
find_from_sitemap_generator
find_from_links_opml

But not in:

find_from_meta_generator
find_from_rss_generator

Is there a reason for this or can I go ahead and add it to them?

cc @erwanlr, @gbrindisi

Hi...

First thanks for that kind of tool!

When i try to update full list of plugins or themes it's give error. But generate list with --gpl or --gtl working. I need full list.

ruby -v => ruby 1.9.2dev (2010-07-02) [i486-linux]
wpscan version => v2.0r9785c81

Note: Os is BackTrack 5 R3

./wpstools.rb --gfpl

[ERROR] bad URI(is not URI?): http://plugins.svn.wordpress.org/addthischina-收藏分享按钮插件/
Trace :
/usr/lib/ruby/1.9.2/uri/common.rb:156:in `split'
/usr/lib/ruby/1.9.2/uri/common.rb:174:in `parse'
/usr/lib/ruby/1.9.2/uri/common.rb:628:in `parse'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.3.3/lib/typhoeus/request.rb:116:in `initialize'
/pentest/web/wpscan/lib/browser.rb:143:in `new'
/pentest/web/wpscan/lib/browser.rb:143:in `forge_request'
/pentest/web/wpscan/lib/wpstools/parse_svn.rb:62:in `block in get_svn_project_urls'
/pentest/web/wpscan/lib/wpstools/parse_svn.rb:60:in `each'
/pentest/web/wpscan/lib/wpstools/parse_svn.rb:60:in `get_svn_project_urls'
/pentest/web/wpscan/lib/wpstools/parse_svn.rb:38:in `parse'
/pentest/web/wpscan/lib/wpstools/generate_list.rb:49:in `generate_full_list'


./wpstools.rb --gftl

[ERROR] bad URI(is not URI?): http://themes.svn.wordpress.org/anypixelpixel中文版/
Trace :
/usr/lib/ruby/1.9.2/uri/common.rb:156:in `split'
/usr/lib/ruby/1.9.2/uri/common.rb:174:in `parse'
/usr/lib/ruby/1.9.2/uri/common.rb:628:in `parse'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.3.3/lib/typhoeus/request.rb:116:in `initialize'
/pentest/web/wpscan/lib/browser.rb:143:in `new'
/pentest/web/wpscan/lib/browser.rb:143:in `forge_request'
/pentest/web/wpscan/lib/wpstools/parse_svn.rb:62:in `block in get_svn_project_urls'
/pentest/web/wpscan/lib/wpstools/parse_svn.rb:60:in `each'
/pentest/web/wpscan/lib/wpstools/parse_svn.rb:60:in `get_svn_project_urls'
/pentest/web/wpscan/lib/wpstools/parse_svn.rb:38:in `parse'
/pentest/web/wpscan/lib/wpstools/generate_list.rb:49:in `generate_full_list'
./wpstools.rb:103:in `<main>'

Is it worth having this file? I don't see any value in it.

Thoughts?

Hello,

I have updated wpscan to the latest version using the git repository. I am using Backtrack 5 R1, but I think it should not be a problem since I am using the latest version of wpscan.rb. When I start a scan on a site using the following command line:

ruby ./wpscan.rb --url http://t4rg3t.c0m --enumerate p

This is the the error message:

[ERROR] no marshal_dump is defined for class Proc
Trace :
/pentest/web/wpscan/lib/cache_file_store.rb:61:in dump' /pentest/web/wpscan/lib/cache_file_store.rb:61:inblock in write_entry'
/pentest/web/wpscan/lib/cache_file_store.rb:60:in open' /pentest/web/wpscan/lib/cache_file_store.rb:60:inwrite_entry'
/pentest/web/wpscan/lib/browser.rb:116:in block in setup_cache_handlers' /root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/hydra.rb:214:incall'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/hydra.rb:214:in handle_request' /root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/hydra.rb:187:inblock in get_easy_object'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/easy.rb:332:in call' /root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/easy.rb:332:infailure'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/multi.rb:21:in multi_perform' /root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/multi.rb:21:inperform'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/hydra.rb:95:in run' /pentest/web/wpscan/lib/wpscan/modules/wp_config_backup.rb:43:inconfig_backup'
./wpscan.rb:130:in `

It first detects the theme, FPD and locates the readme.html file before showing this error message.

I next tried to update the version of typhoeus using the command line:

sudo gem update typhoeus

here is the output:

Updating installed gems
Updating typhoeus
Building native extensions. This could take a while...
Successfully installed ffi-1.1.5
Successfully installed mime-types-1.19
Successfully installed typhoeus-0.4.2
Gems updated: ffi, mime-types, typhoeus
Installing ri documentation for ffi-1.1.5...
Before reporting this, could you check that the file you're documenting
compiles cleanly--RDoc is not a full Ruby parser, and gets confused easily if
fed invalid programs.

The internal error was:

(ArgumentError) unknown encoding name - "UTF-8"?>

ERROR: While executing gem ... (ArgumentError)
unknown encoding name - "UTF-8"?>

Even though it says that it has successfully installed the new version, it throws an error while installing the ri documentation.

I ran the wpscan.rb once again to confirm if it works now or not:

and I get the same error message:

ERROR] no marshal_dump is defined for class Proc
Trace :
/pentest/web/wpscan/lib/cache_file_store.rb:61:in dump' /pentest/web/wpscan/lib/cache_file_store.rb:61:inblock in write_entry'
/pentest/web/wpscan/lib/cache_file_store.rb:60:in open' /pentest/web/wpscan/lib/cache_file_store.rb:60:inwrite_entry'
/pentest/web/wpscan/lib/browser.rb:116:in block in setup_cache_handlers' /root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/hydra.rb:214:incall'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/hydra.rb:214:in handle_request' /root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/hydra.rb:187:inblock in get_easy_object'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/easy.rb:332:in call' /root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/easy.rb:332:infailure'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/multi.rb:21:in multi_perform' /root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/multi.rb:21:inperform'
/root/.gem/ruby/1.9.2/gems/typhoeus-0.2.4/lib/typhoeus/hydra.rb:95:in run' /pentest/web/wpscan/lib/wpscan/modules/wp_config_backup.rb:43:inconfig_backup'

Any help would be appreciated to solve this issue.

http://wpforce.com/ publishes a vuln report every month.
Would be great if this infos can be merged in the vulns.xml file.

Example:
http://wpforce.com/wordpress-security-threats-sep2012/

When the trailing slash is missing in the target url, wpscan asks if we want to follow the redirection. It should not happen.

Ie : --url http://localhost/wordpress will try to redirect to http://localhost/wordpress/

Reported by erwan:

"The brute force does no longer work because of this :

Start the brute forcer

bruteforce = false
and because the usernames variable is no more an array of usernames but an array of hashes.

Btw, do we really need to know other thing than the username and maybe the id ?

If you still plan to use all these information, it could be easier to create a wp_user class instead of an array of hashes for each user ;)"

@thesp0nge asked: "Another question guys... is there some background decision on about not creating wpscan as a rubygem? I think packing the scanner in a standard rubish CLI way can be a great deal don't you?"

Hello,

I get this error when i try to list Themes on my wordpress.

[+] Enumerating installed plugins ...

[ERROR] undefined method sort_by!' for #<Array:0x7fc64c3fd800> Trace : /opt/wpscan/lib/wpscan/wp_enumerator.rb:135:ingenerate_items'
/opt/wpscan/lib/wpscan/wp_enumerator.rb:37:in enumerate' /opt/wpscan/lib/wpscan/wp_detector.rb:29:inaggressive_detection'
/opt/wpscan/lib/wpscan/modules/wp_plugins.rb:30:in `plugins_from_aggressive_detection'
./wpscan.rb:212

I didn't find issue like that so i posted new one.

I'm on Debian 6. Up to date.

We should add an argument --conf | -c in order to let the user choose another config file to use

Hi,

the installation instructions for Debian seem to be missing something.

I followed these instructions:

sudo apt-get install libcurl4-gnutls-dev libopenssl-ruby libxml2 libxml2-dev libxslt1-dev
sudo gem install bundler && bundle install

But I get:

Successfully installed bundler-1.2.1
1 gem installed
Installing ri documentation for bundler-1.2.1...
Installing RDoc documentation for bundler-1.2.1...
-bash: bundle: command not found

Debian 6.0.6
ruby 4.5
curl 7.21.0

Lars

Yesterday was pointed out on twitter that would be cool to have a way to check from wpscan if a given plugin was vulnerable or not (without scanning).

As said this would be easily solvable by building a public api interfacing with our db and have, at least at the beginning, wpscan as an interactive client.

What do you think?

I think I can put up a basic API quickly if we are interested (finally coding! :).

I've finished the ConsoleOutput class, however the brute forcer is not testable at all and in the current state not clean, given the fact that the results are outputted during the process.

The method brute_force should return at least an array with the (username, password) found. The problem is the verbose and errors output, how to handle them ? return them with the results ?

I guess the method could return an array of login_result or brute_force_result, and the errors would be stored in those objects (yea i think it's the best way)
However, with this, the verbose will be deleted, and results will be outputted at the end of the full brute force, and not after each brute force like now :s (it's not a problem for a small wordlist, but for huge one, well ... xD)

Any ideas ? :x

There have been a lot of changes so I think we will need to test everything before we support it.

I'll update the Gemfile so that users don't install it yet.

As per the http://nokogiri.org/tutorials/installing_nokogiri.html page, could you add in these packages for debian/ubuntu installs
sudo apt-get install libxslt-dev libxml2-dev

^_^[root@Phoenix:/pentest/web/wpscan]# ruby wpscan.rb
[ERROR] no such file to load -- typhoeus
[TIP] Try to run 'gem install typhoeus' or 'gem install --user-install typhoeus'. If you still get an error, Please see README file or http://code.google.com/p/wpscan/

O_O[root@Phoenix:/pentest/web/wpscan]# apt-get install libcurl4-gnutls-dev libopenssl-ruby
Reading package lists... Done
Building dependency tree
Reading state information... Done
libcurl4-gnutls-dev is already the newest version.
libopenssl-ruby is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 50 not upgraded.

^_^[root@Phoenix:/pentest/web/wpscan]# gem install typhoeus nokogiri json
Successfully installed typhoeus-0.4.2
Building native extensions. This could take a while...
Successfully installed nokogiri-1.5.5
Building native extensions. This could take a while...
Successfully installed json-1.7.3
3 gems installed
Installing ri documentation for typhoeus-0.4.2...
Installing ri documentation for nokogiri-1.5.5...
Installing ri documentation for json-1.7.3...
Installing RDoc documentation for typhoeus-0.4.2...
Installing RDoc documentation for nokogiri-1.5.5...
Installing RDoc documentation for json-1.7.3...

^_^[root@Phoenix:/pentest/web/wpscan]# ruby wpscan.rb
[ERROR] no such file to load -- typhoeus
[TIP] Try to run 'gem install typhoeus' or 'gem install --user-install typhoeus'. If you still get an error, Please see README file or http://code.google.com/p/wpscan/

Added support for bundler on my themes branch for easier install.

Install steps on ubuntu are now:

sudo apt-get install build-essential libxslt-dev libxml2-dev libcurl3-dev
gem install bundler
bundle install

Issue only for documentation

What steps will reproduce the problem?

1. Running BT5 R3. Updated Wpscan to 425 from github repository.
2. Prompted to run nokogiri update. Ran successfully.
3. Entered ./wpscan.rb --url mycompany.com

What is the expected output? What do you see instead?

[ERROR] invalid byte sequence in UTF-8
Trace : ["/pentest/web/wpscan/lib/wpscan/wp_target.rb:92:in []'", "/pentest/web/wpscan/lib/wpscan/wp_target.rb:92:inwp_content_dir'", "./wpscan.rb:83:in
`< main >'"]

What version of the product are you using? On what operating system?
BT5 R3 rev 425

What command and flags did you run WPScan with?
--url

Please provide the output of:

$ruby -v
ruby 1.9.2dev

$gem -v
1.3.7

$gem list
*** LOCAL GEMS ***

abstract (1.0.0)
actionmailer (3.0.6)
actionpack (3.0.6)
activemodel (3.0.6)
activerecord (3.0.6)
activeresource (3.0.6)
activesupport (3.0.6)
addressable (2.2.8)
arel (2.0.9)
bson (1.5.2)
bson_ext (1.5.2)
builder (2.1.2)
bundler (1.0.13)
childprocess (0.3.3)
diff-lcs (1.1.2)
em-resolv-replace (1.1.2)
erubis (2.6.6)
factory_girl (1.3.3)
ffi (1.0.11)
fxruby (1.6.25)
hpricot (0.8.6)
http_configuration (1.0.4)
i18n (0.5.0)
json (1.7.4, 1.6.5)
libwebsocket (0.1.3)
mail (2.2.19)
mime-types (1.17.2, 1.16)
mini_exiftool (1.3.1)
mongo (1.5.2)
multi_json (1.3.6)
mysql (2.8.1)
nokogiri (1.5.5, 1.4.4)
polyglot (0.3.1)
rack (1.2.2)
rack-mount (0.6.14)
rack-test (0.5.7)
rails (3.0.6)
railties (3.0.6)
rake (0.8.7)
rchardet (1.3)
RedCloth (4.2.5)
rspec (2.5.0)
rspec-core (2.5.2)
rspec-expectations (2.5.0)
rspec-mocks (2.5.0)
rspec-rails (2.5.0)
rubyzip (0.9.6.1)
selenium-webdriver (2.24.0)
spider (0.4.4)
sqlite3-ruby (1.2.5)
thor (0.14.6)
treetop (1.4.9)
typhoeus (0.3.3, 0.2.4)
tzinfo (0.3.27)
watobo (0.9.8.724)
xml-simple (1.1.1, 1.1.0)
zip (2.0.2)

Please provide any additional information below.
Worked fine before updating.

Hello,
i got error when excute :~# ruby wpscan.rb --url testing.com --enumerate

[+] Enumerating installed plugins (only vulnerable ones) ...

Checking for 262 total plugins... 100% complete.

[+] We found 1 plugins:

[ERROR] expected SCALAR, SEQUENCE-START, MAPPING-START, or ALIAS
Trace : ["/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:24:in scalar'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:24:invisit_Psych_Nodes_Scalar'", "/usr/lib/ruby/1.9.1/psych/visitors/visitor.rb:15:in visit'", "/usr/lib/ruby/1.9.1/psych/visitors/visitor.rb:5:inaccept'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:35:in block in visit_Psych_Nodes_Mapping'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:35:ineach'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:35:in visit_Psych_Nodes_Mapping'", "/usr/lib/ruby/1.9.1/psych/visitors/visitor.rb:15:invisit'", "/usr/lib/ruby/1.9.1/psych/visitors/visitor.rb:5:in accept'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:19:inblock in visit_Psych_Nodes_Document'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:19:in each'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:19:invisit_Psych_Nodes_Document'", "/usr/lib/ruby/1.9.1/psych/visitors/visitor.rb:15:in visit'", "/usr/lib/ruby/1.9.1/psych/visitors/visitor.rb:5:inaccept'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:13:in block in visit_Psych_Nodes_Stream'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:13:ineach'", "/usr/lib/ruby/1.9.1/psych/visitors/emitter.rb:13:in visit_Psych_Nodes_Stream'", "/usr/lib/ruby/1.9.1/psych/visitors/visitor.rb:15:invisit'", "/usr/lib/ruby/1.9.1/psych/visitors/visitor.rb:5:in accept'", "/usr/lib/ruby/1.9.1/psych/nodes/node.rb:46:into_yaml'", "/usr/lib/ruby/1.9.1/psych.rb:190:in dump'", "/opt/pentest/wpscan/lib/cache_file_store.rb:43:inblock in write_entry'", "/opt/pentest/wpscan/lib/cache_file_store.rb:42:in open'", "/opt/pentest/wpscan/lib/cache_file_store.rb:42:inwrite_entry'", "/opt/pentest/wpscan/lib/browser.rb:118:in block in setup_cache_handlers'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/hydra.rb:216:incall'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/hydra.rb:216:in handle_request'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/hydra.rb:187:inblock in get_easy_object'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/easy/callbacks.rb:7:in call'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/easy/callbacks.rb:7:insuccess'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/multi.rb:110:in read_info'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/multi.rb:136:inrun'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/multi.rb:83:in perform'", "/var/lib/gems/1.9.1/gems/typhoeus-0.4.2/lib/typhoeus/hydra.rb:95:inrun'", "/opt/pentest/wpscan/lib/browser.rb:193:in run_request'", "/opt/pentest/wpscan/lib/browser.rb:133:inget'", "/opt/pentest/wpscan/lib/wpscan/wp_plugin.rb:47:in version'", "/opt/pentest/wpscan/lib/wpscan/wp_plugin.rb:52:into_s'", "wpscan.rb:192:in block in <main>'", "wpscan.rb:190:ineach'", "wpscan.rb:190:in `

am using lastest wpscan v2.0r12587e6, anyone know how to solve this?

When wpscan find a huge debug.log (tested with Length: 5077697265 (4,7G) [text/plain]), it try to get all the content of the file so it's a bit long xD, and it seems to crash w/o error (no more network activity)

Any idea about how to get only few bytes from a file with Typhoeus ? :D

cc @ethicalhack3r

I found this : http://www.cvedetails.com/version-list/2337/4096/1/Wordpress-Wordpress.html

Might be useful ;)

cc @gbrindisi @ethicalhack3r

New Feature:
wpscan should be able to detect if user registration is enabled.
due to localization, this must be accomplished via the redirect after calling wp_register.php or wp_login?action=register.
Maybe there are more registration methods and urls. Need to work through the wordpress docs....