The WordPress Plugin and Theme Editor Must Go
…or “How WordPress Gets Hacked”
The prelude
With so many reports of WordPress sites being hacked in one way or another, I decided to see how exactly WordPress sites are being invaded. The WordPress Codex has an excellent FAQ section titled “My site was hacked“, and it’s great. Hardening WordPress is another fantastic entry that deserves even more attention.
Not so long ago, I setup a honeypot on one of my private servers. I grabbed the latest stable version of WordPress and installed it. Waiting for any new WordPress vulnerability to be exploited would not be viable (although the TimThumb vulnerability is occasionally being attempted). I considered the latest stable version of WordPress secure, correctly setup, so I chose the single weakest link in the chain, located between the chair and the screen – the Admin.
Thus, the most practical point of entry was set to be the login screen, with a simple username and password set – admin:admin. Simple enough. The hardest part was to get the site indexed so that malicious bots would start knocking at my door. I set up a simple content spinner to get things going (sorry, Google).
About two weeks later the first attackers joined the crawler party. A fair share of automated commenting, some automated vulnerability scans, both specific to WordPress and not, and of course wp-login.php bruteforcing. Eventually something did get in. Here’s what it did:
15623-##########.ru:80 host-41.215.241.146.citynethost.com - - [16/Feb/2012:16:16:39 +0500] "POST /wp-login.php HTTP/1.0" 302 932 "-" "Mozilla/4.0 (compatible; Synapse)" 15625:##########.ru:80 host-41.215.241.146.citynethost.com - - [16/Feb/2012:16:16:42 +0500] "GET /wp-admin/theme-editor.php?file=/themes/twentyten/404.php&theme=Twenty+Ten&dir=theme HTTP/1.0" 200 28115 "-" "Mozilla/4.0 (compatible; Synapse)" 15626-##########.ru:80 host-41.215.241.146.citynethost.com - - [16/Feb/2012:16:16:45 +0500] "POST /wp-admin/theme-editor.php HTTP/1.0" 302 598 "-" "Mozilla/4.0 (compatible; Synapse)" 15627:##########.ru:80 host-41.215.241.146.citynethost.com - - [16/Feb/2012:16:16:48 +0500] "POST /wp-content/themes/twentyten/404.php HTTP/1.0" 200 539 "-" "Mozilla/4.0 (compatible; Synapse)" 15629:##########.ru:80 host-41.215.241.146.citynethost.com - - [16/Feb/2012:16:16:49 +0500] "POST /wp-content/themes/twentyten/404.php HTTP/1.0" 200 539 "-" "Mozilla/4.0 (compatible; Synapse)" 15630-##########.ru:80 host-41.215.241.146.citynethost.com - - [16/Feb/2012:16:16:52 +0500] "POST /wp-admin/theme-editor.php HTTP/1.0" 302 598 "-" "Mozilla/4.0 (compatible; Synapse)"
An unexpected turn of events
This was quite unexpected. I completely forgot about the fact that WordPress had built-in Theme and Plugin Editors stashed away in the Plugin and Appearance menus. Last time I used one was at least 4 years ago, and even then it didn’t work.
And it didn’t work because it requires PHP to be able to write to the editable files, so permissions would have to probably be set. Unless PHP is almighty for the files the editors are useless. Changes can’t be made, and that’s great, right? I think so.
A lose-lose situation
In most correct (you’re-doing-it-right) setups, site administrators wouldn’t have specifically set permissions for PHP to write to any of the wp-content files, and the files wouldn’t belong to a user or group that PHP belongs to. So the WordPress built-in Editors are of no practical use.
In setups where PHP does have permissions to write to files and the password is not strong enough, Houston would have a problem, wouldn’t it? <?php if (isset($_GET['cmd'])) echo system($_GET['cmd']); ?>
appended or prepended to a file would be the beginning of all problems. So the WordPress Editors are a major security risk, aren’t they?
Why give WordPress administrators functionality to edit files from the Dashboard in the first place? If they’re using these built-in Editors they’re probably not advanced users, they’re bound to mess things up. A relation between the probability that the password is of the admin:12345 type and the probability that the administrator uses the Editors is bound to exist.
The editors must go
You don’t use these Editors, do you? I bet you don’t.
They were introduced more than 7 years ago and all code has been since rewritten, but the concept remains the same – allow editing of PHP files via WordPress. People who know what they’re doing never use them, people who don’t – get hurt eventually.
Thinking about the rookie
In one-click setups of WordPress, offered by popular web-hosting companies, the permissions are set for seamless updates (although permissions don’t have to be set for ‘ftpext’ updates) and plugin/theme editing. That’s indeed convenient, since users won’t have to go FTP. But then don’t be surprised, especially in shared environments, how WordPress sites are hacked en masse, even with secure passwords. The PHP user is probably shared (unless you suexec), so once it’s under control, the whole node would be. Depends on the host of course.
Maybe provide access to the style.css file only as it appears to be the least dangerous file of all (unless it’s execution bit is set or all files are forwarded through CGI, which is rare). If a rookie is wanting to edit PHP files he’s got to at least learn FTP; being incapable of FTPing one’s way to PHP files smells like trouble when giving easy access via built-in Editors.
If you know of a rookie that would not agree with the fact that they should know their way around FTP before editing PHP files, ask them to add the following code to their theme’s functions.php via their shiny built-in WordPress Editor to achieve God Mode (an unhackable shell will surround their site immediately):
<?php add_action( 'init', 'iddqd' ); function iddqd() { /*SET_GOD_MODE = true, never*/die('iddqd'); } ?>
Getting rid of the Editors
Thanks to ever-seeing @Rarst, the correct way to disable the Editors is to use the DISALLOW_FILE_EDIT
configuration “directive”. Maybe the solution to the whole problem would be to have it enabled by default?
Conclusion
Do you use the built-in WordPress Plugin and Theme Editors? Would you miss the editors if they’re suddenly gone?
I started to use the built in editor just to implement small quick fixes where I didn’t have time to connect to FTP.
I use to use Netbeans as my IDE but for some reason Netbeans would decide to double all my line breaks. On a bad day Netbeans would even decide to put my whole PHP file onto a single line and break a whole site since a comment would end up commenting out a whole line/file. I couldn’t find an editor that worked how I wanted so I’ve been working on my own editor using the ajaxorg editor (same as c9.io) and combining that into a plugin to pimp the built in editor. Giving it line numbers, syntax highlighting, code completion, automatic file backup etc.
This solution is not without issues but I’m now working on a newer version that is totally separate to the built in editor (just in case they remove it!). The new version has tabbed editing, it’s own file browser and just works better.
I agree the built in editor should go as it’s easy to break a site even with the best intentions but I do think there is room for a better editor plugin. I still see there is a security whole there but maybe it’s down to hosts to allow users to easily lock down a websites permissions when the site is not being modified/updated.
A web based editor is so convenient and if attached to a single WordPress instance you’ve got your whole environment there waiting.
– Save your open tabs.
– Code completion with links through to codex and other docs.
– Automatic backup of all edited files as a minimum.
– Git version control where available
– .LESS
– Live CSS editing
– Syntax check before upload
Being web based there are so many opportunities to link into API’s and do some cool stuff.
Simon, very interesting input. Some online IDEs offer FTP connection (I think c9io does this, but I may be wrong). There may be room for plugins for WordPress that have the functionality where and when appropriate/needed. Personally, I wouldn’t use anything other than crude SFTP, and even then, I’d prefer to push via version control for controlled commits in serious (small-, medium- and large-scale projects). However, tiny, internal projects and experiments would perhaps benefit from quick editing of some file. Although it’s generally faster to work via FTP then hit save and wait for a page reload in WordPress.
Your ideas are interesting. Please do let us know more about the plugin you are working on. Thanks for the feedback.
In general I think of WordPress as an outrageously outstanding CMS, which does not need any of the functionality of an online IDE.
Good post. I wouldn’t say that anyone who uses the theme editor every day on their site is a rookie as it can save a lot of time if you update your site every day.
Wouldn’t a good compromise be to allow theme files to be edited but to password protect the admin area using htaccess?
Thanks for your feedback, Kevin. The theme and plugin editors are still there mainly for rookies, I think, for their convenience; but this does not mean that anyone who uses it is one, absolutely not. I agree that occasionally, if the website is small enough and not tied to any version control systems one can perhaps edit some file, making small changes. But the security price to pay is quite high, and really not worth any bit of convenience left.
Protecting via Basic Authentication (in .htaccess) doesn’t mean that the panel will not get hacked. An additional layer of security is always a plus, of course, but, unfortunately, entering two different credential sets is seen as an inconvenience by many, especially if you’re running a site with multiple users.
Four of my websites get hacked & defaced yesterday. Upon looking into the raw log files, I found the similar entries. Actually googling that entries brought me here.
Somehow the “404.php” file get through and saved in /wp-content/themes/twentyten/.
The file is actually an uploader that is used to upload another file. In my case, the culprit uploaded “d3viL.php” into /wp-content/themes/ which is a shell access script.
With that, he can have a huge control on all the files inside.
But is it true that there’s vulnerabilities with theme-editor.php or was it because the attacker already has the password or earlier access?
Hasani, thank you very much for coming forward and sharing your experience. Yes, only administration access allow for the built-in file editors to be used as an attack vector; without administrative access it’s not possible as far as I’ve researched. The 404.php file is a standard theme file, so it’s not external, it’s completely normal. But, the uploading bit had to be added externally, possibly via the Editors, but there are other methods of doing so. So couple of questions to start with, if you don’t mind:
Good luck.
[…] a pity that the Editors are still made available, […]
My site was hacked 3 times over the past 2 days. For the theme editor hack, does the hacker needs to login via wp-admin or not?
Yes, the attacker has to have editor privileges in order to leverage them. Without the editors switched on the attacker would be limited to working inside of the current WordPress he’s managed to get in only. With the editors switched on escalating to PHP-user wide privileges is a matter of little effort.
Upgrade, change FTP passwords, check the logs to see how they’re doing it. Good luck!
I have checked the wp_users table and there was no new users. My password was sufficiently sophisticated. I wondered how the hackers brute forced their way through. How can I see this from the log?
I have tried sending you an e-mail, got a domain not found error; would like to see more logs if possible. What is your e-mail?
Quite an eye opener for me! Thanks Soulseekah. Not being a coder I do not edit the php files but do hack into the css sometimes to alter a design idiocy in a theme.
I use some security plugins – one being wp firewall. Do you know if it would stop such an attack? Or any other plugin that could do so?
Alex, thanks for stopping by. This attack vector requires certain rights and privileges as those of Administrators. Without actually being able to login under a username with these necessary rights and privileges (“capabilities”) the editors are not exposed and do not provide any security risk. However, once an account is compromised (sniffed, logged, bruteforced, etc.) the editors can be used to do a lot of different things. With the editors turned off, a logged in attacker can install a Plugin with malicious code in it, given enough rights. The point is – keep your WordPress and your server safe and secure by using strong passwords, a clean computer environment, and trustworthy plugins and themes. Additional layers of security can be utilized if your server contains important data that is classified, if you run a just a blog – don’t bother with too many “security” plugins, most of them provide too much overhead for the tiny benefit they add. Check out the Hardening WordPress Codex entry for more information. Feel free to ask if you have any more doubts or questions.
This is a simple change that you will likely want to add to wp-config.php – it will disable the theme editor :
define(‘DISALLOW_FILE_EDIT’, true);
Source: https://codex.wordpress.org/Hardening_WordPress
[…] in compromised user accounts. And from there, depending on what account gets compromised – editing PHP files to achieve arbitrary code execution and everything that […]