From: Codex [codex@BOGUS.NET] Sent: Wednesday, June 07, 2000 3:28 PM To: BUGTRAQ@SECURITYFOCUS.COM Subject: SessionWall-3 Paper + (links to) code 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 Maelstrom Codex 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.