Quoting Paul Robertson ([EMAIL PROTECTED]): > > trust encrypted data streams. Nothing stops me from writing a remote > > control trojan doing its work over SSL with seemingly proper cleartext > > pre-negotiation. > > Or one that does it over HTTP and is called WebEx...
You *do* know how HTTP, the Hypertext Transfer Protocol, works? To even imply, WebEx "does it over HTTP" makes me shudder. WebEx uses a Website to establish the initial meeting parameters and, from there on, could potentiall use every Port available. Which is, btw., not that different from about every serious software I know. HTTP is a well defined protocol, and NO, WebEx does not use it. WebEx uses its own protocol, orthogonally different from HTTP. > Perhaps you will _if_ you're an intentionally malicious user, but we have > two issues here that aren't covered by that, the first is an oppertunity > for a released employee, and the second is for a user to lower the overall Please, show me a usage scenario in which a released employee, from remote, activates this remote control functionality. He will need exactly that level of access he would gain by activating this feature to activate it. IF the user has the ability to start the client, he already HAS full access to the desktop. The WebEx client is not bound to a socket, cannot be accessed inbound and requires ative interaction *on the shared dektop* to share the desktop. Again, how would you propose I'd do that? > > Aggreed. Poor business decisions should not be blamed on vendors or > > concepts, though. It seems you have not had a look into the way WebEx > > works: > > It seems you've only looked at the "meeting" feautre, and not the "remote > support" feature. In fact, I looked at exactly this feature a lot lately. An awful lot. > Apples and oranges are alike because they are both fruit, claiming that So, what you're saying here, is that you compare apples and oranges to draw your conclusions? > > Assuming the administrator still has enough access to activate the > > sharing, the NetSec dept. has a bigger problem than WebEx being > > installed. There is NO way to connect to a box with WebEx' client > > installed. The client connects outbound. > > If you can't automate an outbound connection... If you can automate an outbound connection, you do not need WebEx. I can use a web browser for this kind of exploit, a mail program, an IRC client, a telnet client, a ftp client, yada yada. At that point, you just declared *everything* on a computer a severe security risk. What is to stop me from automating MSIE to connect to Port 80 on my malicious server, download payload and execute payload, e.g. a program to project dektop data hidden in seemingly legitimate HTTP requests and receiving commands via HTTP responses? It's easy. To decry WebEx as any kind of security threat, just because it can be used like any other software out there, is irrational. > Absolutely- there's no way I'd allow a tunnel like SSH inbound- it'd be > silly to complain about tunnels if I simply allowed them. You just told me, you allow VNC over SSH inbound. > Absolutely- I guess you're aware that not everyone runs packet filtering > only firewalls in "let it all through" mode? A firewall is, first and foremost, a concept. It's a divider between two networks, which is one of the reasons the name "Personal Firewall" for those "Packet-Filter-IDS-Application-Blocker"-Monsters is a misnomer. How I run firewalls is a question of network design, and hopefully no two setups are alike. To assume anything, from "packet filtering only firewalls in "let it all through" mode" to full fledged layers of pyaload inspection, promotes insecurity. So does misnoming and confusing servers with clients (hint: man bind(2)) -- Jonas M Luster -- d-fensive networks, Inc. -- http://www.d-fensive.com _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
