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.