- #DOES MARSEDIT USE XMLRPC INSTALL#
- #DOES MARSEDIT USE XMLRPC UPGRADE#
- #DOES MARSEDIT USE XMLRPC FULL#
- #DOES MARSEDIT USE XMLRPC FREE#
Understanding the Basics of Remote Publishing So my goal is to explain the current state of remote publishing and control of WordPress sites, how the forthcoming JSON API impacts that, and what it all means. It includes a pointer to this very helpful exploit scanner script.One of the hallmark features of WordPress 4.1 - yes we just got WordPress 4.0, and you’re right, it is really awesome - is likely to be a new way to remotely publish to WordPress: the hallowed “JSON REST API.” But for a lot of people, I know that that sounds like a whole lot of random meaningless letters. Yes, I see bogus “wp_options” entries for fake “active_plugins” too.Īnother set of instructions on what to do.Ī great description of how this “ekibastos attack” takes place. UpdatesĬheck out this eight month old thread catching the birth of this attack. Until then, we feel good about this afternoon’s work. Hopefully the POST monitoring will give us a better idea of how this happens if it does happen again. We will be more vigilant for the next few months and see if they return. While we think we have cleaned up our mess, we are still not sure how the nasties got onto our system in the first place. I found that a WP plugin had been written to assist with that task, check out the vi-logger post-logger. I want to know if anyone does anything strange. Since our WP installs do not run behind SSL, we decided to create new dedicated admin accounts (note, we did not call this new user “admin”), and todowngrade our existing authoring accounts to “Author” or “Editor” privileges.Īctually, since we don’t really know how this happened, I also decided to add a layer of logging to one of our WP installations for the time being.
We had been authoring on our blogs from accounts that had admin privileges. We were as conservative as we could be about what we left in the “wp_content” folder, but we did have to leave some of our old themes and plugins there.įinally, we decided to change our authoring practice. We essentially followed the procedure documented at WordPress for upgrading installations, removing the “wp_admin” and “wp_includes” directories and copying fresh WP files over everything else. We then decided that we wanted to make sure the nasty invader had not added any other files to our WP installations.
#DOES MARSEDIT USE XMLRPC INSTALL#
A normal WordPress install does not have a user named “WordPress”, so get rid of it. Look for anything administrative that should not be there, in particular look for the “WordPress” account. We simply deleted all suspicious users and usermetadata.
#DOES MARSEDIT USE XMLRPC UPGRADE#
We decided to clean up the databases first, then copy fresh WP installs in place of the old ones, and then upgrade the databases for the (often new) versions of WP.Ĭleaning out the “wp_users” and “wp_usermeta” tables was done with CocoaMySQL, though you could probably do the same thing with phpMyAdmin or any number of other tools. Find your own Alex, it is nice to have a partner to ask questions and keep you on track. The first thing I did was call my son Alex in to help me sort through all of this.
#DOES MARSEDIT USE XMLRPC FREE#
Feel free to leave brighter ideas in the comments! I’m sure there are cleaner ways of doing this, but for the record, here’s what I did. We had to fix both our WP databases and our WP installation. Yuck! Finally, I eventually noticed some added admin users in “wp_users” who had the names of other legitimate admin users, but with a single (random?) letter attached. When I searched the “wp_usermeta” table for “admin” I found that each database also had one or two administrative users metadata which had more scripts in place of the display name. This user was invisible to the admin interface of WP, yet it was authorized as an administrator. The user accounts were a bit trickier.Įach database had a user called “WordPress” in the “wp_users” table that was obviously an intrusion. I’m not even sure it was part of the same scheme. The posting was easily identified, it was one of those with a thousand poker-related links in it. Sure enough, I found at least one corrupted posting and in virtually every database I found improper user accounts. Once I was sure that my WP installs had been compromised, I started digging deeper into the WP databases. In fact, this very illuminating post gave me some ideas what might be behind this line.
#DOES MARSEDIT USE XMLRPC FULL#
Yikes! This looks like a line that waits for “browsers” with a special cookie to stop by and then runs (evaluates) a coded (base64_decode) version of a file full of PHP on our host! What’s in that ‘file’? Who knows, but I’m sure it is not pretty.
0 kommentar(er)
