Summary and check now option not showing

Maybe the plugin only does excessive calls when having the unexpected behaviour on siteground.

They identified it doing an audit while I was having excessive resources consumption, using the user-agent:
coamb.cat:87.125.38.221 – – [16/Oct/2019:14:03:35 +0200] “POST /wp-admin/admin-ajax.php HTTP/1.0” 200 47 “https://www.coamb.cat/wp-admin/admin.php?page=wpscan” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.2 Safari/605.1.15”
coamb.cat:87.125.38.221 – – [16/Oct/2019:14:05:34 +0200] “POST /wp-admin/admin-ajax.php HTTP/1.0” 200 47 “https://www.coamb.cat/wp-admin/admin.php?page=wpscan” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.2 Safari/605.1.15”
coamb.cat:87.125.38.221 – – [16/Oct/2019:16:21:41 +0200] “POST /wp-admin/admin-ajax.php HTTP/1.0” 200 48 “https://www.coamb.cat/wp-admin/admin.php?page=wpscan” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.2 Safari/605.1.15”

Sorry for not being able to provide more information.

What logs would you like from us (SiteGround)? There’s nothing we do that adds to the number of calls…

Hi @hristo-sg,

Thanks for helping.

Could you provide some details on how/why SiteGround attributed excessive /wp-admin/admin-ajax.php AJAX calls to the WPScan WordPress plugin?

The POST body would be useful, as this would give us the “action” being used.

How many requests a minute are you seeing from the WPScan plugin to categorise it as excessive?

I was unable to reproduce locally, so just trying to figure out what the issue might be.

Again, many thanks for your help.

Ryan

@hristo-sg thanks for posting. Your help could be very valuable.
Could you (as you are from Siteground) simply create a test wordpress site within your server, install de wpscan plugin, activate it and see (as you would totally control the server, logs, environment) why it is failing?
I’m sure @ethicalhack3r could provide you with an api key for this test with no problem.

Being us the testers, we are somehow blindfolded, as we no see any error, the plugin just hangs. But you could be able to see any task the plugin is doing, and maybe find what is preventing it from executing the vulnerabilities call.

Thank you.

Well, the log provided above is pretty clear, the request URL is:
https://www.coamb.cat/wp-admin/admin.php?page=wpscan

and there are like 500 a day towards that site only.

That could be number of tabs left open on that page and heartbeat hitting it constantly, some scan, can’t really say more beyond the access log. We don’t keep the entire post request in the server log due to security reasons.

@humaniza are you hitting the /wp-admin/admin.php?page=wpscan page with some kind of script/browser on a regular basis?

@ethicalhack3r No, I only loaded the page, saw that it didn’t work and closed it. But it seems in fact, that it kept running and making resource consumption.
The plugin is now removed due to the advise they gave me so now I’m sure the plugin is now causing 0 more hits.

Another SiteGround user tested for us and reported no issues and we were unable to replicate locally.

The AJAX requests are coming from a web browser on the 87.125.38.221 external IP visiting the /wp-admin/admin.php?page=wpscan page. This IP is from Spain. According to @hristo-sg around 500 times per day.

I don’t know what else to suggest, sorry.

Hi @ethicalhack3r
That’s my own ip, which is odd as it’s imposible that I did 500 requests on my own, somehow something stuck and kept repeating like hanged.

I’m sorry I can’t give more clues.

For the original issue, ie the Summary section not showing, this is due to the WP Cron not running, which can be due to:

The DISABLE_WP_CRON constant is set to true in the wp-config.php file, but no system cron has been set (crontab -e).

A plugin’s caching pages is enabled (see https://wordpress.stackexchange.com/questions/93570/wp-cron-doesnt-execute-when-time-elapses?answertab=active#tab-top).

The blog being unable to make a loopback request, see the Tools->Site Health for details.

If the issue can not be solved with the above, putting define(‘ALTERNATE_WP_CRON’, true); in the wp-config.php could help, however, will impact the SEO of the blog.

Hi,
Today we resolved this issue, and I wanted to post the solution here:

Unexpectedly, it appeared to be related with an ssl problem in the configuration of the site.

I had seen some plugins giving this error:
Error: cURL error 35: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure (http_request_failed)
So that made some cURL calls to fail, hang…

This was supposed to affect the cUrl call that wpscan does in order to get the information, so it halted there and made it break.

Last time I saw this error was in the WordPress health summary, telling me that it could not connect with that “SSL handshake” error.

The clue for me was that the Siteground plugin “SG Optimizer” failed when trying to enable ssl, telling that there was some ssl certificate error.

Finally with that error, I was able to open a ticket to SG support and they resolved it with the following diagnostic:”Regarding the WordPress Site Health and the error message and the cURL error 35, the Cloudflare DNS records were pointing in the DNS zone with us and that was caused the issue. The Cloudflare records were removed for the DNS zone with us and now the error isn’t showing up.”

After doing that, The WordPress health error dissapeared, and the WPSCAN plugin began to work fine!

So finally I can confirm it is resolved / working now for me, and I’m giving you the information I got so maybe it can be of help to anyone.

Thank you to the WPScan support crew, who really tried to resolve this, and to the Siteground support, that finally got the error and where able to give me a solution.