[VulnWatch] defeating Lotus Sametime "encryption"

loper_at_hushmail.com
Date: 08/07/03

  • Next message: _at_stake Advisories: "[VulnWatch] Sustworks Unauthorized Network Monitoring and tcpflow format string attack"
    Date: Thu,  7 Aug 2003 12:33:49 -0700
    To: vulnwatch@vulnwatch.org
    
    

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

    - ----- Forwarded Message from Mycelium <mycelium@hushmail.com> -----

    .-=( 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

    wkYEARECAAYFAj8yqY4ACgkQoV/1CFyTO43M7ACfek9UX9DerqzYGhm85oe36EcM/CwA
    nAj/Wur1pHJxCbNvKiPjSq+SsTFO
    =BVSb
    -----END PGP SIGNATURE-----

    Concerned about your privacy? Follow this link to get
    FREE encrypted email: https://www.hushmail.com/?l=2

    Free, ultra-private instant messaging with Hush Messenger
    https://www.hushmail.com/services.php?subloc=messenger&l=434

    Promote security and make money with the Hushmail Affiliate Program:
    https://www.hushmail.com/about.php?subloc=affiliate&l=427


  • Next message: _at_stake Advisories: "[VulnWatch] Sustworks Unauthorized Network Monitoring and tcpflow format string attack"