COMMAND

    SessionWall-3

SYSTEMS AFFECTED

    SessionWall-3

PROBLEM

    Codex found following.   The example code  which compliments  this
    paper can be found on

        http://www.phate.net/progs/sw3

    SessionWall-3  (more  recently   known  as  e-Trust   IDS)  is   a
    graphically controlled sniffer and network monitor for the Windows
    platform.  It  provides a point  and click interface  allowing the
    trivial viewing of various "sessions" such as web, telnet, ftp and
    mail (SMTP, POP3 and IMAP) among others.

    Two interesting "features" have been discovered and both have  XOR
    operations as the central theme.

    Firstly  the  password  used  to  protect  the  installation  from
    unauthorised viewing  or configuration  changes is  stored in  the
    registry using a _cunning_ XOR scheme.  This scheme has been  used
    since this feature was added to the product over two years ago.

    Secondly SessionWall-3 can be detected and identified remotely  by
    a single ICMP packet.   Again this scheme involves some  amount of
    XORing.  This feature has been known about for over two years  and
    used to great effect, however this paper takes into  consideration
    a slight change in this scheme made in the most recent release  of
    the software.  A Denial  of Service condition also exists  in this
    detection feature.

    SessionWall-3 implements  a password  scheme in  order to  protect
    the software from unauthorised  access and re-configuration.   The
    password is encoded in the registry at the following location:

        HKEY_LOCAL_MACHINE\Software\ComputerAssociates\SessionWall\1.0\Security

    The values we are interested in are stored in the  "AdminPassword"
    registry key, and are hex values of no fixed length.  There is  no
    fixed key, it changes every time we run SessionWall, however  this
    doesn't deter us  in the least  because the key  that was used  to
    encode the  current valid  password is  contained in  the registry
    key.   Due to  this minor  oversight and  provided an attacker has
    access to this registry key  (is not denied by physical/OS  access
    control) it is  possible to reverse  the _encryption_ process  and
    retrieve the password in plaintext.

    The registry entry for our target password might look like this:

        (all values     .__._________________._______________________.__.
         are in hex)    |A |         B       |           C           |D |
        "AdminPassword"  25,67,4d,3c,28,5f,4a,37,8c,6f,7b,88,85,35,89,00
        
        where   (A) is the XOR key length,
                (B) the XOR key,
                (C) the XORed password, and
                (D) terminating null.

    The _"algorithm"_ used to encrypt passwords is a very simple one:

        1. To calculate  the length of  the XOR key,  we subtract 0x20
           from the first byte (A above), actually 0x1f, as this gives
           us the number of bytes from 0 - (A).
        2. Current byte from XOR key has 0x20 subtracted from it.
        3. Current byte of XORed password has 0x20 subtracted from it.
        4. The bytes from stages (2) and (3) are then XORed, and  0x20
           added to the result.
        5. Next  byte of  XOR key  and password  are selected for next
           iteration.

    If the  password length  is greater  than the  XOR key length, the
    key will  loop round  until the  calculation encounters  a null in
    the password.   A tool to  extract the password  from the registry
    is available from the URL listed at the end of this document.

    SessionWall-3 is able to detect other versions of the same product
    running elsewhere on a network to which it is attached.  This  may
    be a useful feature given the obvious potential for abuse.

    Network traffic analysis showed that the product detection feature
    utilised ICMP echo  requests and replies.   With a single  product
    on the network a "product detect" will cause an ICMP echo  request
    to be  generated on  the wire  and directed  at the  broadcast MAC
    address ff:ff:ff:ff:ff:ff  at the  ethernet level  and the network
    broadcast  at  the  IP  level.   All  the  other IP devices on the
    network will generally reply to this broadcast request and  return
    the data payload as per the ICMP specification.  In the case where
    the network has an additional SessionWall-3 product operating,  it
    will return  a reply  with an  altered payload.   This payload was
    found to have only six essential bytes in order to cause a  remote
    detection event, and further analysis showed that this was  indeed
    the  MAC  address  of  the  replying  machine  encoded  using  the
    following scheme.

    Suppose a machines MAC  address is aa:bb:cc:dd:ee:ff then  the MAC
    address will be encoded in  the optional data portion of  the ICMP
    reply packet at the byte offsets 05, 10, 13, 19, 21 and 26 as  the
    table below shows:

        Byte        Operation
        
         05        aa XOR 0x44
         10        bb XOR 0x41
         13        dd XOR 0x43
         19        ff XOR 0x55
         20        cc XOR 0x73
         26        ee XOR 0x6c

    (Versions prior to 1.4 use the same operators but this is  encoded
    at different byte offsets in the  payload: 04, 08, 14, 16, 20  and
    28 respectively)

    Early versions  of the  software had  a "Detect  Period" set to 15
    mins, current versions have this set to "0" by default  (disabling
    auto detect).  For the early versions, looking out on the  network
    was sufficient to  detect that there  was a SessionWall-3  in use,
    provided the owner had not  altered this default value.   In order
    to detect  newer versions  with the  default zero  value or  older
    version where  the owner  has set  detect to  "zero" there are two
    possibilities.    First,  and   most  stealthy,   the   legitimate
    SessionWall-3 owner  could try  to detect  other products,  and an
    attacker could  capture the  ICMP request  that also  has the  MAC
    address of the requesting machine  encoded in the ICMP payload  as
    described above.   Secondly an  attacker might  spoof a  detection
    packet with some random or more carefully chosen MAC address  that
    any  active  SessionWall-3  products  cannot  help  but  reply to,
    thereby disclosing its existence.

    For extra  fun you  might like  to generate  a moderate  number of
    detect  request  that  appear  to  come  from a variety of network
    hardware.   Either  real  machines,  capable  of  running  such  a
    product, or for  sheer amusement value  devices such as  firewalls
    and routers that could not possibly run the software.

    A Denial of Service  condition was observed in  SessionWall-3 when
    a large  number (in  the order  of several  thousand) of discovery
    packets  were  generated  on  the  wire  each  with  different MAC
    addresses.  The effect on  the target depends upon the  underlying
    platform: the user interface crashed on NT however the  underlying
    engine  continued  to  capture  sessions.   System  resources were
    exhausted on Win98.  Very  little further work was done  as DoSing
    the machine was  not the main  objective of the  work presented in
    this paper.

    SessionWall-3 is widely available  for free trial download  from a
    number  of  Internet   sites.   Demonstration   keys  are   freely
    distributed by the makers, and expire after 30 days and mask  some
    of  the  content.   The  product  can  be  turned  into  a   fully
    functioning version by entering a valid key.  Many  administrators
    may  find  that  users  are  already  running  their  own  "little
    brother" monitoring operations and logging otherwise private  data
    and information.

    Using the tools  mentioned in this  paper, a system  administrator
    could  check  their  network  for  the  presence of rogue machines
    without the need to own a copy of SessionWall-3.

    Users  of  network  nodes  can  use  these  tools  to  discover if
    administrators  are   using  SessionWall-3   to  snoop   on  their
    activities.

    SessionWall-3 can be used to block access to certain resources  by
    spoofing RST packets and interfering with connections.   Attackers
    may  use  the  tools  mentioned  in  this  paper  to  identify the
    offending censor, and either  remotely disable it using  a variety
    of  other  means  or  gain  physical  access  and use the password
    recovery tool also presented here.

    The  password  encoding  scheme  implemented  by  SessionWall-3 is
    extremely  insecure.   It  is  yet  another  example  of  a vendor
    providing the illusion of security where in fact none exists.  XOR
    encoding has  been widely  abused and  written about  in the past,
    yet it  still makes  its way  into commercial  products.  The fact
    that SessionWall-3  uses subliminal  channels to  communicate with
    other SessionWall-3 machines can be used in a variety of  attacks,
    and  as  a  means  of  discovery  by those other than the original
    operator.

    The original  designers quite  obviously did  not expect thousands
    of products to  inhabit the same  network, however one  of its own
    features can  be used  to limit  the functionality  of the machine
    under certain circumstances.   This "window" of opportunity  could
    be exploited by a variety of attackers.

    Whilst  these  features  have  been  known  about  for a number of
    years, the  exact nature  of these  features have  not been widely
    known about  or indeed  understood.   The tools  presented in this
    paper make a number of other things possible and the authors  hope
    use of  these tools  will lead  to a  greater understanding of the
    features identified  in this  paper and  that further  discoveries
    may be made.

    Proof of  concept code  to perform  several of  the tasks detailed
    above is available from:

        http://www.phate.net

SOLUTION

    Nothing yet.