One thing that has not garnered a lot of discussion in this thread is the security of the framework within which this system works. My Understanding, and forgive me if it is not correct, is that this Control is installed on a machine and then allows the person at the remote end of the link to interact with the users desktop. There are two important points to note. One if this is how the product functions, then the person on the remote end only has the same "User Privilege" as the person logged on at the console. If care has been taken in assigning security levels and groups appropriately (namely not granting "Local Administrator Rights") then this vector of attack will only be as successful as the person at the console. In other words if they are in the Domain Users group they will not be able to cause major harm on your network. This also assumes one doesn't leave the console logged in and unlocked, I feel locking the console is more secure then leaving it at the login prompt. Two If you don't trust the people with "Domain Administrator" (The ones who could do damage on the servers), then you have much larger problems. It is not possible to trust everyone in the enterprise, but trusting "Domain Admins" is a must. These are the people who could damage your network by installing and activating this service. The major difference I see between WebEx and a common Trojan is that most Trojan's will grant the intruder "Local System" (Local Administrator or Root equivalent) rights regardless of the currently logged on user. This distinction makes it possible to remove this "Service" from the classification of "Trojan" in my mind (Personal Opinion, YMMV). That said, as a security administrator I will be blocking access to any IP addresses owned or used by WebEx. We have our own support staff and meeting scheduling systems and therefore do not require any of their services. Following Jurus Prudence anything which is not needed is blocked. Nothing personal you understand.
Ken Claussen MCSE CCNA CCA "In Theory it should work as you describe, but the difference between theory and reality is the truth! For this we all strive" -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Robertson Sent: Friday, December 21, 2001 7:17 PM To: Barak Engel Cc: '[EMAIL PROTECTED]' Subject: RE: WebEx and the firewall mailing list On Fri, 21 Dec 2001, Barak Engel wrote: > What Im asserting, basically, is that even if the client *is* installed on > a machine, it *cant* be operated without a user specifically asking for it, > manually. I am also saying that it cant be triggerred remotely. And lastly, I'd take a bet on the "manually" part of that statement. > I am saying that for this feature to work requires a set of circumstances > that makes it difficult to abuse. I'm saying that in the $high_number of years I've been doing computer security work (Most of about 18 years in the industry)- I've seen such things abused before and I think it's simplistic to expect that such things won't be abused again. It's a classic tunneling vector, and more importantly if there are significant support companies using it, then it's an attractive target. I'm also saying that people who have large-scale enterprise experience (like for instance, me) will find that the lack of "security friendliness" of such products will cause us to continue to recommend they not be installed, and in some instances be actively blocked by site or AS. In risk terms, the risk profile for such tools is about the same as it is for the trojan set. If someone reverses the protocol, it could be considerably worse. > Basically what Im trying to say is that I dont think that it will be abused > *incidentally*. Of course, it can for example be abused by a disgruntled > employee. Now the question becomes - how much does one trust one's > employees? When you have tens of thousands of employees, one doesn't trust at least a few of them. Surely you don't believe that all the bad guys are unemployed? Even more surely, you don't trust all of your developers enough to not review their work and change access control mechanisms? > Btw, we really are not in support space. We are in the meeting space. The > meeting product has an additional feature that can be purchased for an > additional fee that allows the *customer* to support *their* users. Webex is > not a part of it except in the sense that we provide the tool. It's the tool that the discussion was centered around, but if you don't sell the server, then you're obviously running it, no? If so, then 3rd party assurance of your site is imporant, if not, then obviously assurance at each vendor site is paramont- normal software developer overflow idiocy aside. In that space, obviously the assurance ball is firmly in your court. Also, surely WebEx itself uses WebEx to provide support to it's own WebEx customers, and therefore has some level of access to their systems? Don't get me wrong- I'm appreciative of any vendor who's willing to discuss issues in public- and that should weigh in people's minds as they make decisions, but there's a point where you need to decide to either play well with grumpy security admins, or decide that their requirements suck and accept the valid criticism of those folk who'll be biting the bullet if/when there's a failure. Paul ---------------------------------------------------------------------------- - Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
