Drupal

Spammers Still Abusing Drupal Webform Module to Put Spam PDFs and Pages on Websites

It is common for hacked websites, whether running Drupal or other software, to be used for web spam campaigns. But there are other methods for putting spam content on websites. While looking into a spam campaign covered by Bill Toulas in a story at the Bleeping Computer, we noticed there are at least several issues that were being used by the spammers. One of those includes abusing the Webform module for Drupal.

Here was the URL for one spam page included in Google’s search results from a website of Duke University:

https://healthpolicy.duke.edu/sites/default/files/webform/speaker_request/3878/HYL5z.html

The beginning of the directory structure there, /sites/default/files/, is something that those handling Drupal websites might recognize, as that is a structure that Drupal uses. The website is running on Drupal 10.

A spam PDF from a website from Harvard, which is running Drupal 7, also showed up in the results:

https://www.nmr.mgh.harvard.edu/files/webform/vbucks-wgu-rih.pdf

What they also have in common is the /webform/ directory is where the spam was stored. That is the directory used by the Webform module for Drupal.

This isn’t a new issue. Here was the beginning of an issue report for that module from November 2021:

We have a simple form that has a file upload feature to attach PDF documents. It gets spammed by bots by uploading random PDFs without submitting the form. The files stay uploaded in the server and can be accessible at /sites/default/files/webform

The reporter of the issue went on to note another problem here:

Anti-spam modules like Google reCAPTCHA are bypassed, because you need to fill it only to submit the form, spammer does not need to submit the form to fill the server with advertised PDF files.

A simple solution to spammers being able to abuse that is by not having files uploaded through that stored in a public location. Though, as a reply on the issue report noted, there are still other issues:

IMO It’s a low-risk security problem. In our case PDF files with malicious links are submitted constantly. These malicious files are uploaded to private folder and then deleted by cron, but malicious files are constantly being sent so there are always some malicious files on the server.

This is still a risk by our users because they can find this files using modules like IMCE or File browser. Uploading a PDF, PSD or GIF file in a user accessible folder can be used to exploit a zero-day vulnerability like FORCEDENTRY if users are using a mobile and simple check the file, or include malicous links inside PDFs files to try to pishing if someone found this files browsing.

Uploaded files should be uploaded to temporally folder and then moved to private or public folder when the form was submited and validated. This would be safer because forms implement anti-bot filters that are being skipped in file submit.

The good news for those being hit by this for spam is the solution is pretty simple. For those that have actually had their Drupal website hacked, the process for addressing that is a lot more complicated. If you need a hacked Drupal website professionally cleaned, we can handle that for you.

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.

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.

GoDaddy’s Bad Response to the Drupal 7 Vulnerability

Back on October 15, Drupal released Drupal 7.32, which resolved a highly critical security vulnerability that existed in prior Drupal 7 versions. Unlike security vulnerabilities that have been fixed in recent years in Drupal and other major software, this vulnerability was easily exploitable. By the next day we were seeing attempts to exploit the vulnerability and we have been seeing a steady pickup of people contacting us about cleaning up their hacked Drupal websites, which were hit due to this. The speed and scope of the exploitation points to the need to improve how security vulnerabilities are handled in Drupal and more broadly.

Since making software that is completely free of vulnerabilities is next to impossible the best solution for this type of situation is to introduce an improved upgrade mechanism, like the one in WordPress. Starting with WordPress 3.7, security updates are automatically applied without requiring any user intervention. Checks for new versions are normally done every 12 hours and the WordPress server can instruct them to happen more frequently ahead of a planed update, so within a day most websites will have the security update applied. Not only does this protect those websites, but it makes the remaining vulnerable websites a less attractive target since the success rate of trying to exploit the vulnerability is much smaller (that doesn’t mean that they won’t get hacked though).

In the meantime, getting the word out on the need to update or take remedial as soon as possible is important to lessening the severity of security vulnerabilities. In this case Drupal recommend restoring a backup from before October 15 if you didn’t upgrade right away and every day that passes makes it harder to do that. Web hosts could play an important role in getting the word out. At least some of the largest web hosts already have the capability to detect what software and in some cases what version is in use, so they can inform impacted customer of the situation. GoDaddy has attempted to do this for the Drupal 7 vulnerability, though their implementation leaves a lot to be desired.

Today we have had a number of people contacting us saying that they had just been informed of they needed to upgrade Drupal due to a security issue. Considering that the last security update for Drupal 7 was 7.32 and that was released in the middle of October we were wondering what was causing this. It turns out that GoDaddy has just been letting people know of the vulnerability. While rather late, what was more problematic was what they said in the email.

The first big problem is that based on their email you would think that that is just occurred:

A few days ago Drupal announced a “Highly Critical Public Service announcement” that affects all Drupal users. In short, there’s a major security vulnerability that attackers can leverage against your visitors.

The Highly Critical – Public Service announcement was released back on October 29, not a few days ago. Even before that was released it was widely known that there was urgent need to update as the details of the vulnerability were disclosed with the release of the update on October 15.

The email gets more problematic from there. The beginning of the emails indicates that the required action is updating:

Action required:

Update your Drupal website

Later it says:

It’s extremely important that you update your site immediately to ensure you’re not putting your customers at risk.

At this point if you have Drupal 7 website still running a version below 7.32, that hasn’t been otherwise protected against the vulnerability, you should assume that it has been hacked, so just updating isn’t an appropriate resolution. That isn’t mentioned in the email at all, despite the public service announcement they cite being very clear about that.

Drupal Did Not Recommend This

After reading over this we were curious to see if GoDaddy was spreading this bad information on their website as well. It looks like they only got around to mentioning the issue on November 6, but at least in that case they provided accurate information. Another article linked to from that page those highly inaccurate though. Specifically the section Manually Remove Backdoors, which says:

If you do not have a backup of either your website or database (or both), you must manually remove any backdoors from your Drupal installation.

To do this for you, we offer an Expert Service for $79. With this service, we will perform all of the work for you to make our best effort to remove all backdoors using the procedures identified by Drupal. This service does not guarantee your website is free from compromise, but it is as close to compromise-free as anything can come if your Drupal installation wasn’t upgraded before the first reported compromises or restored from a backup created before Oct. 15, 2015 at 11pm UTC.

To purchase the Expert Service, contact customer support.

You can also manually remove any backdoors yourself using the Drupal-recommended procedure outlined here. This procedure is very complicated and requires an advanced understanding of the technologies Drupal uses (PHP, MySQL) to use effectively. Not all steps listed in the procedure are applicable to shared hosting environments, but completing what you can from this list will provide you the greatest likelihood of removing backdoors from your site.

If you follow the link “the procedures identified by Drupal”, you will find that it isn’t actual something from Drupal. Later GoDaddy links to the same page and describes it as the “Drupal-recommended procedure”, but if you actually look at the page it says “The official recommendation is: Restore from pre-October-15-backups.”. You really have to wonder about a company trying to sell you on an “Expert Service”, for which they don’t have the expertise to actually understand a basic, that is they they are citing something that isn’t actually procedures identified by Drupal or recommend by them.

Drupal 7.32 Usage Reached 24 Percent in Second Week

With a highly critical vulnerability found Drupal 7 versions prior to 7.32 and with Drupal providing data on usage of various versions, a good opportunity to see at what speed websites are being updated when there is a pressing need to do so is available now. Last week we found that in the first week only 12.46% of Drupal 7 websites had been updated to Drupal 7.32. In the second week it has now increased to 23.77%. We should note that it is possible to patch the vulnerability without doing a full upgrade, so not all websites that have not been upgraded are necessarily vulnerable at this point.

Drupal 7.32 usage has now surpassed to 7.31 usage, which was also a security update. What is rather troubling is that 59.28% of Drupal 7 websites haven’t been updated to at least 7.31 despite it being released nearly three months ago.

For those in need of an upgrade we provide one time Drupal upgrades and ongoing upgrades for Drupal 7 (with security updates in a day). You can use our Drupal Version Check chrome extension and Up to Date? Chrome app to keep track of the update status of Drupal websites you manage.

Exploit Attempts of Drupal 7 Vulnerability Are Reminder That Hiding Software Versions in Use Isn’t a Security Measure

When it comes to securing website there is lots of bad advice out there, much of it coming from people that claim to have security expertise. A prime example of this bad advice is the claim that hiding version of software in use on the website will somehow protect you being hacked. While there a number of reason it won’t protect you, the central issue is that most hackers won’t bother checking if you are using software, much less what version of the software is in use. Instead they will simply try to exploit the vulnerability without checking anything first. That means that no matter how hard you try to hide the version information it won’t protect you if you are running a vulnerable version. Seeing as people continue to believe and tell others that hiding versions information is a security measures we thought it would be a good time show a real world example of this in action.

Recently a highly critical vulnerability was found in Drupal 7 versions below 7.32 and shortly afterward attempts to exploit it were happening. Below is the series of requests from one of those attempts that occurred the day after the vulnerability was fixed:

62.76.191.119 – – [16/Oct/2014:21:03:25 -0400] “POST /?q=node&destination=node HTTP/1.1” 200 4929 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0”
62.76.191.119 – – [16/Oct/2014:21:03:26 -0400] “POST /user HTTP/1.1” 500 3566 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0”
62.76.191.119 – – [16/Oct/2014:21:03:27 -0400] “GET /?q=ocyuys HTTP/1.1” 404 6035 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0”
62.76.191.119 – – [16/Oct/2014:21:03:27 -0400] “GET /ocyuys HTTP/1.1” 404 6035 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0”
62.76.191.119 – – [16/Oct/2014:21:03:28 -0400] “GET /modules/profile/mhtd.php HTTP/1.1” 404 6035 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0”

The IP address the requests came from, 62.76.191.119, appears to have been used for a widespread attempt to exploit the vulnerability.

Looking at the requests the first thing that sticks out is what isn’t requested. If you were going to check what version of Drupal is in use the first thing to request would be the file CHANGELOG.txt, which on Drupal websites will contain the Drupal version in use, if the file hasn’t been deleted. Since our website is running Drupal and we haven’t deleted the file the hacker have seen that we were running version 7.32 and therefore were not vulnerable. If the CHANGELOG.txt file doesn’t exist then you could check other files to get some idea of what version is in use. In this case the vulnerability only exists in Drupal 7, so a hacker might check for a file that exists in that version and not in Drupal 6.

Instead of doing any checks first, the hacker first request appears to be an attempt to exploit the vulnerability. The log of requests doesn’t include the POST data, so we don’t exactly what was done, but it was likely something similar to the POC #1 listed here. The rest of the requests seem to be checking if the first request was successful.

Beyond this being a reminder that hiding software is not a security measure, it is an important reminder that you need to keep the software running up to date. Something people running Drupal 7 websites have not been good at doing. It also highlight the fact that many people dealing with security have little understanding of it and in many cases are not doing the work they should do. Determining how a website has been hacked is one of the key things to properly cleaning up a hacked website, yet we see over and over we are hired to re-clean hacked websites that person hired before hadn’t done that. If people were doing that then they would know that hackers are not checking for the versions of software in use and therefore wouldn’t be telling people that hiding software versions is security measure.

Only 12 Percent of Drupal 7 Websites Upgraded to 7.32 In First Week

One of the basic measures needed to keep websites secure is to keep the software on them up to date, as that prevents them from being hacked due to a known vulnerability in the software. That unfortunately isn’t something that people are very good at doing. With Drupal you can get fairly good data on how well people are at keeping up to date due to the developers publicly releasing data on what version are in use. When we looked at the data in late March we found that only 33 percent of Drupal 7 websites were up to date and only 72 percent of Drupal 7 websites were up to date or less than year out of date.

With a highly critical vulnerability fixed in Drupal 7.32, which hackers started exploiting shortly after the fix being released, we are curious see how fast websites are being updated. The first week of data, for the week of October 19, has now been released and it shows that only 12 percent of websites have been upgraded to 7.32. We should note that it is possible to patch the vulnerability without doing a full upgrade, so not all websites that have not been upgraded are necessarily vulnerable at this point.

That number is better than with a previous, less severe, security update. We previously look at the rate that Drupal 7 was updated to 7.27, which fixed a moderately critical vulnerability. In that case after a week only about 5 percent had been upgraded and it was only up to about 15 percent at two weeks.

What is more troubling is how few websites have been upgraded to the previous release, Drupal 7.31, which fixed a moderately critical vulnerability. That version was released on August 6, so there has been plenty of time for an upgrade. As shown in the chart below, at this point 62 percent of Drupal 7 websites are still running a version below that:

Drupal 7.32: 12.46%, Drupal 7.31: 25.74%, Drupal 7.30 or older: 61.80%

Drupal Websites Not Receiving Security Updates in a Timely Manner

At the end of March we took a look at Drupal’s usage statistics and found that two months after new versions of Drupal 6 & 7, which included security updates, were released only 33 percent of Drupal 7 websites were running the latest version and only 19 percent of Drupal 6 websites were running the latest version. That obviously isn’t what you would like to see if you care about security.

It has now been two months since another set of security updates, 6.31 and 7.27, have been released. The percentage of websites that have updated to at least those versions isn’t much different from what we saw with the last set of updates. 29 percent of Drupal 7 websites are running at least 7.27 and 17 percent of Drupal 6 websites are running 6.31.

For those interested we have graphed the percentage of websites that have been upgraded over time:

Drupal 7 Update Pace Graph

For both Drupal 6 & 7 the graphs show that during the first two weeks after a new version is released there is pretty quick uptake and then it slows down.

With drupal.org still running 7.27 a month after 7.28 was released that might indicate that the upgrade process could be improved:

With our Up to Date? Chrome app you can keep track of the Drupal versions (as well other web apps) on all of the websites you manage in one place, so you can easily check if they are in need of an upgrade.

Another Major University is Running Outdated and Insecure Version of Drupal

Last week we spotlighted the fact that only a third of websites running Drupal 7 are up to date. As keeping the software running a website up to date being an important security measure and with the most recent version of Drupal 7 being a security update that obviously is a problem (though certainly not a problem limited to Drupal). What makes this more troubling is that it isn’t just small websites that are not keeping their software up to date, but large institutions that are more than capable of doing the upgrades. In gets worse when you see institutions that have departments focused on the technology security that are failing to keep their software up to date. Last month we looked at the fact that the University of Cambridge was running an outdated version of Drupal, while the blog of their Security Group was running on a very out of date version of WordPress. They unfortunately are not alone.

Using our Drupal Version Check web browser extension, available for Firefox and Chrome, we can see that the Rutgers University website is still running Drupal 7.21:

That version is now a year out of date and two security updates have been missed (7.24 and 7.26). Making sure the website is kept up to date is something that you would hope that Rutger’s University Information Protection and Security Division would be on top of, but they are not even keeping their website up to date:

That website is less out of date than the main Rutgers website as the current version of Drupal 6, 6.30, was released in January, but it was a security update so they should have gotten it upgraded by now.

For those reading this and realizing they need to get their Drupal installation up to date, you can find the upgrade instructions here.

Only One-Third of Drupal 7 Websites Are Up-To-Date

Earlier this month we looked at some data from our tools showing that large percentages of Joomla, WordPress, and MediaWiki websites checked with them were running outdated versions of the software. For Drupal, there is much more comprehensive set of data publicly available that comes from the Update status/Update manger module. To get a better idea of how well webmasters are at making sure Drupal websites are being kept up to date we have analyzed the data reported for March 16, 2014, which has data on over a million websites. Making sure the software running websites is a basic security measure and when they are not it can lead to them being hacked if the vulnerability can be used for that (as we have been seeing recently with a vulnerability in older versions of Joomla).

At this point a large majority of the websites, 79 percent, using Drupal are using version 7. Of those only 33 percent are running the latest version, 7.26. This is troubling as this version was a security update, so websites running older versions are potentially vulnerable to being hacked. This version was released on January 15, so even websites that need extensive testing before apply an upgrade should have been updated by now. Looking beyond that, 72 percent of the websites are either up to date or less than a year out of date so the majority of websites are probably getting updated, if somewhat infrequently.

Drupal 7 Version Freshness: Up To Date 32.75%, Less Than 1 Year Out of Date 39.72%, More Than 1 Year Out of Date 22.53%, More Than 2 Years Out of Date 5.00%

For Drupal 6 the situation is worse. The latest version of Drupal 6, 6.30, was released alongside of 7.26 on January 15, but so far only 19 percent of websites have been updated to that version. The situation in terms of somewhat recent updated websites is also worse, with only 64 percent of website being up to date or less than a year out of date. 20 percent are at least two years out of date, which means they have missed at least four security updates.

Drupal 6 Version Freshness: Up To Date 18.62%, Less Than 1 Year Out of Date 45.06%, More Than a Year Out of Date 16.59%, More Than 2 Years Out of Date 11.34%, More Than 3 Years Out of Date 6.46%, More Than 4 Years Out of Date 1.90%, More Than 5 Years Out of Date 0.02%

To make it easier to check for Drupal websites in need of an update we have made the web browser extension Drupal Version Check, available for Firefox and Chrome, which in most cases will identify what version of Drupal is in use and in others indicate if the website is using an outdated version of Drupal.

If you are in need of a Drupal upgrade we can do that for you or we can also handle upgrades on an ongoing basis, so you don’t have to worry about taking care of this.