Support » Requests and Feedback » WP security should be layered and in-depth

  • Hi,

    I just cleaned up two of my WP sites from the “stealth virus.” That’s the virus which will live on inside of WP despite re-installs. It doesn’t change any visible behavior on the WP Blog or control panel. It does change WP output on some RSS streams and, more importantly, it is happy to act as an DDOS bot via code that runs in WP.

    It is my fault that I didn’t more actively update the sites (they were at 2.7). But there is still more that can be done:

    The point of this post is that I propose that WP should have more security in depth. As noted, this virus lives on despite WP upgrades. It does this by adding rogue entries to the dbms and hidden files in plugin directories.

    WP should continue to try to keep out the malware. But in addition, it should assume that malware may get past the outer gates. WP needs additional defenses. Or at least detection schemes. I’m sure there are hundreds of sites that have the stealth virus and don’t realize it. And they have no way to tell unless they’re handy with sql or a dbms browser such as phpMyAdmin.

    I suggest:

    1. The ‘plugins’ part of the dashboard should show all of the plugins that are being activated by the active_plugins entry in the dbms. If a “plugin” in the dbms does not match the usual plugin directory layout then the dashboard should make this clear to the user. It should also look for attempts to run hidden files.
    2. The wp updating and plugins mechanisms should be extended to include “bills of lading” that are cryptographically signed. The idea is that the act of installing or re-installing either a plugin or WP itself should be able to ensure that there are no added software programs in the directories.
    3. Either include mechanisms to check the check-sums of all the php files or make it easy to install other sw that does.

    4. Do not show the WP version in default template outputs or to anyone who is not an admin. This should be the default! No plugin should be needed!

    Of course, this sort of thing is not easy. But it is doable: the perl guys have done it for a while now in CPAN. PEAR may also include cryptographic signatures of packages, I don’t know.

    But otherwise, I’d say that WP’s future is not as bright as it could be. With the speed of zero-day exploits, and the temptations of large numbers of WP sites that are not managed by IT experts, WP has become an attractive target.

    Currently, admins don’t even know that they’ve been hacked.



Viewing 4 replies - 1 through 4 (of 4 total)
  • You seem to be alluding to an “infection” of a polymorphic nature with a generic nomenclature (“stealth virus”), yet you fail to mention the exact name of the discovered issue. What exactly were you “infected” with, and how did you identify it? Where were it’s entries located, and what was the course of remediation? What code was running in WP, and can you steer me toward the documentation that indicates this as a WordPress specific “stealth virus” variant? I would like to dissect the known methods of proliferation.



    Hi Cj,

    The virus is the one I posted about here:

    Re: a name for it– Good point, that’s something else that should be done: The list of known exploits on the Codex could be more visible. I did find page but only by searching. Am I right that the page is in someone’s private pages? Doesn’t make sense: a list of exploits should be part of the main section of the Codex.

    Re: polymorphic — either the virus itself or its installer used different file names for its executables on different systems. It adds files to an already existing plugin. One system it added:

    On another, it added

    It lives on despite upgrades because the WP upgrade instructions tell you to save your plugin directories. And the upgrades never look at the active_plugins db record carefully. If you know SQL, you can find the presence of the virus easily.

    Re: what was I infected with–It had several parts:

    1. 2 file names were added to the active_plugins record in the db. The files were added as hidden files in a plugin directory. I don’t know all that the files do. I can make them publicly available, any harm in that?
    2. A “wordpress” user was added to the blog
    3. On one of the machines, the backdoor file remv.php was added to the system

    Re: how did you identify it? — It’s stealthy, hence my name for it. It does not cause any difference in normal output when viewing the blog’s main site or admin site. It does add spam to the RSS feed when the request comes from the Google Reader. I found info about it by looking in my own system. Info from the web was of some help. See and

    Re: Where were its entries located, and what was the course of remediation?
    Entries were in wp_options — Virus adds to the installed plugins by changing the plugins option row in the table:
    Look for the table row where option_name = active_plugins

    Virus files loaded as bogus plugins here: (field option_value)

    From the above, you can see that the virus installed and was running the files
    The virus chooses a plugin and then creates additional hidden files in the plugin’s directory. This is NOT a bug from podpress, I have seen the virus use other directories in another wp system.

    Re: remediation–
    Need to remove the added files, remove the extra entries from the db, remove any added WP users, change db and linux passwords. Change WP admin passwords. Change secret phrases in WP config. Upgrade WP. Check directory permissions. Check all directories for hidden files. Check .htaccess files. Usual stuff when hacked.

    Re: What code was running in WP — one was 2.7, one was older.

    Re: and can you steer me toward the documentation that indicates this as a WordPress specific “stealth virus” variant?
    — Don’t know what you mean. My point is that there isn’t enough documentation and attention to these issues. If there’s already a virus called a “stealth virus,” then that’s something different. I’m trying to give a name to this WP infection. It probably has nothing to do with any Windows or other type of malware.

    Re: I would like to dissect the known methods of proliferation.
    — Presumably the WP folks who work on security share that info. I don’t have it. The virus deleted the server logs so I don’t know what bug in WP it exploited to enter my system.

    My point is that it should be able to easily (and automatically) audit a WP system to check for extra files and techniques such as adding file names to the active_plugins dbms record.



    Thanks for all the info Larry. There is a wealth of information there to look over.

    My knee jerk reactions is that I suspect you just suffer the results of a hack/injection rather than what we generally think of in terms of a virus. (in the “windows” sense of the word anyhow) That’s not to say that a breach may not have originated from one of your own computers that was infected with a virus/trojan that harvested and compromised your ftp credentials, but just the same, if the WordPress versions that were compromised were 2.7 or older they were no longer secure to begin with. But that’s hind-site at this point.

    The virus deleted the server logs so I don’t know what bug in WP it exploited to enter my system.

    Now that, is something that really would make me nervous. Especially if the server was under my control locally.

    Thanks again for taking the time to post the info.

    Best wishes.

    My main point is that the hack/virus/whatever you want to call it/ survives upgrades of WP. I’m pleased to see that the latest instructions for people to recover from a hack tells them to rebuild their db rather than preserve it.


Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘WP security should be layered and in-depth’ is closed to new replies.