Exploiting my own WordPress part 4 – Attack surface

I rerun ZAP and wpscan online password attack against a presumably less defended target, and realize that sometimes just talking to people is the best trouble shooting methodology

Before leaving ZAP and trying out new tools, I do a scan of this blog, emalstm.tech.

My hypothesis is that ZAP will find more flags on this WordPress. The only protective measure I’ve implemented on this site is secure ssh connection, disallowing root login and putting up a firewall including fail2ban.

I run the passive and active scan, and to my surprise I see that the total amount of alerts is much smaller: only 241. Hmm.  This blog is very simple and doesn’t have plugins, which reduces the attack surface.

The most obvious security flaw that I intentionally left is that Let’s Encrypt isn’t configured. Thus my passwords are sniffable. ZAP does not test this and also doesn’t flag it as an issue. I guess that most people who operate ZAP know the field well enough to know that login without https is something they should look out for anyway, but still.

I also want to test how online password attacks works on this site – and in the meantime I do a really stupid mistake.

I change the password of one of my users to a password that is in the list I have. Then I spin up dockerized wpscan via this command:

docker run -it -v $(pwd)/1000-most-common-passwords.txt:/wpscan/1000-most-common-passwords.txt –rm wpscanteam/wpscan –url https://scanyourowndamnsite/ –wordlist 1000-most-common-passwords.txt –username anenumerateduser –threads 1

I have previously run this against my other site. This time the attack fails and I get an error message about firewalls. I can’t reach the site via browser anymore and get an error message about firewalls. And I have enabled ufw and fail2ban, which are firewall utilities, but… surely it can’t be a firewall issue?

Sometimes when one works alone, the most obvious answer doesn’t come to you. I remembered that I had absolutely configured fail2ban on the other site, and my IP wasn’t banned then. Therefore I thought it was unplausible that I was banned, although about 15 different symptoms pointed in that direction. So, after way to much time, and some discussions with friends, the obvious answer dawns: fail2ban is not configured on the other site. Oops.

So after letting myself out from fail2ban’s jail, I whitelist myself and perform the attack again. It only takes a bit more than a minute to test all 1000 passwords to my exposed login page. That’s concerning. An online password attack is orders of magnitude less fast, and a lot less stealthy than an offline password attack.

At first I think this scan has failed also, because I expect the Password to show up in the Password row of the table above. It doesn’t. However, there’s an “ERROR: We received an unknown response for login: emalstm and password: wilcat”. I do not know if this is how the wpscan online password attacker is supposed to work, but anyhow, it’s the right answer. Now that I finally was able to exploit the target, I can change my password back to something reasonable again.

Speaking about stealthy approaches: I haven’t disabled comments on this site, and the ZAP active scan left a quite obvious trail of its existence: