[ENHANCEMENT] v2.1 is blind to Better Wordpress Security and Wordfence lock-outs

[Botster]

I modified 5 files to add awareness of, and time-out delays (based on some installation defaults) for, Better Wordpress Security and Wordfence lock-outs:

1. wpscan.rb (modify behavior based on BWPS & Wordfence intrusion detection discovery)
2. lib/wpscan_options.rb (--bwps-safe-mode, --wordfence-safe-mode)
3. lib/wp_target.rb (BWPS & Wordfence intrusion detection discovery)
4. lib/wp_target/wp_login_protection.rb (add recognition for Wordfence as a login protector)
5. lib/common/common_helper.rb (add a time-out function to facilitate waiting for security lock-outs to clear)

The diff files (published version 2.1 vs. modified) can be found at:

1. http://www.filefactory.com/file/483q643ett8h/n/wpscan_diff (3.83 KB)
2. http://www.filefactory.com/file/5hi8bxhxd7qn/n/wpscan_options_diff (0.17 KB)
3. http://www.filefactory.com/file/135jzxzr8wip/n/wp_target_diff (1.12 KB)
4. http://www.filefactory.com/file/73rm3y3a95ej/n/wp_login_protection_diff (0.87 KB)
5. http://www.filefactory.com/file/1zos5d5oyydz/n/common_helper_diff (0.14 KB)

I'm sure there are more elegant ways to do what I did. But it works.

[erwanlr]

Would you mind to fork the wpscan repo and send a pull request with your changes ? :)

[Botster]

I would be glad to. However, I don't seem to be able to do so.

I have created a fork and cloned it. But, I do not seem to be able to push my commits.

Even though (git version 1.8.1.5) git remote -v shows that I am using a HTTPS clone (https://github.com/tldavidson/wpscan.git) for fetch & push and I have set my username via git config --global user.name "tldavidson", git push origin master triggers ssh-askpass asking for a password only, as if the protocol is SSH. And, apparently, my GitHub password is not the correct one.

I have searched for a solution for this apparent contradiction and only found instructions to switch protocols; not how to fix a HTTPS clone trying to use SSH.

[Botster]

By the way, some of the paths I listed in my original comment are incorrect. The should be:

• lib/wpscan/wpscan_options.rb (--bwps-safe-mode, --wordfence-safe-mode)
• lib/wpscan/wp_target.rb (BWPS & Wordfence intrusion detection discovery)
• lib/wpscan/wp_target/wp_login_protection.rb (add recognition for Wordfence as a login protector)

[anantshri]

Why not just edit the files using web interface saves all the hassels of push and pull stuff. you can then create a pull request for all commits online

[Botster]

I actually started doing that, at first, anantshri. But I quickly realized what a hassle that would be. So I abandoned that idea in favor of:

1. Clone
2. Drag-n-drop 5 files
3. Push

I just got hung up on the Push step. But I would still rather be able to do a Push than to try to copy-n-paste five files in that dark and hard-to-read web interface. Thanks for the response though :-)

[dequis]

Here's the patch as an unified diff against dcc443ac9ac5171f91df498b619f9d6efc16aff2 in a pastebin.

http://pastebin.com/5RVLNEJj

I didn't bother turning this into a mergeable github repo because it was useless for me, to say the least. Starting by the fact that the test to find BWPS / Wordfence is just a loop that floods the server with requests (21 and 75 requests respectively, with no delay between them) and returns true if we got banned by it. There are parameters to disable these flood tests, --bwps-safe-mode and --wordfence-safe-mode, but if you pass only one of them... the flood test for the other plugin still runs.

The lockout timeout is hardcoded to 5.25 minutes and only applied after the flood test plus a few random spots. There's no code to actually prevent lockouts due to sending requests too often. The only real change of the safe modes is to disable some of the enumerations.

[Botster]

While perhaps not worthy of a merge, it at least provides a temporary work-around to WPScan's lack of lock-out awareness. So, lest anyone else get the impression that it would be useless to them as well, let's try to understand a few things.

Yes, the test to find BWPS / Wordfence is just a loop that floods the server with requests with no delay between them. How else would one simply simulate a bot flood? Introducing a delay into the loop would unnecessarily delay the test results and could result in a false negative due to faulty semantics.

The number of requests (21 and 75) are based on some of the default settings for the security plugin installations. BWPS triggers a lockout based on the number of requests with a threshold of 20, and Wordfence triggers on request velocity (ie. requests per minute). The number 75 needed to be substantially greater then 60 due to, I presume, latency within the 'net or the apps themselves. (I didn't waste alot of time determining if the number could be reduced to save a few milliseconds.)

Both of the respective 'safe-mode' parameters disable the aggressive enumerations thereby allowing at least some testing to be done. But there needed to be distinct safe modes because the plugins are not the same and therefore behave differently. And of course, disabling one respective flood test does not disable the other.

The default lockout expiration in BWPS is five minutes. The lockout timeout is set at 5.25 minutes to help ensure the lockout's expiration time has completed. And since we likely cannot phone the site's administrator and ask them what they have this set to, we just assume they are lazy and have left it at the default. So, why not hardcode it? It was only intended as a temporary solution anyway.

(The only reason I created a fork is because it was requested. I have deleted it.)

There is no code to actually prevent lockouts due to request velocity, because I didn't care to spend the time trying to determine if Typhoeus::Hydra has a speed controller.

So, the patch I published may be useful to someone, at least until WPScan progresses to the point that it is lockout aware and does not continue blindly on with its output erroneously indicating that it is actually doing something.

Thank you for taking the time to produce a unified diff.

[erwanlr]

Hi there,

There is already a plugin awareness for the brute forcing (it just check the existence of known plugins that might block the attack), however 'full awareness' is - IMO - an advanced thing would require to have a specific system for that, as well as keep the detection up-to-date (and also include others wp lockout plugins ?)

So, actually it would be complicated to have such thing, but we will keep this idea in mind :)