Friday, 18th July 2014
The world is waking up without suspecting that a wave of attacks has affected thousands of WordPress sites.
Even up to date in their version of their favorite CMS, the attacks came from elsewhere, it is not WordPress itself that is at issue.
One can always ask the question “Will not there be a flaw in WordPress?” And even if it happens, I have never seen a wave of piracy following an undisclosed flaw in WordPress.
The vulnerabilities are discovered by the team in charge of security, and also by the contributors: you! Then they are corrected in a minor branch and a version come out quickly in order to keep the fault less known, without patch.
Who Has Been Affected?
This is totally random, you will find people with a dedicated server, others with a shared hosting. Some have a custom theme, others a Premium theme from the forest. Some still use 2 plugins, others 20. Needless to look for a common point among these people, the wave tries to exploit several flaws in one go to make profitable.
Why attack websites?
Haaaa the famous question! The shortest answer would be: You (your site) represent a resource on the net, you are a bandwidth, you are a place of storage, you are the starting point of emails, you are a starting point for Backlinks SEO blackhat.
You will be used to relay viruses, spams. Even if you only keep the blog of the pony club with 2 visits per month (you, to check that it goes well!), Even if the target of your site are the retired, the content, SEO does not matter, you will be targeted and exploited if the flaw exists in your site.
So how did it happen?
Chances are it’s a plugin. And no, I will not say “This is MailPoet!” As Sucuri did on his blog who had the case on his clients. YES, MailPoet is part of the list, but the list is long and has no end …
On the other hand, there is a good chance that it is a flaw in a plugin, discovered recently. Here is the list of plugins affected between June 18th and July 18th (from the most recent to the oldest):
- Gallery Objects 0.4 SQL Injection
- WPTouch Authenticated File Upload
- CopySafe PDF Protection 0.6 Shell Upload
- Tidio Gallery 1.1 Shell Upload / XSS
- Download Manager 2.6.8 Shell Upload
- BSK PDF Manager 1.3.2 SQL Injection
- MailPoet wysija-newsletters Unauthenticated File Upload
- NextGEN Gallery 2.0.63 Shell Upload
- blogstand-smart-banner.1.0 Cross Site Scripting
- ml-slider 2.5 Cross Site Scripting
- wp-construction-mode.1.8 Cross Site Scripting
- Simple Share Buttons Adder 4.4 CSRF / XSS
In bold, those that allow the upload of a malicious file. There are six, it’s huge in such a short time.
NextGen has been downloaded 10 times more than MailPoet, potentially 10 times more likely to make a site vulnerable.
And then?
The same day Maxime BJ created an article to talk about the attack and some think of MailPoet, others are not sure. Personally, even if my clients and I were not affected, a follower told me that one of his sites had been hit, without MailPoet.
Same thing in the Sucuri post, some yes, some no. I do not like that we throw a plugin name that will take all the thunders of other flaws.
I even read a comment saying it was still up to date everywhere and that it was using a ThemeForest. As if the TF was a guarantee of quality, sorry to spit in the soup because I use it, but they are VERY often vulnerable …
I also see the preventive and effective solutions of some, and I see WordFence in the heap. Just to tease, my next article here will concern it following faults found, I say no more, wait for a patch for it …
What does the attack do?
The attack, any plugin mixed among our 6 incriminated permits to add, upload a PHP file containing malicious code.
It allows to have an almost complete access, as on an FTP. Free to your imagination of what one can then do of the site.
The backdoor is first added to a folder, then when it is first launched, it is duplicated in the header of all the PHP files of the site. Sometimes it duplicates itself everywhere in the installation, sometimes it replaces the contents of plugin files, etc.
Their detection is not simple because the content changes, the variables take random names, which makes the pattern of detection unstable. No script allows you to find everything exhaustively.
It has happened on some installations that an administrator is added, to the name or ID “1001001”. This is not related to a backdoor, certainly, we can do it, but I rather see the feat of a flaw SQL injection. Reread the list of the last vulnerable plugins … This flaw of an admin added in 1001001 has existed for more than a year, so it is not MailPoet.
So what to do?
You might say “No problem, I have backups!”, And that’s the drama. Why ? Because the backups were there when you lost the site, or the database, following a bad manipulation in prod.
But NEVER use a backup after hacking. The reason is simple. Once the malicious files are sent, the exploitation of this backdoor is not instantaneous. The hacker (or via its zombies) will wait several days, weeks, months before activating. The goal ? Wait to enter your backups …
And it works, the proof is that another comment from Maxime says he found a file uploaded 1 month back and another more recent. For me, it means that the recent one quickly exploited the fault, the other was still waiting before moving.
Adding a security plugin would be the minimum to do. Here we have installed SecuPress Pro, maybe you use others like Wordfence or iThemes Security or Sucuri Security? But if it’s installed a posteriori, then it’s almost useless, it’s not going to solve anything.
My advice, I would tell you to search the database and look for unwanted JS script, unwanted META tags, that kind of thing.
For files, delete everything that is core, theme, plugins, and re-upload everything to clean with the latest versions.
For the upload folder, make sure it does not contain any PHP files, otherwise delete them, even the index.php. If you want to avoid listing the contents of your folders, use the following .htaccess rule: Options -Indexes
Also, in the uploads folder, prohibit the execution of any PHP file, there must NEVER be PHP in this folder, the plugin that does, made a mistake, I discussed it with Andrew Nacin if it can to convince.
Use this .htaccess file that you will add in /uploads/:
[pastacode provider=”manual” lang=”markup” manual=”%3CFiles%20*.php%3E%0ADeny%20from%20all%0A%3C%2FFiles%3E”/]
With this, all PHP files are forbidden to run, their direct access returns a 403 Forbidden error.
Of course, and above all: keep your plugins up to date, make backups to at least retrieve your uploads and the database if it is clean, but, I repeat, never use them like that, search, clean or bring in A web security pro.
Finally
It’s not THAT MailPoet’s the faulty, even if YOU have been hit by its fault, Friday’s attacks also come from other plugins or themes.
