Carl Tyler's Blog :: What I consider to be a Sametime security risk, IBM does not.

Category Sametime Password

For the last few months I have been having conversations with IBM concerning some functionality in the IBM Lotus Sametime Connect Client API. So before anyone bitches that I am being irresponsible writing this please note that I've gone about this through the right channels, I am not publishing this without IBMs knowledge, this post wont be a surprise to them, they do not consider this a security risk, So what functionality am I referring to? The getPassword() function (Community.getRtcSession().getSigninInfo().getPassword()) in the Connect Client API.

This function allows a Sametime plug-in developer to retrieve the users clear text Sametime password if they are logged in. Why do I feel this is an issue? Well I've always felt that programmers should only have access to the users login token (Notes does not allow access to a users clear text password for example and only provides access to the token). A login token has a time limit on it, and a token isn't used to access other domains, where as people's passwords are often the same for multiple places.

Running a company that makes plug-ins that are freely available, I feel this is an issue as it is a function that could easily be abused by someone that maybe isn't to be trusted and if plug-ins get out that they steal people's passwords, that is bad for all Sametime Plug-in developers, and the very thing (3rd party applications) that Sametime will really need to succeed will be under threat.

Right now it's very easy for someone to build a plug-in for Sametime claiming it does one thing, a to do list for example, whilst in the background the plug-in could be retrieving a users clear text password, server name, username etc. and posting them discreetly in the background to a HTTP site or something where they are all collected.

If you're interested in exactly how this works here is a zip file containing a Sample Sametime plug-in that does nothing more than show the users name and password when clicked. Source and update site here.

So how can you protect yourself against this risk?. Well it depends on if you're using the stand-alone Sametime client or the integrated Notes client.

1. Only use signed code, this is actually harder than it would appear, in the Notes client if you install a plug-in you are shown and prompted if you trust the licensee for the code, the Stand-alone Sametime Connect client doesn't show this information.

2. If using the Notes Integrated Sametime Client, use the Single Sign-On (SSO) option, and don't enter a Sametime password. This way the getPassword function returns nothing.

3. Don't allow users to download and install 3rd party plug-ins. This is controlled in Sametime policies, but be aware this can easily be overridden by a user that badly wants a plug-in by just logging into a different Sametime server, bleedyellow for example.

4. If you don't trust code signing and really need a plug-in ask to see the plug-ins code and check it, this will probably involve lawyers and 3rd party escrow type agencies, but it's probably the only way you can be sure.

It would be great if IBM maybe added some code that notified you if this function was being called (similar to the way that 3rd party apps using the Notes login prompt), although that is hard for the versions of Sametime already out there.

Make sure you know the people you're getting your plug-ins from!

Comments

1 - you got to be kidding me

Posted by Keith Brooks At 08:24:30 PM On 01/31/2009 | - Website - |

2 - It is worth noting that the Notes client feature to share your ID with other programs is described in the user security dialog as:

"Don't prompt for a password from other Notes-based programs (reduces security)".

And I believe that the default setting is off.

Posted by Richard Schwartz At 08:35:47 PM On 01/31/2009 | - Website - |

3 - Re your #4 -- you would actually have to build the code yourself to be sure that what you saw is the actual code.

Posted by Richard Schwartz At 08:58:36 PM On 01/31/2009 | - Website - |

4 - Carl, is it difficult to set a policy on the Sametime server to disallow the installation of 3rd party plug-ins? We might be willing to set such a policy on BleedYellow to avoid leaving such a vector open. I'd certainly propose it to the BY admin team, if I knew what to set.

For the life of me, I can't figure out why there is such an API call for .getPassword(). What possible legitimate use does that have?

Code signing in Eclipse in general is still at mess at the moment. I do know that there are some very capable people from IBM working on stronger runtime code signature solutions, but there's simply a lot of work still left to be done there.

I'm not even going to start on some of the risks with Notes plugin code... Emoticon

Posted by Nathan T. Freeman At 10:51:20 PM On 01/31/2009 | - Website - |

5 - I agree in respect to your concern. I also think security (end to end) doesn't exist (or at least is not cheap).

This said..I think that the "best" solution (the one I'd prefer) would be an ECL alike system where this kind of API call opens up a warning & accept dialog.

Obviously these ECL should be enforceable and controllable by the server/admin.

A nice note: every time a new security problem/concern appear in new software (IBM or not) you just discover notes solved it in an elegant way .. years ago.

Posted by Daniele Vistalli At 04:20:53 AM On 02/01/2009 | - Website - |

6 - In theory you are at risk that your password gets compromised. In the real world I doubt that anyone is interested in attacking Sametime.

Posted by Henning Heinz At 05:00:58 AM On 02/01/2009 | - Website - |

7 - @6 My concern is more about other systems they can get access to once they have your password.

Posted by Carl Tyler At 06:39:12 AM On 02/01/2009 | - Website - |

8 - IBM can be baffling sometimes. I thought the biggest argument they had for corporations to use Sametime was the security model, and this just sounds like a PR mess waiting to happen, even aside from its obvious real security concerns.

And for what it is worth, your point in #7 may be the biggest concern, the fact that people tend to use the same passwords on different systems, and that giving them access to a less secure Sametime may also give them access to more secure systems such as Notes.

Bad show, IBM! Emoticon

Posted by Ben Langhinrichs At 08:49:59 AM On 02/01/2009 | - Website - |

9 - @5: An ECL-like warning, "Plugin 'X' has requested access to your password" is the obvious solution. Not simple, as the client will then have the problem of having to keep a secure record of plugins that have been approved to access the password... but you're so right: IBM learned the right way to solve these problems years ago. It is surprising to see them forget the lessons they learned, and even more surprising to hear that they are denying the importance of this vulnerability.

Posted by Richard Schwartz At 11:16:44 AM On 02/01/2009 | - Website - |

10 - @4 Yes Notes is a whole other bag of worms, once installed a plug-in can pretty much do anything in Notes (except get a clear text password).

Personally I get tired of the excuse "Oh that is eclipse's problem" it's been used for Java Views, for security for all sorts.

Posted by Carl At 11:27:12 AM On 02/01/2009 | - Website - |

11 - @ALL Thanks for your comments, I'm relieved to see others believe this is an issue to.

Posted by Carl At 11:30:12 AM On 02/01/2009 | - Website - |

12 - @10 Oh that is eclipse's problem

I can't agree with this answer (whoever is answering).

IBM successfully implemented DEEP security control in number of java product (I'm thinking of WebSphere Portal and Websphere commerce that have wonderful design for security).

So the "it's eclipse problem" argument is not enough. After all when accessing notes/domino objects it's still going trough domino ECL/Notes API ECL.

What's missing is a JAAS layer on top of the eclipse API to make it hacker/plugin proof.

I would accept a "it needs time" argument but not a "it's not an issue argument".

As noted in @6 password often come from LDAP which could mean Domino directory or active directory.

This mean a Microsoft Enterprise Admin could be hacked with a plugin and just imagine the power (even if "real" enterprise admin should have an isolated enviroment to work in).

Time will tell

Posted by Daniele Vistalli At 12:00:54 PM On 02/01/2009 | - Website - |

13 - P.S.

Before this post becomes the "sametime is not secure" foundation for journalists easy on security holes.

Sametime is on of the most secure systems around.. just having that API available in the wild put some concern on Carl (and others too)

Let's see how the guys at IBM will react (even if you said it's not a problem for them).

Posted by Daniele Vistalli At 12:04:06 PM On 02/01/2009 | - Website - |

14 - @Carl - Does the password still display if using the following setup in the sametime.ini on the Sametime server?

[Directory]
ST_DB_LDAP_SSL_ONLY_FOR_PASSWORDS=1

More information on it here - { Link }

-Tim E. Brown

Posted by Tim E. Brown At 05:41:35 PM On 02/01/2009 | - Website - |

15 - @14 I believe so, as that is the data over the network being encrypted, not what a user has entered as their password in the client.

Posted by Carl Tyler At 08:58:32 PM On 02/01/2009 | - Website - |

16 - @14 & @15 - Yep, it still displays :(

-Tim E. Brown

Posted by Tim E. Brown At 09:53:39 PM On 02/01/2009 | - Website - |

17 - Daniele, please educate me. How is Sametime a secure platform if it can deliver the clear text password to a plug-in which is defined in its architecture.

Posted by Volker Weber At 09:07:37 AM On 02/02/2009 | - Website - |

18 - eh eh :)

It is secure by the fact that it cannot be spoofed over the wire due to sametime encryption.

The getPassword() method is there by design (even if we don't agree). ST Policies allows to set or limit the ability for users to deploy/install plugins thus limiting the issue.

By "insecure" I mean an undocumented way to bypass system security without a way to avoid the issue for the Administrator.

There's no secure system as long as somebody can place code/his hands on the thing.

For instance a Windows 2003 domain controller (local password) password can easily be cracked with tools that corrupts ntuser.dat registry. This doesn't mean it's unsecure overall.

That's why even with this API around Sametime can be considered, in a controlled environment (as enterprise SHOULD be), secured.

Just my point of view.

Posted by Daniele Vistalli At 12:22:28 PM On 02/02/2009 | - Website - |

19 - @18 One of my biggest fears is that someone figures out some exposure in the Websphere server that is embedded in Sametime and in turn can get access to Sametime API calls when a user visits a webpage.

{ Link }

Posted by Carl At 12:29:00 PM On 02/02/2009 | - Website - |

20 - @10 - "Personally I get tired of the excuse "Oh that is eclipse's problem" it's been used for Java Views, for security for all sorts. "

Is that your interpretation of my reply? 'Cause that wasn't what I meant to say.

Posted by Nathan T. Freeman At 01:37:55 PM On 02/02/2009 | - Website - |

21 - @20 Nope, it was a general statement not directed at you. It was something alluded to in some of the emails with IBM.

Posted by Carl At 01:39:43 PM On 02/02/2009 | - Website - |

22 - Wow. How did that function ever make it into a shipping API? Astounding that IBM "Security" merely shrugged off the serious problem you've outlined.

Posted by Rod Stauffer At 05:19:45 PM On 02/02/2009 | - Website - |

23 - @18: re "in a controlled environment (as enterprise SHOULD be)"...

This is exactly the kind of thinking that has gotten many a vendor in serious trouble! Emoticon

The presumptions that the controls will be enforced properly, that they will work as designed even when enforced properly, and that they can't be subverted by attackers or indavertantly by users... these are precisely the reason why "don't store unencrypted passwords in memory longer than required, and don't permanently store them anywhere!" is a lesson from security 101!

And you are not correct that all bets are off if someone can place code on a system. It's an insult to your own company's products to make that claim. Yes, it's true that if someone can load DLLs on a Notes client they can access data with the user's privileges and possibly do great damage... but they still can't steal the Notes user's password without making it apparent that they are tying to do so because the password prompt won't look right! And ordinary Notes applications that are centrally deployable, written in LotusScript and Java, have fine-grained control over what they can and can not do.

This vulnerability potentially allows a rogue developer within a "controlled environment" to steal everyone's password, from the mail room guy up to the CEO. This is preventable and the fact that exposing the plaintext password is part of the API "by design" indicates only one thing: The design favored convenience over the security of users.

Posted by Richard Schwartz At 07:28:10 PM On 02/02/2009 | - Website - |

24 - Clarification... by saying "your own company's products" I was making the assumption that Daniele works for IBM. I actually have no idea if that is the case. In fact, I suspect that I was wrong. So... make that "IBM's other products" instead.

Posted by Richard Schwartz At 07:33:22 PM On 02/02/2009 | - Website - |

25 - @23: re "but they still can't steal the Notes user's password"

I'm afraid I disagree with you on that, although I believe R6 and up are more robust... (DefCon Las Vegas, July 2000 { Link } )

Posted by Wouter Aukema At 11:52:52 PM On 02/02/2009 | - Website - |

26 - And I respectfully disagree with you, Wouter. That article is referring to the user's Internet password for Domino, not the Notes ID password... and I was specifically referring to the fact that the password is secure even if "someone can load DLLs on a Notes client".

Also that article fails to mention that salted Internet passwords were already available as an option on the Domino server at the time of publication. The vulnerability was real with respect to the default setting -- IBM shipped a template that had the setting disabled in order to assure backward compatability on networks that still had very early versions of Domino that didn't understand the salted password.

That said, if you can install a keylogger on the Notes client, or a sniffer on the Domino server, then nothing Lotus does would be able to stop you from intercepting unencrypted passwords.

Posted by Richard Schwartz At 07:34:14 AM On 02/03/2009 | - Website - |

27 - Carl, you may need to modify your 3rd bullet point above... Emoticon

{ Link }

Thanks for the information, and I hope that IBM can resolve this sometime soon.

Posted by Chris Whisonant At 09:39:10 PM On 02/03/2009 | - Website - |

28 - After installing the attached plug-in my sametime client got crashed. Instead of getting online user's password, it forgot my password it self...so i feel sametime passwords are safe! Emoticon

Posted by Joju Augustine At 02:54:38 AM On 02/04/2009 | - Website - |

29 - @28 Thanks JoJu. Sorry to hear that happened, for many other people that has not happened.

By the way I traced your IP address to IBM Global services Inidia, so it's good to see you following the company line.

Posted by Carl At 07:40:59 AM On 02/04/2009 | - Website - |

30 - @28 So according to Carl's trace you work for IGS yet IBM assume that ANY secure enterprise would not allow plugin installations by its users.

There's either something very wrong with IBM's assumption or their internal security if you managed to install the plugin at all Emoticon

Posted by Gab Davis At 10:15:44 AM On 02/04/2009 | - Website - |

31 - Spot on, Gab.

Same can be said about ECLs or ACLs. I have never seen any infrastructure that got it right.

Posted by Volker Weber At 10:21:58 AM On 02/04/2009 | - Website - |

32 - @26:
The article was written the night before we published but fails to mention that we demonstrated two ways to unlock the notes id-file using the http hash found in the nab: 1. on the target workstation using dll-injection against a running notes client and 2. off-site using our sesame utility.
You're right when you say that the Notes password is secure, but that won't help because we can replace the ID-file password with our own. (Sesame was never released for obvious reasons...)

@31:
Notes API calls are not intercepted by the ECL so no matter how strictly implemented, it can easily be bypassed. (VB: set session = createobject("notes.notessession"), etc.)

Posted by Wouter Aukema At 01:36:25 AM On 02/05/2009 | - Website - |

33 - @32: Do your attacks on the Notes ID work only if the http password and Notes ID password are the same?

Posted by Richard Schwartz At 11:56:36 AM On 02/05/2009 | - Website - |

34 - Correct Richard. Alternative method is to obtain a hash from the memory of a running notes client.

Posted by Wouter Aukema At 11:08:44 PM On 03/18/2009 | - Website - |

35 - Good to see that getPassword doesn't work in Sametime 8.5 API. Emoticon

Posted by Jim At 07:12:21 AM On 08/03/2010 | - Website - |

36 - We just discovered this API call and are pretty shocked by its existance.

@35 - The API calls DO work in Sametime 8.5.1

I didn't try the plugin attached to this article, I just added one line of code to an existing plugin:

System.out.println("Your sametime password is " + CommunityUtil.getDefaultPassword());

I disagree with the article saying that one solution is for users to only install signed code. After all, anyone can buy a certificate and sign their plugins....

Posted by Colin Tucker At 10:30:11 AM On 03/29/2011 | - Website - |