A good explanation. I had one of these. I took the call to “wp_footer()” out of my footer.php file, and that stopped that nonsense. I couldn’t find any of the files noted in this articles example; I can only hope it gets weeded out on a re-install.
An even better explanation … I got one of those “active_ plugins”, but the option value is “a:0:{}”. I have no idea what it means … it looks like a placeholder. What I do have is one with “option_name” equal to “wp_links”, with the “freemacwareDOTcom” address conspicuously highlighted. This was causing popups on closure. I have uploaded the value of the memo field for scientific purposes. NOTE: I removed all of the left-angle brackets (“<") from this file to disable the code. Not indexed by Technocrati … How wonderful! Now I’ll have to reinstall the current version of WordPress and cross my fingers that I can still understand it!
Capturing $_POST commands … I just might try this, you know. PrefBlog has been under heavy attack lately by spam comments.
So anyway … my apologies to all readers who have been inconvenienced – or simply puzzled – by the recent popups. Please let me know of any odd behavior by PrefBlog (I mean odd behavior that is system-related, of course!) in the future and I’ll be that much quicker tracking things down.
Update, 2008-8-16: The database has a table, wp_postmeta, which tracks attachments. One record in this table has the values: meta_id=8474, post_id=2181, meta_key = ‘_wp_attached_file’, meta_value=’/services1/webpages/p/r/prefblog.com
/public//../../../../../../../../../../../../../../../../../tmp/10bum.txt’
There is also: meta_id=8472, post_id=2180, meta_key = ‘__wp_attached_file’, meta_value = ‘/services1/webpages/p/r/prefblog.com
/public//../../../../../../../../../../../../../../../../../tmp/2newbum.txt’
These records have been removed.
I have also deleted some entries in the wp_posts table. As far as I can make out from the WordPress codex the value of ‘post_parent’ should reference a ‘post_id’ in the same table, which are all positive integers.
After noting some odd entries, I queried the database: ‘select * from wp_posts where post_parent < 0' and came up with seven records. Two have post_parent set to numbers that are large and negative; the 'guid' field indicates that this is stuff that I did, in fact, upload but somehow screwed up.
The remaining 5 records all have post_parent set to -1, with 'guid' having a variety of values: the first one, with 'post_modifed' = '2008-03-25 05:26:58' has 'guid' = 'http://www.prefblog.com
//../../../../../../../../../../../../../../../../../tmp/3rbsmag.txt’. The other entries are similar, with filenames 10bum.txt (three times) and 2newbum.txt.
All these records have been deleted. Note that with these long field values, I have added a HTML line-break to make the full field look nice on this post.
I note that the first of these highly suspicious entries occurred within a week of my WP 2.3.3 installation! I have requested database validation for forthcoming releases of WordPress.
Update, 2008-8-16: Problems with the file 3rbsmag.txt have been discussed on WordPress.
I installed the $_POST checker mentioned above … now I will see if this comment gets logged!
Another test, with a slightly souped-up $_POST-grabber.
[…] the discovery that PrefBlog was hacked, software has been […]
[…] http://www.village-idiot.org http://technorati.com http://googlewebmastercentral.blogspot.com http://blogsecurity.net http://playground.ebiene.de http://www.teohuiming.name http://www.prefblog.com […]