Exploiting my own WordPress part 2 – online password attack

TL;DR:

When attempting an online password attack, I find that wpscan gives me false positive and false negative results . Also I find my defenses work, but not as I expect them to.

 

This is part 2 of my attempt to hack myself. After successfully DoSing my own site using a vulnerability I found with wpscan, I decide to try out wpscan’s password guessing feature. I do not expect this to be successful. An online password guessing attack will be prohibitively expensive, because I’m using a computer generated, long password that I store in my password vault. Also I only allow three login attempts and my login page is not called /wp-admin or /wp-login.php.

 

docker run -it -v $(pwd)/1000-most-common-passwords.txt:/wpscan/1000-most-common-passwords.txt –rm wpscanteam/wpscan –url https://[ this-is-illegal-attack-a-site-where-you-have-obtained-permission] –wordlist 1000-most-common-passwords.txt –username [a username I’ve enumerated, i.e admin] –threads 5

 

Command line to English translation: run docker image wpscan and mount a wordlist with common passwords. Specify a url where you have permission to attack, specify a username you suspect exist and lastly,  specify how many concurrent threads to use.

 

To my horror the wpscan interface indicates that a working password guessing dictionary attack is underway. Using 5 threads I manage to “test” all 1000 passwords within 1:22 minutes. I doubt that it’s truly working, I think it’s a false positive. But how can I verify that?

 

I change the password of the account I’m trying to attack. One of the last passwords in the list is “wildcat”, and I change my password to this. When doing so, I also have to acknowledge that this is a BAD password. Nice! Thanks wordpress!

I run the attack again, and sure enough, the password is not cracked despite being in the list. This verifies that changing your login site to something other than /wp-admin is a reasonable script kiddie protection. I change my password to something strong again and update my password vault entry.  

 

Something that surprised me is that the –threads flag with 30 concurrent threads I caused my database to temporarily crash. Also surprising is the fact that I am allowed to perform many obviously illicit calls to the server despite fail2ban being used. I need to investigate this further.

 

In an upcoming test, I will re-run these tests on a WordPress with default settings.