-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The following is my response to IBM / Lotus concerning their denial reaction
to the vulnerabilities disclosed in Sametime. This is not a flame / troll,
and there is some new information here, including a packet level analysis
of
a CURRENT Sametime 3.0 login message.
Ed Brill with IBM/Lotus said:
> The alert describes "moderately critical" encryption vulnerabilities
in
> the product. Certainly something worth looking into.
No, I didn't say the information I disclosed was "moderately critical",
it was "severe." About the only thing worse would be buffer overflows
giving
remote privileges (which I'm working on, also). There are also 4 potential
DoS attacks which I'll also be releasing later when I get time to write
them
up. I'll be sure and release PoC code next time, so you won't be so quick
to
deny the truth.
> The good news is, the particular vulnerability being reported hasn't
been
> in a shipping version of Sametime for years. The particular problem
in
> question was recognized as a security flaw in Sametime 1.5, and was
fixed
> in Sametime 2.0 (and all versions since then).
This is blatantly false. See the analysis of the Sametime 3.0 login
packet at the end of this message. The original disclosure I posted had
essentially three points. First was that the key was being sent along
with
the user's encrypted password. Let me ask you something from crypto 101,
Ed.
How do you do secure key exchange in a single packet? The answer is "you
don't". Sametime 3.0 (the most current Windows Sametime client), sends
a
SINGLE packet containing much the same info as a Sametime 1.5 does. Yes,
it's structured a bit differently, and you guys _might_ have added an
initialization vector at the end of the key, but essentially the information
is EXACTLY the same stuff with EXACTLY the same problem as Sametime 1.5
has.
You simply can't send a user's credentials somewhere over a network securely
unless you either use a key-exchange protocol, or you already have a
symmetric key agreed on. Windows Sametime 3.0 client does neither.
Secondly the original disclosure cited the fact that the client was
using a very weak method of key selection. The key is basically 10 bytes
of
data composed only of the possible ascii digits "0" to "9" (hexidecimal
0x30
to 0x39). If you have 10 bytes of data each with 10 possibilities that
gives
you 10^10 possibilities instead of what a standard 10 byte key would
give
you which is 256^10 possibilities. This is 4th grade math. The Sametime
3.0
client STILL has this problem and it's clearly illustrated by the packet
analysis at the end.
The third part of the disclosure was the fact that Sametime messages
open up with the same 6 encrypted bytes every time. This leads to the
ability to do a "known plaintext" attack against the messages similar
to the
way WEP is broken. Sit on the wire and sniff enough messages and you
can
easily recover the key after you get enough known ciphertext, and especially
considering the fact you are using RC2. This problem is also still in
Sametime 3.0.
> I've deliberately not linked to the security advisory from this blog
> entry, because I'm really not interested in publicizing a four-year-
old
> find.
I know I'm not the first person to notice that you send the key in-
line
with the user's password. Anyone can figure that out by looking at a
packet
trace for about 30 seconds. However, I am pretty sure I am the first
to
point out the key generation issues, and the known plaintext issues.
Furthermore, I don't know of any IBM or Lotus advisories on any of
the
issues. Even if your claim that the problems only existed in 1.5 were
the
slightest bit true, you guys have had 4 years to publish your own advisories
to inform your customers. Instead you are too busy publicizing how secure
Sametime is and how easy it allows a corporation to monitor messages
(with
newer Lotus press releases). I also don't see anything in the Sametime
documentation that points out the critical fact that Sametime chat sessions
CANNOT be encrypted end-to-end with the regular Sametime clients. They
are
merely improperly encrypted from the client to the server. This might
have
protected against MitM attacks if you guys had done it right, but it
still
does nothing to protect the user's privacy. Funny how that just gets
swept
under the rug.
I wonder how many Sametime user's see a padlock-icon on their chat
session and think they are safe from corporate invasion of their private
conversation. Maybe IBM or Lotus should start selling devices to monitor
audio and video in the employee workplace without the employee's knowledge.
If it were legal, perhaps you could also create a PBX which breaks out
all
conversations to a digital voice recorder mux (again without either party
knowing you are recording). The latter would of course be illegal in
most
states. However, I doubt the same law applies to electronic conversations,
so you guys are safe, and since this is the age of the DCMA, RIAA, and
homeland security, any privacy law with real effectiveness is getting
long
in the tooth.
> For those who haven't yet enountered it, we've asked the publisher
to
> specify the version number associated with this problem (or remove
the
> bulletin altogether).
I don't know who you are talking about, but you sure as heck didn't
send
me anything. However, it wouldn't really change anything if you did.
You
need to go fix the code and the architecture of your software, and stop
wasting time denying that you screwed up. Don't get comfy either. I have
plenty of other Sametime bugs which I'm contemplating release of. Some
of
them are not at all "known issues" so I'll probably zero-day them out
to the
script kids on IRC first, then let full-disclosure and bugtraq in on
it
after the kids had some fun for a few months. I don't do pre-release
commercial vendor notification: ever.
A Sametime 3.0 Login Message Analysis:
00 -- length of packet
00 -- length of packet
00 -- length of packet
76 -- length of packet (118 bytes)
00 -- message type
00 -- message type
00 -- options
00 -- options
00 -- channel ID
00 -- channel ID
00 -- channel ID
00 -- channel ID
00 -- major version
1e -- major version
00 -- minor version
1d -- minor version note that the IETF draft says 0x0018. Trick?
00 -- master channel ID
00 -- master channel ID
00 -- master channel ID
00 -- master channel ID
00 -- server sees IP
00 -- server sees IP
00 -- server sees IP
00 -- server sees IP
10 -- login type
02 -- login type (C++ / ActiveX)
c0 -- client ip (192)
a8 -- client ip (168)
01 -- client ip (1)
1e -- client ip (30)
01 -- end of handshake?
00 -- "hi this is > st2.x"
00 -- "hi this is > st2.x"
01 -- "hi this is > st2.x"
00 -- length of key
0e -- length of key (14 bytes)
37 -- RC2 key data <--- You lied Lotus; it's still here.
37 -- RC2 key data <--- You lied Lotus; it's still ascii 0-9
30 -- RC2 key data
37 -- RC2 key data
35 -- RC2 key data
20 -- RC2 key data
30 -- RC2 key data
39 -- RC2 key data
31 -- RC2 key data
31 -- RC2 key data
62 -- an IV perhaps?
60 -- an IV perhaps?
31 -- an IV perhaps?
62 -- an IV perhaps?
00 -- length of ciphered data
00 -- length of ciphered data
00 -- length of ciphered data
38 -- length of ciphered data (56 bytes)
xx -- begin 56 bytes of ciphered data w/ username + password (my actual
data removed)
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- Body of encrypted data
xx -- end of encrypted data
00 -- length of ascii node name
00 -- length of ascii node name
00 -- length of ascii node name
08 -- length of ascii node name (8 bytes)
76 -- ascii (v)
6d -- ascii (m)
77 -- ascii (w)
61 -- ascii (a)
72 -- ascii (r)
65 -- ascii (e)
32 -- ascii (2)
6b -- ascii (k)
- ------[ the end ]--
- --
Mycelium
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.3
wkYEARECAAYFAj83lDkACgkQ4QvHYXjnrA/hRACdF/6v9JL5YSmVCyFP2OdboLAbRDAA
nRw3l+tPTmtM52utVumxpojVnxYm
=EgKO
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Mon Aug 11 2003 - 06:31:01 PDT