----- Original Message -----
From: "Mycelium" <mycelium@hushmail.com>
To: <full-disclosure@lists.netsys.com>
Sent: Wednesday, August 06, 2003 10:52 PM
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-----
>