Crons in WordPress are very important, even if they are not a security problem by themselves. With a bit of enthusiasm, it would be possible to make a DDoS attack against wp-cron.php since it will return a 200 code when executed.
There are usually three ways to run it: the internal automatic system, the system to turn off the cron but to run it via an HTTP call, or to run it via an internal cron / WP-CLI.
In these cases, it may be interesting to warn that the WP-CRON is publicly accessible if it returns a 200 code or if it is protected when it returns a 403 or similar.
As the wp-cron is loaded and executed when someone visit the blog (https://github.com/WordPress/WordPress/blob/master/wp-cron.php#L5), DDoS by calling it directly is the same as a DDoS by visiting the homepage for example. Hence I don't think it's worth to report this file being publicly accessible.
However, there are these two lines (https://github.com/WordPress/WordPress/blob/master/wp-cron.php#L10-L11):
* Defining DISABLE_WP_CRON as true and calling this file directly are
* mutually exclusive and the latter does not rely on the former to work.
If I understand them correctly, even with DISABLE_WP_CRON = true, calling the cron file directly will execute it, ignoring the DISABLE_WP_CRON, right ?
OK, so:
Case 1 (normal status): Every time a visitor enters a page, triggers the wp-cron.php (not always, depends on cache, and WP-AJAX and other things, but usually, yes). Yo can access a page or wp-cron.php to DDoS.
Case 2 (DISABLE_WP_CRON = true): Every time a visitor enters a page does not trigger the WP-Cron, so you must execute it. If you access wp-cron.php you can trigger the cron. So, you can access wp-cron.php to DDoS.
Case 3 (DISABLE_WP_CRON = true & disable access to wp-cron.php): You must call the cron via Crontab or WP-CLI. Usually calling wp-cron.php returns a 403. Also, you can allow an IP and run via HTTP.
What I want to suggest is to add a "Interesting findings" (like with robots.txt or others) that you have the wp-cron "opened to call via HTTP", nothing else...
Thanks for the feature request @javiercasares!
I think if we can prove that it is a common scenario that creates security issue then we should consider implementing the check, otherwise I don't think we should.
Are you able to create a DoS from your testing? If so, could you provide the steps for us to reproduce?
There is documentation about it...
https://medium.com/@thecpanelguy/the-nightmare-that-is-wpcron-php-ae31c1d3ae30
https://www.iplocation.net/defend-wordpress-from-ddos
Usually: www.example.com POST /wp-cron.php?doing_wp_cron HTTP/1.1
You can "execute" the wp-cron doing this:
POST /wp-cron.php?doing_wp_cron
Thanks @javiercasares!
Personally, I think I'd like to see some real world examples of this issue being actively exploited to cause a DoS attack. To see how likely it is that this is possible to achieve "in the wild".
I'll do some testing of my own against some of my own clients and see if I can trigger a DoS.
I definitely know personally some clients that have WP-cron jobs that would
result in a DoS if triggered remotely at high frequency. These cron jobs
kick off serious DB calls that would exhaust MySQL. I see this as a
misconfiguration opportunity to exploit.
On Mon, Mar 4, 2019 at 6:42 AM Ryan Dewhurst notifications@github.com
wrote:
Thanks @javiercasares https://github.com/javiercasares!
Personally, I think I'd like to see some real world examples of this issue
being actively exploited to cause a DoS attack. To see how likely it is
that this is possible to achieve "in the wild".I'll do some testing of my own against some of my own clients and see if I
can trigger a DoS.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/wpscanteam/wpscan/issues/1299#issuecomment-469223036,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJn0iP4yWuRNmzC1yha3I-GjBcaNiwdsks5vTQa8gaJpZM4bCeIq
.>
John M. Martinelli
website security consultant
(424) 333-4133 | https://secureli.com
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
I will add that as an interesting finding, so far thinking of returning it when a GET to /wp-cron.php returns a 200.
References used would be this issue along with https://www.iplocation.net/defend-wordpress-from-ddos
Most helpful comment
I will add that as an interesting finding, so far thinking of returning it when a GET to /wp-cron.php returns a 200.
References used would be this issue along with https://www.iplocation.net/defend-wordpress-from-ddos