combating_file_infectors_corp_networks

Combating File Infectors on Corporate Networks Vinoo Thomas & Nitin Jyoti McAfee Avert Labs, India vinoo@avertlabs.com nitin@avertlabs.com Abstract In this age of botnets, rootkits, spyware, and other bleeding-edge security threats, file infectors are frequently thought of as a dead threat. But during the past year or so, we have observed an unprecedented growth in classic file-infecting viruses that have enjoyed a relatively high degree of success in the wild—causing widespread damage [1] to computer systems. Many of the new viruses seen today aren’t advancements in their own right; rather, they have just taken advantage of advancements in technology. And the sophistication of infection techniques and vectors used by viruses these days are on the rise. With a recent increase in network file-infecting viruses, it’s high time we revisit the traditional techniques used to detect virus-like activity on the network and improve them. This paper proposes using virtual area networks (VLANs) technology to mass deploy a SAMBA based honeypot to the entire site. We also look at setting up a server message block (SMB) based sniffer to capture file-infector activity on the local area network. The proposed solutions are scalable, cost effective and were internally implemented at McAfee Avert Labs. parasitic infectors targeting script files (.asp, .htm, .php et al.). When an infected file runs, directly or indirectly, the virus is activated, and proceeds to carry out the payload that it was programmed to do. A single infected machine can have hundreds or even thousands of copies of the virus and is capable of infecting other machines on the network. All file viruses are not created equal—hence we need different terms to describe them. Some exist merely to propagate; others exist to inflict damage, while still others start to blur the line between virus and spyware as they install backdoors or lower the security settings of the infected system. According to their infection mechanism, file viruses can be broadly classified as follows: − Parasitic: Infects files (executable, scripts). − Overwriting: Completely replaces the code in an infected file with its own. − Companion: The infected code is stored in a ‘companion’ file instead of the host. Each class of infectors can further be classified in detail but that is beyond the scope of this paper. We will stick to the theme of combating file-infecting viruses. For interested readers, a good study on this subject can be read at Viruslist [4]. Descriptions for all viruses listed in this paper can be found in the appendix section. 1. Background 2. Survival of the fittest Historically, file viruses were among the very first types [2] of virus, dating back to the 1980’s. The earliest demonstration file infector for personal computers was written in 1986 and christened “Virdem”—a proof-of-concept virus to help computer users understand how a computer virus operates. Since then, there have been a multitude of computer viruses that have tested the research skills of the antivirus community. File infectors primarily infect program executable files (files with an .exe, scr, or .dll extension), although recent trends [3] have shown a marked increase in Viruses with worm capabilities spread by infecting files on open shares or by copying themselves onto poorly secured shares on a network. As a simple matter of propagating after infecting files on the host machine, most viruses immediately scan the network for vulnerable hosts using ICMP or NetBIOS broadcasts and then attempt to infect any host they locate. They proceed to spread by infecting files with write permissions or copying themselves onto open shares on the target machine. The targeted host in turn gets infected when an infected file executes directly or 85 978-1-4244-3289-9/08/$25.00 c 2008 IEEE indirectly. Thus the virus gets activated and proceeds to carry out the payload that it was programmed to do. And this vicious self-sustained cycle continues unabated. What makes a virus tick and ensure that it successfully spreads and infects a large number of machines on the Internet? Unlike Trojans, which must trick careless users into executing questionable files using social-engineering techniques, file infectors have the luxury of piggy-backing on publicly available files on the Internet or on malware executables. Viruses are known to experience peaks of activity when they infect executable files of worms: The virus will then travel as far and wide as the infected worm file. For instance, we still encounter samples of prolific mass mailers such as W32/MyDoom@MM, W32/Netsky@MM, and W32/Bagle@MM that are infected by file viruses such as W32/Funlove, W32/Pate, or W32/Sality. In the wild, we regularly come across compromised web sites hosting Trojan executables that have accidentally been infected with a file infector —thanks to poor antivirus practices by malware authors themselves. And we still see legitimate public servers in which files hosted for public download are infected! [5] 2.2. Lessons from the field We regularly come across simple parasitic infectors that manage to infect every workstation and server on the network. And administrators are at their wits’ end trying to figure how the simplest of viruses managed to spread and infect every networked machine in so little time and with such stunning effect. Administrators routinely attend to distress calls from hapless users whenever they have an issue with their workstations. And administrators typically tend to log onto the affected workstation using their own account—which has domain administrative credentials. For a moment, let us assume the user whose workstation was acting weird was infected with a worm/virus. What could possibly go wrong from here? Most worms routinely scan for any alive hosts on the network using ICMP or NetBIOS broadcasts and then attempt to connect to the administrative shares of the hosts they find, using the credentials of the currently logged-on user. If the initial login attempt using a regular user account fails, the worm attempts a brute-force attack on the admin account using a predefined list of hard-coded usernames and passwords. Because most corporations have enforced complex password policies these days, brute-forcing is hardly effective. However, when an administrator logs to the affected machine using their domain admin account, the worm now runs on the affected machine using the elevated credentials of a domain administrator. Straight away the worm can now infect and spread to any host on the domain using these newly acquired administrative credentials. And in a matter of minutes the entire network with thousands of machines gets infected—by the dumbest of worms. And all this because an ignorant administrator committed the cardinal sin of logging into an infected machine using their own account. 2.1. Traditional countermeasures The age-old security practice to counter file infectors on a network was to set access-control lists (ACLs) on shares so that they are protected by the appropriate read/write permissions. Although userdefined shares can be protected by ACLs, the ACLs for administrative shares (C$, D$, Admin$, etc.) have read/write permissions that are enabled by default on Windows NT/2000/2003/XP machines. Windows Vista machines that are joined to a domain are an exception [6] and do not expose the administrative shares by default unless explicitly configured [7] to do so. It is possible to create a group policy or registry setting to not treat administrators differently—so that write access to the administrative shares is blocked over the network. However, this can be a double-edged sword. Disabling administrative shares on networked machines will severely limit the use of the computers on the network and potentially affect the way that they are managed—by breaking many patch deployment or systems management applications that rely on their existence. For example, if computers were managed by pushing files to them, this change will prevent updates or patches from being installed over the network. 3. Catch me if you can The presence of a file infector on the network has traditionally been difficult to detect over the wire. This is primarily because NetBIOS and Server Message Block (SMB) are very noisy protocols and an intrusion detection system (IDS) would be hard pressed to differentiate between a user copying or modifying files over the network versus a worm or virus doing the same. Files transferred over the wire can vary from a few kilobytes to many gigabytes; scanning these files in real time on the network could cause serious performance issues. 86 2008 3rd International Conference on Malicious and Unwanted Software (MALWARE) To add to these woes, huge numbers of false alerts can be produced by poorly configured IDS’s; many IDS deployments lie dormant [8] after being tagged as noise-generation tools by disillusioned IT personnel. John Morris of Nortel Networks first proposed the SMB Lure design at Virus Bulletin Conference 2002 to act as an early warning system for attracting file infectors or share-hopping worms [9]. The SMB Lure is a network honeypot that runs Samba file server specially configured to appear as a large number of computers in the Windows Network Neighborhood. The Samba server is configured to run in debug mode to provide extensive logging for every file transaction and contains a variety of interesting files and directories for the worms to interact with. After entering a network, worms typically exploit shared folders as a stealthy means of infecting more computers. The SMB Lure actively attracts file infectors or share-hopping worms to itself so that it can detect and identify the infected computers. SMB Lure has been successfully deployed on numerous corporate and educational networks to detect and identify infected computers and can be used to catch the following type of network worms: − Open-share file infectors (W32/Detnat, W32/Pate) − Open-share droppers (W32/Rontokbro, W32/Opaserv) − Those that use cached credentials or weak passwords (W32/Spybot, W32/Fujacks) Detailed instructions on setting up an SMB Lure have been covered in depth by Martin Overton and Paul Schmehl in previously published works [10, 11]. 3.1. The need for a VLAN based SMB-Lure Small or medium-sized companies typically have a single uncomplicated network where one instance of a SMB-Lure honeypot will suffice. But as the organization grows and more networks and subnetworks are added, multiple instances of SMB-Lure would need to be deployed. And this translates into additional hardware and software resources. Virtualization software such as VMware or Virtual PC could be used as a way to re-use existing hardware infrastructure but this would result in duplicate copies of SMB-Lure on the network and the additional overhead of managing these. The solution that we propose in this paper is to have a single honeypot server that is accessible from every networked computer on the entire site. The SMB Lure Figure 1: Deploying a honeypot via VLAN trunking 2008 3rd International Conference on Malicious and Unwanted Software (MALWARE) 87 honeypot is placed in a secured virtual local area network (VLAN) and is made accessible to every workstation and server via VLAN tagging. This honeypot server should have reasonable hardware to handle the load and emulate common vulnerable services that are targeted by network worms (in this case SMB/NetBIOS). default on almost every OEM manufactured computer. *NIX flavors support VLAN tagging by default, while Ethernet cards on Windows would need their vendorspecific drivers to enable this feature. The only prerequisite for setting this up is a basic working knowledge of network switches and technical know-how to configure Ethernet card settings for their respective operating systems. 4. VLAN requirements 4.1. Configuring VLAN trunking on the switch A local area network (LAN) is a group of connected computers that share resources among themselves. A small company can have one such LAN while larger companies will have multiple LANs each belonging to different departments possibly independent and isolated from each other. In such a scenario, a virtual local area network [12] could be used to share common infrastructure by creating logically separate LANs termed as a VLAN. Hosts on a virtual local area network (VLAN) communicate as if they were attached to the same wire, regardless of them not being physically located on the same LAN segment. The requirements for setting up a VLAN is that the network switch, the Ethernet adapter, and the host operating system must all support VLAN tagging — also known as 802.1q [13]—in order for them to trunk. Almost any enterprise or small/medium business-grade switches these days made by Cisco, D-Link, NetGear, and other vendors support VLAN tagging. Most current Ethernet cards support VLAN trunking and come by IOS Command Enable Configure Terminal Interface FastEthernet0/1 Switchport mode trunk Switchport trunk encapsulation dot1q The figure above (Figure 1) is a schematic representation of the proposed solution. We’ve drawn a typical medium-sized network with three different VLANs (sales, accounts, and engineering). Our objective is to enable our honeypot to be visible to all subnets across the three VLANs. Once the designated VLANs have been configured on the switch, to setup a VLAN trunk [14], encapsulation and trunk type must be set. This is followed by configuring the trunk to allow the VLANs that need to be monitored. Remember to look up the capabilities for each port on the switch, as not every module and interface on a switch supports trunking. At the switch level, we make the following configuration changes to enable VLAN trunking on the switch ports. In this example (Table 1), we use Cisco IOS switch commands [15]; commands for setting up a VLAN can vary among switch vendors. Switchport trunk allow vlan 100,101,102 Exit Exit Write memory Description Switch to privileged EXEC mode Enter global configuration mode Entering interface configuration for port 0/1. This is where you pick the port you want to trunk. Set port to trunking mode Set trunk type to 802.1q. If your switch supports only either ISL or 802.1q, this command does not exist because there is nothing to specify. This command works only when you can choose between the two. Allow only VLANs 100, 101, and 102. It is important that you restrict the VLANs to only the ones you need for security best practices. Exit interface Exit global configuration Commit changes to NVRAM Table 1: IOS commands for configuring VLAN on the switch 88 2008 3rd International Conference on Malicious and Unwanted Software (MALWARE) 4.2. Configuring VLAN trunking on the Ethernet card On the network adapter of the honeypot machine, we make the following configuration changes so that it is visible to every machine on the VLAN. In this example, we use Linux commands; commands for setting up a VLAN can vary among operating system vendors. Step 1: Initialize the interface eth0 $ ifconfig eth0 0.0.0.0 up Step 2: Add three VLAN interfaces for eth0 having the VLAN id 100, 101, and 102 $ vconfig add eth0 100 $ vconfig add eth0 101 $ vconfig add eth0 102 Step 3: Assign an IP address to each of the three VLAN interfaces and bring up the interface $ ifconfig eth0.100 192.168.1.100 broadcast 192.168.1.255 netmask 255.255.255.0 up $ ifconfig eth0.101 192.168.2.100 broadcast 192.168.2.255 netmask 255.255.255.0 up $ ifconfig eth0.102 192.168.3.100 broadcast 192.168.3.255 netmask 255.255.255.0 up up a varied collection and make use of a subset of small to large goat files for optimum results. This makes it possible to efficiently verify the infection behavior of polymorphic network worms. For each predefined period (for example, five minutes, etc.), a module may be executed that compares two directories, one containing a master copy of the files stored on the honeypot device and the other containing the share that is exposed as an open share on the honeypot device. If any file is added or modified, an alarm sounds, and the modified or added file is copied to a predefined folder along with the samba log file; from this we can parse the IP address of the machine responsible for triggering the alarm. Any files captured can be scanned with the latest signatures and if undetected can be immediately sent to the antivirus vendor. SMB Lure is a simple and easy-to-implement solution that can be mass deployed to a site using VLAN tagging. The setup we’ve discussed allows for only one resource to be used as a honeypot and can serve as worm bait for every subnet on the site. Any worm-like activity on the internal network could be proactively detected via this setup, which goes a long way toward containing and isolating the source of infection or attack. Step 4: List the new interface configuration $ ifconfig –a 5. A reactive approach - SMB File Sniffer Administrators are often faced with situations where a file infector is fast spreading by infecting open shares on the network. In the absence of an SMB-Lure type honeypot, locating the source of the infection can be like looking for a needle in a haystack. In these situations, having a protocol analyzer (sniffer) can come in handy. Unlike hubs, switches prevent promiscuous sniffing. Therefore in a switched network environment, the protocol analyzer is limited to capturing broadcast/multicast traffic and packets sent or received by the workstation on which the sniffer is running. Most modern switches support "port mirroring”, which is a feature that allows one to configure the switch to redirect the traffic that occurs on some or all ports to a designated monitoring port on the switch. By using this feature, one will be able to monitor traffic on the entire LAN segment. A handy reference to configure network switches for port mirroring can be found at the Wireshark site [17]. Conventional packets sniffers poorly decode server message block protocol (SMB) network activity on If a DHCP server is already in place for the different VLANs, each virtual interface will pick an IP address automatically. 4.3 Bait and captures The custom Samba configuration file “smb.conf” [11, 16] on the SMB Lure is then modified as shown below to assign multiple workstation names to our honeypot and make it the master browser of every workgroup in the network neighborhood. This would force it to appear in every vlan on the corporate network. netbios name = 000-Worm-Sensor netbios aliases = C00-worm-sensor E00-wormsensor J00-worm-sensor M00-worm-sensor domain master = True remote announce = 192.168.1.100/Sales 192.168.2.100/Accounts 192.168.3.100/Engineering It is imperative that we make use of a wide variety of “goat” files to get the stubborn or difficult-to-infect viruses to replicate. It is generally a good idea to build 2008 3rd International Conference on Malicious and Unwanted Software (MALWARE) 89 port 139 and 445 and cannot intercept and dump files that are being transmitted. To accomplish this, on the affected network we hook up SMB File Sniffer [18] a powerful protocol analyzer that can be used for logging SMB files operations and capturing file bodies transmitted within a local area network. SMB File Sniffer allows one to log SMB file operations with two levels of logging detailed and errors only. The sniffer is installed onto a windows box and connected to the mirror port of the switch where one can monitor all traffic on the network. A screenshot of the sniffer interface (Figure 2) is shown below: Figure 3: W32/Rontokbo sample captures Figure 2: SMB Sniffer Interface The spikes indicate file activity using the SMB protocol on the network. By examining packets from the mirror port of the switch, SMB File Sniffer captures any file operations taking place in real-time over the wire. Any file being copied or modified using the SMB protocol can be dumped to disk using the SMB sniffer. This way if a file infector or share hopping worm is active on the network, copies of the worm or modified files can be captured in real-time and samples isolated. Files transmitted over the wire that are captured by the sniffer are stored in directory names containing the source and destination IP addresses. The above screenshots (Figure 3,4) are examples of sample captures. One must keep in mind that this technique of using a dedicated SMB file sniffer on the mirror port is to be used only when there is a suspected network infection. Otherwise it can cause serious network congestion issues if every packet on the wire has to be analyzed by the sniffer. Figure 4: W32/Fujacks infected samples 6. The road ahead Combining SMB Lure with VLANs provides for improved detection and isolation of infected systems. The method described in this paper is not limited to deploying a SMB type of honeypot and can be used for implementing any honeypot to the site using VLANs. SMB Lure could be made into a pre-built VMWare image that can run off the freely available VMWare player [19]. This would greatly aid field engineers and administrators in incidents where they are called to track down the source of an infection on a network. With parasitic infections on the rise in the current malware climate, it is wise to revisit traditional countermeasures and improve upon our virus defense strategies. Reviewing the number of parasitic malware over the last couple of years [20], it’s clear this problem will not go away soon. With advancements in technology, we can expect to encounter more complex and challenging samples of this genre. It is only a matter of time until the next W32/ZMist heads our way. 90 2008 3rd International Conference on Malicious and Unwanted Software (MALWARE) 7. References [1] Computer Economics, "Annual Worldwide Economic Damages from Malware Exceed $13 Billion." http://www.computereconomics.com/article.cfm?id=1225 [2] IBM Research, “Virus Timeline.” http://www.research.ibm.com/antivirus/timeline.htm [3] Trend Micro, “PE_FUJACKS: Jacking Up to the Times.” http://www.trendmicro.com/vinfo/secadvisories/default6.asp? VNAME=PE_FUJACKS%3A+Jacking+Up+to+the+Times [4] Viruslist.com, “Classic Viruses.” http://www.viruslist.com/en/virusesdescribed?chapter=15254 0474 [5] security.itworld.com, “Antivirus company's Web site serves up malware.” http://security.itworld.com/4340/virusdownload-080208/page_1.html [6] Microsoft, “Microsoft Help http://support.microsoft.com/kb/947232 and Support.” [15] Cisco Systems, Inc., “Configuring 802.1Q Trunking Between a Catalyst 3550/3560/3750 and Catalyst Switches That Run Cisco IOS Software.” http://www.cisco.com/warp/public/473/88.html [16] Paul Schmehl, “Samba config file created for SMBLure.” http://www.utdallas.edu/~pauls/smblure/smb.conf [17] Wireshark, “Switch http://wiki.wireshark.org/SwitchReference Reference.” [18] microOLAP, “SMB File Sniffer.” http://www.microolap.com/products/network/smbfilesniffer/ [19] VMware, Inc., “VMware http://www.vmware.com/products/player/ Player.” [20] McAfee Avert Labs, “Top 10 Threat Predictions for 2008.” http://www.mcafee.com/us/local_content/white_papers/threat _center/wp_avert_predictions_2008.pdf 8. Appendix From McAfee Virus Information Library: VirDem http://vil.nai.com/vil/content/v_1347.htm W32/Bagle@MM http://vil.nai.com/vil/content/v_100965.htm W32/Detnat.a http://vil.nai.com/vil/content/v_139344.htm W32/Fujacks.worm http://vil.nai.com/vil/content/v_141204.htm W32/Funlove.gen http://vil.nai.com/vil/content/v_107926.htm W32/MyDoom@MM http://vil.nai.com/vil/content/v_100983.htm W32/NetSky.p@MM http://vil.nai.com/vil/content/v_101119.htm W32/Opaserv.worm http://vil.nai.com/vil/content/v_99729.htm W32/Pate.b http://vil.nai.com/vil/content/v_99690.htm W32/Rontokbro.gen@MM http://vil.nai.com/vil/content/v_136318.htm W32/Sality.t http://vil.nai.com/vil/content/v_139579.htm W32/Spybot.worm.gen http://vil.nai.com/vil/content/v_100282.htm W32/Zmist.gen http://vil.nai.com/vil/content/v_99382.htm [7] Microsoft TechNet, “File and Printer Sharing in Windows Vista.” http://technet.microsoft.com/enus/library/bb727037.aspx [8] Baylor, K., and Brown, C. “Killing Botnets: A view from the trenches.” McAfee, http://www.mcafee.com/us/local_content/white_papers/wp_b otnet.pdf (2006, October) [9] John Morris, “Fighting Worms in a Large Corporate Environment: a Design for a Network Anti-Worm Solution.” In Proceedings from Virus Bulletin Conference, Virus Bulletin, New Orleans, U.S.A., 2002, Page 56–66 [10] Martin Overton, “Worm Charming: Taking SMB Lure to the Next Level.” In Proceedings from Virus Bulletin Conference. Virus Bulletin, Toronto, Canada, 2003 [11] Paul Schmehl, “SMB Lure http://www.utdallas.edu/~pauls/smblure/ Scripts.”, [12] George Ou, “An introduction to VLAN Trunking.”, http://www.lanarchitect.net/Articles/VLANTrunking/Introdu ction/ [13] IEEE Standards Association, “Virtual Bridged Local Area Networks.” http://standards.ieee.org/getieee802/download/802.1Q2005.pdf [14] Cisco Systems, Inc., “Configuring VLANs.” http://www.ciscosystems.com/univercd/cc/td/doc/product/lan /cat4000/rel7_1/quick_sw/vlans.pdf 2008 3rd International Conference on Malicious and Unwanted Software (MALWARE) 91