After explaining the issue multiple times to YITH, showing detailed server log files, they are refusing to acknowledge a potential issue – instead they keep asking for a Live login, which we can’t provide for many reasons.

YITH are unwilling to investigate on their own servers – instead they expect you to set up a test server for them, demonstrating how their plugin doesn’t work. They have been extremely unhelpful – and so far have refused our money back.

We often have sites from agencies to fix which seem to be using Free downloaded commercial themes and Nulled Plugins. They often cleaned the problems up pretty well but sometimes they miss parts and the the sites or actually complete servers seem to be turned over to hackers.

Saying this the easiest way to secure WordPress and to make WordPress safer would actually be to provide all commercial themes and plugins also as a CLEAN(edup) version – but really cleaned up version on a trusted site. Only that way Networks like WP-VCD could be stopped with their malicious sites and finally WordPress would be made much securer. Instead of charging for 1 sites, 5 sites etc licenses which actually are not compliant with GNU GPL anyway as GPL says you can modify, copy, and even redistribute the code as long as you keep the same licenses in place. It would be much better that they focus on their reputation and helping the community of all to use cleaned code and benefit from support and more project requests due to their much better visibility.

Anyway that is not the question here – we have to deal still with those malicious sites and clean up the mess, So what plugins to do so are still working in 5.5 as this one hasn’t been updated by even Automatic!!! since 3 years – does not really speak for their reputation either or?

The site in question has Contact Form 7 5.0.2, Contact Form 7 Honeypot 1.13 and Flamingo 1.8.

Thank you in advance for your timely advice on this situation!
KeriAnn

How could I know if what they present is true.

Would it be possible for core developers to add this fix into main WordPress software?

Thanks.

wp-admin/network/

classmongodb.php
classmongodb-inc.php

the -inc file beings like this, with no comments or explanations and I can’t make heads or tails out of it.

[ Redacted, please do not post that here in these forums ]

And so on, and so on…

Is this part of the WP installation, or is it suspicious?

I noticed several access intents to files inside WordPress and WordPress themes, like for instance

/wp-content/themes/(theme-name)/(subfoldername)/css/loading.gif
/wp-content/plugins/newsletters-lite/css/jquery-countdown.css

There is no loading.gif in the CSS folder and in the second case, the newsletters-lite plugin is not and has never been installed in this server.

The IPs originating those access are not related to visitors that usually visit my website. I wonder if those are exploits/scanners that are posing a risk to my WordPress website.

Any advice is welcome.

wget -q -O – https://mysite.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

However, certain commands inside .htaccess file is blocking my cron job from running every hour. After spending some time researching, I confirm they are came from these additional commands I added for protecting my site from query string exploits.

# BEGIN QUERY STRING EXPLOITS
# The libwww-perl User Agent is forbidden – Many bad bots use libwww-perl modules, but some good bots use it too.
# Good sites such as W3C use it for their W3C-LinkChecker.
# Add or remove user agents temporarily or permanently from the first User Agent filter below.
# If you want a list of bad bots / User Agents to block then scroll to the end of this file.
RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (;|<|>|’|”|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]
RewriteCond %{REQUEST_URI} owssvr\.dll [NC,OR]
RewriteCond %{HTTP_REFERER} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_REFERER} \.opendirviewer\. [NC,OR]
RewriteCond %{HTTP_REFERER} users\.skynet\.be.* [NC,OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)cPath=https://(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*embed.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^e]*e)+mbed.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*object.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^o]*o)+bject.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} ^.*(\(|\)|<|>|%3c|%3e).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\x00|\x04|\x08|\x0d|\x1b|\x20|\x3c|\x3e|\x7f).* [NC,OR]
RewriteCond %{QUERY_STRING} (NULL|OUTFILE|LOAD_FILE) [OR]
RewriteCond %{QUERY_STRING} (\./|\../|\…/)+(motd|etc|bin) [NC,OR]
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} \-[sdcr].*(allow_url_include|allow_url_fopen|safe_mode|disable_functions|auto_prepend_file) [NC,OR]
RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ – [F,L]
# END QUERY STRING EXPLOITS

I know if I just delete these commands, then everything should be alright. But, these commands could help me to reduce query string exploits which I got them from other site. Can you all help me to identify which part of the commands are the culprits?

Of particular note in this post is the message displayed only to WP users whose blogs were used in the attack:

You are seeing this because your blog was recently used as part of a DDOS attack against Trilema.

The way this works is that the attacker sends pingbacks to a long list of blogs. The blogs in question then load the indicated url to try and verify if the pingback is legitimate (ie, if the url of the pinged blog actually appears on page), resulting in massive traffic spikes for the victim.

This works because WordPress pingbacks are poorly implemented. A more solid implementation would verify if the pingback originates from the same IP as the site that supposedly sent it, and discard the request if there’s a mismatch. The current implementation allows pingbacks to be sent by any arbitrary IP, and so allow a malicious user yet another DDOS vector.

Please do your part by fixing your pingbacks implementation. The easiest way would be to open the file xmlrpc.php found in the root directory of your blog installtion, and modify the part that says

// Let's check the remote site

		$linea = wp_remote_fopen( $pagelinkedfrom );

To instead say

// Let's check the remote site

    // First, make sure we're not being used for DDoS!

    if (gethostbyname(parse_url($pagelinkedfrom, PHP_URL_HOST))
      <> $_SERVER['REMOTE_ADDR'])
      die ("Sorry, you will have to send this from your blog's IP.");

    		$linea = wp_remote_fopen( $pagelinkedfrom );

This checks that the IP of the domain you think you’ve been pinged by and the IP of the client informing you were pinged match, and dies if they don’t – rendering this particular DDoS avenue inoperable while maintaining all the pingback functionality you could possibily want.

Thanks for being part of the solution!

WordPress community, sound off? Does this vulnerability really exist, and if so, is it possible to fix it in the core? What do you think of the proposed solution? Could there be a possible downside to it?

I’m not a programmer and I had never heard about such a vulnerability before, but since my blog was one of the blogs implicated (the list is almost 300 MB, have asked the blogger to check it for me) I’m obviously quite concerned and I wonder if other people have heard of or experienced such attacks before.

Someone must have injected something into my site, and it does a never-ending loop, redirecting it back to wp-admin/install.php. No, I did not forgot to install wordpress, the Site has been installed long before and has been running for Months already. I don’t know if you’ll be able to view this, but that’s my site above, and I can’t load my site anymore because it’s been “Looping”.