Open adam-ah opened 10 months ago
@adam-ah: Thanks for opening an issue, it is currently awaiting triage.
In the meantime, you can:
@adam-ah: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.
/kind feature
/kind enhancement
/kind bug
/kind packaging
Transferring parser/scenario request to the hub repository
Hey 👋🏻
I don't use word press personally but if repeated calls to xmlrpc in short duration is not normal behavior then you can open a pull request on this repository with your changes you purposed
thanks for moving the ticket to the right repo, @LaurenceJJones I'll keep that in mind for future reference
this sounds like a bad idea, especially when you take into consideration 3rd party plugins that use the xmlrpc API endpoint heavily.
@GNU-Plus-Windows-User your point of view is inaccurate for the following reasons:
xmlrpc.php
endpoint (see capacity and leakspeed parameters in Crowdsec)xmlrpc.php
it's either DDoS or password bruteforce xmlrpc.php
(I have over a dozen plugins installed, only hackers call the xmlrpc.php
endpoint)http-bf-wordpress_bf
plugin fails to block bruteforce attacksxmlrpc.php
1 2http-bf-wordpress_bf
protecting them from bruteforce attacksFurther reading on fail2ban and xmlrpc 1 2
In your response, could you please address each of these, with a special focus about the concern regarding adding a correct brureforce filter with the appropriate leakspeed and capacity parameters, with evidence (logs) showing that indeed, it is not possible or downright harmful?
no legit plugins should hammer the xmlrpc.php endpoint
I don't know about this, plugins like jetpack do use the xmlrpc endpoint a fair bit. I don't use jetpack anymore so this may have changed. I can test this if you like.
if anyone hammers xmlrpc.php it's either DDoS or password bruteforce
Maybe, it depends on what the xmlrpc.php is used for, and the use case, this is my main concern by expanding the scenario to cover xmlrpc.
none of the stock standard popular WP plugins use xmlrpc.php (I have over a dozen plugins installed, only hackers call the xmlrpc.php endpoint)
That doesn't mean anything, the xmlrpc api endpoint wasn't created for hackers to hack wordpress. Yes, it's a common attack vector but so is port 443, that doesn't mean you should be shutting off port 443. If you don't need it then it makes sense to disable it since that's a basic attack surface reduction technique.
without using a 3rd party plugin (e.g., WordFence), crowdsec's http-bf-wordpress_bf plugin fails to block bruteforce attacks
I understand that concern and I fully support expanding brute force protection to XMLRPC, if it doesn't cause any additional FPs which is my main concern.
several security guides recommending downright disabling
You shouldn't be blindly following the advise of security guides online, if you don't need the xmlrpc.php endpoint then it makes sense to disable it. Disabling xmlrpc is something that should be taken on a case by case basis, disabling stuff without knowing what it does is a sure fire way to break stuff. I've seen a lot of very bad takes in the wordpress community, to be fair many of these people aren't security experts.
users without deep technical knowledge incorrectly believe http-bf-wordpress_bf protecting them from bruteforce attacks
Agreed, CrowdSec should add a disclaimer for the scenario to prevent confusion.
These logs are from using the wordpress app:
0.0.0.0 - - [30/Oct/2023:05:37:03 +1100] "POST /xmlrpc.php HTTP/2.0" 200 631 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:03 +1100] "POST /xmlrpc.php HTTP/2.0" 200 265 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:05 +1100] "POST /xmlrpc.php HTTP/2.0" 200 278 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:05 +1100] "POST /xmlrpc.php HTTP/2.0" 200 403 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 5154 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 9523 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 635 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 678 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 678 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 635 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 635 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 635 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:06 +1100] "POST /xmlrpc.php HTTP/2.0" 200 678 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:07 +1100] "POST /xmlrpc.php HTTP/2.0" 200 135 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:08 +1100] "POST /xmlrpc.php HTTP/2.0" 200 135 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:10 +1100] "POST /xmlrpc.php HTTP/2.0" 200 403 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
0.0.0.0 - - [30/Oct/2023:05:37:10 +1100] "POST /xmlrpc.php HTTP/2.0" 200 278 "-" "Mozilla/5.0 (Linux; Android 14; Pixel 7 Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/118.0.0.0 Mobile Safari/537.36 wp-android/23.4"
You'd have to have a seperate scenario with a fairly leniant leak speed and capacity, maybe 5s leak speed and a capacity of 20. There may be some other plugins that use xmlrpc even more than the wordpress app
I also just realized, we have a separate scenario
It is NOT included by default due to reasons outlined by @GNU-Plus-Windows-User
https://app.crowdsec.net/hub/author/crowdsecurity/collections/wordpress
Great find, @LaurenceJJones
The solution could be (?) then to add it to the description of the collection to encourage installing the optional http-bf-wordpress_bf_xmlrpc as in most cases this would be needed.
I think these all come back to the high suprise factor of CrowdSec defaults - I would not expect a wordpress scenario made by CrowdSec to be not included in the WordPress collection (probably most users would not expect it, even though it is a critical scenario for most of wp users). Taking 3 days and 3 people to find this may suggest that something is not quite right...
The solution could be (?) then to add it to the description of the collection to encourage installing the optional http-bf-wordpress_bf_xmlrpc as in most cases this would be needed.
Yeah I agree, we have over 200 scenarios so adding links in the markdown is easy to aid other to find them. We are also working on a recommendation system in the hub depending on tags. So when viewing the wordpress collection it will offer other scenarios with similar tags (Excluding the ones inside the collection itself)
Edit: Plus when our WAAP (waf) comes out, we can easily generate rules based on the HTTP body itself rather than having a vague scenarios based on higher limits
What would you like to be added?
/kind enhancement
What
WP brute force often comes as repeated
200
requests toxmlrpc.php
. The currenthttp-bf-wordpress_bf
does not catch this.Sample log (this repeated 20 times before WordFence blocked it)
Sample explanation
Why
WP will assess login requests sent to
xmlrpc.php
and return200
. WordFence will eventually block the user but that is much more compute-intensive task. Without WordFence this would not get blocked, letting bruteforce attacks through.How
Simply add checking for
xmlrpc.php
inhttp-bf-wordpress_bf.yaml
:Sample after the change
The parsing is as-expected after the change:
Why is this needed?
xmlrpc.php
brute force attacks are not captured correctly