And that explains the redirect issue (Updated by AWA)
A years-long campaign by miscreants to insert malicious JavaScript into vulnerable WordPress sites, so that visitors are redirected to scam websites, has been documented by reverse-engineers.
An investigation by analysts at Sucuri into malware found on WordPress installations revealed a much larger and ongoing campaign that last month, we’re told, hijacked more than 6,600 websites. The team has seen a spike in complaints this month related to the intrusions, according to analyst Krasimir Konov.
Anatomy of a campaign to inject JavaScript into compromised WordPress sites
Just when you thought you found a somewhat stable platform, assholes have to come and screw it because they can.
“As new vulnerabilities in WordPress plugins are discovered, we anticipate that they will be caught up in the massive ongoing redirect campaign sending unsuspecting victims to fraudulent websites and tech support scams,” they wrote.
Basically, we are far from over.
Update from AWA.
Yes, it looks like this is a description of what was happening to the site. To me, the more interesting part is how they kept coming back to try different methods.
Their first method was to infect every javascript file on site. The were able to run arbitrary PHP code which did the infection. Their second method was to add PHP code to specific wordpress files such that every page did a redirection. By this point we had locked the site down hard enough that they couldn’t modify files anymore. Their third method was to add HTML code to a half dozen postings which caused anybody that visited those postings to be redirected. Their last method was to inject javascript code into every posting.
The first three methods did not match the article given. The last one produced results that are the same as what the article suggests.
Bad guys need to be able to insert code in such away that administrators don’t see the injection. They do this in a couple of ways. The most common is to write code that looks like it is just regular javascript like jQuery but in reality is hiding nefarious code. They use to do this by using base64 encoding and then simply decoding a long string and executing it. They used other methods like that as well. Today most good administrators know to look for base64 strings and to treat them as suspect. This was part of the first injection attack.
They have since moved to encoding strings in the path of code execution. So they have a bunch of small arbitrary strings and then combine them to create an actual program. Consider “a quick brown fox jumped over the lazy dog”. From this one string you can pull ‘h’ from “the”, ‘t’ from “the”, “p” from “jumped” and so on. You can construct any set of words this way. They use this method to hide what their true intentions are.
What makes the newest attack vector so insidious is that the first URL used looks like it should belong. Did Miguel actually want to use the emojii package from legendarytable? If so there is no reason to be suspicious of this URL being called. And because emojii code is pretty complex and dispicable to begin with, having another source of emojii isn’t a concern. It is only when it is discovered that legendarytable is calling drakefollow that things start to get suspicious. Again, the name isn’t completely unreasonable. It is only when drakefollow randomly forwards your browser that you realize that it is malicious.
This meant that we had to track down the legendarytable reference. It didn’t appear anywhere in the code. Our lock down functioned as expected regarding that. The means it must be in the database. We searched every record of the database until we found a reference. That told us where to look. Once we discovered what was in the database and where it was in the database we wrote some custom code to remove it from the database.
This means that the site is safe for the time being. We are using more and different tools to help keep it safe.
Thank you to all of our readers that sent in error reports with screen shots. Thank you for the reader that sent in the link to the article. And thank you to all our readers that sent in suggested WordPress plugins to help protect the site.