Custom Vulnerability Object to detect Failed WordPress Logins

[SimonBlackler]

I'm trying to stem the flood of wordpress brute force attacks coming into our network (we host a lot of WP sites).

Detecting WP logins is relatively easy, by setting up a signature that looks for the regex wp\-login\.php in the http-req-uri-path context with the http-method = POST qualifier. I can now see all of the wp-login requests coming into our network.

However, detecting a failed WP means also detecting the 200 response code from the web server (WordPress issues a 302 redirect upon sucessful login, a 200 upon failure).

I have tried adding an extra AND condition to my signature which checks for http-rsp-code = 200 but it doesn't trigger. So...

Custom Vuln Signature:

Severity : Informational

Default Action : Alert

Direction : client2server

Affected System : server

Signature (Standard)

Scope : Transaction

Ordered Condition Match

Condition 1 : pattern-match http-req-uri-path ~= wp\-login\.php

Condition 2 : equal-to http-rsp-code == 200

Why is this failing to work? Without Condition 2 it shows up all wp logins, but with Condition 2 it sees nothing. Help 🙂

[HULK]

Hello Simonblackler,

Could you please post your query to DEVCENTER, they might help you for your custom signature.

Thanks

[HITSSEC]

Simon,

We control wordpress logins in the following manner:

force your web content management staff us only access the Wordpress login page from on the network (internal zone) and if they require it from of the network then require them to use a vpn solution.   This then means that any wordpress login request from the internet is not desirable and can be blocked with the signature that just identifies the incoming request from the internet.  We have been doing this for over a year now with a lot of success.

Phil

[SimonBlackler]

Thanks Phil, unfortunately this won't work - we are a web host and host thousands of wp sites - we need to block/reset incoming connections from external/public IP addresses that repeatedly fail to log into WP correctly.

[pulukas]

The signature does look correct for the response code 200.  Can you do a packet capture on a failed login and confirm what the data looks like in the response?

[hyadavalli]

Hello Simon,

Try making the scope as session instead of transaction.

Regards,

Hari Yadavalli

[HITSSEC]

Simon,

If you look at the document located here: Creating Custom Threat Signatures in particular look at Example 4 located on page 45.  You can create a combination signature to detect brute force attempts with variables you can set (# of connection attempts in a time period) that will separate the valid users from those who are up to no good.

Phil

[SimonBlackler]

Hey Steven, thanks for your reply. I captured the transaction - and here is the "Follow TCP Stream" output from Wireshark of the relevant packets...

POST /wp-login.php HTTP/1.1

Host: www.sant-media.co.uk

Connection: keep-alive

Content-Length: 110

Cache-Control: max-age=0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Origin: http://www.redacted.co.uk

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Content-Type: application/x-www-form-urlencoded

DNT: 1

Referer: http://www.redacted.co.uk/wp-login.php

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

Cookie: wordpress_test_cookie=WP+Cookie+check

log=admin&pwd=xxxxxx&wp-submit=Log+In&redirect_to=http%3A%2F%2Fwww.redacted.co.uk%2Fwp-admin%2F&testcookie=1

HTTP/1.1 200 OK

Server: nginx

Date: Mon, 04 Aug 2014 09:36:41 GMT

Content-Type: text/html; charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

X-Powered-By: PHP/5.3.28

Expires: Wed, 11 Jan 1984 05:00:00 GMT

Cache-Control: no-cache, must-revalidate, max-age=0

Pragma: no-cache

X-Frame-Options: SAMEORIGIN

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

Content-Encoding: gzip

The actual Hex dump of the POST and the response (respectively) are:

Wireshark has no difficulty seeing this transaction and correctly decodes the Status Code as 200 in the analysis frame at the bottom of the window.

I can only assume that there is a bug in PAN OS or this is by design (i.e. unable to mix req and rsp contexts in a single signature)?

https://dl.dropboxusercontent.com/u/247153/FileChute/Screenshot-20140804-1111.png

[SimonBlackler]

Thanks for your reply - I have read that document backwards and forwards several times, trying to see if I'm missing something obvious 🙂

Unfortunately, the approach highlighted in the example is too simplistic. It is quite possible that an IP address might log into numerous WP sites legitimately. Web designers in particular are a customer group we don't want to annoy by being overly zealous. As we are a web host, we have a LOT of legitimate WP login requests. We already block clear cases of abuse using a similar combination signature, but a lot of attacks are characterised by a handful of failed logins from an IP every hour - not enough to trigger the combination signature, but still a problem, especially when we have several hundred IPs exhibiting similar behaviour.

[SimonBlackler]

Dear Hari,

Making the scope Session is not appropriate - and doesn't work anyway :-)... In a session it would be expected that at some point a POST request for wp-login.php will be made, and at some point later in the session a 200 status will be issued (not necessarily as the direct result of a login, but precipitated by a later page request in the same session).