CHAPTER 8
DESKTOP AND SERVER OS VULNERABILITIES
After reading this chapter and completing the activities, you will be able to:
Describe vulnerabilities of the Windows and Linux operating systems
Identify specific vulnerabilities and explain ways to fix them
Explain techniques to harden systems against Windows and Linux vulnerabilities
In Chapter 6, you learned how to enumerate systems to discover open ports that can be used to access data and resources. After enumerating systems, your job as a security tester is pinpointing potential security problems. You must also be familiar with methods of improving security on tested systems and correcting vulnerabilities you find. This chapter examines how security testing is used to analyze an OS for vulnerabilities and correct them. Finally, you explore techniques and best practices for hardening OSs and services.
WINDOWS OS VULNERABILITIES
Many Windows OSs have serious vulnerabilities. In Windows 2000 and earlier, several services and features are unsecured and open for access. To secure these systems, administrators must disable, reconfigure, or uninstall these services and features to lessen the vulnerability to attack. To improve security, Windows XP, Vista, Server 2003, Server 2008, and Windows 7 have most services and features disabled by default. In these environments, administrators must configure them to be available, or users can’t access needed resources. In other words, security is tighter in these updated versions, but users can’t do their jobs. An entire chapter could be devoted to this problem, but for this chapter, you just need to know that default installations of Windows OSs can contain serious vulnerabilities that attackers exploit.
Table 8.1 Windows Server 2008 vulnerabilities found at CVE
To determine vulnerabilities for any OS, you can check the CVE Web site (www.cve.mitre.org). Table 8.1 briefly describes a few CVEs and CANs (candidates) for Windows Server 2008 and shows how a vulnerability in one OS version also applies to newer versions. (For more detailed explanations of the vulnerabilities listed in this table, visit the CVE Web site.)
Many of the explanations at the CVE Web site are complex and might be difficult to understand. What’s important, however, is that you’re able to research a vulnerability that’s relevant to the security test you’re conducting. For example, if the system you’re testing uses the Remote Desktop Connection client noted in CVE 2009-1929, you might need to do research on what Remote Desktop Connection is and whether the version the company is running is vulnerable. You might also have to visit the Microsoft Web site to see whether any patches or security updates are available for this vulnerability. For example, searching on “Remote Desktop Connection vulnerability” at the Microsoft Web site reveals the following: “Microsoft Security Bulletin MS09-044 - Critical Vulnerabilities in Remote Desktop Connection Could Allow Remote Code Execution (970927).” Information about the vulnerability and links to download the patches are provided at www.microsoft.com/technet/security/Bulletin/MS09-044.mspx.
As a security tester, you must be able to go beyond the basics to perform your job effectively. A security tester is an investigator who doesn’t stop at one piece of information. You are the Columbo of the IT world, always saying “Oh, and one more question …”
Security testers can use information from the CVE site to test a Windows computer and make sure it’s been patched with updates from Microsoft that address these known vulnerabilities. Hackers visit Web sites that offer exploit programs to run against these vulnerabilities, but launching exploits is not your job. In other words, you don’t want to blow up a refinery to demonstrate the company’s safety violations; you want to inform the company when it isn’t in compliance with safety regulations. Many of these known vulnerabilities use ports that port-scanning tools can easily detect as being open. For example, NNTP (port 119), SMTP (port 25), and RPC (port 135) might be vulnerable to attack.
When you’re conducting research on possible vulnerabilities, don’t skim the CVE and CAN information. Remember, attention to detail is what separates skillful security testers from the mediocre. As Pete Herzog states in the OSSTMM: “Do sweat the small stuff, because it’s all small stuff.” The tools and procedures you have performed in previous chapters can be carried out on any OS.
Windows File Systems
The purpose of any file system, regardless of the OS, is to store and manage information. The file system organizes information that users create as well as the OS files needed to boot the system, so the file system is the most vital part of any OS. In some cases, this critical component of the OS can be a vulnerability.
File Allocation Table
File Allocation Table (FAT), the original Microsoft file system, is supported by nearly all desktop and server OSs. Because of its broad support, FAT12 is also the standard file system for most removable media other than CDs and DVDs. Later versions, such as FAT16, FAT32, and Extended FAT (exFAT, developed for Windows Embedded CE), provide for larger file and disk sizes. For example, FAT32 allows a single file to be up to 4 GB and a disk volume to be up to 8 terabytes (TB). The most serious shortcoming of FAT is that it doesn’t support file-level access control lists (ACLs), which are necessary for setting permissions on files. For this reason, using FAT in a multiuser environment results in a critical vulnerability. Microsoft addressed this problem and other shortcomings of FAT when it introduced its first OS for enterprises, Windows NT.
NTFS
New Technology File System (NTFS) was first released as a high-end file system in Windows NT 3.1, and in Windows NT 3.51, it added support for larger files and disk volumes as well as ACL file security. Subsequent Windows versions have included upgrades for compression, disk quotas, journaling, file-level encryption, transactional NTFS, symbolic links, and self-healing. Even with strong security features, however, NTFS has some inherent vulnerabilities. For example, one little-known NTFS feature is alternate data streams (ADSs), written for compatibility with Apple Hierarchical File System (HFS). An ADS can “stream” (hide) information behind existing files without affecting their function, size, or other information, which makes it possible for system intruders to hide exploitation tools and other malicious files. Several methods can be used to detect ADSs. In Windows Vista and later, a switch has been added to the Dir command: Enter dir/r from the directory you want to analyze to display any ADSs. For previous Windows versions, you need to download a tool such as LNS from www.ntsecurity.nu/toolbox/lns/. Whatever method you use, you need to determine whether any ADS you detect is supposed to be there. A better and more efficient method of detecting malicious changes to the file system is using host-based file-integrity monitoring tools, such as Tripwire (www.tripwire.com) or Ionx Data Sentinel (www.ionx.co.uk). A *nix-based version of Tripwire is also available.
Remote Procedure Call
Remote Procedure Call (RPC) is an interprocess communication mechanism that allows a program running on one host to run code on a remote host. The Conficker worm took advantage of a vulnerability in RPC to run arbitrary code on susceptible hosts. Microsoft Security Bulletin MS08-067, posted October 23, 2008, advised users of this critical vulnerability that allowed attackers to run their own code and offered a patch to correct the problem. Even though the vulnerability was published in advisories and a patch was available weeks before the Conficker worm hit on November 21, 2008, millions of computers were affected. Microsoft Baseline Security Analyzer (MBSA, discussed in more detail later in “Tools for Identifying Vulnerabilities in Windows”) is an excellent tool for determining whether a system is vulnerable because of an RPC-related issue. In Activity 8.1, you download and install it on your Windows computer.
Activity 8.1: Downloading and Installing MBSA
Time Required: 30 minutes
Objective: Download and install Microsoft Baseline Security Analyzer.
Description: In this activity, you download and install MBSA, a helpful tool for discovering vulnerabilities in Windows systems.
1. In Windows, start your Web browser and go to www.microsoft.com/technet/security/tools/mbsahome.mspx.
2. Click the link for downloading the latest version of MBSA.
3. Click the Download Now link, and then click the link under the Download Now heading. Scroll down and click the Download button next to your Windows version (usually MBSASetup-x86-EN.msi unless you’re running Windows x64).
4. After the download is finished, browse to the location of the saved file and double-click the setup executable file. If you see a warning message, click Run or OK to continue. The MBSA Setup Wizard starts.
5. After closing all running Windows applications, click Next.
6. Click the I accept the license agreement option button, and then click Next.
7. Follow the prompts, accepting the default settings.
8. When the installation is finished, start MBSA by clicking Start, pointing to All Programs, and clicking Microsoft Baseline Security Analyzer or by double-clicking the desktop icon, if available.
9. Take some time to explore the interface and familiarize yourself with the program. Leave MBSA running for the next activity.
NetBIOS
As you learned in Chapter 6, NetBIOS is software loaded into memory that enables a program to interact with a network resource or device. Network resources are identified with 16-byte NetBIOS names. NetBIOS isn’t a protocol; it’s just the interface to a network protocol that enables a program to access a network resource. It usually works with NetBIOS Extended User Interface (NetBEUI), a fast, efficient protocol that requires little configuration and allows transmitting NetBIOS packets over TCP/IP and various network topologies, such as token ring and Ethernet. NetBIOS over TCP/IP is called NBT in Windows 2000 Server; in Windows Server 2003, it’s called NetBT. (NetBIOS isn’t available in Windows Vista, Server 2008, and later versions of Windows.)
Systems running newer Windows OSs can share files and resources without using NetBIOS; however, NetBIOS is still used for backward compatibility, which is important when corporate budgets don’t allow upgrading every computer on the network. In addition, customer expectations must be met. Customers expect, for example, that a document created in Word 97 can still be read in Word 2003. In fact, they demand it. Therefore, software developers face the challenge of improving OS security yet still ensuring compatibility with less secure predecessors. As long as newer Windows OSs have to work with older NetBIOS-based systems, security will always be a challenge.
Server Message Block
In Windows, Server Message Block (SMB) is used to share files and usually runs on top of NetBIOS, NetBEUI, or TCP/IP. Several hacking tools that target SMB can still cause damage to Windows networks. Two well-known SMB hacking tools are L0phtcrack’s SMB Packet Capture utility and SMBRelay, which intercept SMB traffic and collect usernames and password hashes.
Interestingly, it took Microsoft seven years to patch the vulnerability these hacking tools exploited. Many security researchers point to this situation as another example of the problem caused by ensuring backward compatibility. By continuing to use a protocol with a known vulnerability (which can also be described as a design flaw), Microsoft exposes its products to attack and exploitation.
Microsoft introduced SMB2 in Windows Vista, and this version has several new features and is faster and more efficient. In addition, in Windows 7, Microsoft avoided reusing code from Windows XP in the OS but still allowed backward capability by including an option for a virtualized Windows XP environment, called Windows XP Mode.
Common Internet File System
Common Internet File System (CIFS) is a standardized protocol that replaced SMB in Windows 2000 Server and later, but to allow backward compatibility, the original SMB is still used. CIFS is a remote file system protocol that enables computers to share network resources over the Internet. In other words, files, folders, printers, and other resources can be made available to users throughout a network. For sharing to occur, there must be an infrastructure that allows placing these resources on the network and a method to control access to resources. CIFS relies on other protocols to handle service announcements notifying users what resources are available on the network and to handle authentication and authorization for accessing these resources. CIFS is also available for many *nix systems.
The Network Neighborhood or My Network Places services use broadcast protocols to announce resources available on a network. Essentially, a computer calls over the network connection “Here I am! My NetBIOS name is Salesmgr, and I have lots of files and folders to share with anyone out there.” To share files and folders, CIFS relies on SMB, but it offers many enhancements, including the following:
Locking features that enable multiple users to access and update a file simultaneously without conflicts
Caching and read-ahead/write-behind capability
Capability to run more efficiently over slow dial-up lines
Support for anonymous and authenticated access to files to improve security
To prevent unauthorized access to these files, CIFS relies on SMB’s security model. An administrator can select two methods for server security:
Share-level security—A folder on a disk is made available to users for sharing. A password can be configured for the share but isn’t required.
User-level security—The resource is made available to network users; however, a username and password are required to access the resource. The SMB server maintains an encrypted version of users’ passwords to enhance security.
Windows 2000 Server and later listen on most of the same ports as Windows NT, which means many old attacks might still work on newer OSs. For example, by recognizing which ports are open on a Windows Server 2003 or 2008 system, a security tester can find vulnerabilities that allow introducing a Trojan or other remote control program for capturing authorized users’ passwords and logon names. Most attackers look for servers designated as domain controllers (servers that handle authentication). Windows Server 2003 and 2008 domain controllers are used to authenticate user accounts, so they contain much of the information attackers want to access. By default, Windows Server 2003 and 2008 domain controllers using CIFS listen on the following ports:
DNS (port 53)
HTTP (port 80)
Kerberos (port 88)
RPC (port 135)
NetBIOS Name Service (port 137)
NetBIOS Datagram Service (port 139)
LDAP (port 389)
HTTPS (port 443)
SMB/CIFS (port 445)
LDAP over SSL (port 636)
Active Directory global catalog (port 3268)
In Windows Server 2003 and 2008, a domain controller uses a global catalog (GC) server to locate resources in a domain containing thousands or even millions of objects. For example, if a user wants to locate a printer with the word “color” in its description, he or she can use a GC server, which contains attributes such as the resource’s name and location and points the user to the network resource.
Null Sessions
As you learned in Chapter 6, a null session is an anonymous connection established without credentials, such as a username and password. Also called an anonymous logon, a null session can be used to display information about users, groups, shares, and password policies. Null sessions are necessary only if networks need to support older Windows versions. Nonetheless, many organizations still have null sessions enabled, even though all their old Windows systems have been removed from the network. You can use the Nbtstat, Net view, Netstat, Ping, Pathping, and Telnet commands to enumerate NetBIOS vulnerabilities.
Web Services
Many Windows services leave systems vulnerable to attack, especially Web services and IIS in particular. Microsoft developed the IIS Lockdown Wizard specifically for locking down IIS versions 4.0 and 5.0. You can download it from http://support.microsoft.com/kb/325864. As a security tester, however, you should encourage clients to upgrade any OS that’s no longer supported instead of using security workarounds, such as the IIS Lockdown Wizard.
IIS 5.0 is installed by default in Windows 2000 Server, and many administrators aren’t aware of it until a problem occurs. On networks still using Windows 2000 Server, don’t assume there’s no Web server on your network just because you didn’t specifically install one.
Although IIS 6.0 (Windows Server 2003) and IIS 7.0 (Windows Server 2008) are installed in a “secure by default” mode, previous versions left crucial holes that made it possible for attackers to sneak into a network. Regardless of the IIS version a system runs, keeping systems patched is important, and system administrators should still be aware of what patches are installed and which services are running on their Web servers. Configuring only necessary services and applications is a wise move.
SQL Server
Microsoft SQL Server has many potential vulnerabilities that can’t be covered in detail in this book. The most common critical SQL vulnerability is the null SA password. All versions before SQL Server 2005 have a vulnerability that could allow remote users to gain System Administrator (SA) access through the SA account on the server. During SQL Server 6.5 and 7 installations, the user is prompted—but not required—to set a password on this account.
SQL Server 2000 uses Windows Integrated authentication by default, but the user can also select mixed-mode authentication. In this authentication mode, an SA account with a blank password is created, and this account can’t be disabled. If attackers find this account, they have administrative access to not only the database, but also potentially the database server.
Buffer Overflows
As you learned in Chapter 3, a buffer overflow occurs when data is written to a buffer (temporary memory space) and, because of insufficient bounds checking, corrupts data in memory next to the allocated buffer. Normally, this problem occurs when copying strings of characters from one buffer to another. Because of design flaws, several functions don’t verify that the text they generate fits in the buffer supplied to hold them. If this lack of verification is exploited, it can allow attackers to run shell code. Both C and C++ lack built-in protection against overwriting data in memory, so applications written in these languages are vulnerable to buffer overflow attacks. Because these programming languages are widely used, buffer overflow vulnerabilities are prevalent in many applications and OSs. Buffer overflow attacks don’t require an authenticated user and can be carried out remotely.
Note
Several Microsoft buffer overflow exploit plug-ins are available free for download and are included with Metasploit as part of this book’s companion website. If you have access to these exploit tools, you can be sure that attackers will, too.
Passwords and Authentication
You’ve already learned that the weakest security link in any network is authorized users. Unfortunately, this link is the most difficult to secure, as it relies on people who might not realize that their actions could expose their organization to a major security breach, resulting in damaged systems, stolen or destroyed information, mal-ware infection, and so forth. There might also be legal issues to deal with after an attack, and a company can lose customers’ confidence as a result.
Companies should take steps to address this vulnerability. A comprehensive password policy is critical, as a username and password are often all that stands between an attacker and access. A password policy should include the following:
Change passwords regularly on system-level accounts (every 60 days at minimum).
Require users to change their passwords regularly (at least quarterly).
Require a minimum password length of at least eight characters (and 15 characters for administrative accounts).
Require complex passwords; in other words, passwords must include letters, numbers, symbols, punctuation characters, and preferably both uppercase and lowercase letters.
Passwords can’t be common words, words found in the dictionary (in any language), or slang, jargon, or dialect.
Passwords must not be identified with a particular user, such as birthdays, names, or company-related words.
Never write a password down or store it online or in a file on the user’s computer.
Don’t hint at or reveal a password to anyone over the phone, in e-mail, or in person.
Use caution when logging on to make sure no one sees you entering your password.
Limit reuse of old passwords.
In addition to these guidelines, administrators can configure domain controllers to enforce password age, length, and complexity. On Windows 2000 Server, Server 2003, or Server 2008 domain controllers, some aspects of a password policy can be enforced, such as the following:
Account lockout threshold—Set the number of failed attempts before the account is disabled temporarily.
Account lockout duration—Set the period of time the user account is locked out after a specified number of failed logon attempts.
Unless support for older systems (before Windows 2000) is necessary, be sure to disable LAN Manager hashes in the Registry to prevent storing passwords as seven-character chunks, which makes cracking passwords easy. On Windows Server 2008 and later domain controllers, multiple password policies can be enforced. For example, one password policy might require a complex password of 15 or more characters for administrator accounts, and another password policy might require only 8 characters for user accounts with no administrative privileges. Despite the best efforts to promote security by enforcing password policies, it’s still entirely possible that a password can be cracked. The latest tools that incorporate rainbow tables can crack complex passwords surprisingly fast. You explore password cracking in more detail in Chapter 12.
TOOLS FOR IDENTIFYING VULNERABILITIES IN WINDOWS
Many tools are available for discovering Windows vulnerabilities. Using more than one tool for analysis is advisable, so learning a variety of methods and tools is beneficial to your career. Familiarity with several tools also helps you pinpoint problems more accurately. Some tools might report deceptive results, and if these results aren’t verified with another method, you might not have an accurate assessment to report. Popular OS vulnerability scanners include eEye Retina, Tenable Nessus, Qualys-Guard, GFI Languard, and IBM Internet Scanner as well as OpenVAS, which you were introduced to in previous chapters. All these products scan both Linux and Windows OSs. In addition, several tools are built into Windows, and you learned about some in Chapter 6. In this following section, you explore a Windows tool for assessing Windows systems.
Built-in Windows Tools
This section focuses on Microsoft Baseline Security Analyzer (MBSA), which you installed in Activity 8.1. Although security problems exist in all computer systems, many attacks can be avoided with careful system analysis and maintenance, which can include anything from establishing an efficient, regular update scheme to reviewing log files for signs of unusual activity. When Microsoft learns of problems or vulnerabilities in its software, it publishes patches, security updates, service packs, and hotfixes to address them as soon as possible. Microsoft has also addressed the problem of finding configuration errors, missing patches, and so on, and MBSA is an excellent, free resource for this task (see Figure 8.1). This tool is capable of checking for patches, security updates, configuration errors, blank or weak passwords, and more.
Table 8.2 summarizes MBSA’s scanning capabilities. Note that these scans aren’t performed, even in full-scan mode, if the associated product isn’t installed on the system you’re scanning. More information and complete instructions are available in the MBSA Help interface or the Microsoft Security Tools Web site (www.microsoft.com/technet/security/tools).
Using MBSA
Any computer meeting the system requirements shown in Table 8.3 can scan another computer or be scanned locally or remotely by MBSA. MBSA has its origins in the HFNetchk scanner created by Mark Shavlik, a Windows NT developer. Microsoft collaborated with Shavlik to develop and refine MBSA. The latest MBSA version uses the dynamic features of Windows Update.
Like the original HFNetChk tool, you can run MBSA from the command line, too, which enables you to use scripts. Figure 8.2 shows the output of running mbsacli.exe from a Windows 7 Enterprise system and targeting a file server running Windows Server 2008.
Figure 8.1
Checks available in MBSA
Courtesy Course Technology/Cengage Learning
Table 8.2 Checks performed by MBSA in full-scan mode
Table 8.3 Minimum system requirements for MBSA
Figure 8.2
Scanning with the mbsacli.exe/target command
Courtesy Course Technology/Cengage Learning
Activity 8.2: Using MBSA to Scan the Local Computer (Optional)
Time Required: 30 minutes
Objective: Use MBSA to scan the local computer for weak or missing passwords.
Description: In this activity, you scan your computer with MBSA to discover vulnerabilities, including weak or missing passwords. At the end of the activity, summarize your findings and write up brief recommendations for correcting the problems you found.
1. Start MBSA, if necessary. (In Windows Vista and Windows 7, right-click the program menu item and click Run as administrator.)
Courtesy Course Technology/Cengage Learning
Figure 8.3
Viewing the MBSA report
2. Click Scan a computer. In the Which computer do you want to scan? window, accept the default settings, and click Start scan.
3. When the scan is finished, the report window displays the results (see Figure 8.3). What problems did MBSA find? Did it find any password vulnerabilities or other vulnerabilities? Are any results unexpected?
4. Write a brief summary of vulnerability problems that MBSA found. Close the MBSA window, and log off Windows for the next activity.
BEST PRACTICES FOR HARDENING WINDOWS SYSTEMS
As a penetration tester, your job is simply to find vulnerabilities and report them as defined in your contract. Your responsibility ends there. However, a security tester must not only find vulnerabilities; he or she must be familiar with methods of correcting them. Typically, managers want solutions included with reports of potential problems, particularly for technologies they might not fully understand.
Although the only way to make a system truly secure is to unplug it and lock it away in a vault, this approach defies the purpose of a network. Because you can’t lock network computers away to keep them secure, the best option is to be vigilant. A security breach is only one undiscovered vulnerability away, but with careful management, most systems can be secured adequately and still meet users’ needs. There are some general things you can do to make and keep a network secure, discussed in the following sections.
Patching Systems
The best way to keep systems secure, operating at peak performance, and using the newest features is to keep systems under your care up to date. As noted, many attacks have taken advantage of a known vulnerability that has a patch available. There are several methods for obtaining service packs, hotfixes, and patches. If you have only a few computers to maintain (10 or fewer), accessing Windows Update manually from each computer works fine, but this method is still time consuming. Depending on the Windows version, you can configure Automatic Updates on each machine. This option is usually better because it helps ensure that machines are always up to date without the administrator or user’s intervention. The downside is that some patches can cause problems, so testing a patch before applying it to a production system is preferable, particularly in large networks.
For a large network, applying updates manually isn’t feasible. Configuring Automatic Updates is an option if you have physical access to all computers, but downloading patches to each machine can slow network performance. There are a couple of options for patch management. Microsoft’s Systems Management Server (SMS) can manage security patches for all computers on your network. This service assesses machines in a defined domain and can be configured to manage patch deployment. (Although this service has many other capabilities, for the purposes of this chapter, you simply need to know that it can be used for patch management.)
Another option is Windows Software Update Services (WSUS), a client/server technology designed to manage patching and updating system software from the network. Instead of downloading updates to each computer, WSUS downloads patches and publishes them internally to servers and desktop systems. Unlike Automatic Updates, which downloads and installs updates automatically, the administrator has control over which updates are deployed. This feature is a major advantage, considering that some updates can cause problems with certain network and application configurations and should be tested before being deployed.
Third-party patch management solutions are also available from vendors such as Symantec, McAfee, Shavlik, and HP. Whatever patch-management technique is the best fit, remember that keeping systems up to date is one of the most critical steps in keeping systems secure. As a security tester, often you’ll find that patches aren’t current on the system you’re testing. An effective patch-management scheme might seem like common sense, but administrators often get so busy with other complicated issues that they forget the simple solutions. You must recommend effective patch management to your clients and be able to explain why it’s crucial to system security.
Antivirus Solutions
Whether you’re working with an enterprise network consisting of hundreds of servers and thousands of clients or a small business network of 15 systems and one server, an antivirus solution is essential. For small networks, desktop antivirus tools with automatic updating might be enough, but in a large network, a corporate-level solution is needed. Several excellent products are available, and selecting the right one requires some research. What’s important to remember about an antivirus tool is that it must be planned, installed, and configured correctly to ensure the best protection. An antivirus tool is almost useless if it isn’t updated regularly. Ideally, an antivirus tool should automatically download and install updates daily. If your examination of a system reveals that no antivirus tool is running, you should recommend installing one immediately. You must also stress keeping it up to date for the best protection.
Enable Logging and Review Logs Regularly
Logging is an important step for monitoring many crucial areas, including performance, traffic patterns, and possible security breaches. It must be configured carefully to record only useful statistics because logging can have a negative impact on performance. Review logs regularly for signs of intrusion or other problems on the network. Scanning through thousands of log entries is time consuming, and missing important entries is likely. A log-monitoring tool is best for this task. Several are available, depending on network needs and budget.
Disable Unused Services and Filtering Ports
Disabling unneeded services and deleting unnecessary applications or scripts make sense because they give intruders a potential point of entry into a network. For example, if you have a Windows Server 2008 system acting as a file server, you certainly don’t need DNS services running on it; doing so leaves port 53 TCP/UDP open and vulnerable to attack. The idea is simple: Open only what needs to be open, and close everything else—also known as reducing the attack surface. (The attack surface is the amount of code a computer system exposes to unauthenticated outsiders.) With fewer services exposed, there’s less chance of an attacker being able to find an unpatched vulnerability.
In addition, filtering out unnecessary ports can protect systems from attack. Some ports frequently subject to attack include the following:
FTP (20 and 21 TCP)
TFTP (69 UDP)
Telnet (23 TCP)
DNS (53 TCP/UDP)
NNTP (119 TCP)
NetBIOS (135 TCP/UDP, 137 and 138 UDP, 139 TCP)
Windows 2000 NetBIOS (445 TCP/UDP)
Remote Desktop Protocol (3389 TCP)
SNMP (161 and 162 TCP/UDP)
Windows RPC programs (1025 to 1039 TCP/UDP)
The best way to protect a network from SMB attacks is to make sure perimeter routers filter out ports 137 to 139 and 445. Blocking ports 139 and 445 has the added benefit of protecting against external null session attacks. Even Windows Server 2003 doesn’t disable SMB on port 445 by default. In fact, if the computer is a domain controller, you need to provide access to SMB. The server’s job is to make sure the person attempting to log on to the network is indeed authorized to access network resources. Because you usually want to share resources on a server, closing port 445 could create other problems, such as users not being able to access shared folders and printers.
An attacker can gain entry through many other ports. It isn’t possible to close all avenues of attack and still offer the functionality users need, but with careful planning, an administrator can make sure there are fewer ways in. For a complete list of ports and services, consult IANA’s Assigned Port Number page at www.iana.org/assignments/port-numbers.
Caution
Use caution when disabling services and blocking ports. Make sure that no required services depending on a port or other service are disabled.
Other Security Best Practices
In addition to keeping software up to date, running antivirus tools, and disabling services, you can take the following steps to help minimize the risks to a Windows network:
Use TCP/IP filtering.
Delete unused scripts and sample applications.
Delete default hidden shares and unnecessary shares.
Use a different unique naming scheme and passwords for public interfaces.
Be careful of default permissions.
Use packet-filtering technologies, such as host-based software firewalls, enterprise-class hardware firewalls, and intrusion detection and prevention systems, that are suited to the environment.
Use open-source or commercial tools to assess system security.
Use a file-integrity checker to monitor unauthorized file system modifications and send alerts of these changes.
Disable the Guest account.
Rename the default Administrator account.
Make sure there are no accounts with blank passwords. A good password policy is crucial.
Use Windows group policies to enforce security configurations on large networks efficiently and consistently.
Develop a comprehensive security awareness program for users to reinforce your organization’s security policy.
Keep up with emerging threats. Check with Microsoft, SANS, US-CERT (www.us-cert.gov), and other security organizations for the newest developments.
The security field is changing rapidly, and security professionals must keep up with new developments, threats, and tools. Securing Windows systems can be challenging, but a number of tools can be used to pinpoint problems.
LINUX OS VULNERABILITIES
Like any OS, Linux can be made more secure if users are aware of its vulnerabilities and keep current on new releases and fixes. It’s assumed you have some experience working with a *nix OS, so basics of the Linux OS and file system aren’t covered in this chapter. Many Linux versions are available, with differences ranging from slight to major. For example, Red Hat and Fedora Linux use the yum command to update and manage RPM packages, and Ubuntu and Debian (and the Linux version included with the BackTrack files) use the aptget command to update and manage DEB packages. Whatever Linux version you use, it’s important to understand the basics, such as run control and service configuration, directory structure, file system, basic shell commands and scripting, and package management. (If you’re unfamiliar with these *nix basics, spending some time reviewing them is highly recommended. One of the quickest ways security testers can make a poor impression on clients is to show a lack of knowledge about the systems they’re testing.)
Note
Guide to Operating Systems, Enhanced Edition (Michael Palmer, Course Technology, 2007, ISBN 1418837199) is highly recommended for more information on Linux as well as Windows, NetWare, and Macintosh OSs. A thorough understanding of OSs is essential for security testers.
A typical Linux distribution has thousands of packages developed by many contributors around the world. With such diverse sources of code, it’s inevitable that flaws will happen and sometimes be discovered only after they have been incorporated in the final product. Too many network administrators believe Windows is easier to attack and view *nix OSs as inherently more secure. Security professionals must understand that making these assumptions can be dangerous because vulnerabilities exist for all OSs. When conducting a security test on systems running Linux, you should follow the same rules you would for any OS.
Samba
Users expect to be able to share resources over a network, regardless of the OS used, and companies have discovered that users no longer tolerate proprietary systems that can’t co-exist in a network. To address the issue of interoperability, a group of programmers created Samba (www.samba.org) in 1992 as an open-source implementation of CIFS. With Samba, *nix servers can share resources with Windows clients, and Windows clients can access a *nix resource without realizing that the resource is on a *nix computer. Samba has been ported to non-*nix systems, too, including OpenVMS, NetWare, and AmigaOS. At the time of this writing, Samba contributors continue to analyze SMB2 so that it can be supported in the upcoming Samba 4. Security professionals should have a basic knowledge of SMB and Samba because many companies have a mixed environment of Windows and *nix systems.
For a Windows computer to be able to access a *nix resource, CIFS must be enabled on both systems. On networks that require *nix computers to access Windows resources, Samba is often used. It’s not a hacking tool; this product was designed to enable *nix computers to “trick” Windows services into believing that *nix resources are Windows resources. A *nix client can connect to a Windows shared printer and vice versa when Samba is configured on the *nix computer. Most new versions of Linux include Samba as an optional package, so you don’t need to download, install, and compile it.
Table 8.4 Linux vulnerabilities found at CVE
Tools for Identifying Linux Vulnerabilities
Visiting the CVE Web site is a good first step in discovering possible avenues attackers might take to break into a Linux system. Table 8.4 lists a small portion of the CVEs and CANs found when searching on the keyword “Linux.” To give you an idea of the multitude of Linux vulnerabilities, more than 500 entries were found. Many of these vulnerabilities can no longer be exploited on systems that have been updated.
You can use CVE information when testing Linux computers for known vulnerabilities. Security testers should review the CVE and CAN information carefully to ensure that a system doesn’t have any vulnerabilities listed on the CVE Web site and has been updated.
In Chapter 6, you learned how tools such as OpenVAS can be used to enumerate multiple OSs. A security tester using enumeration tools can do the following:
Identify a computer on the network by using port scanning and zone transfers.
Identify the OS the computer is using by conducting port scanning and enumeration.
Identify via enumeration any logon accounts and passwords configured on the computer.
Learn the names of shared folders by using enumeration.
Identify services running on the computer.
Figure 8.4
Viewing an OpenVAS scan report on a Linux computer
Courtesy Course Technology/Cengage Learning
The following example shows OpenVAS enumerating a Linux computer. Figure 8.4 shows the OpenVAS report after a Linux computer with the IP address 192.168.1.102 has been scanned. (The rhel in the left pane indicates a Red Hat Enterprise Linux 5.3 system.)
In the left pane of Figure 8.4, note that OpenVAS discovered 44 high-risk vulnerabilities, 15 medium-risk vulnerabilities, and 107 low-risk vulnerabilities. After you select the target system name rhel5 and expand the generated report by clicking the right arrow and then the Report tab on the right, you can expand each vulnerability category (such as general/tcp, ssh, and so forth) to see more detailed information.
Figure 8.5 shows details of a security warning when you expand the netbios-ns (137/ udp) item in the left pane. OpenVAS has revealed that the Linux computer is a Samba server and was able to enumerate the server’s NetBIOS names—so far, not exactly damaging information, but certainly information that attackers can use. You can see why understanding Samba is important and how a security professional’s knowledge can help prevent possible attacks. Beginning security testers might be surprised to see references to NetBIOS on a Linux computer unless they understand the important role that Samba plays.
Figure 8.5
Viewing security warning details
Courtesy Course Technology/Cengage Learning
With 44 high-risk vulnerabilities, there’s enough information in this one scan to take up an entire chapter, but take a look at another figure to see how you can use Open-VAS for security testing. Figure 8.6 shows that OpenVAS discovered a critical Firefox vulnerability.
Many of the vulnerabilities OpenVAS has discovered allow running remote code, which means attackers could gain complete access to the system. In Figure 8.7, Open-VAS found that the Linux computer runs a vulnerable version of the ISC DHCP client, which is susceptible to a buffer overflow attack. If you research the Internet for this vulnerability, you’ll find that exploit code for this vulnerability has been published. If this system is a workstation in the comptroller’s office of a Fortune 1000 company, for example, this vulnerability represents a serious risk.
Figure 8.6
OpenVAS revealing a security hole resulting from a Firefox vulnerability
Courtesy Course Technology/Cengage Learning
Figure 8.7
OpenVAS revealing a security hole resulting from a DHCP client vulnerability
Courtesy Course Technology/Cengage Learning
Activity 8.3: Discovering Exploits for Linux Systems
Time Required: 20 minutes
Objective: Research the Internet to discover Linux exploits.
Description: In this activity, you visit a Web site listing exploits you can use to attack different OSs. As a security tester, you should be aware of the resources available to both security testers and attackers.
1. If necessary, boot your computer into Linux with the BackTrack files. Start a Web browser and go to www.securityfocus.com.
2. On the Security Focus home page, type wireshark in the search text box at the upper right and press Enter.
3. Review some of the documents in the search results. Click the discussion, exploit, and solution tabs in each document to find more information. In which versions of Wireshark are vulnerabilities reported? Find at least one vulnerability for which an exploit or proof of concept (code used to demonstrate the vulnerability) has been published and included for download from the Security Focus Web site.
4. To determine the version of Wireshark running on your computer, open a Konsole shell, and then type wireshark and press Enter to start Wireshark.
5. In the Wireshark Network Analyzer window, click Help, About Wireshark from the menu. What version of Wireshark is running on your system?
6. Would the exploit you found in Step 3 work on your system?
7. Close the Wireshark Network Analyzer window and the Konsole shell, but leave your Web browser open for the next activity.
Checking for Trojan Programs
One method of attacking networks remotely is installing Trojan programs that record keystrokes and other processes without users’ knowledge. Trojan programs can be installed after users click an attachment to an e-mail, or users might download a file from the Internet thinking it’s a patch or a security fix for the OS they’re running. Because the Web server logs the IP address of all visitors, when users download a file from the Internet, attackers then know the IP address of the person who downloaded the Trojan. When a Trojan is installed on a computer, it advertises information it finds to a specific port, so the attacker needs to monitor or connect to that port to gather the information. Most Trojan programs perform one or more of the following functions:
Allow remote administration of the attacked system
Create a file server (FTP) on the attacked computer so that files can be loaded and downloaded without the user’s knowledge
Steal passwords from the attacked system and e-mail them to the attacker
Log all keystrokes a user enters and e-mail the results to the attacker or store them in a hidden file the attacker can access remotely
Linux Trojan programs are sometimes disguised as legitimate programs, such as df or tar, but contain program code that can wipe out file systems on a Linux computer. Trojan programs are more difficult to detect today because programmers develop them to make legitimate calls on outbound ports that an IDS or a firewall wouldn’t detect. Because the traffic generated is normal network traffic, it’s difficult to detect. For example, a Trojan program called Sheepshank makes HTTP GET requests over port 80. There’s certainly nothing strange about these requests occurring on a network. The Web server could then be configured to issue commands that are carried out on a Linux computer. The HTTP traffic appears to be normal network traffic, but the commands sent from the Web server could contain other commands requesting that the attacked computer download or copy sensitive files to a remote Web server. Some recent Trojan programs are controlled by encoded commands that attackers post on social networking Web sites. To someone monitoring network traffic coming from these infected systems, it might look like a normal user browsing through Facebook or Twitter, for example.
Protecting Linux computers against Trojan programs that IT professionals have already identified is easier. For example, the Linux.Backdoor.Kaiten Trojan program logs on to an Internet Relay Chat (IRC) site automatically and waits for commands from the attacker (controller). Linux antivirus software from McAfee, Sophos, and Symantec can detect this backdoor Trojan, however.
Even more dangerous are rootkits containing Trojan binary programs ready to be installed by an intruder who has gained root access to a system. Attackers can then hide the tools they use to perform further attacks on the system and have access to backdoor programs. A common Linux rootkit is Linux Rootkit 5 (LRK5), but mal-ware coders create other rootkits almost daily. When a rootkit is installed, legitimate commands are replaced with Trojan programs. For example, if the LRK5 rootkit is installed on a Linux computer, entering the Trojaned killall command allows the attacker’s processes to continue running, even though the Linux administrator thinks all processes were killed. The ls command doesn’t show files the attacker uses, and the netstat command doesn’t show suspicious network connections the attacker makes. So everything looks normal to Linux administrators because they’re using commands that have been Trojaned.
Activity 8.4: Using Tools to Find Linux Rootkits
Time Required: 15 minutes
Objective: Learn how to find Linux rootkits on the Internet and use a rootkit-checking program.
Description: Attackers can locate rootkits for many Linux platforms easily. In this activity, you visit the www.packetstormsecurity.org Web site, which has thousands of tools and exploits that attackers or security professionals can use. You also run a rootkit detection program included with BackTrack to find rootkits running on your system.
1. If necessary, boot your computer into Linux with the BackTrack files, and start a Web browser. Go to www.packetstormsecurity.org.
2. On the home page, point to search in the navigation bar, type rootkit in the text box that’s displayed, and press Enter. At the bottom of the page, you’ll see that hundreds of results were returned for this search.
3. Look through the list for Linux Rootkit 5. The description shows some Linux commands that are Trojaned when using this rootkit. List five of these commands.
4. Open a Konsole shell, and then type chkrootkit and press Enter to check for rootkits on your system. Do you recognize any of the Linux commands you wrote down in Step 3?
5. Log off the BackTrack session.
Note
As a security tester, you should check Linux systems periodically for installed rootkits.
More Countermeasures Against Linux Attacks
You’ve learned about some defenses against Linux vulnerabilities, and in this section, you learn about additional countermeasures for protecting a Linux system, especially from remote attacks. The most critical tasks are training users, keeping up on kernel releases and security updates, and configuring systems to improve security. Having a handle on these tasks is an essential start to protecting any network.
User Awareness Training
Making it difficult for social engineers to get information from employees is the best place to start protecting Linux systems from remote attacks. Tell users that no information should be given to outsiders, no matter how harmless the information might seem. Inform them that if attackers know what OS the company is running, they can use that information to conduct network attacks. Make users aware that many exploits can be downloaded from Web sites, and emphasize that knowing which OS is running makes it easier for attackers to select an exploit.
Teach users to be suspicious of people asking questions about the systems they’re using and to verify that they’re talking to someone claiming to be from the IT Department. Asking for a phone number to call back is a good way to ensure that the person does work for the same company. A 30-minute training session on security procedures can alert users to how easily outsiders can compromise systems and learn proprietary information.
Keeping Current
Software vendors are in a neverending battle to address vulnerabilities that attackers discover. As soon as a bug or vulnerability is discovered and posted on the Internet, OS vendors usually notify customers of upgrades or patches. Installing these fixes promptly is essential to protect your system.
Most Linux distributions now have warning methods for informing users when they’re running outdated versions. These warnings in the latest versions of Fedora and Ubuntu Linux are hard to ignore. Figure 8.8 shows the warning that’s displayed when a user logs on to a Fedora 10 Linux system that isn’t current.
Secure Configuration
Many methods and tools can be used to configure a Linux system to help prevent intrusions. Vulnerability scanners not only detect missing patches, but also help identify when a system is configured poorly. You should use built-in Linux tools, too. Security Enhanced Linux (SELinux), a National Security Agency (NSA) project, is now built into many of the main Linux distributions. SELinux contains several features and modules that use Mandatory Access Control (MAC), an OS security mechanism that enforces access rules based on privileges for interactions between processes, files, and users. If an intrusion happens on a system running SELinux, it’s less likely the intruder will be able to take complete control of the system. Classes from enterprise Linux vendors, such as Novell or Red Hat, cover use of this tool, and you can find more information at www.nsa.gov/research/selinux or by searching for SELinux on any Linux distribution Web site.
Figure 8.8
The Fedora 10 security updates warning
Courtesy Course Technology/Cengage Learning
One of the best ways to measure and report objectively on how an OS is secured is to use the free benchmark tools provided by the Center for Internet Security (CIS, www.cisecurity.org/benchmarks.html). These benchmarks are available for many versions of *nix and Windows. When you take the time to work through securing a Linux OS by following recommendations in the CIS benchmark tool, your knowledge of Linux security, and Linux in general, will improve.
Finally, a commercial tool worth mentioning is Security Blanket from Trusted Computer Solutions (www.trustedcs.com). You install this program on Red Hat, CentOS, or Solaris *nix systems to tighten the system’s security configuration by using templates. If your client is required to follow certain security policies, Security Blanket can secure systems quickly and save *nix system administrators from hours of manual configuration work. Security Blanket can be described as the *nix equivalent of using Windows group policies.
CHAPTER SUMMARY
Default installations of Windows OSs can contain serious vulnerabilities that attackers exploit. The CVE Web site is a good place to start when checking for Windows vulnerabilities.
Vulnerabilities in Windows file systems include lack of ACL support in FAT and risk of malicious ADSs in NTFS.
Other Windows vulnerabilities involve RPC, an interprocess communication mechanism that allows a program running on one host to run code on a remote host; NetBIOS, which is still used for backward compatibility; and SMB, which is also still used for backward compatibility and contains a vulnerability that enables attackers to intercept SMB traffic and collect usernames and password hashes.
In Windows, null sessions and default installations can leave passwords blank and resources unprotected, causing major problems.
Many Windows services leave systems vulnerable to attack, especially Web services and IIS in particular. The IIS Lockdown Wizard is available for locking down IIS versions 4.0 and 5.0, but clients should be encouraged to upgrade to the most recent IIS version.
Microsoft SQL Server has a critical SQL vulnerability called a null SA password that enables remote users to gain System Administrator (SA) access through the SA account on the server.
Buffer overflow attacks can allow attackers to run arbitrary code.
Users represent a major security vulnerability, so creating a comprehensive password policy and having user awareness training programs are essential.
Many tools are available for discovering vulnerabilities in Windows systems, such as MBSA. Learning to use more than one tool is essential.
Some steps you can recommend to secure systems include keeping systems updated with the most current patches and updates, running antivirus tools, enabling logging and reviewing logs regularly, disabling unused or unneeded services, and filtering out unnecessary ports.
Vulnerabilities of the Linux OS can be discovered with security tools, such as OpenVAS, and at the CVE Web site.
To address the issue of interoperability, a group of programmers created Samba as an open-source implementation of CIFS.
Tools such as chkrootkit can detect rootkits installed on Linux systems.
Built-in Linux tools, such as SELinux, are available for configuring systems securely. In addition, free benchmark tools are available from the Center for Internet Security, and commercial tools with templates can be used to tighten security configurations quickly and easily.