Ray Zadjmool explores a solution to the number of false positives specifically created by the use of Windows Media Player
One of the biggest problems in managing security for your organization is the ability to properly identify false positives. Often, the excitement of a new security or intrusion detection device gives way to the realization that the logs are too informative. All too quickly, what is supposed to be valuable data becomes irrelevant and diminishes the value of logging.
As more and more online applications find their way into mainstream corporate culture, it is very important that security engineers understand how they work, so they can properly identify the characteristics while combing through their intrusion detection log files in search of attack signatures.
Versatility, but at a price
From a security standpoint, one of the most misunderstood applications is the popular streaming application client from Microsoft - Windows Media Player. One of the principal uses of Windows Media Player is the viewing of streaming WMV or ASF audio and video files through the use of the MMS protocol.
Exclusive to Windows Media Server, MMS has become one of the de facto streaming protocols used on the internet today. Its popularity is due, in part, to its versatility in being able to deliver quality streams regardless of the network configuration. It is this versatility that places it at odds with security solutions, such as firewalls and intrusion detection systems (IDS).
In order to understand why Windows Media Player is directly responsible for a lot of false positives on firewalls and IDS, it is important to understand the rationale behind the MMS protocol and streaming.
Meeting the challenge
The biggest challenge in delivering quality media streams is the requirement to deliver network packets in the correct sequence. While this is not a new concept in data networking, the sheer number of packets required to send quality streams makes timing and overhead very important.
Traditionally in TCP/IP communications, error correction is done at the fourth layer on the OSI model-TCP. If a packet is missing or out of sequence, information in the TCP header is used to request a 'resend' from the sender. This is why TCP is known as a connection-based protocol. Some overhead is associated with this error checking capability, both in network traffic and packet size. It is this overhead that makes TCP a reliable protocol.
User datagram protocol (UDP), on the other hand, is considered a connection-less protocol. It has no error checking capabilities and, therefore, cannot respond to missed or out-of-sequence packets in the same way that TCP can. Consequently, it is a much lighter protocol, both in terms of the network traffic it produces and in the relative size of the packets. It is for this reason that routers put a priority on UDP packets over other types of packets, such as TCP.
Intelligent routers understand that UDP packets are smaller than their counterpart TCP packets and will not have any of those pesky resends normally associated with TCP. This is why UDP is the preferred method of video streaming on the internet. Given this, if they wanted to use UDP, the developers of Windows Media Player/Server had to come up with another method to provide the error correction that is so critical in internet streaming.
They decided instead to focus the error correction functions of packet transmission onto layer 7 of the OSI model - the application layer. They built these capabilities directly into the client server application of Windows Media Services. This is where we get to the problems of firewalls and enterprise clients using Windows Media Player.
When a Windows Media Player requests a stream file through the MMS protocol, a series of events happen sequentially to determine the best method of delivery by the Windows Media Server. First, the connection request is made by the client, on TCP port 1755, to the Windows Media Server that is referenced by a URL or an .ASX pointer file. This client connection is important because it establishes a TCP session that can usually be made through most corporate firewalls.
Microsoft defines the function of this initial connection as passing 'command and control' packets to the media server. With the initial 'command and control' connection in place, the media server then proceeds to determine the best delivery method for the stream. The default settings on Windows Media Player is to request streams in the following order - UDP, TCP, and if all else fails, HTTP.
Any port in a storm
This process is iterative and follows some interesting logic. First, the client creates a UDP listening socket. This port number is randomly assigned and lies between 1024 and 5000. Secondly, the client establishes a UDP port connection on 1755 to the server for the purpose of requesting UDP resends. With the connections ready to go, it is now the server's turn to start sending UDP packets.
At this point, the Windows Media Server must determine the availability of the UDP listening port that the client has established. It accomplishes this by initiating a series of UDP scans on the client's internet IP. If it is unable to find the UDP listening port that client has created, the server then resorts to TCP unless the client has specifically asked for HTTP streams. But, if the server does find the client's selected UDP listening port, the server starts sending UDP packets indiscriminately to the client's media player.
During a UDP MMS streaming session, the client's media player must keep track of the packet sequence at the application layer. If a packet is deemed corrupt or missing, Windows Media Player must then send a request via UDP port 1755 to the streaming server for the missing packet. The server must be able to resend the packet successfully within the client's buffer time or the packet is lost forever and the stream skips a beat.
Now you know how the Windows Media Player works, you should understand the security implications of your users running the application in your corporate environment.
Any security administrator can tell you that the primary purpose of a corporate firewall is to prevent outside access into a network by blocking external ports and providing logging information regarding access attempts. Given this, the behavior of Windows Media Player/Server introduces some great security concerns.
First and foremost, the UDP scanning behavior of Windows Media Server is disruptive to say the least. Most security administrators spend a lot of time investigating what seems to be a malicious computer scanning your network for open UDP ports. The real danger is when the discovery is made that the alerts originating from their firewall or intrusion detection system are really false positives. This usually compels security administrators to do two things: disable the alerting options for range scanning on UDP, and/or open up the entire range of UDP 1024-5000 inbound in an effort to accommodate Windows Media Player.
While the thought of opening up a range of more than 3,000 ports and disabling the alerting for UDP scans might seem appalling, most engineers end up doing it anyway as they feel that they are forced into this option by the fact that if they don't, they will have to sacrifice the reliability of their firewall logs and alerting mechanisms, which become quickly inundated with false positives surrounding Windows Media Player.
Using this rationale, it is a pretty good assumption that a determined hacker can, and will, use this behavior pattern to focus attacks and probes around UDP ports 1024-5000 without any fear of detection.
For instance, a Trojan that gets executed on a client workstation could establish a listening port on UDP 1024-5000 in relative safety from intrusion detection systems.
Detailed below is a suggested way of overcoming the security risk.
Ray Zadjmool is president of Tevora Business Solutions (www.tevora.com)
How to mitigate the risk
How can you combat this potentially huge security flaw without compromising your users' ability to view streams?
One surefire method is to disable the use of UDP in Windows Media Player and restrict the player to using TCP or HTTP. With UDP disabled, Windows Media Server skips its UDP scan and does not attempt a UDP transmission.
Using TCP would only require that you open inbound port TCP 1755. With routers becoming faster and faster, the performance hit has become negligible, with most users and networks seeing no difference whatsoever between UDP and TCP.
You can disable the use of UDP in Windows Media Player 7 and 9 by going to Tools/Options/ Network Tab. In Windows Media Player 6 go to View/Options/ Advanced/Change streaming media options (Figure 1).
Here you can also disable the use of TCP and UDP, and allow only for streams across HTTP. This does not require any inbound ports to be open on a firewall, but it should be noted that it may cause some potential disruptions to your users as Windows Media Server, by default, does not support HTTP streaming. Server administrators have to manually configure their servers to stream via HTTP.
Given the sheer number of Windows Media Servers that serve video and audio content on the internet, it is likely that this has been overlooked by many administrators. If they have not taken the extra effort to enable for HTTP streaming, your users will not be able to view content if they are only configured for HTTP.
In corporate environments that use Active Directory, a template can be used to configure the users' Windows Media Player settings through group policy.
The wmpaert.adm template is installed automatically with Windows 2000, but must be loaded manually in group policy.
To load the template, inside group policy go to User Configuration, and right click on the administrative templates console. Choose Add/Remove Templates and add wmplayer.adm found in c:\winnt\inf (Figure 2).
Once added, the protocol limitation for Windows Media Player can then be configured on the Windows Media Player/ Networking console (Figure 3).