WordPress

OneHourSiteFix’s Crazy Claims About WordPress Websites Being Hacked

Recently we got a spam comment on one of our posts that was meant to provide a link to onehoursitefix.com. The name given with the comment was “how to fix a hacked site” and the comment, which was irrelevant to the post, was:

You might be scratching your head at this point because you are
certainly not sure what tattoo. It is also a classical technique, which started out
for the dancers to seem weightless. s always preferable to let someone
know your location going and which route you.

It probably doesn’t say great things about that website, OneHourSiteFix, that they appear to need to promote themselves in that way, but that turns out to be much less concerning than the blog post we noticed linked to from their homepage.

The title of the post in the title HTML tag is “WordPress Website Defaced ? Due To A Well Known Security Company ?” and the on page title is “WORDPRESS PLUGIN VULNERABILITY MEANS MILLIONS FIND THEIR WORDPRESS WEBSITE DEFACED BY HACKERS”. The post is listed as being put out on June 26, 2017.

The first paragraph seems to be written by someone who has absolutely no idea what they are talking about:

Free open-source website and blog creation tool ‘WordPress’ has left millions of pages defaced, due to a remote code execution (RCE) feature being added to the package. This feature has allowed hackers to take control of pages using WordPress plugins allowing attackers control over editorial features in order to vandalize pages or even worse execute malicious payloads. Plugins are those great bits of extra software you can add to your WordPress site to do everything from show a map of visitors to show a fancy photo gallery. Plugins however, have always been a l known and documented ‘attack vector’ for hackers. An attack vector being ‘a way in’ or path into a website. The end result is millions of site owners have found their WordPress website defaced by hackers.

What it sounds like this person might referring to is a vulnerability that had existed in WordPress 4.7.0 and 4.7.1 that allowed attackers to change the content of posts and was fixed in January. It wasn’t a “remote code execution (RCE) feature” and there hasn’t been something like that added to WordPress. The vulnerability could have had more serious consequences if certain plugins that allow PHP code to be run in posts, which might be what the reference to plugins there is trying to refer to. There was nothing that could remotely be what is described there that happened in June, what did happen in January also doesn’t appear to have impacted millions of websites.

That explanation seems more likely based on the next paragraph (though it again doesn’t make much sense as written):

A well known security firm released a statement saying they had detected multiple hackers seizing control of sites. A backdoor in the protocol allows attackers to inject ads, spam and affiliate links. The security firm expects many more attacks to follow and even advised users to disable the plugins due to attackers using these them to insert malware into any affected website More often than not the old, ‘Hacked By GeNErAL’ ! types of defacement are being replaced by monetising hacks with compromised sites being used to make money for the hacker via the use of paid ads (selling everything from viagra, research chemicals to fake crypto currency exchanges) or redirect them to an ‘online pharmacy’

The fourth paragraph claims, which is below, would seem to confusedly reference what happened as well. As the exploitation only started after it was disclosed that WordPress 4.7.2 had included a fix for the vulnerability a week after that version was released.

What is also interesting is that before the security company released the details of the hack, very few WordPress websites had actually been compromised. The timeline in which the hack was detected, details released and then the fix released – does arouse suspicions amongst the conspiracy theorists amongst us.

The third paragraph makes a claim that seems crazy:

In March alone, over 45 million of WordPress websites were defaced and infectd. Many websites are still affected with many of their users not even realising that hidden within their blog there is a page that is selling some seedy pharmaceutical product . Often these hacked website pages are only found by using very specific search terms in google so blog owners are blissfully unaware that their sweet and innocent cupcake blog is actually harbouring a deep secret within the blog pages…

If it were true that 45 million WordPress website had been “defaced and infected” in just that month that would likely mean that a majority of WordPress had that happen to them. While the numbers seem to be a bit of an estimate, there are figures out there for the total number of WordPress websites at figures like 75 million according to a Forbes article from December. Clearly over half of WordPress websites were not hit during that month.

Another Very Odd Claim

In looking at their service there is another element that makes it sound like something is very amiss. One part of their service is cleaning up hacked websites and the other is a web application firewall (WAF) that is supposed to stop them from being hacked again. What is missing is the thing that should tie those together, determining how they website got hacked. If you don’t do that you can insure the vulnerability that was exploited has been fixed and the website won’t get hit again. That would also seem important to make a WAF effective.

Instead of doing what would actually prevent the website from being hacked again they make a claim that doesn’t sound believable:

IN ADDITION – our security experts manually analyse EVERY element of your site – every row in your database and every line of your files is checked and cleaned. This layered approach ensures we don’t just throw the hackers off a site – we slam the door on them as well.

That would take a very long time to do on most websites, yet somehow they are also going to fix the website in an hour, and it would likely be very ineffective since the sheer amount of information being reviewed would make it less likely that someone would spot a real issue among everything else.

On the page about their cleanup service there was a linked review that while giving them five-stars and seemed positive, indicated that this person’s websites have been repeatedly hacked:

Always quick, always clean.

OneHourSiteFix staff goes above and beyond everytime we’ve had an issue. Quick service, speedy cleaning, and even making sure sites like Google rank you site as safe again. We can’t thank them enough for keeping our servers from getting shut down by our service provider due to infections/spam. Top notch, our go to company for website cleaning everytime! Need help, look no further!

Which isn’t surprising based on what else we saw.

Security Plugins and Plugins by Automattic Haven’t Been Updated To List Them as Compatible With WordPress 4.8

Back on May 31 we received an email from WordPress.org asking us, as developers of several plugins, to make sure that the plugin were listed as being compatible with the then upcoming WordPress 4.8. The beginning of the message reads:

Hello, White Fir Design!

WordPress 4.8 is scheduled to be released on June 8. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.8. This information provides peace of mind to users and helps encourage them to update to the latest version.

As scheduled, that version was released on June 8.

While looking at something the other day we noticed that a security plugin had not been updated to list as being compatible with the new version. Looking at the plugins tagged security it turns out that many haven’t been two weeks after the release of that new version of WordPress. That doesn’t seem to be a great indication as to the state of security plugins, but more striking was that several of the most popular plugins tagged security that have not been updated come from the company Automattic, which is closely associated with WordPress.

First up being Jetpack by WordPress.com, which is tied with 6 other plugins for having the most active installs, 3+ million:

One of those other plugins with the most active installs is another Automattic plugin, which despite shipping with WordPress also isn’t listed with WordPress 4.8:

Getting back to the security tagged plugins, another Automattic plugin not listed as being compatible is VaultPress:

Among the other security tagged plugin that haven’t been updated to be listed as being compatible, you have iThemes Security:

You also have Sucuri Security, which still hasn’t even been listed as being compatible with WordPress 4.7, despite that being released in December:

The parent company of that plugin GoDaddy also hasn’t updated their other plugins to list them as compatible:

Also worth noting, considering SiteLock’s questionable involvement with WordPress, is the SiteLock Security plugin:

Google Handling Advertising For Website Serving “Nulled” WordPress Themes and Plugins With Malicious Code

Recently Google has been deciding to show ads for one of our services on websites serving “nulled” web software, which is paid web software being distributed illegal, possibly with security measures removed from it. That isn’t something we are interested in having our ads run on and we have excluded those websites from showing our ads. Today while looking into a hacked WordPress website that we were contacted about, we noticed that Google is handling the advertising for another such website, dlwordpress.com, where “nulled” WordPress themes and plugins are being distributed with malicious code in them.

At the top of the homepage are two ad blocks being served by Google (bordered in red):

The website (and the others that had included our ads) seems to pretty clearly be in violation of Google’s AdSense programs policy related to copyright material:

AdSense publishers may not display Google ads on pages with content protected by copyright law unless they have the necessary legal rights to display that content. This includes pages that display copyrighted material, pages hosting copyrighted files, or pages that provide links driving traffic to pages that contain copyrighted material.

The malicious code being reported to be served with the software at that website would seem to cause the website to violate a couple of their content guidelines as well:

Software or other content that violates the Unwanted Software Policy

Malware or adware

It doesn’t seem like it would be hard for Google to detect that these websites are engaged in the activity they are, so it seems if they didn’t want them to be in their advertising program they already could be excluded. We have been reporting the ones that have been showing our ads, though.

dlwordpress.com Warns About Similar Websites Distributing Files Containing Viruses

While the website prominently links to a page for filing DMCA takedowns for copyrighted content on the website, the website is promoting that it actually is involved in placing such content on their website, which would seem to remove the safe harbor protection that DMCA provides for websites:

While a WordPress theme’s (or a plugin’s) code would need to be licensed under the GPL and therefore can be legally distributed to others after being purchased, other assets included with them would not.

On the “Submit Your Theme or Plugin” page, they pretty clearly are requesting content that they know wouldn’t be legal for them to distribute. But more striking is that they ask people submitting themes and plugins to not submit them from other similar sites because they “can share files with viruses”:

Cloudflare Too

Google isn’t the only legitimate company involved with this website, as when we went to check to see where the website’s server was located we found that it is being served through Cloudflare.

A couple of months ago we found them doing the same for a website being used as part of a hack to compromise credit card credentials.

A Single Tweet Nicely Sums Up the Problem With WordPress Allowing SiteLock to Be Involved With WordCamps

The web security company SiteLock has a well earned reputation that can be summed up with what Google suggests when you type in their name:

That obviously isn’t a reputation you would think that any company would want. It would probably be difficult for SiteLock to legitimately change it though since their business model seems to be based around the activity that gets them labeled as such.

It would also be difficult because if they, for example, stopped partnering with web host to try to get people to pay them to clean up hacked website that are not in fact hacked, then they would actually have to really clean up websites to get paid and from everything we have seen they are even worse than the average web security company, which is already quite bad, when doing that. For example, we are often brought in to re-clean hacked websites after some other company had previously had done that and then the website got hacked again. While that isn’t always their fault, in almost every instance we have been told that the determining how the website was hacked never even came up, despite trying to do that that being a basic part of the cleanup and important to make sure the vulnerability that allowed the website to be hacked has been fixed. That is certainly something we have seen with SiteLock. What we haven’t seen with other companies is that SiteLock has caused websites to be broken after doing their work.

Instead of trying to change, SiteLock looks to have focused on various efforts to present a public face very different than the one that their customers and not always willing potential customers can find themselves dealing with. What looks to be an important component of that effort is their involvement and sponsorship in the conferences for WordPress, WordCamps, which uses money they have gotten from their questionable business practices. We think a tweet put out by one of those WordCamps succinctly shows what the problem with WordPress allowing that to occur is:

@SiteLock wants to make your WordPress secure. Like this tweet is secure. TY for being our amazing sponsor. Stop by their booth! #WCEU

— WordCamp Europe (@WCEurope) June 16, 2017

The claim that SiteLock wants make your WordPress secure is belied by many things we have run across, including a few recent examples: thinking that leaving malicious code on a website for a while is not a threat, not taking the actions needed to prevent hacked websites from being reinfected, and not warning about vulnerable plugins or insuring they are being kept up to date on a website they are supposed to be keeping secure. But maybe the most troubling recent example is that SiteLock is still knowingly spreading false information about the security of the core WordPress software and using it to make a profit. We would love to hear from someone on the WordPress or WordCamp side of things how that makes anyone’s WordPress secure.

At some point, maybe we have already reached that point, you have to say that WordPress is complicit in what is going on here. Back in September of last year we contacted the central WordCamp organization to let them know that about the issues with SiteLock and ask for a comment about the situation or a more general comment on any restrictions on who can be a sponsor. We never got any response from them, though it was pretty clear they saw the message. So it seems that they can’t actually justify what is going on, but are still willing take money SiteLock has gotten through less than above board business activity. We later left a comment on a blog post about SiteLock on the WordCamp US’ website, shortly afterwards the comments left on that post were removed and commenting was disabled, so there does seem to an effort to hide what is going on.

What could explain some of why they continue to allow SiteLock’s participation is that SiteLock’s owners don’t just sponsor WordCamps under the SiteLock brand, but also through brands of the web hosting company Endurance International Group, which they run. For example, at WordCamp Europe they were a higher level sponsor through EIG brands Bluehost and MOJO Marketplace (MOJO Marketplace also doesn’t seem to be too concerned about security):

Checkmarx Running Outdated and Insecure Version of WordPress

Back in November over at the blog for our Plugin Vulnerabilities service we discussed the fact that the security company Checkmarx was making a claim that a number of WordPress eCommerce plugins had severe vulnerabilities without providing any evidence, even what the name of the plugins was, to support that. That didn’t stop security journalists from covering the claim at the time. The details were supposed to be released later, but when went looking for them several weeks ago we couldn’t find them and when we contact Checkmarx to inquire about them, we received no response. At this point we think it is reasonable to wonder if the vulnerabilities ever existed.

It turns out though that this company that doesn’t seem to have a problem with making what appear to be baseless claims about the security surrounding WordPress, uses WordPress on its own website at the same time.

What should be surprising, but is an all too common occurrence, it also turns out that they are running an out of date and insecure version of WordPress on their website as can be seen in the source code of the website’s pages:

There have been four releases of 4.6.x with security fixed since then: 4.6.2, 4.6.3, 4.6.4, and 4.6.6 (they also have updated to the latest major release of WordPress, 4.7). The oldest of those was released over four months ago.

The plugin listing its version number below the line for WordPress is not surprisingly also out of date.

What makes their lack of updating stick out is that WordPress would have normally automatically updated without any action required by Checkmarx, due to the automatic background updates feature. So either Checkmarx’s server environment has some incompatibility with that (which they could help WordPress to get fixed) or they intentionally disabled them. In either case you should expect that a security company would be concerned enough about security enough to manually apply those updates.

With all of that, it doesn’t seem like it should be all that surprising that security is in such bad shape these days.

SiteLock Unintentionally Provides Reminder That They Don’t Keep WordPress Websites Secure

One of our long time concerns with the security industry is that that their efforts to sell more advanced security measures make it less likely that people will take more basic security measures. Right now even many security companies are not doing the basics when it comes to security and as a hacking of one of Trend Micro’s websites earlier this year showed, more advanced security measures are not necessarily even as effective as the basics.

Another example of this comes from a recent case study from the security company SiteLock where they highlight a website that is using a version of a WordPress plugin with known vulnerabilities while they falsely claim one of their services is insuring the website is “safe and secure at all times.”

The Unmentioned Business Relationship

Before we get the details of that it is worth noting that SiteLock isn’t being upfront about how they came to be involved with the website mentioned in the case study, which seems important when you consider they are leaving it insecure.

Here is their explanation:

One day Kasal unexpectedly received an email from his hosting provider alerting him that his blog had been infected with malware. Due to the stealthy nature of the attack, there were no obvious signs that his blog had been compromised. “I was unaware that my site had been hacked and at a total loss as to how to find or fix the problem,” he recounts.

Kasal’s hosting provider informed him that his blog would be taken offline unless he removed the malicious code that was inserted on his website. His host recommended he contact SiteLock_® to remove the malware and help prevent future attacks.

What they don’t mention is who the web host is or why they recommended SiteLock. Looking at the DNS records the web host is IPOWER. That is one of the many brands names that the Endurance International Group (EIG) does business under. That is rather important in explaining the recommendation, as it turns out that SiteLock’s owners are the CEO and a board member of the company and the company has disclosed that they get 55 percent of revenue coming from the sales of SiteLock’s services through a partnership they have. If there were not those connections we doubt the web host would be recommending SiteLock, considering the many problems with SiteLock (one the reoccurring complaints is that they sell protection services that don’t actually protect websites).

SiteLock Doesn’t Detect Vulnerabilities

The case study doesn’t go in to details as to how the website was cleaned, but no mention was made of doing two important parts of cleanup, making the website secure as possible (which usually mainly involves getting the software up to date) and trying to determine how the website was hacked. Based on our own experience being brought in after them to re-clean websites and everything else we have seen, it is likely those things were not done.

Without knowing what caused the website to be hacked you can’t say what would have prevented it from happening, but we can be fairly sure that SiteLock’s idea of a “proactive approach” isn’t the best way to secure the website going forward:

Once his website was clean, Kasal decided to take a proactive approach to website security by implementing SiteLock_® SMART^™, a daily scanner to help protect his blog from future attacks. SMART provides continuous file scanning to detect vulnerabilities and malware, including backdoor files and malicious code. If malware is identified, it is automatically removed and Kasal is immediately notified.

SMART also provides a full website analysis of each scan, ensuring Kasal’s site is safe and secure at all times.

It is strange that they are describing that as being proactive, since it is clearly reactive. If you are detecting malware on a website, it means it has been hacked and it wasn’t protected. There are further problems with that approach, like the inability to undo the compromise of a website’s data and that SiteLock has a limited ability to remove malicious code automatically (when they are even successful at detecting it).

A quick look at the website shows that is a couple of vulnerabilities that SiteLock must not have detected. Looking at the source code of the website’s pages you scan see that the version 2.9.45 of the plugin WordPress Download Manager is in use:

The plugin is several versions and a couple months out of date, with the next version, 2.9.46, having been released on April 17. That version fixed two vulnerabilities in the plugin, which is somewhat obliquely mentioned in the changelog with these two entries:

Added nonce check with settings form
Blocked unwanted file type upload

This is a perfect example of where doing the basics would be better, because if the website’s owner was keeping their plugins up to date they would actually be protected against those vulnerabilities. They wouldn’t even have to take manual action do that as there are a number of options available, including our Automatic Plugin Updates plugin, to have plugin updates happen automatically.

Keeping plugins up to date is free, unlike SiteLock’s service, but would another paid service actual have warned about those vulnerabilities? We know of one, our Plugin Vulnerabilities service, which warned about both vulnerabilities even before they were fixed (we also were the ones that discovered one of the vulnerabilities).

One last thing to note is that instead of SiteLock being able to tout that it actually detected those vulnerabilities or any other issue, they instead point to the number items checked:

SiteLock captured billkasal.com’s SMART scan results from a 30-day time frame. During the given 30 days, over 170,000 files, 120,000 links and 15,000 pages were thoroughly scanned for malware.

Sheer numbers clearly don’t equal quality.

Security Companies That Deal With WordPress Websites Should Understand That Usernames Are Not Considered a Secret

When it comes to improving the poor state of security one of the major impediments is security companies. Far too often they either don’t seem to understand the basics of security themselves or are intentionally telling people things that are false as means to push products that are not needed.

While looking into something related to another post we ran into the security company WeWatchYourWebsite again. The last time we did that, we found them providing what was claimed to be an example of hacker looking for infected websites, but was in fact something very different, a hacker trying to exploit a vulnerability in a plugin that was never on a website. Amazingly they claim to “specialize in root cause analysis” despite not having a basic understanding of the topic.

Since then they put out a post showing they didn’t understand the difference between brute force attacks, which are not happening, and dictionary attacks. And a post with this troubling line in reference to a WordPress website:

In this instance the hackers were able to find the admin username and guess the password. So, even though the owner took the step of changing the admin username, using an easily guessed password negates that.

We really can’t emphasize this enough, WordPress usernames are not considered a secret and therefore changing them is not a security step that could be negated.

What makes that mention seems so odd, is they seemed to understand how easy it can be to get the username on a WordPress website currently:

First, the hackers worked at finding out the name of the admin user. There were a number of these in the logs:

“GET /?author=1 HTTP/1.1”

“GET /?author=2 HTTP/1.1”

“GET /?author=3 HTTP/1.1”

“GET /?author=4 HTTP/1.1”

…and continued on by incrementing the integer after “author=”

Apparently it worked as the customer had changed their username for admin.

So either they had seen that WordPress has a major security issue (if the usernames were meant to be a secret) or they should have realized that it isn’t meant to be secret and not made a statement implying otherwise.

Journalists Spread SiteLock’s Fake Claim Involving Nonexistent Legitimate Plugin

When it comes to security journalism, there doesn’t seem to be much actual journalism going on. Instead much of what passes for news coverage these days simply involves repeating the claims of security companies, without doing any fact checking of those claims. This would be a problem just based on the low quality of information coming from security companies, but it looks to us that security companies have realized that in getting coverage what matters is not the truth but saying something that a journalist think they can get clicks by repeating.

A good case in point of journalist simply repeating a security company’s claims we ran across recently was a claimed trending WordPress security issue. Beyond the fact that no evidence was presented that actually backs up the claim that the issue was trending or that the issue was is some way actually significant (and deserved to be covered instead of another issue), something else stood out to us. In the security companies SiteLock’s post on this issue, they claim a “fake” plugin involved in the issue is a forgery of a legitimate plugin:

It is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

In coverage of the issue, that claim was repeated by journalists. Here is how it was reported in the Threatpost’s article:

The fake WP-Base-SEO plugin is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

Here is how it was reported in Infosecurity Magazine’s article:

Dubbed WP-Base-SEO, the plugin is a forgery of a legitimate search engine optimization plugin, called WordPress SEO Tools, according to SiteLock, the firm that originally uncovered the threat.

Finally here how it was reported in SC Magazine’s article, this time without naming the claimed legitimate plugin:

The fake plugin is called WP-Base-SEO and is based on a legitimate SEO module so it is easily overlooked during security scans and seems to be a viable tool by a web team intent on boosting its traffic, said a research team at SiteLock.

The problem with all this is that the supposed legitimate plugin WordPress SEO Tools doesn’t exist. If you do a Google search on the name or on WP SEO Tools it doesn’t bring up results for a plugin with that name. Looking at the Subversion repository that underlies the Plugin Directory, where most plugins are found, there are not entries for a plugin with the slug wordpress-seo-tools or wp-seo-tools.

This should have been something that journalists could have easily checked and if they had look into that they might have realized something was amiss here.

In a quick check over this, something else also stands out to us. While the reason for this issue getting covered is that the “fake” plugin is supposed to be trending, it looks as it might be rather old (or at least based on something that hasn’t been updated in a long time). That is particular noticeable in the screenshot provided by SiteLock of the plugin’s header comments:

The copyright there is 2013, though on its own wouldn’t mean much, what is more noticeable in dating this is this the Plugin URI, which is http://wordpress.org/extend/plugins/. If you visit that URL now you are redirected to https://wordpress.org/plugins/, which is the address of the Plugin Directory. So why would the URL include “extend” when it doesn’t exist the URL you are redirected to? The answer is that the “extend” used to be part of the URL, but that was removed on May 22, 2013 (the switch to HTTPs occurred in 2014). Based on that it is entirely possible this malicious plugin isn’t a new issue, just being promoted that way so that a security company could get coverage.

The Obviousness of Unnatural Reviews for a WordPress Security Plugin

An important element of security is trust, seeing as most people are not going to have ability to independently verify what a security product or service is doing what it is claimed to do and instead have rely on the those behind it to be truthful. What we have seen in our experience with the industry is that they don’t even really attempt to be honest with the public, instead correctly seeing that they can get away with misleading and outright lying because the checks that should exist against that are not working. The end result of this is current poor state of security.

Over at the blog for our Plugin Vulnerabilities service today we looked at a security plugin that fails to actually do its most important function. We also noted that most of the reviews for the plugin look like they came from people that were connected to the plugin, which provided a distorted view of the plugin.

That plugin certainly isn’t alone among WordPress security plugins having many reviews that don’t look to have come naturally. Another plugin we came across within the last few days pretty obviously has unnatural reviews. The plugin WP Security Optimizer has 4 reviews despite having less than 10 active installs:

That is well beyond even an extremely high number of reviews for the amount of active installs. By comparison our plugins have the following mix of reviews to installs:

Automatic Plugin Updates: 9 reviews / 10,0000+ active installs
Plugin Vulnerabilities: 14 reviews / 5,000+ active installs
No Longer in Directory 10 reviews / 1,000 active installs

Not only are the reviews out of line with the number active installs, but three of the four accounts used for the reviews were created on the same day as the review and have not been used for anything else (the fourth was created several days before the review).

Also like many other plugins it is promoted in a way that is likely far from reasonable, considering that the description of the plugin begins:

Prevent hackers to sabotage your rankings in search engines.

While we haven’t tested the plugin against real vulnerabilities yet, it looks like it is mainly focused on trying to hide the fact that a website contains vulnerable software instead of doing anything that could resolve the website being vulnerable. Considering many times hackers don’t do any checks before trying to exploit a vulnerabilities, it wouldn’t do much to prevent hackers from succeeding.

WordPress Plugin Directory’s New Search Algorithm Still Failing To Show Plugin When Searched For By Its Name

Earlier this week the refreshed version of the Plugin Directory section of wordpress.org went live. One of the touted features of it is an improved search algorithm, but the new algorithm clearly still needs some work as it still is having problems showing plugins when they are searched for by name.

While that used to be the case for one of our plugins, changes made during the open beta fixed that. Unfortunately it isn’t the case for another plugin we happened to be doing a search for the other day, BuddyPress Docs.

Here are the first page of results:

It doesn’t show up there and a lot of results don’t look like they could be considered more relevant for the query.

The plugin finally shows up more than half way through the second page of results (22 plugins in all are shown before it):