Skype has taken some fairly aggressive steps to ensure the privacy and integrity of phone calls made within its network. While the protocols it uses are proprietary, Skype commissioned an independent review of its encryption communication infrastructure in October 2005 (available at http://www.skype.net/security/) from Tom Berson. In the report, Berson verified the cryptographic techniques that would prevent eavesdropping and insertion attacks against anyone sniffing traffic in a network where Skype was being used.
Skype also contains anti-debugging measures to ward off reverse engineers poking around. However, at RECON (Reverse Engineering Conference) 2006 in Montreal (http://www.recon.cx), one of the presentations involved some in-depth Skype reverse-engineering and analysis by researchers at EADS. Among other things, the talk covered Skype's crypto scheme, some easter eggs, and general traffic analysis (http://www.recon.cx/en/f/vskype-part1.pdf; http://www.recon.cx/en/f/vskype-part2.pdf).
The researchers were able to circumvent some of the anti-debugging techniques and also discover a vulnerability in the Skype application itself. Just because an application uses proprietary protocols does not mean it is immune to vulnerabilities. At the time of publication of this book, six security vulnerabilities in Skype (http://www.skype.com/security/ bulletins .html ) had been discovered that have been consequently patched. Most of these issues have been discovered by independent security researchers employing fuzzing techniques to certain parts of the protocol that are better known ( callto:// and so on). See Chapter 11 for more information on fuzzing.
Much like its P2P file-sharing predecessor KaZaA, Skype is fairly robust in its ability to thrive in most any network environment. This, however, can create a headache for network administrators who want to prevent or limit the amount of bandwidth that Skype consumes in their network. In a university environment, for example, administrators might notice that Skype and other P2P applications take up 70 percent of the bandwidth, indirectly starving some other critical bandwidth- intensive programs. As you learned in Chapter 4, there are a variety of rate-shaping and quality of service technologies that aim to help tame the bandwidth utilization in your organization.
However, because of the amount of encryption and network obfuscation used, Skype traffic is fairly difficult for network devices to detect or even block for that matter. There are a few solutions from traditional firewall and rate-shaping vendors that purport to detect the latest versions of Skype. SonicWall and Checkpoint have both added features to their firewall set that supposedly allow Skype filtering. Traditional rate-shaping solutions such as Packeteer also claim Skype detection and throttling support, as do many intrusion prevention vendors . Akonix also markets a device called L7 Skype Manager, which purports to be able to log and enforce Skype usage in the network. All of these product claims, however, are following a moving target, as each new major version of Skype tends to increase the amount of payload obfuscation in order to evade these types of technologies.
The only sure-fire way to block Skype from an enterprise perspective is to prevent its installation from a host-based policy enforcement approach. There is even a freeware tool called SkypeKiller, shown in Figure 10-2, that will allow an administrator to uninstall Skype from various computers within a given domain.