Incorrect Plugin Detection

[wpscanteam]

Incorrect Plugin Detection

[ethicalhack3r]

Thanks for the info.

Just to clarify. An invalid plugin redirects you back to the main site?

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

If so, this could probably be fixed by taking a hash of the index page and then comparing it against the plugin enumeration response. Like we do with the 404 hash.

[Xploit3r]

Yeah, that is correct.

A GET Request to: http://www.target.com/wp-content/plugins/not-a-plugin/

returns you the content of the index page. However, the URL in the browser still remains:

http://www.target.com/wp-content/plugins/not-a-plugin/

It doesn't actually redirect you to http://target.com/index.php however the content is the same as that of index.php

Probably some sort of URL rewrite done on the server side.

For a valid plugin it will return a 403 forbidden response.

I saved the index.html and then the invalid plugin response and they are the same :)

I think you are correct, if we compare the hash of the index page with that of the invalid plugin response, we can filter the false positives.

[erwanlr]

Does this only happen for wp-table and wp-table-reloaded or were they just examples ?

[Xploit3r]

This happens for any plugin that does not exist on that wordpress.

So, as an example I took a plugin with the name - not-a-plugin to show the issue.

[firefart]

I think Issue #24 would do the trick here. Have not had the time to implement it yet.

[ethicalhack3r]

I think @firefart's solution will fix this but might be worth to implement the 'homepage hash' check too to try and automatically prevent this particular behaviour. However, when the 'homepage hash' automated check doesn't work, then @firefart's string detection could be used by the user.