full-disclosure - RE: FW: defeating Lotus Sametime "encryption"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <200308120328.h7C3SI5D045763@mailserver3.hushmail.com>
From: mycelium at hushmail.com (Mycelium)
Subject: RE: FW: defeating  Lotus Sametime "encryption"

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

> How interesting, ;)

Then you'll find this even more interesting, synok.

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

Wrong. The disclosures apply to current versions of the Sametime
client (3.0) just as much as the older 1.5 versions. Read the
original post.

> Seems this was fixed a long time ago.

Wrong. None of it has been fixed and it exists as a problem to this
day.

Now for the rebuttal to the "forums" post (I don't post to web
forums. It's a waste of time.)

> I hate such people like mycelium trying to make fuzz talking about
> old versions of software.

Wrong. I'm not "making fuzz about old software" I stated clearly in
the initial disclosure that it applied to Sametime 1.5 and 3.0.

> This is all about ST 1.5 as a server, not about 3.0 or 3.1. ST 3
> uses 128-bit RC2, no less.

The key length is irrelevant when you GIVE THE KEY AWAY or use bad
key-generation techniques which allow guessing-attacks against your
key (_current_ ST3 has both problems). Not only does Sametime 1.5,
2.0, and 3.0 give the key away in the login packet, it generates the
key weakly. READ the original post before you "make fuzz", mmkay?
Furthermore the server version is not germane in any way shape or
form. The _current_ Sametime 3.0 Windows client sends a combined
handshake and login in the initial packet. If you had read the
original disclosure and looked at the analysis before you made your
criticism.

> Deciding whether to encrypt all meetings -- Data that passes
> between Sametime Meeting Room clients can be encrypted using
> 128-bit RC2 encryption.

    This is a misrepresentation. The data never passes between
clients directly and the data is only encrypted between the client
and server. Clients have no end-to-end encryption protecting their
privacy from being invaded by whomever operates the server. Clients
are not notified of this fact. They are merely told that their chat
is "secured" and shown a lock icon in the client.

> Note With Sametime releases 2.5 and higher, all chat data is >encrypted
> regardless of whether the "Encrypt all meetings" setting is  >selected.

None of this is germane to my disclosures. What good is encryption
if someone can recover your key with ease?

> mycelium should try to look at a ST 2.5 or higher server and
> client connection. But maybe this would not give such a nice
> headline.

In fact it does "gives such a nice headline" since Sametime 3.0 is
just as vulnerable to these flaws as Sametime 1.5. I suggest you
spend some time READING the original advisory and think before you
speak.

mycelium

-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.3

wkYEARECAAYFAj84ULAACgkQ4QvHYXjnrA//lgCeOOjK0o6GacKDPoFVk3tNxpYVaa8A
n0gcJdPfi9Dc8Qnxjcvuo8eFmbhz
=L1QN
-----END PGP SIGNATURE-----