Detecting plugins - how?

wpscanteam / wpscan

WPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites. Contact us via contact@wpscan.com

https://wpscan.com/wordpress-cli-scanner

Other

8.64k stars 1.27k forks source link

Detecting plugins - how? #654

Closed sydneydarnay closed 10 years ago

sydneydarnay commented 10 years ago

I'm currently using wpscan in an automated script to scan certain sites we host on a monthly basis. However, it is not returning anywhere near the amount of plugins which exist.

For example in a dev environment it detects 13, the same site live on a different server returns 2. So I'm trying to work out why this may be happening. I see there is a list of plugins which can be regenerated with wpstools.rb, so I'm not sure if it literally just checks through if the expected plugin address returns anything - but then I can't see a difference between live and dev.

So any input is appreciated

erwanlr commented 10 years ago

Reasons that could cause such a behaviour:

Presence of WAF / AP on the live server
Updated plugins' versions on the live site and outdated one in the dev env (then if you enumerate only the vulnerable plugins, there will be less found on the live site)

The plugins detection is done with the following logic:

Depending on the enumeration required (option -e p,vp or ap), the list of target URLs is constructed (e.g blog.com/< wp-plugins-directory >/< plugin-name >)
These URLs are tested for existence:
- if the response status is a 200, 401, 403 or 301 & the body doesn't match a custom 404 or the home page & doesn't match the potential --exclude-based-content option, then the plugin is considered to be present on the blog.

ethicalhack3r commented 10 years ago

You could try using a proxy like Burp/ZAP and running WPScan through it. You will then be able to see what the response is for detected/un-detected plugins more easily. This should help diagnose the issue. If you find out what the issue is please let us know as we might be able to implement feature/fix bug.

It could also be a web server configuration that is different between dev/live (if the dev/live servers are not direct clones).

sydneydarnay commented 10 years ago

Hi,

Thanks for the suggestions, hopefully I'll get back on to this within the next couple days. There shouldn't be any application firewalls, though it was one of the earlier things I checked. The sites are also identical so same versions, however we don't actually host the servers in our DC, we just administer them.

The Apache configs do have some differences but I tried to test the changes and disable where possible.

But I'll update with further findings.

Cheers,

sydneydarnay commented 10 years ago

A little bit of an update, for some reason on the dev environment the URL for the plugiin - e.g http://SITE/wp-content/plugins/advanced-code-editor/ returns a 403 due to permissions, which you'd expect.

The live returns a 404 - not found. However, if I use the default php page for the plugins I'll get a response - e.g http://SITE/wp-content/plugins/advanced-code-editor/advanced-code-editor.php returns a 200 with the notice you cannot access this page directly.

Permissions on dirs are the same, but parent dir of each plugins returns 404 as opposed to 403 on dev, but accessing the php file works.

erwanlr commented 10 years ago

Hi,

I can't implement such detection in the current code w/o turning it into piece xD

Will keep that in mind for the future detection method