Vulnerable phpBB : Find and Disable.

Monday, July 18th, 2005

Here’s a little script I wrote that attempts to find and disable old phpBB instances that may be vulnerable to the recent phpBB Worm in the wild.


#!/usr/bin/perl
# Name: Augie Schwer
# File: find-vuln.pl
# Date: 18, July 2005
# Purpose: Find vulnerable phpBBs and disable them.

use strict;

my ($line,$location,$user,$this_version,$newest_version);

$newest_version = '2005/06/26';

# where to search.
my $webdir = '/home/WWW_pages/';

# spawn sub shell and find the viewtopic.php and capture its version and location.
my @output = `find $webdir -type f -name viewtopic.php -print | xargs --verbose grep '\$Id: viewtopic.php,v' 2>&1`;

# parse out location and version.
foreach $line (@output)
{
if($line =~ /(.+?): .+ \$Id: viewtopic.php,v .+ (\d{4}\/\d{2}\/\d{2}) .+/)
{
$location = $1;
$this_version = $2;

# old phpBB, disable it.
if($this_version ne $newest_version)
{ print "OLD PHPBB\n" ; `chmod 000 $location`; }

print "Location: $location \n";
print "This V : $this_version \n";
print "New V : $newest_version \n";
}
}

Getting Firefox and Thunderbird to play nice under Linux.

Sunday, May 1st, 2005

Mozilla Firefox and Thunderbird are great programs, but they need a little glue to get them to talk to one another. Here’s how I did it on Linux.

The documentation for these two scripts can be found here for those that would like more information.

The path to the two scripts need to be added to your respective Firefox and Thunderbird configuration files (prefs.js). In Firefox you can use the about:config dialogue, and in Thunderbird you will need to edit the prefs.js file by hand.

In Firefox set the following value to the path to your thunderbird.sh script.
network.protocol-handler.app.mailto

Thunderbird is similar, but you may want to add more than one entry:
user_pref(“network.protocol-handler.app.ftp”, “/home/augie/bin/firefox.sh”);
user_pref(“network.protocol-handler.app.http”, “/home/augie/bin/firefox.sh”);
user_pref(“network.protocol-handler.app.https”, “/home/augie/bin/firefox.sh”);

Here are the scripts that I use:

Firefox


#!/bin/sh

# if firefox is already running, then open a new tab.
firefox -remote "ping()" && firefox -remote "openURL($@,new-tab)" && exit 0

# otherwise start firefox.
firefox "$@"

Thunderbird


#!/bin/bash

# if thunderbird is already running, then open a new compose window.
thunderbird -remote "ping()" && thunderbird -remote "mailto(${1#mailto:})" && exit 0;

# otherwise start thunderbird with a new compose window.
thunderbird -compose mailto:${1#mailto:}

FreeNX on Mandrake 10.1

Friday, March 11th, 2005

FreeNX is an open source alternative to NoMachine’s NX Server. This means super speedy remote desktop access over SSH; I was streaming audio, surfing the web, chatting, checking email at home and doing the same via the nxclient on my work machine without any noticeable lag on the remote box.

There were however some hoops to jump through, so I chronicle them here.

Server: (aka work/remote machine)

To make things a bit easier you will want to add these install media.

urpmi.addmedia mirrors.usc.edu_devel_contrib-i586 rsync://mirrors.usc.edu/mandrakelinux/devel/cooker/i586/media/contrib/

urpmi.addmedia mirrors.usc.edu_devel_contrib-x86_64 rsync://mirrors.usc.edu/mandrakelinux/devel/cooker/x86_64/media/contrib/

By the way; rsync media seems to be less popular, and less likely to be flooded with a bunch of people, than FTP media.

Next install freenx via urpmi:

urpmi freenx

Along with the freenx package this will also install its dependencies; nxagent, libnxX11_0, and nxproxy.

Then do the following:

chmod 640 /var/lib/nxserver/nxhome/.ssh/client.id_dsa.key

Rename the following to stay more in line with standards:

mv /var/lib/nxserver/nxhome/.ssh/authorized_keys2 /var/lib/nxserver/nxhome/.ssh/authorized_keys

cat ~augie/.ssh/authorized_keys2 >> ~augie/.ssh/authorized_keys .

Add the user(s):

nxserver –adduser augie
nxserver –passwd augie

I keep sshd pretty tight, so this may or may not be needed for you.

Add ListenAddress 127.0.0.1 to /etc/ssh/sshd_config if need be.

Client: (aka home)

urpmi nxclient

Copy /var/lib/nxserver/nxhome/.ssh/client.id_dsa.key from server to /usr/NX/share/client.id_dsa.key on the client

chmod 644 /usr/NX/share/client.id_dsa.key

Run nxclient –wizard as root.
Copy /root/.nx to ~augie/ .
chown -R augie:augie ~augie/.nx/
Edit ~augie/.nx/nxclient.conf

Unison to keep files synced.

Thursday, March 3rd, 2005

I saw this article on Linux Journal and decided that I had to check it out; especially since installing unison for Mandrake is as easy as urpmi unison.

I had been using rsync to keep certain local and remote directories in sync, but I found that I would have to always remember which had the most recent data so I didn’t clobber my files; unison seems to do a far better job of merging conflicts.

My first test was to sync my IRC logs from #nblug:

unison .gaim/logs/irc/augie@irc.nblug.org/ ssh://linux/.gaim/logs/irc/augie@irc.nblug.org/

Success!

Now for the same thing but with less typing (over the long term); I create a file called irc.nblug.prf under the .unison directory like so:

root = .gaim/logs/irc/augie@irc.nblug.org/
root = ssh://linux/.gaim/logs/irc/augie@irc.nblug.org/

Now when I want to synch the two directories up it is as simple as unison irc.nblug .

SHA-1 Broken and GnuPG (GPG)

Saturday, February 19th, 2005

As noted on slashdot ([1] , [2]) earlier this week; famed cryptologist Bruce Schneier noted in his blog entry that the hashing algorithm SHA-1 had been successfully broken. While the new advances against SHA-1 are computationally feasible they are still quite difficult, however the general recommendation is that people move away from SHA-1 for digital signatures.

Moving away from SHA-1 for digital signatures when using GPG may take a little bit of work since SHA-1 is the default hashing algorithm for digital signatures.

First you will need to upgrade to GnuPG 1.4 if you have not already; this is because the previous versions of GPG lacked support for writing SHA256, SHA384, and SHA512. Unfortunately the package maintainers for many of the Linux distributions have not been keeping up, so finding a GPG 1.4 package may be difficult; even though the announcement for 1.4 states that 1.2 reached its end of life cycle last month. I recommend contacting your distributions GPG package maintainer, and giving them a friendly nudge to keep up to date.

Once you have upgraded you can pass the command line option (or put it in your ~/.gnupg/options file) –digest-algo sha256 (or sha384, or sha512) to sign your messages with the updated hashing algorithm. However if you are like me and chose the default key pair when generating your keys, then you have a DSA signing key and an ElGamal encryption key; which due to limitations in the DSA algorithm means that you will get this error when trying to sign with anything other than a 160 bit hashing algorithm (which SHA-1 is):

gpg: DSA requires the use of a 160 bit hash algorithm

The solution is to generate a subkey. Subkeys are extremely handy for just such a job; when generating a new key pair would mean losing all of the signatures you have worked so hard to gather, but you need a new encrypting (or in this case signing) key.

To generate a new subkey begin by editing your key (–edit-key ‘name’), then choose addkey, and finally choose RSA (sign only). That’s it; now you can use the newer SHAs.

One final note: Enigmail the GPG plugin for Thunderbird does not support SHA256 and above for PGP/MIME. The reasoning behind this decision can be found on this Enigmail mailing list thread.