Mostly Harmless

Well not really panic, just your usual vulnerability patching day at the office.

When I saw Dan Kaminsky demonstrate voice over DNS, I was convinced that he dreams in BIND source code.  It was a neat demonstration.

Now he has uncovered another vulnerability in BIND regarding UDP source port prediction. It’s causing some excitement in the work place as to what the impact could be and how soon our vendors can release patches.

I’ve had to do some explaining as what it means;  see Matasano’s blog for more information.  Thomas Ptacek sums it up really well here and states the impact more here.

You’ve got to love someone who can explain the seriousness using a movie quote from Jack Black.

Over a week ago I complained about WordPress users crying security wolf and not being able to recover their blog when the “Bad Thing(tm)” happens.

Since then a real brawl developed on the support forum that could be summed up like so:

1. One or more users is insisting that there is an XMLRPC exploit in 2.5.1.
2. The same one or more users refuses to back this claim up with data, or apparently send the WordPress security e-mail alias any info (maybe, how would other people know what was sent via e-mail?)
3. Many people tried to reasonably explain that such an exploit may exist but without data there is nothing to solve.

This discussion was just plain nuts and went around in circles.  Complaining about a problem without providing any proof and then getting all pissy about it is totally useless.  It is entirely possible that such an exploit exists and many people replied so.  But without any providing data other than saying “I can assure you that the hack occurs via XMLRPC”, then everyone’s time gets wasted.

Fortunately, Donncha provided a page that covers the issue succinctly and today he added another post on setting up aide.  His two posts are good and anyone considering monitoring their WordPress files for modification should give this a try.

Aide will let you see if your installation files and directories have been tampered with.  It won’t protect you against HTTP POSTS or database attacks but it’s very good if someone succeeds in modifying your files.

There are ways to log what’s being sent via an HTTP POST and examine that information; if (or even when) I get hacked, I’ll try to start looking at that data.  MYSQL database monitoring, that could be interesting but for now I’m not aware of a good tool to do that.

On my OpenSuSE installation, installing aide is simple.  As root run

zypper install aide
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
aide --check
cp /usr/share/doc/packages/aide/examples/etc/cron.daily/aide.sh /etc/cron.daily/

All of which I just did.  I ran the check option to make sure I did not create any issues with the aide.conf file.  I’ll play with the aide.conf file and see what kind of output I get when the daily cron job gets run.  If I add and modify files and I set it up correctly then I should see that in daily cron job’s output.

Update: this worked but in /etc/aide.conf change the line verbose=1 to verbose=5.  That will get you a useful output of which files and directories changed.

If you are not running the latest version of WordPress and you get hacked, don’t go to the WordPress forum and tell the world.  Odds are you invited the disaster yourself.

When WordPress 2.5 came out I was disappointed to find that the old version 2.3.x was basically abandoned.  There would be no more planned patches for 2.3.x just the current 2.5.  The 2.0.x branch would continue to be supported as part of the commitment to the Debian version model.

So as of right now versions 2.0.11 and 2.5.1 are supported. If you are running 2.2.x, 2.3.x, 2.5(.0), or any other version then you run the risk of being exploited.

So why do users continue to use the old versions?  Everyday there are posts in the support forum that (so far) always deals with someone’s blog getting hacked and they are not using the current 2.5.1 version (as of this writing).  Eventually someone writes “I’ve been hacked” and some other user writes “Is this a vulnerability of insert current version HERE?!? Why are the developers not doing SOMETHING?!”.

It’s like there is some axe to grind and the first one to find the axe gets 1000 gold points.  The moderators usually show great patience; I’d get ticked if I were them.  These users seriously should just avail themselves of WordPress.com and stop trying to self host a blog.

The freely available WordPress from WordPress.ORG is not commercially supported, and commercial support if often not that good anyway. So for anyone who is thinking about using WordPress.org’s software, they should be able to do the following by themselves.

You need to be able to make backups.

Read this Codex article for backing up your WordPress installation.

WordPress uses two components.  The easy one is the file system and backing that up should be trivial.  I use a shell script that creates a tar.gz archive every night.  Another cron job deletes backups that are older than 30 days.  Why fill up my disk?  The backups are not for historical use, just to get me back to the state I was 24 hours ago if need be.  30 days is too much but hey, disk space is cheap.

The mysql database is the other component.  The same backup script also creates a text dump of my entire WordPress database.  This copy gets gzipped and added to my file backup.  The mysqldump command is your friend and should be used.

You need to be able to know how to restore those backups.

The Codex has a good article on how to restore your blog database here.

Making the best backups is pointless if you don’t know what to do with them when the “Bad Thing” happens.  Take your backup and restore it to a WAMP or LAMP installation on your own PC.  If you need a Windows Apache Mysql Php setup, use Google and install the one you feel comfortable with.  In Linux just add the packages (See this link for Ubuntu).

Once you have the Apache web server, Mysql, and PHP running locally on your PC then start playing.  Install WordPress locally, restore your backup and just change the name of your installation in wp-config.php to localhost and test.  To adjust your local installation to run on your PC just add these two lines to the copy of the wp-config.php on your PC:

define('WP_SITEURL', 'http://localhost');
define('WP_HOME', 'http://localhost');

Then on your PC point your browser to http://localhost/ and test it.  Beat it up; it’s a local copy on your PC.  Go nuts on it and confirm that your posts, categories, tags, comments, etc. are all there.  Anything on your PC that you mess up in WAMP or LAMP should be no big deal.  Just start over if you get lost.

Play with it until you understand what you are doing, because when you DO lose your blog you’ll need to do this for real.

Practice performing an upgrade on your PC’s local copy.

That sounds like a plan right? Some plugins don’t work with the latest and greatest version.  If the version you are running is vulnerable to an exploit then you don’t need that plug in.

Security updates are the number one driver for minor number version releases such as 2.5 to 2.5.1.  Yes, there are bugs but they usually are tolerable.  Exploitable code is serious business and usually gets fixed quickly.

Once you are comfortable with upgrading and testing your local installation, upgrade your real blog.  I personally keep good backups and know how to restore them so I never bother with this step.

If you know how to backup and restore your blog, then even if the upgrade is bad, you will be able to put it back the way it was before the upgrade.

I was checking out my server logs (gripping reading, could not put it down) when I saw these two entries:

208.78.98.108 - - [09/Jul/2007:20:28:07 -0400] “GET /wp-pass.php?_wp_http_referer=http://topnlpsites.com/images/gif/echo.txt? HTTP/1.1″ 403 860 “-” “libwww-perl/5.803″

81.169.188.151 - - [09/Jul/2007:20:54:39 -0400] “GET /wp-pass.php?_wp_http_referer=http://doublezer0.free.fr/echo.txt? HTTP/1.1″ 403 1032 “-” “libwww-perl/5.69″

File wp-pass.php? Where’d that come from?

See the BUGTRAQ explanation here. By passing arguments to wp-pass.php, the wp-pass.php file will send the requesting browser to the URL that wp_http_refferer points to. By using a simple script the WordPress installation is easily verified as susceptible.

The bad buy sends out a SPAM or bogus link that points to a WordPress installation and that WordPress blog redirects the request to where ever the attacker wants. This is not earth shattering but really annoying.

Luckily Apache’s .htaccess is our friend. In my blog root at the end of my .htaccess file I added the following two lines:

RewriteCond %{REQUEST_URI} “.*wp-pass.php”
RewriteRule .* - [F]

I do not have any password protected posts so I don’t use that file (which is all I gather it is for…) and after implementing this my blog continues to work fine. Any requests that match that rewrite conditions gets a return value of 403: Forbiden.

This is to be fixed in WordPress 2.2.2 says the posting. The BUGTRAQ posting also mentions wp-includes/pluggable.php, wp-includes/functions.php maybe vulnerable due to the use of problematic code.

Security. Sweet.

Security on Safari 3 Beta. Not so sweet.

BetaNews | ‘Day One’ for Safari for Windows Becomes Zero-Day Nightmare

Speed! Sweet.

Speed. Can’t see the increase myself. Not so sweet.

Joel on Software: Apple Safari for Windows: The world’s slowest web browser

Joel updates the post a few times regarding the speed thing. I get a kick out of his “Safari even managed to bring the inferior font rendering of the OS X platform to Windows, no easy trick.”

I’ve already removed it from my system. When I need to check a web page for how it displays, I use Firefox, Internet Explorer 7, and Opera 9. If I could easily swing it I would also check with Internet Explorer 6. I guess having a working Safari on Windows would be useful, but I’ll wait for it to come out of beta.

The claims of better, faster, more secure just irks me. It would not have been that difficult to have someone reputable ethically hack Safari 3 beta before releasing it. Given the large number of security folks who are “Give me Mac or give me death!” I’m sure they could have found some good volunteers.

Images lifted from Apple’s Safari web page.

Or what I do for a living. But follow this link anyway:

http://www.matasano.com/log/384/oh-the-bad-crypto-youll-see-an-open-letter/

I don’t know anyone who tries to write there own crypto code (I hope) but I run into items 2 and 3 often enough to make me say things like “and to think, he can vote too”.