Gooochi talks to /bc/123kah.php

This is weird, a huge number of POST requests started to hit the Shite Drivers website a few days ago. The requests came from lots of IP addresses and all requests went to the non existent /bc/123kah.php

The payload was an array that looked like this:

Array
(
    [showed] =>
    [clicked] =>
    [version] => 2.6.2.4
    [id] => c3b342beb6ad7adf39499e7a38f93c09f681611d
    [tm] => 1266855758
    [aff_id] => gooochi
    [net_id] => gooochi
    [safe] => 1
    [exceed] => 2505,2507,2582,2597,2602
)

So I presume it’s the Gooochi malware referenced in this search for that word. Strange that the infected PCs hit my server though.

The traffic was never overwhelming but I decided to put a stop to it with a simple deny from all in a .htaccess file. Much better than having WordPress serve up a 404 page.

I mentioned the 123kah.php file on Twitter and I’m not the only one to see these odd requests. I guess even malware has bugs! (which is all the more reason to keep your anti-virus software up to date if you use Windows)

Remove unused utm_source from your urls

Sometime last year I noticed that links to my blog on Feedburner had attracted a few extra parameters. A simple link to a post became this huge monstrosity:

http://ocaoimh.ie/exploit-scanner-095/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+HolyShmoly+(Holy+Shmoly!)&
utm_content=Google+Reader

It’s a marketing thing right? It’s all useful information but I don’t really care about it, have never used it and don’t like my URLs getting mangled. It annoys me for two reasons:

  • People will probably use that big long url in their own posts. Other people will use the shortened custom permalink that my blog provides. Won’t the pagerank earned by the post be split in two now?
  • It makes caching less efficient. Supercache won’t create a static cached file of the page. It will create a regular php powered cache file but when you’re running Supercache you want the very best performance don’t you?

So I added a new option to Supercache to redirect the url and get rid of the utm_source bloat.

If you want to give it a go, grab the development version of the plugin and upgrade.

Oh, and if someone has decent docs on utm_source and it’s friends I’d love to read it. Google didn’t return much when I went looking.

Exploit Scanner 0.95

I’ve just released version 0.95 of WordPress Exploit Scanner.

This release fixes a number of bugs and makes it easier to scan for exploits and read the results.

I’ve added an “Exploits” scan level which looks for obvious code that hackers use. It will return a few false positives but it’s a good first scan to try if you suspect your website has been hacked. You can then use the “Blocker” and “Severe” to scan for ever more suspect strings.

Scans are now done 50 files at a time, with the page reloading after each. The scan results are saved in the database (in your options table as not-autoloaded records to minimize load on your blog) and you can open another browser window or tab on the Exploit Scanner admin page to view the saved results even before the scan is completed.

MD5 hash records for WordPress 2.9.2 have been added, and the hash records for 2.9.1 were corrected.

In other news I’m looking for testers to try out the almost ready WordPress MU 2.9.2. More details are on the forum thread above.

WP Super Cache 0.9.9

Well, the new WP Super Cache is available now.

This release adds experimental object cache support. Don’t go looking for it unless you have an external object cache already. It won’t show up. I recommend using the Memcached object cache.

Some of the other major changes include more translations: Chinese (Pseric), Ukranian (Vitaly) and Japanese (Tai). The Italian and Japanese translations have since been updated but not included in 0.9.9. You can grab them from the languages directory if you don’t want to wait until the next release.

If you have WordPress Mobile Edition installed the plugin will grab the list of mobile user agents from that and warn if your .htaccess is outdated.

And, a small but significant change is that the PHP cache loader will use the static “super” cache if necessary. This might happen if your rewrite rules aren’t working properly and not serving cache files. At least your anonymous visitors will see some sort of cached file. Use the debugging system built into the plugin to determine where the cache comes from.

See the changelog for the complete list of changes.

Matt Mullenweg and Craig Newmark

Matt and Craig

I was in Dublin yesterday to see Matt and Craig become Honorary Patrons of The University Philosophical Society in Trinity College. It was a low key informal event with many students and a few staff in attendance.

Eamon Leonard, of Echo Libre, kindly used my Flip Mino to record the Q&A session that followed. I want to express my gratitude to him for doing a fine job, especially as I saw him switch the camera from arm to arm during the hour long event. It wasn’t easy holding the camera aloft for so long. I’m currently transcoding the video and trying to make it smaller before uploading it.
I’ll add it to this post later, you won’t want to miss it!

Update! Matt was interviewed by Silicon Republic earlier today. Catch up on what’s happening at the Web Summit in Dublin by following #dws2 on Twitter.

WP Super Cache with Object Cache support

Here’s a quick post to encourage brave testers. I’m adding object cache support to WP Super Cache so you’ll be able to store your cached files in a memcached backend instead of disk.

It’s not complete but it’s running on this blog and well, you’re reading this which means it’s doing something and not breaking! If you want to give it a go grab the development version from the download page.

There are few caveats, but three spring to mind:

  • It won’t cache anything for “known” users. That is users who are logged in or leave comments. Usually a tiny minority of the visitors to any site.
  • Refreshing of the cache is very incomplete. If you leave a comment, the cache for that page may not update immediately. The cache lifetime is set to 30 seconds, and after you leave a comment you become a “known user” and see the uncached version of the page anyway.
  • When posts are updated the whole cache is invalidated.

If you don’t know what memcached is, or how to set it up then you probably don’t want to test this. If you do, use Google and find out about them. Unfortunately I don’t have time to explain how to install it.

Inspiration and some code taken from batcache, the excellent caching plugin we use on WordPress.com.

Update! I updated the Changelog in the readme.txt and I’m looking for testers. Here’s what’s new in the development version:

* Added experimental object cache support.
* Added Chinese(Traditional) translation by Pseric.
* Added FAQ on WP-Cache vs Supercache files.
* Use Supercache file if WP-Cache file not found. Useful if mod_rewrite rules are broken or not working.
* Get mobile browser list from WP Mobile Edition if found. Warn user if .htaccess out of date.
* Make sure writer lock is unlocked after writing cache files.
* Added link to developer docs in readme.
* Added Ukranian translation by Vitaly Mylo.
* Added Upgrade Notice section to readme.
* Warn if zlib compression in PHP is enabled.
* Added compression troubleshooting answer. Props Vladimir (http://blog.sjinks.pro/)
* Added Japanese translation by Tai (http://tekapo.com/)
* Updated Italian translation.

The biggest changes are the addition of the object cache and a small change to the php code that serves cached wp-cache files. If the mod_rewrite rules on your site don’t work for whatever reason the plugin will look for the Supercache file and serve that instead. An extra header is added to the served page when this happens. It’s all in the readme.txt!

WordPress MU 2.9.1.1

one dot one dot one dot one dot dot dot…. Yes, last week’s release of WordPress MU wasn’t to be the last one. This is. Really.

WordPress MU 2.9.1.1 fixes #1193 and #1195, two annoying but one liner bugs that crept into the last release.

This is also a security release fixing a bug in the installer that has existed for quite some time. If you can’t update yet, delete the file index-install.php immediately. That file is only used when you install WordPress MU for the first time so it’s not needed afterwards. Don’t ask, “I’m using version x.x.x, do I need to delete this file?” Just do it. Thanks Mad Sprat for reporting the problem.
The index-install.php in 2.9.1.1 is safe, but I’ve added a note at the end of the install recommending the file be removed. The file is not used after installation and it’s always a good idea to clean up unused scripts.

Get WordPress MU 2.9.1.1 on the download page or wait until your Dashboard upgrader finds the new release.
If you’re adventurous, download and replace the following files on your site to upgrade:

  1. index-install.php
  2. wp-admin/includes/mu.php
  3. xmlrpc.php
  4. wp-includes/version.php

Sorry Jeffro! 🙂

Close

Ad-blocker not detected

Consider installing a browser extension that blocks ads and other malicious scripts in your browser to protect your privacy and security. Here are a few options.

  • uBlock Origin is a free, open source, ad blocker for your browser.
  • Use pi-hole if you have a spare Raspberry Pi on your network.
  • Set the private DNS settings on your phone to dns.adguard.com to block adverts and trackers.