NetMeeting Security Concerns and Deployment Issues

Be afraid, be very afraid. Abstract
NetMeeting is a product which allows point-to-point audio/video conferencing and multi-point file transfer, chat, whiteboard, and application-sharing over the Internet. It claims to follow various industry standards to ensure interoperability with other products but may not be as compliant as desired. Unfortunately, the complexity of some of these standards makes proxying the application's network traffic through a firewall very difficult. Further, the application sharing feature allows remote access to the shared user's desktop, allowing arbitrary functions to be run such as file writing, deleting, launching other applications, downloading cracker tools, etc. This product gives excessive control to remote connections making the user's desktop machine and network resources highly vulnerable. Deployment may require severely restricting the capabilities of the product in order to use it safely, possibly making it useless for the collaboration purposes it was intended.

Overview and Architecture

Participants use NetMeeting to connect to a machine which "hosts" a conference; I'll refer to this the "shared" host or system or the "sharing user", and the others as "remote" or "client" systems and users. Various topologies can be used including star or tree, and network traffic follows the conference topology. This implies that in a tree-like topology, if a host connecting two clients crashes or leaves the conference, the clients' connection will also be severed.

A directory called Internet Locator Server (ILS) can be used to find other users and facilitate rendezvous. ILS implements the Lightweight Directory Access Protocol (LDAP) but has extensions which render it incompatible with other LDAPv2 or LDAPv3 software, such as that used by NASA or directories other vendors might offer.

Once established, participants can use point-to-point audio and video to communicate; note that they cannot use this to communicate with more than one person at a time. The system uses H.323 protocols to establish the connection and various other H.323 standards for audio/video format and bandwidth negotiation. This seems to work fairly well over LAN, WAN, and even dialup networks. The H.323 protocol is very complex, however, and this makes safe proxy transmission through firewalls difficult.

Various data-conferencing facilities are also available including directory lookups, file transfer, chat, whiteboard, and application sharing. These are multipoint so you can share data with more than one person at a time. It uses the T.120 standard and runs on statically-assigned TCP ports which are easy to configure a firewall to permit. Unfortunately, application sharing in "collaborate" mode allows others full access to all the power of the applications you share, including file save and remove, macros, etc, posing a serious risk to the shared machine and network on which it resides.

Third party gateways exist which may help improve reliability, robustness, scalability, and security. An architecture employing such a product is discussed near the end of this paper.

Standards: H.323, T.120, LDAP (mostly)

Microsoft has recently made changes which indicate it may be ready to embrace various industry networking standards in their products; from the NetMeeting Resource Kit:
NetMeeting is based on standards from the ITU.... In contrast, some Internet products are proprietary and leave their users stranded, able to talk only to people with the same product.
and
the time for proprietary products has passed, and the time to build standards-based, 100% interoperable, multimedia communication and conferencing products is here. As the marketplace rallies around standards, Microsoft takes a leadership role in developing standards-based products...

NetMeeting bases its services on various standards from the International Telecommunications Union (ITU) and Internet Engineering Task Force (IETF). The International Multimedia Teleconferencing Consortium (IMTC) promotes interoperability and is a good resource for ITU specifications (the ITU still charges for access to their documents!). ITU T.120 is used for data conferencing, ITU H.323 is used for audio/video conferencing, with IETF Real Time Protocol (RTP) packet format. IETF Lightweight Directory Access Protocol (LDAP) is used for the ILS directory.

The T.120 standard covers document conferencing (data sharing) and provides protocols for establishing and managing data flow, connections, and conferences; other standards in the suite cover specific facilities of data conferencing. T.126 specifies multipoint still image and annotation for whiteboard applications. T.127 covers multipoint binary file transfers. The Resource Kit speaks of a T.128 standard for application sharing, but this isn't listed on the IMTC list; they do show a T.Share which sounds similar but it is a draft, not an ITU ratified standard (as of October 1996, the date of IMTC's list). The ITU site indicates it has a T.128 Multipoint Application sharing recommendation but of course you can't read it unless you're a member; it's dated 1997-12-09. Lack of a ratified standard for application sharing may make it impossible to interoperate with other T.120 products.

H.323 includes call setup and management as well as codecs for different grades of audio (G.711, G.723) and video (H.261, H.236). This uses the packet format specified by IETF RTP and RTCP for framing, sequencing, and error detection for audio/video streams.

IETF LDAP provides access to directory services, in this case Microsoft's ILS. The current LDAP standard (Version 2) is primarily targeted for static information such as Internet White Pages. ILS implements a notion of dynamic information which has an expiration and refresh lifetime. They are documented in the IETF Drafts; the most appropriate document for this discussion is draft-ietf-asid-ldapv3-dynamic-07.txt from December 1997 by Microsoft and Critical Angle. Until this becomes an official IETF standard and is widely adopted by other vendors, as the Resource Kit says:

no other compatible servers are currently available for NetMeeting.

Microsoft's lack of full compliance to existing standards and proprietary extensions to established standards will complicate interoperability with other products including conference gateways, proxies, firewalls, etc. This may in part be due to the evolution of standards (e.g.: LDAPv2 to LDAPv3, T.Share versus T.128), or perhaps it's similar to the TV mini-series tag-lines: "Based on a story by ...", bearing only passing similarity to real standards. This remains to be seen and will most likely play out with (in)compatible products from third-parties.

Network Security: Firewall Very Difficult

The H.323 call setup protocol (1720/TCP) dynamically negotiates a TCP port used by H.323 call control protocol. Also, both the audio call control protocol (1731/TCP) and H.323 call setup protocol (1720/TCP) dynamically negotiate UDP ports for use by H.323 streaming protocol (RTP). The Resource Kit example shows the MS Proxy Server configured to allow outbound connections on all UDP ports 0-65535, and allow inbound/outbound reply packets ("subsequent connections", elsewhere these are called "secondary" connections) to all UDP ports. This makes for a very unsecure firewall configuration -- unless MS-Proxy is smart enough to decode the H.323 dynamic port negotiation and only allow UDP traffic on ports selected by the peers and between those peers only; according to MicroSoft's NetMeeting lead technical folks, it is not.

Network Ports used by NetMeeting
Port TCP/UDP Static/Dynamic Standard Protocol Submitted by NetMeeting Use
389 TCP static LDAP UMich Internet Locator Server (ILS)
522 TCP static ULP Microsoft User Location Service (deprecated, use ILS)
1503 TCP static imtc-mcs DataBeam T.120
1720 TCP static h323hostcall Intel H.323 call setup
1731 TCP static msiccp Microsoft Audio call control
1024-65535 TCP dynamic H.245 H.323 call control
1024-65535 UDP dynamic RTP/RTCP H.323 streaming (RTP)

Engineer Brien Wheeler from firewall vendor Raptor has written two very good explanations about the H.323 protocol complexity and difficulty implementing firewalls; both are from comp.security.firewalls, one from December 1977 and the other from January 1998. Basically he states that packet filters will not work and that writing an application proxy is very difficult because of the way dynamic ports are negotiated and the ASN.1 protocol encoding.

Microsoft's Proxy firewall doesn't actually understand the H.323 protocol so it can't dynamically open and close dynamic ports between pairs of NetMeeting users. Confidence isn't reinforced by information from the Resource Kit:

Important: Because of current limitations in most firewall technology, few products are available that allow you to securely transport inbound and outbound NetMeeting calls that contain audio, video, and data across a firewall. You should consider carefully the relative security risks of enabling different parts of NetMeeting call in your firewall product. Especially, you should consider very carefully the security risks involved when modifying your firewall configuration to enable any component of an in-bound NetMeeting call.

Microsoft points out and Checkpoint's web site confirms that Firewall-1 has some support for NetMeeting, but it's mostly marketing hype. What it doesn't say is whether it's any more careful than the MS-Proxy scenario described above. Checkpoint's online documentation unhelpfully suggests "Add TCP port 1503 in GUI." This would only open up the T.120 port, not H.323 control or the dynamic ports, nor LDAP.

I've created a simple ruleset to see what Firewall-1 does when you ask it to accommodate NetMeeting. The first rule allows "H.323" (1720/TCP), "NetMeeting" (1503/TCP, T.120), and "NetMeeting-DirSrv" (522/TCP, deprecated ULS directory); all these are being allowed from any source to my laptop. The second rule simply denies all other unmatched packets. The compiled policy script doesn't look like it's doing anything besides allowing some static ports -- there's certainly nothing in it about parsing H.323 to find the dynamically negotiated TCP and UDP ports.

Application Security: Too Much Remote Control

Collaboration considered harmful

The T.120 data conferencing systems appear easy to accommodate with firewall packet filters but major features of this put the sharing workstation and all its resources -- including its LAN -- in serious jeopardy.

The standard ITU T.120 services appear to not pose much risk to the sharing or client systems. The chat and whiteboard allow exchange of information but no change can be made by a remote user to a shared system or other remote user. The file transfer facility will of course change the destination host(s) but it appears the risk is low since received files are kept in ProgramFiles\NetMeetingNT\ReceivedFiles directory; if senders could target the file to some other directory they could overwrite critical system files. This is the danger posed by the collaboration feature.

One of the more interesting features of NetMeeting is the ability to "share" an application; this is implemented using the T.Share/T.128 pseudo-standard. In this mode, the sharing system offers one or more desktop applications and this application is displayed on the remote client screens; a strictly "shared" application is read-only, that is clients can't run the application remotely. Shared applications can also be made available for "collaborating". In this mode, remote users can take control of the application with all their actions being shown to other participants. Participants can take control on the fly, their keyboard and mouse becomes the controlling input to the shared applications. The risk here is that any remote user has access to full power offered by the application. If the program can write to disk (e.g.: Word, NetScape) then the remote user can save a file to disk, possibly over-writing critical system files like explorer.exe. Other scenarios include hostile macros (like existing mail-borne macro viruses), downloading and executing destructive ActiveX or other applications with a web browser, inserting COMMAND.COM into Word to get a command prompt, downloading network sniffers to harvest passwords, etc, etc. This gives remote users access to an unprecedented destructive power on the shared system, power which only increases as Microsoft ties applications to each other and integrates OLE objects into everything.

Microsoft says be vigilant

Microsoft's suggestion to this threat is to be vigilant and monitor what remote clients are doing to your shared machine: you can hit ESCAPE to regain control but this may be too late.

From a Word document shared with "collaboration" enabled, we were remotely able to get a command prompt and delete files from the sharing system in about 10 seconds -- probably not enough time for the sharing user to notice and hit ESCAPE. This was on an NT system; similar attacks are applicable to 95.

They also say that NetMeeting was designed with the idea that you'd collaborate with trusted colleagues. This is a cop-out: even friends can accidentally overwrite important files. It also ignores the fact that these days crackers can splice packets, hijack sessions, spoof addresses, etc, thereby gaining access to a session you trust. Notice also that NetMeeting has no idea of a "user" -- you call a machine, not a username@machine; the omission of any kind of authentication seems an obvious oversight and indicates a lack of designed-in security. Another sign is the total lack of NetMeeting security information in Microsoft's online database, evidenced from a recent search:

Your search for netmeeting security found the following
articles:

  1.  What's New in Internet Explorer 4.0? 
      Excerpt from this page: The latest Microsoft product technical
      support information. (size 7,352 bytes, updated 1/19/98 3:31:53
      PM GMT)

It's possible that the massive security threat posed by this is the way the T.120 application sharing protocol is defined, but we can't tell yet what this definition is: Microsoft claims a T.128 standard, but the nearest thing the IMTC documents is T.Share. The implementation of the T.120 protocol and applications seems safe enough, but it appears the T.Share/T.128 protocol is designed to offer this power to remote networked users. The T.120 chat and whiteboard, for example, are immune from these problems. The difference is that they don't give remote users virtual access to the keyboard and mouse of the shared machine, so they can't do any harm. Microsoft needs to rework the shared application model so collaboration does not endanger the shared machine.

It's ironic that when an application is shared, only the sharing user can save the document that has been collaboratively developed to his/her disk -- the remote clients cannot save a copy to their own disks for later use. Instead, Microsoft recommends the sharing user mail the document to the participants. Due to the vulnerabilities in collaboration, all the remote users would have to do is invoke the sharing machine's mailer from the application they're sharing and mail a copy of the document to themselves. Of course they could mail any other file, too, perhaps the sharing user's .pwl password file.

Microsoft says to use system policies

System policies can be set which disable some of the dangerous features of NetMeeting. Microsoft provides a policy template file conf.adm which you can work on using poledit.exe. Restrictions can be made on a variety of features including: file transfer, application sharing, setting options, answering calls, using audio or video, accessing directory services, and changing user information. The sharing option has sub-options you can select, the most important is the ability to disable "collaboration".

Implementing policies not helpful

Colleagues at other Centers indicate most NASA sites implement system policies as part of the Windows domain login process. They suggest that disabling dangerous features would best be part of this established procedure. This does sound workable but is inadequate to actually protect users from themselves -- that is, to actually enforce a security policy. Users who are determined to shoot themselves in the foot could turn on their machines without logging in to the domain and bypass the policy installation. This would allow their machines to be victimized, possibly putting the other users on the Center network at risk. This seems likely to keep the honest users honest, but "clever" users will not be deterred. This illusion of security may provide less safety than no security at all. You cannot base the security of your enterprise network upon voluntary compliance to policy -- it must be enforced with non-defeatable means.

Alternate Architectures

There may be ways of deploying NetMeeting which reduce the risk it poses to the user and the enterprise. These typically rely on other mechanisms to hide the NetMeeting users from attacks, typically by network-oriented approaches rather than trying to fix the inherent vulnerabilities of the application.

Virtual private networks

The term "Virtual Private Network" (VPN) has gotten a lot of press recently and is marketed as a panacea for all our networking ills; this is far from the truth. A VPN securely connects two or more disjoint networks over an intervening network. It might be used to connect different branch offices over the Internet, for example. The presumption is that the intervening network is hostile and by extension that the joining networks are secure.

If the networks in question are not secure, then the VPN only connects one unsecure network to another. If, for example, you use a VPN to connect a well-protected network to one with no protection whatsoever, you have just merged the unsecure net into the secure one, presenting all the vulnerabilities of the latter to the former. By opening the gate of the fortress to the surrounding fields, you assume all the risks to which the latter may fall prey. VPNs are useful only if you are connecting two secured networks (or at least two networks with the same security posture, even if it's poor). Otherwise it's the "weakest link in the chain" situation.

Some Centers have experimented with using commonly available VPN-type tools including Checkpoint's SecuRemote and MS PPTP. They concluded that the network security was improved but that the application was still inherently vulnerable. This is very similar to the DataBeam approach described below, and for the same reasons: it's an attempt to solve application problems with network-oriented solutions. Note also that these solutions are PC-only; while their recommendation noted that NetMeeting is also PC-only, it is hardly helpful for collaborating with the 40% of NASA people who do not use PCs.

The Checkpoint product comes with their Firewall-1 product and can be deployed on end-user workstations, PC only. The PPTP product yet another tunneling protocol, and of course runs only on PCs. There has been fairly heated debate on it recently, including an essay from NTbugtraq "Is PPTP Secure?". PPTP is slated for replacement by L2TP anyway so it seems short-sighted to base a security strategy on this product at this time.

Databeam neT.120

Companies such as DataBeam produce products which interoperate with H.323/T.120 products like NetMeeting. It may be possible to deploy a publicly reachable H.323/T.120 gateway which performs authentication, access control, and then passes this presumed-trusted traffic through the firewall via a hole dedicated to it. The DataBeam neT.120 Conference Server claims to be the only data collaboration product compatible with NetMeeting, presumably because it's the only one which implements the T.Share/T.128 protocol.

We set up an NT Server system with the Apache web server and the neT.120 product and watched the network traffic. Our experiments confirmed our suspicions: packets flowing between NetMeeting participants were indeed channeled through the DataBeam server, but application sharing still occurred on the client workstations (NetMeeting v2.1, neT.120 v2.5). The only benefit the server provides is a modicum of authentication and a choke-point for network traffic. We were still able to cause damage on participating machines with collaboration.

While the neT.120 propaganda extols the virtues of improved security, all authentication is done in the clear. Conference access passwords, administrator passwords, and secret conference names are all sent over the net using the standard HTTP -- easily intercepted. It's surprising that the product hype doesn't discuss using an SSL-protected web server; this would encrypt such sensitive information and also provide server authentication. Better still would be to use client browser certificates to authenticate users to the SSL-secured web server to ensure mutual authentication. The literature doesn't discuss whether this is possible; it may not be as the neT.120 server also runs its own HTTP (web) server and Java server on separate ports from the main web server.

Even with strong authentication, the participating users and their enterprises are still at risk because the NetMeeting application offers too much power to the remote users -- or whoever is on their machine. Without end-to-end security it's possible for crackers on the remote end to infiltrate a "friendly" network or machine and simply use the gateway as a bridge inside a firewall and attack protected machines as described earlier. The gateway simply requires the bad guys to first break into machines we allow to connect to our gateway -- just one more hop for the crackers.

This is inadequate. We need real security (cryptography) and we need to be able to have fine-grained, guaranteed control over the actions remote users can execute on shared machines. This needs to happen all they way up to the application layer -- it's not appropriate to blame a lack of network security for a poorly designed application.

Some have argued that if clients are strongly authenticated, and you trust your partners and their machines and their LANs then you shouldn't be at risk. But this assumes the application and its protocol are robust and bug-free. The SMB protocol Microsoft uses for file and print sharing on NT, for example, has design-flaws and bugs which have been exploited to gain access to these resources. Hackers didn't use the normal, well mannered, client software from MicroSoft -- they wrote their own tools (e.g., smbclient, netcat, L0phtCrack) which implemented the protocol and exploited its weaknesses. It's naive to think the same will not be done with something which affords as much access as NetMeeting. Some bugs have already been found in NetMeeting and details of the exploits publicly posted.

Deployment Recommendation

Deployment recommendations can really only be made with guidance from a site's security policy; the policy dictates how much risk you are willing to assume. A financial institution would probably be very risk averse and not tolerate anything which might pose a threat. It might be expected that the same is true for military sites, but recent attacks have shown otherwise. Other Federal agencies must establish their own policies but again, recent attacks indicate it might be prudent to be more conservative (see www.antionline.com among others)

These recommendations are based on my perception of NASA/HQ security posture (even as it evolves) as well as the dramatic increase in the frequency and sophistication of network attacks. Actual deployment will undoubtedly require further site-specific security review and consideration for the site's tolerance for pain versus the importance of "convenience".

Block H.323 audio/video

Unless a good H.323 application proxy can be found we cannot deploy NetMeeting's audio or video features: firewalls currently can't pass it securely due to its complexity.

Disable application collaboration

Due to the risk that collaborative sharing poses to the shared system and its network environment, we must disable "collaboration"; we can allow other data-conferencing facilities including chat, whiteboard, file sending, and read-only application sharing.

Unfortunately, it is unclear whether we can rely on Center-administered Windows policy enforcement -- it appears that determined users can get around centralized policy restrictions. If we can't rely on users disabling collaboration, how do we block this potentially hostile traffic? Block all T.120 traffic -- including the benign chat, whiteboard, and shared applications -- by blocking TCP port 1503 at the firewall.


Chris Shenton
Last modified: Sun Oct 4 15:00:53 1998