Jen McCown

Update

Wow, there was a lot more wrong with everything than I originally thought. (How many times have we said THAT in tech?)

It wasn’t just 1 or 2 files that had malware…it was 155. And two websites.

The solution (at least, I hope this has solved it):

1. Install and use the WordFence plugin. The free version of this found issues on THIS website, which (again, I hope) I was able to resolve. And I got the paid version for my other site…155 files. I spot checked them. They were all spammy/malware-y.
2. Clear cache. I was able to log into our hosting provider’s control panel, adjust the server-side cache settings, AND clear the cache for the entire website.

That appears to have done it! …..I hope.

I guess if I stumble across rogue code like the code below, it’ll be an instant red flag to perform those two steps again. But I imagine WordFence will catch it before I do.

The original post…

One of my WordPress-backed websites started redirecting to (what were clearly) dangerous sites, and I had a bit of a time tracking down exactly what and where the issue was.

Long story short: the Elementor and Essential Elementor Addins plugins had been compromised!

This article was essential in helping me track down the rogue code. In my case, it was in the file public_html/wp-blog-header.php

The rogue code in question looks like this:

Note that just updating the two plugins wasn’t enough to clear this code. I had to do it manually. The hack doesn’t work any more, luckily, but I still likely have some cleanup to do around the website’s back end.

In future, if I do end up searching PHP files for rogue code, I think I’ll start with the CHR for “.com” – which is:

chr(46)+chr(99)+chr(111)+chr(109)

And the CHR for “.js”, which is:

chr(46)+chr(106)+chr(115)

---

Follow us on MinionWare.net/Articles…we write an AWFUL lot more over there.

And follow me on LinkedIn. I’m more active there than I’ve ever been!

An experienced DBA I know didn’t realize this: if you look at sp_help or sys.columns for an NVARCHAR column, the max_length value will show up as double the allowable length.

Let me explain.

CHAR and VARCHAR length is normal

Let’s say we have a “val” column in a table, and it’s of type VARCHAR(10).

CREATE TABLE test (val varchar(10));
GO
EXEC sp_help 'test';

When we run that sp_help statement, we see that the max_length for val is 10:

You’ll see the same thing with the query SELECT name, max_length FROM sys.columns WHERE object_id = object_id(‘test’);

NCHAR and NVARCHAR length displays as doubled

Now we create a new table, and “val” is of type NVARCHAR(10).

CREATE TABLE  ntest (val nvarchar(10));
GO
EXEC sp_help 'ntest';

For some ungodly reason, sp_help shows that max_length is 20:

And again, you’ll see max_length = 20 with the query SELECT name, max_length FROM sys.columns WHERE object_id = object_id(‘ntest’);

But the nvarchar length is not REALLY doubled

Let’s test this out. Both of the tables have a column that is (10) long. So these will work:

INSERT INTO test (val)  VALUES ('1234567890');
INSERT INTO ntest (val) VALUES ('1234567890');

But these will both return a “String or binary data would be truncated” error:

INSERT INTO test (val)  VALUES ('123456789011');
INSERT INTO ntest (val) VALUES ('123456789011');

Speculation & Answers

My DBA friend said, “It must be showing bytes instead of characters.”

Yes, and also no. Here:

• CHAR/VARCHAR datatype uses one byte per character
• NCHAR/NVARCHAR uses two bytes per character

BUT we also know that VARCHAR and NVARCHAR use 2 extra bytes to record how much space was actually used in that variable-length string. So no, it’s not the storage space for the field.

Microsoft provides us the answer:

“…in NCHAR(n) and NVARCHAR(n) the n defines the string length in byte-pairs (0-4,000). n never defines numbers of characters that can be stored. This is similar to the definition of CHAR(n) and VARCHAR(n).”

Docs.Microsoft.com, “nchar and nvarchar”

Oh well, there you go then!