Enumerate Themes

[firefart]

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

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

[erwanlr]

Nice idea :) (the most difficult will be to find the letter for enumeration as 't' is for timthumbs :p, maybe 'h' xD)

[firefart]

Jeah I will have a look at this today ;)

[firefart]

Almost finished with rewriting the plugin / theme fetching I will commit it tomorrow

[ethicalhack3r]

Nice!

[firefart]

This will be a really big pull request. Anyone interesting in testing a new "beta"? ;)

[firefart]

would be great if you can have a pre-look at it for bugs: https://github.com/FireFart/wpscan/tree/themes

git clone -b themes git://github.com/FireFart/wpscan.git wpscan-firefart

Next thing to do is fix the rspec tests and add a documentation

[firefart]

differences: https://github.com/FireFart/wpscan/compare/master...themes

[ethicalhack3r]

Awesome! I'll have a look through soon.

[ethicalhack3r]

It seems to be checking the wrong theme directory (or at least outputting the wrong directory):

"| Name: 4colourslover | Location: http://www.xxx.com/blog/wp-content/4colourslover/ | Directory listing enabled? No. " Location should be http://www.xxx.com/blog/wp-content/themes/4colourslover/. I think the bug is in the "get_url_without_filename" method. But it seems to work fine for plugins so might not be.

There seems to be a problem with theme version fingerprinting but not sure if this was introduced before.

"[!] The WordPress theme in use is storque v1.0 v1.0"

[firefart]

hmpf it's the function when passive plugin detection returns urls without filename. will fix that thx ;)

[firefart]

both should be fixed now

[ethicalhack3r]

Awesome! Can confirm both fixed for the blog I was scanning. Thanks! :)

@erwanlr, @gbrindisi, you both OK with merging these changes?

[firefart]

great ;) rspec tests still failing need to fix them first ;)

[erwanlr]

A lot of specs fail because the create_location_url_from_name and create_url_from_raw methods do no longer exist in plugin.rb

These methods were used to create the plugin location url from his name or a raw data : https://github.com/wpscanteam/wpscan/blob/master/lib/wpscan/wp_plugin.rb

Furthermore, i would rather do a WpItem class instead of a module :

class WpItem < Vulnerable
class WpPlugin < WpItem
class WpTheme < WpItem

[gbrindisi]

Love this feature! :+1:

[firefart]

thx for the feedback WpItem is now a class

[firefart]

rspec tests are now fixed. time for some final testing guys ;)

PS: i will add tests for the new methods later

[erwanlr]

If the blog uses a custom wp-plugins directory, the plugin enumeration does not work because it try to get them from wp-content/plugins (wp-content can be a custom dir)

A solution could be to pass the wp_plugins_dir directory to the class WpItem like the wp_content_dir one.

Furthermore, for the same reason, the timthumbs enumeration does not work when the file is located in a plugin directory

Custom content & plugins directories are explained there : http://codex.wordpress.org/Editing_wp-config.php#Moving_wp-content

[firefart]

just pushed an update on the wp-content dir detection. When i switch my wp-content directory to a custom location, many themes and plugins render incorrect maybe this is the problem? example: http://10.211.55.8/wordpress/wp-custom/plugins/usr/share/wordpress/wp-content/plugins/add-link-to-facebook/add-link-to-facebook.css?ver=3.3.1

Current version should detect only the "real" wp-content dir, but in this case wpscan detects a usr plugin, because the full path is rendered by the plugin/theme

[erwanlr]

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 ;)

[ethicalhack3r]

Opened a new issue for it: https://github.com/wpscanteam/wpscan/issues/31 (I'll have a look at it)

[firefart]

should i open a pull request so you can merge it in a seperate branch of the "main" wpscan project?

[erwanlr]

What do you want to merge ? the themes branch ?

[firefart]

noooo i thought @ethicalhack3r wants to fix the #31 issue so it would be a possibility to create a themes branch on this project. but the issue was kind of false/positive because it was on my branch ;)

[erwanlr]

kk xD

[firefart]

anybody knows a reliable way to determine a custom plugins directory? or is the sli option the only way to determine it? If so, what do you think of a check if "WP_CONTENT_DIR" + "/plugins" exists on the front page and if not, put a message that either no plugins are installed or a custom plugin dir must be supplied?

[firefart]

@erwanlr custom plugin directory is now working. combination of custom wp-content and custom wp-plugin dir is also working. plugin dir needs to be speficied via cli, wp-content is automatically detected (no need for cli options here)

any open tasks for this left?

[erwanlr]

You are assuming that the plugins directory is a sub folder of wp-content, but it's not necessarily the case for a custom wp_plugins_dir :

# spec/lib/wpscan/wp_item_spec.rb

it "should return the correct url (custom wp_plugins_dir)" do
  @instance.wp_plugin_dir = "wp-custom/c-plugins"
  @instance.type = "plugins"
  @instance.get_url.to_s.should === "http://sub.example.com/path/to/wordpress/wp-custom/plugins/test/asdf.php"
end

Furthermore, a 's' is missing to the wp_plugin_dir attribute of WpItem => wp_plugins_dir

Then, the WpItem#url and WpItem#get_url are tricky xD, i would say that they return the same thing according to their name but no ^^ (i know why you have done that but it could be better to find another name for the attribute url ;))

[firefart]

a ok i thought the plugins die must always be in wp-content. will fix that and the naming issues

[firefart]

new changes are in:

• custom-plugin directory
• naming in WpItem
• check if the supplied/detected wp-plugins directory exists. If not, warn the user
• locate an existing searchreplacedb2.php(http://interconnectit.com/124/search-and-replace-for-wordpress-databases/), found it on a couple of blogs
• new wordpress version detection based on wp-links-opml.php
• check if the site is a multisite enabled installation
• check if the site allows user registration
• Version detected regex simplified (due to errors in readme.txt files, where linebreaks are only \r)

would be great if you can test it ;)

[erwanlr]

I will ASAP, but from what i saw on your commits it looks great :)

Just one thing : in string sometimes you use #{variable} and another time #@attribute like :

ret = URI.parse("#{url}#@wp_plugins_dir/#{path}")

Is there a particular reason or it's just to save 2 chars ? :p

[firefart]

its because the {} are not needed on @ variables and my ide suggests this. so it's just some "code styling" ^^

[erwanlr]

kk :D

[erwanlr]

The wp-content and multisite detection does not work for this site : http://buddypress.org/

For the multisite it's because their redirection is http://buddypress.org/register/

edit : "[+] Userregistration is enabled" a space is missing ;)

[firefart]

wp-content detection works for me on buddypress.org (wp-content).

Multisite detection is a bit tricky on this site. Do you have a good solution for this? I think a 100% accurate multisite detection on customized Wordpress instances is impossible. Or is /register/ a valid wordpress link?

[erwanlr]

wp-content detection works for me on buddypress.org (wp-content).

Ok, it was a rubygems issue (i was with an old one on BT5r3)

I do not think /register/ is a valid wp link, like you said it's a custom one

[erwanlr]

Great :)