[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Full-Disclosure] RE: FW: defeating Lotus Sametime "encryption"
- To: <steve.rempel@rempel-home.com>
- Subject: [Full-Disclosure] RE: FW: defeating Lotus Sametime "encryption"
- From: "Ron Rempel" <gatekeep@mts.net>
- Date: Mon, 11 Aug 2003 10:38:10 -0500
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=724553515-11082003>How
interesting, ;)</SPAN></FONT></DIV>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> steve.rempel@rempel-home.com
[mailto:steve.rempel@rempel-home.com]<BR><B>Sent:</B> August 11, 2003 12:12
AM<BR><B>To:</B> gatekeep@mts.net<BR><B>Subject:</B> Re: FW: defeating Lotus
Sametime "encryption"<BR><BR></FONT></DIV><BR><FONT face=sans-serif
size=2>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:</FONT>
<BR><BR><FONT face=sans-serif
size=2>http://www-10.lotus.com/ldd/stforum.nsf/DateAllThreadedweb/d075c360296b713485256d7c002886dd?OpenDocument</FONT>
<BR><BR><FONT face=sans-serif size=2>Seems this was fixed a long time
ago.</FONT> <BR><BR><BR><BR><BR>
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD>
<TD><FONT face=sans-serif size=1><B>"Ron Rempel"
<gatekeep@mts.net></B></FONT>
<P><FONT face=sans-serif size=1>08/08/2003 08:16 AM</FONT> </P>
<TD><FONT face=Arial size=1> </FONT><BR><FONT
face=sans-serif size=1> To:
<steve.rempel@rempel-home.com></FONT> <BR><FONT
face=sans-serif size=1> cc:
</FONT> <BR><FONT face=sans-serif size=1>
Subject: FW: defeating
Lotus Sametime
"encryption"</FONT></TR></TBODY></TABLE><BR><BR><BR><TT><BR><BR><FONT
size=2>-----Original Message-----<BR>From: Mycelium
[mailto:mycelium@hushmail.com]<BR>Sent: August 7, 2003 1:52 AM<SPAN
class=724553515-11082003><FONT face=Arial
color=#0000ff> , </FONT></SPAN><BR>To:
full-disclosure@lists.netsys.com<BR>Subject: defeating Lotus Sametime
"encryption"<BR><BR><BR><BR><BR>*** PGP Signature Status: unknown<BR>***
Signer: Unknown, Key ID = 0x78E7AC0F<BR>*** Signed: 07/08/2003 12:52:03
AM<BR>*** Verified: 08/08/2003 9:15:42 AM<BR>*** BEGIN PGP VERIFIED MESSAGE
***<BR><BR><BR>.-=( Short version )=-.<BR>
Normal Lotus SameTime login credential encryption with
1.5 and 3.0 Windows<BR>clients use RC2 (very improperly) to encrypt the
password, and even send<BR>the key along with the login packet allowing an
attacker to decrypt the<BR>credentials and steal a user's IM
identity.<BR><BR>.-=( Background )=-.<BR><BR>
Lotus Sametime is an Instant messaging protocol
owned by Lotus<BR>Corporation, who in turn is owned by IBM. The Lotus Sametime
web page<BR>says "... with over 8 million users, is the market leading
instant<BR>messaging and Web conferencing solution for business." More
market<BR>droid speak from http://lotusdevelopmentadvisor.com/doc/11498
says:<BR>"Because of questionable security and other shortcomings in
consumer<BR>IM, companies have become increasingly concerned about
unsanctioned<BR>use. Companies that realize the need for secure and reliable
instant<BR>messaging turn from consumer IM to much more robust business
IM<BR>platforms. For example, Lotus Sametime provides encryption,
logging,<BR>archiving, directory integration, and integration into other
business<BR>applications."<BR><BR>.-=( Synopsis )=-.<BR><BR>
The following information details
several severe flaws in the way encrypted<BR>logins and chats are handled.
Users and administrators of<BR>Sametime should be aware of the vulnerabilities
in the protocol.<BR> In
short, login messages contain the RC2/40 key in the login<BR>message itself.
This allows an attacker to intercept and decrypt the<BR>user's password with
very little effort. Additionally keys are<BR>transmitted with instant messages
as well, and every instant message<BR>has 6 bytes of known-plaintext in the
beginning of the data stream.<BR>Finally, the 10 byte RC2/40 keys are
generated using only ASCII<BR>representations of decimal numbers 0-9
(hexadecimal 0x30 - 0x39),<BR>instead of using the full 256 possibilities
available per each byte of<BR>the 10 byte key. This means there are only 10^10
possibilities for any<BR>Sametime key, rather than the potential 256^10. Even
a low-end (but<BR>fairly modern) personal computer can be used to brute force
the key<BR>rather quickly. Then again, why would you need to since the key
is<BR>right there in the login packet?<BR>
Users who think that they are being protected by
Sametime<BR>"encryption" are not only risking having their passwords exposed,
but<BR>also the messages they send which may contain confidential
information<BR>(especially since Sametime is an IM aimed at corporate
users).<BR>Additionally Sametime users should be aware that encryption is
NOT<BR>end-to-end, and they can be snooped on by the server operator.
There<BR>are several commercial products sold to do this, and they
work<BR>regardless of the "encryption" selected by the client. For non-SEC
use,<BR><BR>this should be considered unacceptable.<BR><BR>=( Login Message
Analysis )=<BR><BR>A Lotus Sametime 1.5 Login (extracted from tcpdump) message
looks like<BR>this:<BR><BR>82 -- A sequence byte. - 0x81 was the first
byte<BR>00 -- Total data length<BR>00 -- Total data length<BR>00 -- Total data
length<BR>45 -- Total data length (69 bytes)<BR>00 -- Message Type<BR>01 --
Message Type<BR>00 -- Options<BR>00 -- Options<BR>00 -- Channel ID<BR>00 --
Channel ID<BR>00 -- Channel ID<BR>00 -- Channel ID<BR>10 -- The type of login
(Java / C++ / ActiveX etc..)<BR>02 -- The type of login (in this case 0x1002
== C++)<BR>00 -- Length of the following string<BR>11 -- Length of the
following string (17 bytes)<BR>6a -- j<BR>6f -- o<BR>65 -- e<BR>62 -- b<BR>6C
-- l<BR>6F -- o<BR>40 -- @<BR>97 -- a<BR>98 -- b<BR>2e -- .<BR>78 -- x<BR>79
-- y<BR>7a -- z<BR>2e -- .<BR>63 -- c<BR>6f -- o<BR>6d -- m<BR>00 -- length of
opaque for auth data<BR>00 -- length of opaque for auth data<BR>00 -- length
of opaque for auth data<BR>22 -- length of opaque for auth data (34
bytes)<BR>00 -- length of opaque for RC2 key<BR>00 -- length of opaque for RC2
key<BR>00 -- length of opaque for RC2 key<BR>0a -- length of opaque for RC2
key (10 bytes)<BR>33 -- opaque RC2 key data 1<BR>36 -- opaque RC2 key data
2<BR>30 -- opaque RC2 key data 3<BR>37 -- opaque RC2 key data 4<BR>34 --
opaque RC2 key data 5<BR>30 -- opaque RC2 key data 6<BR>33 -- opaque RC2 key
data 7<BR>35 -- opaque RC2 key data 8<BR>30 -- opaque RC2 key data 9<BR>31 --
opaque RC2 key data 10<BR>00 -- length of opaque data for encrypted
password<BR>00 -- length of opaque data for encrypted password<BR>00 -- length
of opaque data for encrypted password<BR>10 -- length of opaque data for
encrypted password (16 bytes)<BR>XX -- opaque password data 1 - data omitted
to protect the guilty ;-)<BR>XX -- opaque password data 2 - data omitted to
protect the guilty ;-)<BR>XX -- opaque password data 3 - data omitted to
protect the guilty ;-)<BR>XX -- opaque password data 4 - data omitted to
protect the guilty ;-)<BR>XX -- opaque password data 5 - data omitted to
protect the guilty ;-)<BR>XX -- opaque password data 6 - data omitted to
protect the guilty ;-)<BR>XX -- opaque password data 7 - data omitted to
protect the guilty ;-)<BR>XX -- opaque password data 8 - data omitted to
protect the guilty ;-)<BR>XX -- opaque password data 9 - data omitted to
protect the guilty ;-)<BR>XX -- opaque password data 10 - data omitted to
protect the guilty ;-<BR>)<BR>XX -- opaque password data 11 - data omitted to
protect the guilty ;-<BR>)<BR>XX -- opaque password data 12 - data omitted to
protect the guilty ;-<BR>)<BR>XX -- opaque password data 13 - data omitted to
protect the guilty ;-<BR>)<BR>XX -- opaque password data 14 - data omitted to
protect the guilty ;-<BR>)<BR>XX -- opaque password data 15 - data omitted to
protect the guilty ;-<BR>)<BR>XX -- opaque password data 16 - data omitted to
protect the guilty ;-<BR>)<BR>00 -- Authentication Type<BR>02 --
Authentication Type<BR><BR>A 3.0 version of the client looks very much like
this, but there is an<BR>extra 4 bytes which I suspect is used in some way to
try to partially<BR>address the weak key generation (but I don't know for
sure, since the<BR>3.0 protocol isn't documented). Unfortunately the 3.0
client suffers<BR>from the same stupidity of having the key and they password
sent along<BR>with the initial login message. Java Sametime API docs talk
about the<BR>possibility of using 128bit RC2 with Diffie-Hellman key exchange.
If<BR>the server is capable of doing this, why are the most
ubiquitous<BR>clients (both major Windows clients) doing logins this insecure
way?<BR><BR>.-=( The Details of the Aftermath )=-.<BR><BR>I have noticed three
serious flaws from the former analysis.<BR><BR>1. The RC2/40 key is right here
in the same damn packet as the user's<BR> Sametime password that they
key was used to encrypt!!. This reduces<BR> the encryption to nothing
better than obfuscation on par with XOR<BR> with a known key.<BR><BR>2.
Notice that the 10 bytes of the RC2 key are all in the range of 0x30<BR>
to 0x39 (ASCII for digits 0-9). This limits the possibilities to<BR>
10^10 or 10,000,000,000 rather than 256^10 or<BR>
1,208,925,819,614,629,174,706,176. As you can see, this
drastically<BR> reduces the amount of time needed to brute force a key
even if you<BR> happened to miss stealing it earlier.<BR><BR>3. The
first 6 bytes of the encrypted password field are always the<BR> same,
this makes it easy to use a known-plaintext attack to speed<BR>up<BR>
the decryption process. A similar technique is used on encrypted<BR>
message "channels" and there is some similar stupidity used
there<BR>as<BR> well.<BR><BR>.-=( Credits and Greets )=-.<BR><BR>
The fact that the Sametime
protocol is has been designed so poorly<BR>makes it hard to say "I discovered
this". However, I will take credit<BR>for pointing out the known plaintext and
weak key generation issues.<BR><BR>I'd like to shout out to:<BR><BR>Aliver,
Major Malfunction, Greg Hoglund, Crusader, Gluke, Lockheed,<BR>Jeff K, the
rest of the MCS crew, and my friend Bryan Deneke (RIP).<BR><BR><BR>Till next
time,<BR>mycelium.<BR><BR><BR><BR><BR>*** END PGP VERIFIED MESSAGE
***<BR><BR><BR></FONT></TT><BR></BLOCKQUOTE></BODY></HTML>