System iNetwork

December 2005

December 15, 2005 9:09 AM

Skype Considered Harmful

A previous Dr. I. Doctor blog item (VOMIT: Diagnostic Tool Lets Hackers Target VoIP) discussed Voice-over-IP, noting that Skype was one of the few public VoIP services that encrypts its traffic. This was a good feature, providing a necessary layer of protection for Skype users. Unfortunately, since then several discoveries about Skype have led many network administrators to bar it from their networks.

Skype has become an incredibly popular VoIP service, with more than 60 million subscribers today, according to the technology's new owner, eBay. The main reason for this popularity is low cost -- zero, actually, for all computer-to-computer calls. Skype also delivers reasonably good sound quality and reliability. However, despite its freely available software client and wide ranging open network, Skype uses proprietary protocols and infrastructure, a fact that many users overlooked until recently.

The rub comes in the way Skype's proprietary scheme exploits users' bandwidth to route calls for other, completely unrelated, users. Even when a user is "on hook" (e.g., not making a call), Skype can use that user's Internet connection to route calls to other users. The total bandwidth consumed can impact an enterprise network's Internet performance, despite no Skype services being provided to the network's users!

Worse, many network administrators may not even be aware of Skype users on their network. Skype is a peer-to-peer, port-agile protocol, which means it establishes connections directly between users, even when they're behind firewalls and even when the firewall tries to block VoIP services. Skype's port agility enables it to use virtually any open port to carry VoIP traffic, so it's not readily blocked by traditional network perimeter controls.

This raises the spectre of Skype becoming a back door into an otherwise secure network. Because Skype is proprietary, you have no way of knowing what it's doing under the covers. Skype has had several serious bugs that opened the protocol to exploit by hackers, so such a back door could appear even without malicious intent on Skype's part. But now that Skype is owned by a big outfit (eBay), and other big outfits of late have been caught with their hand in the user's pocket (e.g., Sony and its onerous DRM), depending on eBay for your network security seems ill advised.

So much potential for abuse exists that Gartner Group recommended earlier this year that companies avoid using Skype, as well as other proprietary VoIP services. Gartner points out that an open VoIP standard, Session Initiation Protocol (SIP), already exists and is well accepted. While not perfect, that standard is open to inspection and vulnerabilities are theoretically more quickly discovered and corrected. That prediciton seems to be borne out as SIP usage expands, especially with the growth of Asterisk, a SIP-based, open-source phone system.

With Skype being so slippery in the network, the question becomes how one controls it. Skype can pass through most network firewalls without difficulty once one inside user installs and runs the Skype client, whether authorized or not.

One method is to use an application-layer firewall that employs deep packet inspection to detect Skype traffic based on content. Today only commercial packet-shaping products readily offer that capability, and they can be expensive. The primary open-source contender, L7-Filter for Linux (http://l7-filter.sourceforge.net/), is not a complete solution for Skype filtering. Such low-level filtering also imposes a significant burden on throughput, since every packet must be examined going in and out of the network. Cost rises directly with bandwidth.

A less sohpisticated, but much cheaper, method is to block all outbound ports except those that you pass through an Internet proxy server. The proxy server essentially breaks the VoIP traffic stream, rendering Skype and other peer-to-peer streaming protocols inoperative. You can purchase a commercial proxy, such as Microsoft's ISA Server, or deploy an open-source proxy like Squid (http://www.squid-cache.org/). A paper detailing the process, by the anonomous author vi_cipher, is online at http://www.net-security.org/dl/articles/Blocking_Skype.pdf.

Posted by mbeckman on December 15, 2005 at 9:09 AM

December 6, 2005 7:55 AM

New CERT Guide: Botnets as a Vehicle for Online Crime

If you've spent much time at all analyzing network traffic, you've run into an infamous plague swarming the Internet known as botnets -- the interconnected web of compromised PCs that virus writers use for intelligence gathering and distributed denial of service attacks. But unless you've actually disassembled botnet code, you likely don't have much information about how botnets work. The Computer Emergency Response Team (CERT) whitepaper Botnets as a Vehicle for Online Crime is a first-rate tutorial on the motivations and mechanics of botnets. It should be required reading for all network professionals.

The paper's authors, CERT staffers Nicholas Ianelli and Aaron Hackworth, start out by describing why botnets are such a big draw for hackers. The main reason is one you likely haven't considered: A botnet is essentially a very large, highly distributed, supercomputer. With a botnet, a hacker commands a vast computing resource that rivals those of even the largest government agencies (unless, of course, those agencies themselves are using botnets). Hackers use this computational powerhouse to crack passwords, distribute warez (stolen software), and attack other networks.

Next, the paper details how a hacker starts up a botnet. The valuable information here is that you can greatly reduce your vulnerability to botnets by ensuring that a few well-known, but readily countered exploits do not exist in your network: The Windows RPC, LSA, and DLL buffer overflow bugs. You can block the other common infiltration technique -- social engineering -- by educating your users about phishing and e-mail attachment dangers. The reason that botnets flourish is that the vast majority of Internet users and education and home broadband users fail to invoke these protections.

The authors then dive into a detailed description of various botnet mechanisms, including autorooting and exploit scanning, port redirection, registry mining, key logging, screen capturing, and IRC bouncing. The breadth and depth of botnet tools is sobering, and illustrates how serious the botnet problem has become. The technical discussion also shows how botnet command and control mechanisms work, giving you a fascinating hackers-eye view of botnet manipulation.

Put this on your professional development reading schedule immediately.

http://www.cert.org/archive/pdf/Botnets.pdf

Posted by mbeckman on December 6, 2005 at 7:55 AM

Another Reason to Disable the Cisco IOS HTTP Interface

Microsoft usually wins all awards for quantity and quality of network vulnerabilities, but don't be distracted. There are enough security holes for everyone, and it's easy to become complacent about seemingly innocuous devices like routers and switches. A case in point is a just-announced bug in Cisco IOS that affects all devices -- both routers and switches -- from version 11.0 through 12.4. The problem is with IOS' HTTP interface, a not very useful option that nevertheless is turned on by default in most Cisco products. This interface is a security time bomb, and should be disabled in virtually every Cisco deployment.

That's not just the opinion of Dr. I Doctor; it's conventional wisdom from the vast majority of security professionals in the world. The IOS HTTP interface is not a comprehensive GUI configuration interface -- it's just a gimick, really, that lets you execute textual command line interface commands through a Web browser. This latest vulnerability shows how dangerous such easily forgotten back doors can be.

In the instant event, Cisco reports that all these IOS devices are subject to a cross-site scripting attack in which an interloper can gain control of a router or switch by executing arbitrary IOS commands on a device being controlled through the HTTP CLI interface. To be sure, there are a lot of conditions to meet before this exploit is possible. First, somebody has to be actually using a Web browser on the HTTP interface. Second, they must at the same time visit a hostile site containing the exploit for this vulnerability. And third, the exploiter must have somehow gotten the command he wants executed into the device's memory buffers, and the user must execute an IOS command to view that buffer.

That's a long chain of coincidences, which makes this vulnerability, in theory, not very serious. But in the network security biz, where there's smoke, there's fire. Rarely do programmers commit bugs in isolation. It's quite probable that there are other bugs in the IOS HTTP interface, of unknown virulence, just waiting for hackers to find and exploit them. Since the HTTP interface is unnecessary for router operation, following the principle of least privilege, it should be turned off.

Since most of us have Cisco devices, and we all know (or should know) that the HTTP interface must be disabled as a best practice, this incident should serve as a wakeup call to verify that we have, in fact, disabled this hole. It only takes a minute to verify whether or not HTTP is running in IOS. Just type the command "show ip http server status". If the result is "enabled", you've got a problem. To disable the HTTP server, enter these two commands in configuration mode:

no ip http server
no ip http secure-server

The full Cisco security bulletin discussing this vulnerability is at:
http://www.cisco.com/en/US/products/products_security_advisory09186a008059e470.shtml

Posted by mbeckman on December 6, 2005 at 7:07 AM