Hacked or Hiccup?

[Dirty Butter]

I realize these emails started showing up in my inbox at 2:45AM on April Fool's Day, so the thought occurs to me that some Hacker was just having "fun". Anyway, I had to delete over 9,000 notice email copies of a "New Order" in Outlook this morning for dirtybutter.com/plushcatalog. The order does NOT show as Pending in Admin, and the email itself had no order number, item, or any order specific info at all. And the error log has this information repeated all 9,000+ times (with the same order_id on all of them..

 

 

The arguments are:
status_id => 2
order_id => INV2-MFYW-TZMC-S9AG-R55D
force =>  in /home3/butter01/public_html/plushcatalog/classes/order.class.php on line 720
[01-Apr-2014 08:28:29 America/Chicago] PHP Notice:  Order::orderStatusDid not email anything because + or no content to send

 

Has this ever happened to anyone else? Now that I'm over freaking out, and I was able to delete all the emails, should I still be concerned? We do have SSL enabled for plushcatalog and ReCaptcha is enabled as well.

[bsmither]

I read a conversation where, under a weird set of circumstances, CubeCart will "go ballistic" with emailing a notice of an order. Maybe I can find that post.

 

The entry in the error log is something you and I had discussed, quite some time ago, about trying to find out why your store wasn't emailing anything at all.

 

It's nice to know your hosting provider doesn't automatically ban all outgoing emails, as if the server had a limit.

[Dirty Butter]

I remembered you had something to do with being able to see that error message, and I was kind of glad to see it there, so I could tell the "order number" was not of the correct configuration.

[bsmither]

So, you do not recognize the "format" of the order number?

 

Interesting. I'll have to trace out the code to see what happens when a rogue IPN comes in to CubeCart.

[bsmither]

This is the conversation:

'?do=embed' frameborder='0' data-embedContent>>

[bsmither]

Your sig says you are at CC524. Is that true?

 

What payment gateways do you have enabled? Modules, not Plugins.

 

Whatever the modules that are enabled, I see that, generally, the module's gateway class starts collecting transaction data, then adds more pertinent data based on the transaction result.

 

But before that data is logged in the Transactions database table, CubeCart will first move the order to its respective status (making an email), and recording the respective payment status (also making an email). The consequence is that we do not know where the IPN came from.

 

You would need to examine your web access logs at about 2:45am (local - adjust for the server's time) to find the URL that triggered it.

[Dirty Butter]

I'm on 5.2.5 and will not upgrade until 5.9 is available. There's a glitch with my account here that occurred when I stopped being a mod. I can't edit my own sig any more. Al had to make my links active in my sig, but I can't edit it at all.

 

Anyway - our stores use the Sequential Numbering mod, so the last actual order we had on plushcatalog was #2014-PC-2493.

 

Thanks for the link you gave. I'll go look at it now.

[Dirty Butter]

Well, I read it, but I did NOT have any record of these orders in the database or admin. The headers look legit. I use the PHP function email system.

[bsmither]

I am of the opinion that you would not have any record in the transaction table. The reason is that, whatever is causing the "infinite loop" to send emails, will eventually reach PHP's time limit for executing a script. Then, the web server will send a 500 Internal Server Error response back to whoever initially made contact containing suspect data.

 

Typically, PHP will timeout after 30 seconds. That's plenty of time to put 9000 emails in the queue.

[bsmither]

I would still like to know which payment gateway you think this was associated with.
 
In your store settings, Features tab, is "Order status for admin email notifications" set to Pending or Processing?

 

Please use phpMyAdmin to look in the CubeCart_order_history table. Is there a record with the cart_order_id, possibly truncated, starting with:

INV2-MFYW-TZMC-S9AG-R55D

[Dirty Butter]

They ARE all listed in the order_history table. The history shows statuses of 2 and 3 corresponding to each history_id, and they all have the same order cart_order_id.

 

Our store is set to send emails on Processing, and the only payment choice available is the PayPal gateway.

 

And to make matters even more interesting, I have not been able to successfully delete the corrupted emails from my web server after all. HostGator support was not able to do it either from chat and has escalated the ticket.

[bsmither]

"The history shows statuses of 2 and 3 corresponding to each history_id."

 

But no initial status 1? That is, without the order going to Pending, then we know it wasn't started within CubeCart. I would like to know where that a rogue IPN (need to check the web access logs) came from. From PayPal? Actually, the IP address would be fine.

 

So, status 2 (Processing), then status 3 (Completed). That means CubeCart believed the order to be digital only.

 

Then went back to status 2. And that's were the code needs to be looked at (as well as a number of other places).

[Dirty Butter]

Host hasn't solved it yet, and I had 900+ more dated 4/2 today. So it's still happening. I don't know how to find the IP addresses in all the "stuff" that shows up in the raw access logs.

[bsmither]

Ok, I think I found the logical loop. Until I verify it, please treat this as experimental. Make these change to /classes/order.class.php:

 

Line 196:

Was:
$currentStatus    = $GLOBALS['db']->select('CubeCart_order_summary', array('status'), array('cart_order_id' => $order_id));
Now:
if(($currentStatus = $GLOBALS['db']->select('CubeCart_order_summary', array('status'), array('cart_order_id' => $order_id))) !== false) {

Line 202-203:

Was:
  return false;
}
Now:
    return false;
  }
} else { return false; }

The above intercepts a non-existent cart_order_id and sends false back.

 

In case self::ORDER_PENDING;, just above the break; statement, add unset($content);

In case self::ORDER_PROCESS;, just above the break; statement, add unset($content);

In case self::ORDER_COMPLETE;, just above the break; statement, add unset($content);

Currently, $content is unset only if the Mailer was able to load the email template. If the Mailer was not able to find or load the template, $content would be false.

 

Dropping down to the end of the switch() block (line 315), we test for whether $content is set. It is! $content is set to false. Luckily, there is no order_summary data, so there is no email address for the Mailer to send to.

 

<*> Going back, if an order is being set to Processing, right away $complete is set to true. Because there is no inventory to loop through, $complete never gets set to false. ($complete means to go do the Complete phase, as if this order was digital only.) Line 330 takes us eventually to ORDER_COMPLETE.

 

The first test in ORDER_COMPLETE is to see if this order never went through Processing. This ends up being the case for two reasons: the search for the record in CC_order_history will not be found because there is no matching cart_order_id, and when ever we enter the orderStatus() function, the second thing that is done is to record the order's change in status via the addHistory() function -- which will fail.

 

The next test is if the store setting, "Don't check skipped order processing email" ('no_skip_processing_check') is set to OFF. Which means, "Do check if this order skipped the Processing stage."

 

We get sent to ORDER_PROCESSING. Go to <*>.

[Dirty Butter]

I did put a Support Ticket in to CC yesterday and received notice this morning that a change was made to order.class.php "to avoid non existing orders status change and email sending."

 

My file now has this section, but I don't know if that's the change they made, or the only change they made.

// Update order status, manage stock, and email if required
		if (!empty($status_id) && !empty($order_id)) {
			$currentStatus	= $GLOBALS['db']->select('CubeCart_order_summary', array('status'), array('cart_order_id' => $order_id));
			if ((int)$currentStatus[0]['status'] == 0) return false; // no order record
			// Insert order status if it's changed
			if((int)$status_id !== (int)$currentStatus[0]['status'] || $force) {
				$this->_addHistory($order_id,$status_id);
			} else { // Don't send out emails already sent!
				$this->_email_enabled = false;
				return false;
			}

[bsmither]

That's another way to interdict a bad cart_order_id.

 

By catching a bad cart_order_id, the chances of the rest of what might happen drops. (I won't say to absolutely zero.)

[Dirty Butter]

I do appreciate the time you spent tracking down the issue, as always, Bsmither!! I hope they include this in 5.2.9 so no one else will have to go through this. For some reason or other these corrupted emails could not be deleted normally from the web mail server, so I ended up with support tickets with my host and with CC. It would be a shame for someone else to have to go through all that, if this fix works.