Web Spammers Also Abusing MediaWiki Websites at Major Universities

In looking over recent web spam activity, we have noted two trends. Abusing functionality of popular web software and doing that with websites from major universes. So another element of this isn’t surprising. Spammers are adding spam pages to websites running MediaWiki from major universities.

Here are the latest pages added to a Harvard hosted MediaWiki website:

And here are the latest pages added on a University of California, San Diego hosted MediaWiki website:

Both of those websites are running MediaWiki 1.16, which was only supported through November 2011. So these websites look to have long ago stopped being maintained.

MediaWiki provides various ways to restrict access to editing, which can prevent old websites from being overrun with spam like this when they are no longer actively intentionally edited.

If you have a website that has web spam content placed on it, we can help you to get it cleaned up and hardened to avoid additional issues.

Transferring SuiteCRM to a New Web Hosting Account

If you need to transfer a SuiteCRM website to a new hosting account, either at a new web host or another account at the same web host, the process usually isn’t too hard. But there are things that can go wrong, so below we go through the important things to do as you are working to accomplish that in way that leads to a smooth transfer.

Test Before You Switch

When doing a transfer like this, the best advice is to do a test of the transfer before you make the final switch over. That way, if any problems come up, you can work on resolving them without having to rush the process.

Transfer the Files

You will need to transfer the files from the old hosting account to the new one. That is usually most easily done using FTP or SFTP to copy the files from the old hosting account to a computer and then copying them from there to the new hosting. That also provides you with a backup of the files.

Transfer the Database

You will need to copy the database from the old hosting account to the new hosting. That is usually done through phpMyAdmin, to export a copy of the database from the old hosting account, and using it to import that copy of the database to a database on the new hosting. Though there may be other options depending on the hosting setup. You will need to create a database on the new server to import the existing database.

Update The Configuration File

Once you have copied the files and the database, you will need to update the SuiteCRM configuration file, config.php, in the new hosting to have the credentials for the new database.

Plan for a Switch Over

After you have tested out everything and confirmed that it works, plan for a time to switch over to the new hosting. You will need to allocate time for recopying the database and if the files have changed, the files as well. You also need to allocate for the time it will take for the website’s domain name to point to the new web hosting.

You will also want to make sure that access at the old hosting is blocked, so no more changes are being made once you start the final transfer process.

Redo The Transfer and Point The Website’s Domain to New Hosting

Once you have made a final transfer of the database and possibly the files, you need to update the records for the website’s domain name to point to the new server.

Getting Help

If you need help with SuiteCRM, we offer support and we offer a service specifically to handle transfers like this.

Various WordPress File Upload Functionality Being Abused by Web Spammers

Last week, we looked at various methods that spammers are using to place spam pages and other content on websites. That includes abusing web software, such as a Drupal module on websites from high-profile universities, and a feature of the Wix website builder service. It wouldn’t be surprising to hear that WordPress websites were also involved considering how widely used the software is and how many plugins there are that extend it that might not be hardened against abuse.

In checking over things, we noticed that a website from John Hopkins university had this happen with the Formidable Forms plugin. The website did block access to the uploaded file, with this message:

You are receiving this message because your request triggered one of our security firewall policies. Johns Hopkins faculty and staff may try accessing this page through the JH Pulse VPN Johns Hopkins VPN or MyCloud. If these methods don’t work, contact webhosting@jhu.edu and provide the full URL and support ID below.

Your support ID is: 3030507284814651859

[Go Back]

On a Princeton website, based on the location of the file, it looked like the plugin WP Feedback, Survey & Quiz Manager, later renamed to eForm was the source.

On a website of Southern Illinois University Edwardsville, the file was uploaded to WordPress’ standard directory for uploaded files. Making it unclear what the source was.

The situation is a good reminder that even if file upload functionality is secured to prevent malicious files being uploaded and a hacker taking over the website; it is still possible for file upload functionality to be abused. If you have file upload functionality, where the file uploads don’t need to be web accessible, making sure they are not accessible that way stops web spammers from abusing it.

If you have a website that has web spam content placed on it, we can help you to get it cleaned up and hardened to avoid additional issues.

GitHub Apps and LinkedIn Pulse Being Abused by Web Spammers

In the last few days, we have been looking at various aspects of a web spam campaign. We have found that, among other things, websites from various major universities have been impacted by this. We also found that GitHub and LinkedIn, which are both owned by Microsoft, have been impacted by this and they don’t seem to be doing a great job of catching that.

One aspect of this involves GitHub Apps. Here is one example of spam pages on there:

That, in turn, links to a page on LinkedIn Pulse:

You can see that was published a week ago and is still up.

What is going on with the account that was posted through is unclear. It is listed as a financial services company, but the rest of the description isn’t in line with that:

There is another account for what appears to be the same entity that seems more credible, as among other things, it lists them in the music industry

Brigham Young University CDN Being Abused by Web Spammers

The last few days we have been looking at what web spammers have been abusing to place spam files on various websites. Some of that has involved various websites from major universities, including Duke and Harvard. That isn’t all that surprising as they can have a lot of websites and they can stay up despite no longer being actively used. More surprising is that we found that a CDN belonging to Brigham Young University is also being used, and that appears to have gone unnoticed. Here is an example of spam files that have been included in Google search results from that:

So Google also seems to have a problem with catching web spam as well.

Also, it is worth noting here that Google is willing to display a claim that something has 7,447,548 votes:

That claim comes from data in the file:

<script type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "SoftwareApplication",
      "name": "VBUCKS",
      "operatingSystem": "ANDROID",
      "applicationCategory": "GameApplication",
      "aggregateRating": {
        "@type": "AggregateRating",
        "ratingValue": "4.8",
        "ratingCount": "7447548"
      },
      "offers": {
        "@type": "Offer",
        "price": "9999.00",
        "priceCurrency": "USD"
      }
    }
    </script>

It’s unclear how the spammers are getting the files on that CDN. It looks like you need a login to access the university’s Brightspot CMS that would seem to be connected to the CDN. Possibly, a compromised login could be used here. Though, based on other parts of the campaign, it seems possible that some upload functionality on websites is being abused to do this.

We have alerted Brigham Young University about what is going on.

Kentico CMS Still Being Abused to Host Spam Files on Websites, Possibly Through Vulnerability

Two days ago, we looked at one method web spammers are using to post spam files on to websites, abusing the Webform module for Drupal. Another aspect of this involves a less popular content management system, Kentico CMS. Like the abuse of that Drupal module, this isn’t a new issue. Lorenzo Franceschi-Bicchierai covered this situation in June of last year at TechCrunch.

What is going on there, though, isn’t as clear. The TechCrunch article had this response from the developer of Kentico CMS:

“We are aware of this particular risk that could have happened with Kentico 12 or older versions. This was identified years ago as a result of a misconfiguration, and we already addressed it at the time and changed our documentation,”

It’s unclear what addressing it means and if this was an end-user misconfiguration or a developer misconfiguration.

The security fixes listed version 12 of Kentico CMS on the software’s Hotfixes page, including two fixes for vulnerabilities that allowed uploading files that shouldn’t have been allowed. We found another claim of a similar issue that was supposed to have been addressed in version 11.0.45 of the software, though we couldn’t find a mention on the Hotfixes page of a security fix in that version.

So this is possibly caused by a vulnerability in an old version of Kentico CMS or possibly abuse of intended upload functionality that was addressed in new versions of the software.

For those running Kentico CMS or other web software that have websites that appear to be hacked, we can help you to get that properly cleaned up.

Wix Groups Being Abused For Web Spam Campaigns

Yesterday, we noted how web spammers were abusing the Webform module for Drupal to place spam files on websites. We continue to look into that spam campaign and found another interesting aspect of it. Spammers are also abusing the Groups feature of the Wix managed website service. That is notable, as services like that are supposed to handle a lot of the work for you. It would seem like flagging this type of spam is something they should be doing, but it doesn’t appear being doing that.

In one example we looked at, the spam campaign was also apparently abusing LinkedIn as the content posted on the Wix Group on a website was linking to now non-existent pages on LinkedIn:

That same impacted website, a Christian academy, also had spam added to the group that seems more problematic to the specific website, as it was promoting pornography:

It seems like Wix could do a better job of handling this. It also is a reminder that spammers will take advantage of the ability to post content on websites, so any functionality that allows that should be disabled if not used and otherwise be moderated.

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.

Joomla 3 Doesn’t Contain Unfixed Critical Remote Code Execution Vulnerability

Last week, the developers of Joomla released fixes for a number of vulnerabilities that have existed in the software. As is often the case, journalists (or at least people claiming to be journalists) and security researchers made overstated claims about those. Those claims included that the vulnerabilities were critical in nature and that one of them leads to remote code execution (RCE). Neither of those things is true.

With the claim of a RCE vulnerability, which would be serious, the reality is that this involved a reflected cross-site scripting (XSS) vulnerability that Joomla rated as of moderate severity. That is a type of vulnerability that causes malicious JavaScript code to be output if access a specially crafted URL. And is a type of vulnerability that you don’t see exploit attempts on any large-scale basis. It isn’t a big concern, which might explain why you have journalists and security researchers often hyping up the worst-case scenario with it and not clearly noting the lack of real risk.

That vulnerability also actually involves an issue with PHP, which has been addressed, but only in supported versions of PHP. Joomla’s update addresses it for those running unsupported versions of PHP.

This vulnerability and the others being fixed exist in Joomla 3. Support for Joomla 3 ended in August of last year, meaning that there isn’t generally available official update for those running Joomla 3. There are several options for getting security fixes for it, but you would be better off upgrading to a supported version as soon as possible. That is something that we can help you with.

Just Because a WordPress Plugin You Use Has a Vulnerability It Doesn’t Mean It Got Your Website Hacked

As we have talked about recently, there is often confusion over how websites have been hacked. One issue that comes up from time to time is the claim that a WordPress plugin that contains an unfixed minor vulnerability is the source of a hack. Here is one recent claim of that:

i would strongly urge you to remove it now. My site was hacked several times before I realized it was because of this plug in. It sucks because I was unable to find a replacement and have to do it by hand.

The vulnerability that is known to exist in that plugin would allow someone logged in to WordPress with the Contributor or Author role to cause malicious JavaScript code to be included on frontend pages on the website. (Higher level-users already have the capability to do the equivalent of that.)

Unless you have an untrusted individual with access to WordPress with the Contributor or Author role, either intentionally or because someone with that level of access had their account breached, you don’t have to worry about that. So the chances of that being exploited are slim.

It’s possible that the quoted individual had that situation, but almost no websites will, so the chances of the plugin being the cause of hacks on websites is very small.

Trying to figure out how a hacked WordPress website was really hacked is a standard part of our hack cleanup process for WordPress websites. Our hack cleanups include a free lifetime subscription to our Plugin Vulnerabilities service, which includes providing fixes for unfixed plugin vulnerabilities.