Message-ID: <NHBBJCOKMLKMFIKODHGPCELJCCAA.gatekeep@mts.net>
From: gatekeep at mts.net (Ron Rempel)
Subject: RE: FW: defeating  Lotus Sametime "encryption"

How interesting, ;)
  -----Original Message-----
  From: steve.rempel@...pel-home.com [mailto:steve.rempel@...pel-home.com]
  Sent: August 11, 2003 12:12 AM
  To: gatekeep@....net
  Subject: Re: FW: defeating Lotus Sametime "encryption"



  This surprised me, so I had a quick look at the Sametime Users Forum.  I
found that this "discovery" was made with a four year old version of the
server software.  Here is a link to the discussion thread:


http://www-10.lotus.com/ldd/stforum.nsf/DateAllThreadedweb/d075c360296b71348
5256d7c002886dd?OpenDocument

  Seems this was fixed a long time ago.




       "Ron Rempel" <gatekeep@....net>
        08/08/2003 08:16 AM

                To:        <steve.rempel@...pel-home.com>
                cc:
                Subject:        FW: defeating  Lotus Sametime "encryption"





  -----Original Message-----
  From: Mycelium [mailto:mycelium@...hmail.com]
  Sent: August 7, 2003 1:52 AM ,
  To: full-disclosure@...ts.netsys.com
  Subject: defeating Lotus Sametime "encryption"




  *** PGP Signature Status: unknown
  *** Signer: Unknown, Key ID = 0x78E7AC0F
  *** Signed: 07/08/2003 12:52:03 AM
  *** Verified: 08/08/2003 9:15:42 AM
  *** BEGIN PGP VERIFIED MESSAGE ***


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




  *** END PGP VERIFIED MESSAGE ***



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030811/46a9170e/attachment.html

Powered by blists - more mailing lists