|
-----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 wkYEARECAAYFAj83loUACgkQ4QvHYXjnrA+oxQCfYFAcklwED9m2nRKiiDDoU224840A oJu+ouft/leE+WgaoPuxYoiigZPR =FcmG -----END PGP SIGNATURE-----