BITS Gives Bad Guys an Inroad

Malware developers have been using Microsoft's Background Intelligent Transfer Service (BITS) to download software to Windows systems for quite some time. Using BITS is logical because it's designed to download files and is a standard part of all supported Windows OSs. BITS takes advantage of unused bandwidth to help optimize network usage, which makes its activity less noticeable to a user.

One problem in defending against this misuse is that BITS is used by Windows Update, Microsoft Systems Management Server (SMS), Microsoft Messenger, and other tools, so it's typically trusted by firewalls to move traffic in and out of the network. Another problem in preventing malware developers from using BITS is that when a malicious application downloads files with it, the traffic is seen as coming from BITS and not the application itself.

Firewall leak testers have long known about the potential danger of BITS and have openly discussed the matter for over a year. At least one program, bits_tester.exe (at the first URL below), is available that works with Microsoft's bitsadmin.exe tool (in the Windows XP SP2 Support Tools at the second URL below) to demonstrate how BITS can easily download files from Web servers. http://www.firewallleaktester.com/news.htm#57 http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en

According to Guillaume Kaddouch of the Firewall Leak Tester Web site, the only way to currently control BITS activity is to limit the ability of svchost.exe (on XP and later Windows versions) or services.exe (on Windows 2000) to communicate over the network. So for example, if you want to better guarantee that BITS will be used only for file transfers on your network or between your network and Microsoft's software update sites, then you need to implement a deny-all policy for svchost.exe or services.exe and make specific exceptions for hosts that you want to receive content from through BITS. Keep in mind that because Microsoft also makes a BITS API available for developers to use, you might need to make exceptions for other legitimate desktop applications that use BITS to download their updates or other content.

The danger of malware misusing BITS isn't limited to software downloads. BITS can also become a significant source of information leakage because it can upload files too, although doing so requires that BITS upload to a Microsoft IIS server with BITS extensions installed. Here again, a deny-all policy can help.

Elia Florio brought the BITS problem to light again this month in a post on the Symantec Security Response blog (at the URL below) in which Florio suggested that Microsoft could improve the security of BITS. "It's not easy to check what BITS should download and not download," he wrote. "Probably the BITS interface should be designed to be accessible only with a higher level of privilege, or ... BITS should be restricted to only [download content from] trusted URLs." http://www.symantec.com/enterprise/security_response/weblog/2007/05/malware_update_with_windows_up.html

Microsoft hasn't said much about the issue of BITS being misused or whether the company intends to add any layers of security for it. While we're all waiting to find out, you do need to protect your systems in case your other security solutions fail to detect malware that might misuse BITS. I did a bit of checking to put together a list of URLs for sites that BITS might use to download files and updates from Microsoft. The list below is probably not complete, but you can use it to start building firewall rules. Keep in mind that you might need to prefix the server addresses below with http:// or https://, depending on your firewall rule requirements. I've noted the two addresses that require HTTPS access; the others require regular HTTP access.

windowsupdate.microsoft.com

*.windowsupdate.microsoft.com

*.windowsupdate.microsoft.com (HTTPS required)

*.windowsupdate.com

update.microsoft.com

*.update.microsoft.com

*.update.microsoft.com (HTTPS required)

download.windowsupdate.com

*.download.windowsupdate.com

download.microsoft.com

wustat.windows.com

ntservicepack.microsoft.com

If your rule mechanism allows for it, you could simplify the matter by allowing BITS to access *.windowsupdate.com, *.microsoft.com, and *.windows.com over both HTTP and HTTPS.