On Thu, 18 Mar 1999 21:02:20 -0500, "Larry Cannell" <[EMAIL PROTECTED]> said:
Larry> That means there are live people at each end of
Larry> the line. A user has to take two very distinct steps (in
Larry> _every_ conference) to enable remote control of an
Larry> application. They first must share the app, then
Larry> collaborate. This allows others in the conference to take
Larry> control of the window by double-clicking. The owner of the
Larry> window revoke control by hitting escape.
NetMeeting can be click-n-point configured to autoanswer an incoming
"call", whether you're there or not, so this bypasses human
intervention. I once configged a system at work to do this so I could
go home, "call" it up, and watch who was wandering through my office.
No human intervention required.
Since it's trivial and very quick to insert hostile COM
objects in a shared app, it can be done before the remote users
recognizes what's happened. Further, I don't expect users to actually
sit and stare with rapt attention to every vulnerable pixel -- any
more than folks do at flesh-time meetings, so the MS hit ESCAPE and
you'll be safe doesn't give me much comfort.
Larry> A
Larry> NetMeeting user has to go out of their way in _every
Larry> conference_ to allow this risk to occur.
Not true, due to autoanswer and also due to auto running based on
config files. A while back one of the security lists posted an exploit
where NetMeeting config files (.cnf suffix?) installed as links on
web pages would start the unsuspecting victim's application with all
the config parameters set to the attackers chosen values ("Click here
for free money!"). I imagine the same could be done with email
attachments and such-like.
Larry> 2. There is no way to authenticate other participants in a
Larry> NetMeeting conference.
Larry> True, the programs involved do not authenticate themselves. One
Larry> exception is a conference server. Participants must know the
Larry> conference password to enter. This is established by the
Larry> conference organizer and distributed prior to the meeting.
BFD. Cleartext subject to sniffing or brute-force attacks. Further, I
don't believe the ones I examined did user auth, but rather made the
assumption MS does which is that each machine has one unique user for
all time. Maybe that's changed, but reusable cleartext passwords suck
and they've sucked for a long time. For something that gives remote
hostiles such unprecedented control, I would expect something more
serious in the way of user auth.
Larry> Also, in a business environment a telephone call is involved in
Larry> the conference (I suppose NetMeeting audio could be used, but
Larry> we don't). How do you authenticate your telephone conference
Larry> calls?
Someone calling me on the phone can't delete everything on my hard
drive and send a forged tax form to the IRS. NetMeeting can.
Larry> If you were really worried that someone else had joined
Larry> your conference couldn't you look at the NetMeeting call
Larry> roster?
You can't believe the information there since there's no strong auth.
Larry> NetMeetings involving audio are inherently
Larry> self-authenticating. It's just not done programmatically.
Huh?
Larry> 3. An application proxy is the only way to protect a NetMeeting
Larry> user.
Larry> Well, unfortunately, no T.120 proxies exist on the market
Larry> today. Actually, months ago, I saw references about PictureTel
Larry> and DataBeam developing T.120 proxies but have yet to see a
Larry> product on the market. Checkout this old article in PC Week:
Larry> http://www.zdnet.com/pcweek/reviews/0630/30collab.html. It
Larry> talks about a T.120 proxy disabling certain features in a
Larry> conference (such as application collaboration).
Undoubtedly because these many-fine-lunches protocols are absurdly
complex and therefore very difficult to implement -- or implement in a
way that's secure code-wise, and in a way that improves the security
of the application. IMHO you shouldn't have to buy a proxy to secure
your app -- the app should be fixed.
Larry> However, there are also others ways to protect a NetMeeting
Larry> user. Firewalls and transparent proxy servers (ie. SOCKS or
Larry> MS-Proxy) can restrict where NetMeeting calls can be
Larry> placed.
Firewalls and proxy servers which simply move packets from here to
there with no inspection of the stuff going on aren't going to improve
the situation -- they won't filter hostile traffic.
Larry> - All external T.120 conferences require a conference server,
Larry> no point-to-point connections allowed. This gives us a single,
Larry> manageable point of contact for the conference. - Only a
Larry> limited number of conference servers are allowed connections
Larry> (someone has to approve the connection) - Any conferences
Larry> involving confidential data (current product plans, for
Larry> example) must be hosted on a "secured" server. We will
Larry> configure our firewalls to only allow connections to these from
Larry> private network paths (ANX, private point-to-point lines, etc.)
Larry> but no secured conferences are allowed over the Internet. - We
Larry> are not allowing connections to any external ILS servers.
Since the conference server doesn't do any serious auth, and doesn't
block hostile traffic (it can't tell what's friendly or hostile) bad
guys can simply connect to it and affect your interior workstations.
This just exploits the trust you've given to the conf server.
It's a good approach but the app itself doesn't protect the client
workstation. We proposed setting up a "victim net" outside the
firewall where folks could use NetMeeting; this net would have *no*
access to internal resources such as fileservers, etc; users objected
to this, natch. A colleague recently suggested putting a NetMeeting
box outside the firewall and using something like Citrix app server to
push the graphics back to client workstations; that way when the
external box got compromised the internal users would remain safe.
Larry> I sincerely believe that data conferencing is an
Larry> incredibly powerful tool. It works with existing equipment and
Larry> runs on existing networks. Enabling this to work between a
Larry> manufacturer and supplier offers enormous cost saving
Larry> opportunities. NetMeeting has been very popular where I work
Larry> and I suspect you firewall admins will be asked to accommodate
Larry> these conferences soon (if you haven�t already).
Conferencing SW can definitely be useful, no argument there. It's just
that MS' implementation is absurdly naive and insecure, and can't be
secured by bolting on external conference servers, etc, etc. It's a
bad product and I hope other vendors develop better, more secure ones.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
