On Thu, 3 Jan 2002, Jonas M Luster wrote: > 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.
When you're evaluating solutions, you don't have time to bring every product into a Lab, so you start with the vendor's assertions. But in any case, even if it's a layer 2 transport layer vector- it still burrows out- and you're completely missing the point that enterprise admins would like to have some security cooperation from vendors who's products do that. I doubt you've ever been in a signficantly sized enterprise if you keep missing this. BTW: You may want to try "Links," it's generally been functional on more sites than Lynx. Is the meeting client exactly the same as the support client? I'd hope not, but if it is, and the support client is an ActiveX control, then if solutions like this get significant traction, they'll be obvious places to compromise legitimately installed sofware with malcode. If there were out of band, or out of stream controls that could be applied at a gateway, that'd be much less of an issue. Remember again, the issue isn't that there is lots of bad software and vectors, it's that we shouldn't ignore the chance to make good software and better-trusted vectors. > 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. If you can't depend on the vendor to explain how their program works and what requirements it has correctly, then you can't necessarily depend on the vendor. That's especially important as remote support systems become used by an increasing number of support organizations. The reason that Web servers get attacked instead of SSL is because it's low-hanging fruit. The same will be true of 'Net based support tools. > > 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(). You really don't get it, do you? Sub7 being dangerous has *nothing* to do with having a socket in listen mode. That's the primary vector for intrusions into *home* networks. That doesn't generally work for behind the firewall *corporate* networks (or for that matter even the little switch/firewall or switch/NAT devices for broadband home networks.) That's why things like Sub7 have "tunnel out" IRC control vectors (as well as the fact that the attacker can relay through a 3rd party server- hmmm sound like something that might be familiar?.) Please stop thinking about socket calls and think about how _successful_ trojans allow control back into an enterprise- because it's not from unestablished TCP connections. About the only successful inbound control vector that works on a fair number of enterprises is DNS and/or UDP/53. > > 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. More succintly put, one's normal primary control vector is via an inbound connection, the other's is via an outbound connection. Because most people think "inside = trusted," that's usually supported as a "security feature" when in reality it isn't, especially in large enterprises where network level and user level trust aren't as good as they are on smaller networks. This leads to the fact that enterprise security administrators are more likely to support system control vectors which will have a chance of being integrated with their security control mechanisms. Other than blocking access to the WebEx site to discourage legitmate use (and therefore installation of the software)- and given that the security team isn't the host administrative team in any large company, perhaps you'd like to propose an alternative security control mechanism for the people who's job it is to control the perimeter? > 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. Of course you don't- the point once again is that legitimately useful tools should play well with a security infrastructure, not ignore it. > | ---[ 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 ]--- Right, and when that local user is no longer trusted (e.g. laid off) how does the corporate security staff undo these? Oh yeah, it's time to go scan 5,000 servers. Brilliantly scalable option- not. > | 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. You assume (a) the protocol is secure end-to-end (an unknown) and (b) that the intruder doesn't gain entry via a legitimate vendor. Let alone the fact that an ex-employee has a higher chance of successfully completing a social engineering attack that could get someone to initiate the connection. Once again, in case you missed it- the point isn't that there are a zillion ways to do this, it's that legitimate support tools should be security infrastructure friendly, not neutral or unfriendly. > | 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. One LMHOSTS entry, a protocol analyzer and some time and this isn't necessary any longer though. You're also assuming that the numbers aren't predictable- or that WebEx has some mechanism for alerting on guessable numbers and that the number isn't assertable on the other end. You're also assuming integrity of their Web site, which they (at least at this point) haven't provided any assurance for. > Security is about precision, informed decisions, clear definitions and > a strong exercise of required research. No, security is about cooperation, control and access. All the precision, definition and research in the world won't make SSH v1.5 nor FTP "good" because they lack basic design pieces that should have been better implemented for their environments. > > > 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 If you'd prefer, substitute "transport layer relayed control vector" for tunnel. I'm not as worried about semantics of the vector's name as I am about the vector. Just like your previous assumption that an inband controled Internet site had the same protection capabilities and stance as a switched telco network, router or firewall host, it's important to look at the potential vectors of compromise and try to produce control layers than provide protection for the ones that open exposure (such as filtering for BGP because it's an inband vector in most cases unless you provide a control network seperately from the date network for instance) before passing equivalance of trust judgements. > 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! If your FTP server was a control vector rather than a data vector, then for some set of tunneling through firewalls, it would be. No, it's not the application designer's fault that the bulk of the world has gone from application layer gateways to transport layer relaying, but the application designer can make things more perimeter defense friendly. > I consider this discussion to be futile and generally off-topic here, > please move this off-list and mail me directly, thanks. If you're still confused about binding sockets being the issue, then I'll assume others are and maybe this will clear things up. Feel free to continue off-list if this wasn't enough for you though. 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
