SessionWall-3 Paper + (links to) code

[codex () BOGUS NET (Codex)]

Dear All,

The example code which compliments this paper can be found on

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

Best regards, and enjoy.

-cdx

--

             Design and Implementation Flaws in SessionWall-3
                                    or
         "Using and Abusing SessionWall-3 with the power of XOR"

                                    by
                            Ob1 <ob1 () phate net>
                        Maelstrom <mael () phate net>
                          Codex <codex () phate net>

                                June 2000.

-[ Overview ]-
  ----------

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.

-[ Password Retrieval ]-
  --------------------

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.

-[ Remote Discovery ]-
  ------------------

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.

-[ Summary ]-
  ---------

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.

-[ Conclusion ]-
  ------------

The password encoding scheme implemented by SessionWall-3 is extremely in-
secure. 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.

-[ Example code ]-
  --------------

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

http://www.phate.net

Currently the following files should be online:

sw3passw.exe      -   SW-3 Admin Password decryptor for win9x/NT.
sw3pwsrc.zip      -   x86 asm source to the SW-3 pw decryptor (use TASM).
sw3tools.tar.gz   -   Includes: sw3discover = passive SW-3 detection,
                                sw3munge = SW-3 detect & reply tool,
                                sw3spoof = active SW-3 detect & reply
                                           packet forger.