Interesting Newsletter SPAM

[Dirty Butter]

First of all, I am NOT using the default Newsletter sections of CC5. Instead I have added the API code from MailChimp to my sidebar in main.php and to content.account.php and commented out all the default sections.

So, it's interesting when I checked my Customers list I found what appears to be a fictitous name and that they are "subscribed" to the default newsletter. I assume that means they've hacked something. Should I be concerned? Is this a security problem of some kind that needs to be addressed? Should I delete, rather than comment out the default newsletter code? Is there some other place I should get rid of newsletter code?

[bsmither]

main.php and content.account.php only controls the logic of displaying the page. It does nothing about processing GET and POST data sent into Cubecart.

I am not yet sure how I come to be at the following, but it seems that a properly formatted URL with an attached POST key/value (easy when you know how) will still be interpreted by CC5 and do what it originally did.

In the CC5.0.6 file cubecart.class.php, line 296, the code could hit on "_a=newsletter" or "_a=unsubscribe". If so, private function _newsletter() at 1735 is executed. (Oh, cool! CC5 can archive a series of newsletters.)

In this function, POST['subscribe']="email address" is dealt with in the file newsletter.class.php, line 31.

Also, the file gui.class.php will cycle through the jobs of activating the the various boxes when building the entire page, including the newsletter box. At line 678, a test is made for POST['subscribe'] and the value is dealt with in the newsletter class.

At no point I can discern is a test made to determine if a session has been established. That is, if a session has been established, then it stands to reason that the source of the form entry is from a visitor who is at your store (instead of a robo-form filler).

So, there are a few points of interdiction - none of which have a pre- or post-processing hook. (Well, maybe. Right at the start of index.php, there may eventually be an opportunity for a pre-process hook that will strip the POST keys subscribe, unsubscribe, and newsletter if any exist. (But I have no idea, yet, how to use these hooks.)

I would suggest in the newsletter.class.php file, line 31, add return false just after the opening brace.

This should stop any and all attempts to have emails recorded in the CubeCart_newsletter_subscriber table.

But you said you saw a weird name in the customer list. Maybe (and I am not going to check on this right now) the CubeCart_customer table joins with CubeCart_newsletter_subscriber table to indicate what you saw.

[Dirty Butter]

I would suggest in the newsletter.class.php file, line 31, add return false just after the opening brace.

This should stop any and all attempts to have emails recorded in the CubeCart_newsletter_subscriber table.

Is this what you meant for it to look like?

public function subscribe($email = false) {return false

		// Subscribe, generate validation email, and send

		if (filter_var($email, FILTER_VALIDATE_EMAIL)) {

Should I delete these obviously fake customer info entries or leave them alone?

[bsmither]

That is what I meant it to look like. Oops, add a semi-colon after false.

You can certainly do whatever you like concerning the fake customer info entries.

[Dirty Butter]

I added the semicolon and deleted the obviously spam Customers. BUT I've had a new one show as subscribed to the newsletter since doing that. So there's somewhere else they've found that lets them add themselves as a customer. Is this a security hole?

[bsmither]

There are three total instances of directly inserting a record into the CubeCart_newsletter_subscriber table: newsletter.class.php, user.class.php (an option to subscribe when registering), and cubecart.class.php (via GET in the URL or POST form element).

The cubecart class POST element uses the newsletter class and we have dealt with that. However, the cubecart class also scans the GET input and will directly insert into the table instead of letting the newsletter class do it. But, the GET input only works if the existing customer is logged in.

So we need to come to an understanding that when registering, an option exists to subscribe to the newsletters. Also, once registered, a logged in customer can change their subscription status. Finally, an anonymous visitor can subscribe (which we have dealt with).

Therefore, to be clear, is your complaint that visitors seem to be able to register to be customers when you don't want them to via a newsletter subscribing 'backdoor'? The code suggests this is not the case. They are not subscribing in order to register, they are registering in order to subscribe (or rather opting in). So, the 'fictitious name' in your customer list should have come from the act of registering.

Let's look at user.class.php (line 675): Just after the returned data from the registration form is recorded in the _customer table, the _newsletter_subscriber table also is given a corresponding new record with status=1 (don't know what that means).

I think you have a robo-register problem. But your complaint comes about because we have not dealt with this one (of three) points of the _newsletter_subscriber table acquiring new records. So...

We need to inhibit the auto-insertion of records into the _newsletter_subscriber table in this section of code. One way is to do this:

677: if (isset($_POST['mailing_list'])) { continue;

By adding continue after the open brace, we immediately exit this if() construct and resume processing the customer's registration.

(There are obvious indications that Devellion is still working out how the newsletter system is going to work.)

[Dirty Butter]

I think you have a robo-register problem. But your complaint comes about because we have not dealt with this one (of three) points of the _newsletter_subscriber table acquiring new records. So...

We need to inhibit the auto-insertion of records into the _newsletter_subscriber table in this section of code. One way is to do this:

677: if (isset($_POST['mailing_list'])) { continue;

By adding continue after the open brace, we immediately exit this if() construct and resume processing the customer's registration.

(There are obvious indications that Devellion is still working out how the newsletter system is going to work.)

Since I've deleted the fake customers for right now I'll wait to add the continue; to line 677, so I can check to see if a new fake customer ends up in the _newsletter_subscriber table.

As for Status=1 - I would have guessed that if a previously subscribed newsletter person unsubscribes it would change to zero - BUT I tried changing one record to zero and it still shows as subscribed in Admin, even after emptying cache. So I put it back to 1.

[Dirty Butter]

I just found the "leak", and it's my fault. Since I didn't want to mess up the code I just commented out the default subscription info. I was looking at the homepage Source code for something else and noticed the commented out newsletter subscription code. I copied the link and it subscribed my currently logged in test account to the default newsletter. So that's how the bot is doing it IF they have logged in with fake info. I've deleted the code out of the commented out portion.