Message-ID: <200308070652.h776qKKj011216@mailserver3.hushmail.com>
From: mycelium at hushmail.com (Mycelium)
Subject: defeating  Lotus Sametime "encryption"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


.-=( Short version )=-.
	Normal Lotus SameTime login credential encryption with 1.5 and 3.0 Windows
clients use RC2 (very improperly) to encrypt the password, and even send
the key along with the login packet allowing an attacker to decrypt the
credentials and steal a user's IM identity.

.-=( Background )=-.

	Lotus Sametime is an Instant messaging protocol owned by Lotus
Corporation, who in turn is owned by IBM. The Lotus Sametime web page
says "... with over 8 million users, is the market leading instant
messaging and Web conferencing solution for business." More market
droid speak from http://lotusdevelopmentadvisor.com/doc/11498 says:
"Because of questionable security and other shortcomings in consumer
IM, companies have become increasingly concerned about unsanctioned
use. Companies that realize the need for secure and reliable instant
messaging turn from consumer IM to much more robust business IM
platforms. For example, Lotus Sametime provides encryption, logging,
archiving, directory integration, and integration into other business
applications."

.-=( Synopsis )=-.

	The following information details several severe flaws in the way encrypted
logins and chats are handled. Users and administrators of
Sametime should be aware of the vulnerabilities in the protocol.
	In short, login messages contain the RC2/40 key in the login
message itself. This allows an attacker to intercept and decrypt the
user's password with very little effort. Additionally keys are
transmitted with instant messages as well, and every instant message
has 6 bytes of known-plaintext in the beginning of the data stream.
Finally, the 10 byte RC2/40 keys are generated using only ASCII
representations of decimal numbers 0-9 (hexadecimal 0x30 - 0x39),
instead of using the full 256 possibilities available per each byte of
the 10 byte key. This means there are only 10^10 possibilities for any
Sametime key, rather than the potential 256^10. Even a low-end (but
fairly modern) personal computer can be used to brute force the key
rather quickly. Then again, why would you need to since the key is
right there in the login packet?
	Users who think that they are being protected by Sametime
"encryption" are not only risking having their passwords exposed, but
also the messages they send which may contain confidential information
(especially since Sametime is an IM aimed at corporate users).
Additionally Sametime users should be aware that encryption is NOT
end-to-end, and they can be snooped on by the server operator. There
are several commercial products sold to do this, and they work
regardless of the "encryption" selected by the client. For non-SEC use,

this should be considered unacceptable.

=( Login Message Analysis )=

A Lotus Sametime 1.5 Login (extracted from tcpdump) message looks like
this:

82 -- A sequence byte. - 0x81 was the first byte
00 -- Total data length
00 -- Total data length
00 -- Total data length
45 -- Total data length (69 bytes)
00 -- Message Type
01 -- Message Type
00 -- Options
00 -- Options
00 -- Channel ID
00 -- Channel ID
00 -- Channel ID
00 -- Channel ID
10 -- The type of login (Java / C++ / ActiveX etc..)
02 -- The type of login (in this case 0x1002 == C++)
00 -- Length of the following string
11 -- Length of the following string (17 bytes)
6a -- j
6f -- o
65 -- e
62 -- b
6C -- l
6F -- o
40 -- @
97 -- a
98 -- b
2e -- .
78 -- x
79 -- y
7a -- z
2e -- .
63 -- c
6f -- o
6d -- m
00 -- length of opaque for auth data
00 -- length of opaque for auth data
00 -- length of opaque for auth data
22 -- length of opaque for auth data (34 bytes)
00 -- length of opaque for RC2 key
00 -- length of opaque for RC2 key
00 -- length of opaque for RC2 key
0a -- length of opaque for RC2 key (10 bytes)
33 -- opaque RC2 key data 1
36 -- opaque RC2 key data 2
30 -- opaque RC2 key data 3
37 -- opaque RC2 key data 4
34 -- opaque RC2 key data 5
30 -- opaque RC2 key data 6
33 -- opaque RC2 key data 7
35 -- opaque RC2 key data 8
30 -- opaque RC2 key data 9
31 -- opaque RC2 key data 10
00 -- length of opaque data for encrypted password
00 -- length of opaque data for encrypted password
00 -- length of opaque data for encrypted password
10 -- length of opaque data for encrypted password (16 bytes)
XX -- opaque password data 1 - data omitted to protect the guilty ;-)
XX -- opaque password data 2 - data omitted to protect the guilty ;-)
XX -- opaque password data 3 - data omitted to protect the guilty ;-)
XX -- opaque password data 4 - data omitted to protect the guilty ;-)
XX -- opaque password data 5 - data omitted to protect the guilty ;-)
XX -- opaque password data 6 - data omitted to protect the guilty ;-)
XX -- opaque password data 7 - data omitted to protect the guilty ;-)
XX -- opaque password data 8 - data omitted to protect the guilty ;-)
XX -- opaque password data 9 - data omitted to protect the guilty ;-)
XX -- opaque password data 10 - data omitted to protect the guilty ;-
)
XX -- opaque password data 11 - data omitted to protect the guilty ;-
)
XX -- opaque password data 12 - data omitted to protect the guilty ;-
)
XX -- opaque password data 13 - data omitted to protect the guilty ;-
)
XX -- opaque password data 14 - data omitted to protect the guilty ;-
)
XX -- opaque password data 15 - data omitted to protect the guilty ;-
)
XX -- opaque password data 16 - data omitted to protect the guilty ;-
)
00 -- Authentication Type
02 -- Authentication Type

A 3.0 version of the client looks very much like this, but there is an
extra 4 bytes which I suspect is used in some way to try to partially
address the weak key generation (but I don't know for sure, since the
3.0 protocol isn't documented). Unfortunately the 3.0 client suffers
from the same stupidity of having the key and they password sent along
with the initial login message. Java Sametime API docs talk about the
possibility of using 128bit RC2 with Diffie-Hellman key exchange. If
the server is capable of doing this, why are the most ubiquitous
clients (both major Windows clients) doing logins this insecure way?

.-=( The Details of the Aftermath )=-.

I have noticed three serious flaws from the former analysis.

1. The RC2/40 key is right here in the same damn packet as the user's
   Sametime password that they key was used to encrypt!!. This reduces
   the encryption to nothing better than obfuscation on par with XOR
   with a known key.

2. Notice that the 10 bytes of the RC2 key are all in the range of 0x30
   to 0x39 (ASCII for digits 0-9). This limits the possibilities to
   10^10 or 10,000,000,000 rather than 256^10 or
   1,208,925,819,614,629,174,706,176.  As you can see, this drastically
   reduces the amount of time needed to brute force a key even if you
   happened to miss stealing it earlier.

3. The first 6 bytes of the encrypted password field are always the
   same, this makes it easy to use a known-plaintext attack to speed
up
   the decryption process. A similar technique is used on encrypted
   message "channels" and there is some similar stupidity used there
as
   well.

.-=( Credits and Greets )=-.

	The fact that the Sametime protocol is has been designed so poorly
makes it hard to say "I discovered this". However, I will take credit
for pointing out the known plaintext and weak key generation issues.

I'd like to shout out to:

Aliver, Major Malfunction, Greg Hoglund, Crusader, Gluke, Lockheed,
Jeff K, the rest of the MCS crew, and my friend Bryan Deneke (RIP).


Till next time,
mycelium.



-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.3

wkYEARECAAYFAj8x6QMACgkQ4QvHYXjnrA+aKwCguf+dGZy1G4t5Qs+PVz3YGyaIGKIA
oKGuaMlZaU/hdy6xq09P+kkFB04i
=R0Ip
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists