Vulnerability
SessionWall-3
Affected
SessionWall-3
Description
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.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
