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.

How to Change the Email Address that WPForms Lite Sends Contact Form Submissions To

As part of helping to deal with a problem where a contact form done through the WordPress plugin WPForms Lite wasn’t getting sent to the intended email address, we had to figure out how to change the email address the submissions get sent to. It isn’t the most clear process, so for those that have more trouble than us, here are the steps to take to change that:

  1. Log in to WordPress
  2. Go to the plugin’s All Forms page
  3. Click the Edit link for the relevant form
  4. Click on the Setting menu
  5. Click on the Notifications submenu
  6. Change the Send To Email Address setting to the desired email address.

Getting Help

If you need help with this type of problem or another problem with your WordPress website, we offer a support service to help.

Why a WordPress Contact Page Isn’t Emailing the Submissions

We were recently helping someone deal with an issue where they were not receiving emails for submissions to the contact page of their WordPress website. There are a multitude of different ways contact form submissions are handled and different ways that could go wrong, but there are three principal problems that lie at the heart of that to sort through if you have that problem. Let’s go through those.

The Contact Form Isn’t Working

The first problem is that the contact form isn’t working. So first make sure that when making a submission, it returns a response that the submission has been successful.

Depending on what plugin you are using to handle contact form submissions, the plugin may store a copy of the submissions. Or there may be an additional plugin you can add that will store submissions. If that is an option, that will allow you to make sure the submissions are really getting through and being processed.

Emails Are Not Being Sent

If the contact form is working, the next possible problem is that emails are not being sent. If you are receiving other emails from the website, you can rule that out. If you are not sure about that, you can use a plugin to test if emails are being sent. You can also use a plugin that logs emails being sent to confirm if emails are being sent.

Emails Are not Being Received

If you know that emails are being sent, then the problem that could be that they are not being received at the intended email address.

One way to test this is to try having the emails sent to another email address at a different email provider. That gives a good chance of seeing if there is a problem related to the email account. It could be that it trips a spam filter.

In the situation we were helping with, it turned out that the email account wasn’t receiving the submissions, but when switching to another account, the emails went through.

Getting Help

If you need help with this type of problem or another problem with your WordPress website, we offer a support service to help.

The Difference Between a Backdoor and a Vulnerability on Your Repeatedly Hacked Website

If you have a reoccurring problem with a hack of your website, there are multiple causes that could underly it. Two of those, a backdoor and a vulnerability, are sometimes confused. Understanding the difference is important to dealing with the problem.

A backdoor is some method for the hacker to continuing access to the website, which they place on the website. That often is a file that the hacker can send commands to on the website and those commands will run. Those backdoor files can sometimes be rather complex, but other times are really simple.

A vulnerability is an existing security issue on the website that gives a hacker some access they shouldn’t have.

A key difference between these two issues is how you deal with them. If you were to restore the website back to its state before the hacking, a backdoor couldn’t exist on the website. A vulnerability will still exist if you do that.

Another key difference is who has access in each situation. With a backdoor, only one hacker would have access, unless some other hacker figures out about their backdoor. A vulnerability, by comparison, could be exploited by many hackers.

We recently had someone come to us that thought there was a backdoor on their website, but the change being made with what they thought was a backdoor allowed any hacker access. What they actually had was a vulnerability they hadn’t addressed.

If you need help with a hacked website, we can help you.