Small WordPress sites leaking like sieves Wordpress admins hoping for some feet up time after last week's Twenty Fifteen XSS plugin vulnerability appear to have yet another vulnerability to handle. Researchers at Zcaler have identified a bunch of compromised sites that are all leaking user credentials to the same target domain – conyouse.com hosts the command and …
"But how can they patch when it's an unknown Vuln, by the looks of the article?"
Simple. Look at the source of your <domain>/wp-login.php page. If you see <script type="text/javascript" src="//conyouse.com/wp.js"> then you are infected. Glasgow seem to have resolved the issue, Blissfield have not (yet).
You should be able to re-edit your login.php file and hopefully secure it. This may not stop re-infection but it means you can limp along with close vigilance until the backdoor is identified. Re-edit login.php from the command line not through wordpress - then change your login and password pdq.
Disable all other accounts and warn your users their passwords may be compromised.
On affected sites the conyouse script appears on the wp-login.php and wp-admin pages and on login forms inserted into other pages. So I'm guessing the dodgy code is more likely to be found in the login functions in general-template.php.
(I see Richard Chirgwin thinks Blissfields Festival is a "small community group". Try to keep up with the kids, Richard... :-) )
You can't just edit your wp-login.php, if you look at it you won't see the infection code (it shows up when it renders in your browser).
Nearest I can figure (I don't know the internals of wordpress at all), there is a callback called "logins_script_WP" which is loading the javascript call to the hostile domain.
The bandaid fix I came up with was to edit wp-includes/plugin.php down around line 910 or so (v 4.1.5) in this block of code:
reset( $wp_filter[ $tag ] );
do {
foreach ( (array) current($wp_filter[$tag]) as $the_ )
if ( !is_null($the_['function']) )
call_user_func_array($the_['function'],
array_slice($args, 0, (int) $the_['accepted_args']));
} while ( next($wp_filter[$tag]) !== false );
Change the line:
if ( !is_null($the_['function']) )
to
if ( !is_null($the_['function']) &&
$the_['function']!='logins_script_WP' )
and the jscript call to conyouse.com goes away. But I still don't know how it gets in there, or where the code that function generates is hiding or coming from (my guess is it's obfuscated in the dbase ...somewhere).
"By migrating away from WordPress?"
Oh, how I wish.
Yes I've tried Drupal and Joomla but they just don't have the quantity and ease of off the peg plugins and templates. And with Joomla I've been bitten twice with security vulnerabilities which is one more than Wordpress which I use much, much more.
Still WP is a stinking pile of steaming sh^t. The rot starts not with the coders but with PHP. A true abortion we seemingly cannot escape.
- a retired cgi-bin Perl luvver <:-(
I dislike WP intensely largely for this reason. I want to install the programs/scripts read only - preferably using the OS installer (eg: yum/rpm or apt-get). It is also hard to have one copy of the scripts and use them in several sites. WP makes this very hard, they entire mindset of the developers seem to have little clue about large scale system admin and want WP to do everything.
Also: they seem to favour features over security -- get something working quickly, worry about good coding later.
Actually, a multi-tenanted WP setup is very easy to achieve - it is designed for it. I'm sure you can google it.
Features over stability and security is the blight of the 21st century "agile" software development caused by people incapable of handling the concept that you cannot implement before designing, and you cannot design before analysing requirements.
The biggest problem I have with WP is that it is rather difficult to reconcile it's write permission wishes with basic security concepts without extensive per-file hand-crafting of permissions using either ACLs or SELinux or equivalents. The sanest solution I've been able to come up with is to simply make the entire directory subtree it is installed it only readable but not writable by Apache. This, unfortunately, breaks features such as auto-updates and user content uploads.
Keeping the number of 3rd party plugins used to an absolute minimum also helps to reduce the attack surface, since the most (but by no means all) exploits in WP are in 3rd party plugins rather than the core.
I rather like the "All in one WP security" plugin because it does offer a fairly comprehensive set of tools to shore up WP security. Use that, use Google Authenticator for login, patch timely and don't install what you don't absolutely need (and I include themes in that) and you should be OK.
It's not rocket science, but basic users usually don't have a clue how to secure a site, and WP makes it a bit too easy to get started without the most basic planning.
For small sites where the only person actually logging in is the owner, a simple safeguard is to move the login script and replace it with an empty file. Just put the file back for a few minutes when you wish to login or logout. As many owners will be logging in once a week or less, it is no big issue.
Also removes the load on the server caused by bots constantly downloading the login page and submitting password guesses. For small servers it can provide a noticeable performance improvement as well as better security.
For small sites where the only person actually logging in is the owner, a simple safeguard is to move the login script and replace it with an empty file
There are plugins which move the admin URL to somewhere else, it's one of the simplest ways to avoid dictionary attacks on the admin page. Also, never use "admin" as your admin login, change it to something else. Defaults make for vulnerability to scripted attacks, and I see plenty of those coming at my sites (I have a very interesting 404 log :) ).
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
