Quoting Paul D. Robertson ([EMAIL PROTECTED]): > "Could," but that's not what's implied by their literature: > > http://www.webex.com/home/services_oncall.html?Track=hometext > > "WebEx OnCall agents can instantly engage customers in on-line interactive > support sessions live over the Web without the need to pre-install or > pre-configure any software. "
You might very well be the first person in the security field to even read marketing blarb. I prefer the lab method, saves me some headaches and contact to sales personnel and websites I can not read with lynx. > Futher on down the same page: > > "Netscape Communicator 4.x or Microsoft Internet Explorer 4.x, JavaScript and > cookies enabled" > > If they're opening sockets and not tunneling over HTTP using Netscape and > Javascript (note: not Java- Javascript) then they've got some pretty > darned impressive programmers. You must have never looked at the tool, have you? There's no other way, I could explain your misconceptions. These requirements are used to establish a connection to a website, enter credentials (such as username, password, meeting code, meeting password, etc.) and then to download the actual WebEx client, a Java or ActiveX program, dependin on your choice of OS and Browser. The only place I could find Javascrip was during the first few seconds, when a small Javascript fragment is used to generate a random number and insert in via document.write() to trick a few braindead proxies into accepting this page as a new page (one cannot rely on pragma nocache anymore, blame Microsoft). Javascript is also used to deliver the webiste components, such as rollovers and popups, but that's about it. I understand now, that you based your analysis on marketing material and sales-typical misconceptions. This is, well, unique, and neither very scientifical nor accurate. > > 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. > > Certainly he does- however unlike Sub7 who's ~350 variants can be > automatically be put into the malcode category, suddenly firewalls are Sub7 calls bind(). This is what makes Sub7 dangerous. Sub7 establishes a presence on the host system by calling bind() and listening for incoming connections. You still seem to confuse bind()/listen() and connect(). > supposed to automatically know which support connections are "good" and > which are "bad." Such trends reduce the protective value of the > firewall's protection model significantly- and with cooperative > engineering need not do so. Incoming vs. outgoing connection, Sir. You compare a passive system (Sub7) with an active system (WebEx). Once installed, the former establishes a presence, the latter does not. > > 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? > > There are plenty of record/playback features which can be automated and > scheduled. I do not need to use WebEx for this kind of approach. In fact, WebEx would be my least likely choice, I'd use hundreds if not thousands of other approaches if I had enough access to a system to install a record/playback tool. To use WebEx in the manner you imply, and I repeat myself here, the most likely approach would be to: | ---[ none of these steaps can be performed but by a local user ]--- | | a) As a legitimate user of the system to be compromised, download the | WebEx client bits and pieces. | b) Still, as a legitimate user, I have to tweak my local Java or | ActiveX vm to send WIN_GETEVENT() notices outside of its sandbox. | Quite an undertaking with Java, and pretty impossible with ActiveX | in its current incarnations. | c) Still, as a legitimate user, I have to install a scheduler and a | recorder/playback program. | | ---[ none of these steaps can be performed but by a local user ]--- | | Now, from here on out, I am speculating on a few points: | | The organization involved does not exercise due dilligence procedures, | does not ensure a clear segregation of duties and keeps actually | problematic information on said dektop. It is also assumed that the | user in question is able to leave his desktop running unattended, in a | unsecured network segment and does not chose any of the easier methods | to bug his computer. Also, Port80 outbound is not filtered and does | not witness inspection by any kind of proxy/payload checker. | | d) The user waits at home until the scheduled hour. Now he has to | obtain a phony company name, pay WebEx the amount of money they | require before allowing him to use WebEx, and create a meeting. | | e) The "infected" PC executes its damage routines, plays back the | recorded message, somehow mysteriously knowing the meeting number | which has been assigned to the meeting in question, and connects. | | f) A sophisticated desktop scanner finds the buttons to press and | allows the attacker to remote control the desktop. Sounds pretty far fetched? Yes, it does, because it is. I am not sure how you drew your conclusions, but basically I cannot find a way to reach the same ones you did. > > So, what you're saying here, is that you compare apples and oranges to > > draw your conclusions? > > What I'm saying is that when one talks about fruit, the difference between > an apple and and orange isn't as significant as the difference between an > apple and a rock. Security is about precision, informed decisions, clear definitions and a strong exercise of required research. > To ignore tunnels because they're easy to make is silly. To promote Whay are you constantly ranting about tunnels? I was under the impression we are taling about a protocol. Not an embedded envelope or any other feature someone would call a "Tunnel". If I am installing an FTP server on my system and perform a bind(int s, const struct sockaddr *addr, socklen_t addrlen) at port 80, is that a "Tunnel"? No, it is not! I consider this discussion to be futile and generally off-topic here, please move this off-list and mail me directly, thanks. jonas -- Jonas M Luster -- d-fensive networks, Inc. -- http://www.d-fensive.com _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
