Systems for Searching for Configuration Vulnerabilities
As shown in Fig. 6.2, security analyzers in general, and configuration vulnerability scanners in particular, can function at all levels of the information infrastructure, i.e., at the network level, operating-system level, database level and application-software level.
The most popular systems in this class are security scanners for network services and protocols. This is chiefly due to the fact that the most popular protocols are universal and they support open standards. Thus, overall usage and open information on such protocol stacks as TCP/IP or SMB/NetBIOS enable the efficient checking of the security of the information system running within a specified network environment independently from the software running at higher levels.
Operating-system security scanners are the second most popular security scanners. This is a result of the fact that some operating systems are rather common and universal (this relates to both UNIX and Windows NT-based operating systems). However, since each manufacturer introduces some custom features into each release of the OS (the large variety of UNIX clones illustrates this point), OS-security analyzers usually investigate parameters characteristic to the whole family of the operating system. System-specific characteristics can not always be taken into account.
Security scanners for DBMS and application software are currently less numerous than is desirable. At the time of writing, these solutions existed only for the most popular application software, including Web browsers (Netscape Navigator, Microsoft Internet Explorer), DBMS systems (Microsoft SQL Server, Sybase Adaptive Server), and so on.
When analyzing security, vulnerability scanners use two strategies. The first - passive - is implemented at the level of operating system, DBMS and application software. It implies an analysis of configuration files and system registry for incorrect parameters, scanning password files for the presence of the passwords that can be easily guessed, and the investigation of other system objects to detect security policy violations. The second - active - strategy is mainly implemented at the network level and allows the reproduction of the most common attack scenarios and the analysis of the system's response.
Experience has shown that the most popular of these are configuration-vulnerability analyzers (implementation-vulnerability scanners are next in terms of popularity). This is due to the fact that the end user deals with this stage of the life cycle of various software and hardware products. Because of this, I will cover the systems in this class in more detail.
Network-Level Security Analyzers
Interaction between users in any network is based on network protocols and services that determine the procedure for information exchange between two or more hosts. In early 1970s, when most network protocols and services were emerging, developers practically ignored security requirements. Because of this, reports on new vulnerabilities detected in various implementations of these components appear constantly. Consequently, it is necessary to constantly check the security of all network protocols and services used in a corporate network.
Security analyzers perform a series of remote tests to detect vulnerabilities. These tests are similar to the methods used by intruders when implementing attacks on corporate networks. Scanning begins with obtaining preliminary information on the system being tested, including allowed protocols, open ports, and OS version. Quite often these tests include the simulation of an intrusion using the most common attack types (such as brute force, for example).
Network-level security scanners are not limited to testing the possibility of breaking into a corporate network from public networks such as Internet. These tools are just as effective when used to analyze specific segments or hosts within the organization's internal network. Network-level security scanners can identify an application for evaluating the security level of the organization and controlling the efficiency of network hardware and software configuration. These two fields of applications are the most common for security analyzers. However, other applications can be found. For example, external auditing or consulting companies can use security scanners to investigate their customer's networks. Besides this, there are other interesting possibilities, such as the testing and certification of specific software and hardware products. This approach is rather popular when various test labs evaluate the quality of network equipment, firewalls, etc.
Currently, there are more than 100 programs available that automate the procedure of detecting vulnerabilities in network protocols and services. Some tools are oriented towards detecting a wide range of different vulnerabilities, while others are intended to detect specific vulnerability categories. For example, Internet Scanner, which is one of the most popular products of this type, detects more than 1,300 different vulnerabilities belonging to a range of categories: Denial of Service, Brute force, FTP, LDAP, SNMP, RPC, NIS, NFS, DNS etc. Whisker, on the other hand, was designed specifically for scanning web servers and to detect vulnerable CGI scripts [Shipley1-00].
The first network-level security scanners appeared in early 1990s, at the beginning of the period when TCP/IP-based networks became widespread. The most popular among them is SATAN (Security Administrator Tool for Analyzing Networks), the free tool released on April 5, 1995, by two professionals in the field of information security, Wietse Venema and Dan Farmer [Freiss1-98]. Among other similar tools of note are the Internet Security Scanner (later renamed into Internet Scanner), Nmap and Queso.
Network-level security scanners analyze for vulnerabilities in network services and protocols existing in system and application software as well as in network hardware and software including web servers, FTP servers, mail servers, firewalls, browsers, routers and switches.
A typical scheme for network-level security-scanner implementation (here, the example is Internet Scanner) is shown in Fig. 6.6.
Fig. 6.6. Network-level security scanner
Advantages and drawbacks of systems belonging to this class are outlined in Table 6.4.
 |
| Advantages | Drawbacks |
|---|---|
| | |
| Detects security gaps for a wide range of different platforms and systems supporting unified network protocols. | Analyzers and scanners of this type do not take into account vulnerabilities above the network level. Quite often, they are less precise than security scanners running at the OS, DBMS or application level. |
| Independence from the platforms and systems used within the organization network. | Can negatively impact network performance. |
| Easy to use from the organizational point of view, since agents are not present at the hosts being scanned. | If used incorrectly, these systems can disrupt the function of some network hosts. |
| Incomplete coverage of the existing protocols. For example, only a limited number of programs support IPX. | |
|
OS-Level Security Scanners
Tools of this class are designed to check operating-system settings that have a bearing on security. Such settings include user-account settings, such as password requirements (minimum lengths, and other policy settings, such as minimum and maximum age), permission for users to access critical system files, vulnerable system and configuration files, system registry parameters, and patches installed. The methods for the application of OS-level security scanners are similar to strategies for using network-level security scanners utilized by security departments, auditing companies and the like.
In contrast to network-level security scanners that perform external scanning, these systems scan the internal components of the system being analyzed. This means that they simulate attacks by intruders who have already penetrated the first (network) line of defense. For this purpose, it is necessary to install a special agent in each host to be scanned. This agent will run all required system checks. Beside detecting vulnerabilities and providing recommendations for the elimination of detected security gaps, some OS-level security scanners (for example, System Scanner) allow the automatic elimination of at least part of the problem automatically or the correction of system parameters that do not satisfy security policy requirements.
As already mentioned, OS-level security scanners are less numerous than network-level security scanners. Among the best known systems of this class is the COPS (Computerized Oracle and Password System) system developed by Dan Farmer (one of the authors of the above-mentioned SATAN system) in cooperation with Eugene Spafford, the director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security) and the founder and director of the COAST Laboratory. Another well-known system in this class is System Scanner, from Internet Security Systems, Inc.
The main advantages and drawbacks of systems in this class are listed in Table 6.5.
|
| Advantages | Drawbacks |
|---|---|
| | |
| Produce an accurate, host-specific list of vulnerabilities. | Analysis methods are platform-dependent. Thus, they require very precise configuration for each host type used in organization. |
| Detects vulnerabilities omitted at the stage of network-level security analysis. | Operation and updates often require much more effort than network-level analysis. |
| Not applicable for equipment that does not run an operating system. | |
| Not applicable for network hardware. | |
|
DBMS-Level Security Scanners
Initially, security scanners were developed only for network and operating system levels. Currently, these systems are quite numerous. This is largely because popular network protocols and operating systems are not numerous enough to allow the efficient development of tools for analyzing their vulnerabilities. The necessity of security scanners for DBMS has become strong recently, as companies have began to use databases to retrieve information via public networks.
The developers of these tools have taken into account all of the advantages and drawbacks of network and OS-level security scanners. As a result, DBMS security scanners implement most of the features characteristic of the previous two classes. In particular, they are able to analyze DBMS server security both locally and remotely. Database Scanner, SFProtect and SQL<> Secure Policy are a few examples of these tools.
Application-Level Security Scanners
Despite the fact that tools of this class are absolutely necessary, they have only begun to appear recently. Both network- and OS-level security scanners implement functional abilities for analyzing application security. However, these functional abilities are quite limited and cover only the most common application software. For example, System Scanner provides checks for Microsoft BackOffice, Microsoft Office and Symantec antiviral systems.
Working Mechanisms
There are two basic mechanisms that the scanner uses to check for vulnerabilities - passive and active testing. These are also known as scanning and probing, respectively.
Scanning - a passive analysis mechanism, which the scanner uses to attempt to detect vulnerability on the basis of implicit indications, without actually proving their presence. This method is the fastest and the simplest to implement. In relation to Cisco, the scanning process identifies open ports found on each network device and assembles banners detected when scanning each port. Each banner is then compared to the table of rules for detecting network devices, operating systems and potential vulnerabilities. Based on the results of this comparison, the system then identifies a vulnerability. Checking access rights to the password file, which can indicate cases of information-system vulnerability, is another example of passive scanning.
Probing - an active analysis mechanism, which enables you to determine whether a vulnerability is present on the host being analyzed. Probing operates by simulating an attack to exploit the vulnerability being checked. This method is slower than scanning, but it is also almost always more reliable. According to Cisco, this method uses information collected during scanning ("logical output") for a detailed analysis of each network device. It also employs common methods of attack implementation to confirm the supposed vulnerabilities and detect other points of weakness that can not be detected using passive methods, for example, vulnerability to DoS attacks. Another example of active testing is are password-system checks that simulate brute-force attacks
Beside classifying security analyzers by method used (active or passive), these systems are able to perform both local and remote tests. Local tests run at the same host where the security scanner agent is installed (for example, System Scanner Agent), while remote methods are intended for remote hosts (such as Internet Scanner) [Polk1-92].
In practice, the above-listed mechanisms are based on the methods that will be described in the following few sections.
Banner Checking
This mechanism, which is usually utilized by network-level security scanners, involves a series of scans enabling you to determine whether vulnerabilities exist, based on the banner information in the response returned to a scanner request. A typical example of this type of examination is the analysis of Sendmail or FTP-server banners to determine their version number. Based on this information, it is possible to determine whether vulnerability exists. This method of checking for vulnerabilities is the fastest and the simplest to implement. However, this simplicity can also conceal a number of problems.
The efficiency of banner check is problematic. First of all, it is possible to modify the banner text by deleting the version number or other information used by the scanner. Although cases of banner replacement are relatively rate, this danger should not be ignored. This is especially true if you have security specialists who understand the danger of using default banners. Secondly, version information contained in the response banner often does not mean the software is vulnerable. This relates to software that is supplied with the source code (for example, the GNU project). You can eliminate vulnerabilities by modifying the source code, but forget about modifying the version-number information contained in the banner. Finally, elimination of vulnerability in one version does not automatically mean that this vulnerability will be eliminated in future releases. The mechanism under consideration is the first and the most important step in the course of performing a network scan. It does not result in the disruption of the operations of the network or its specific hosts. However, do not forget that the administrator can modify the text of banners returned in response to external requests.
Active Probing Checks
The active probing-check mechanism is also related to the scanning methods. However, the checks that it implements are based on a comparison of the digital fingerprint of the software to the digital fingerprint of the known vulnerability, rather than on a comparison of the software version information in the banners. This technique is similar to the one used by antiviral systems, which compare the fragments of the software being scanned to the signatures of the known viruses stored in a special signature database. Checks for file size and date implemented in the OS-level scanners are another variant of this method.
A specialized database (in Cisco terms, it is known as the network-security database) contains information on the known vulnerabilities and methods of exploiting these vulnerabilities to implement attacks. This information is complemented by data on the methods of eliminating these vulnerabilities, which enables you to decrease the risk of a successful attack in the event that such vulnerabilities are detected. Quite often, this database is used both by the security scanner and by the intrusion detection system. Both Cisco and ISS use this approach. This method is also relatively fast, but is still more difficult and time-consuming to implement than the banner-checking method.
Exploit Checking
These methods are classified as probing methods and are based on exploiting various bugs in the software. Some vulnerabilities, which are difficult to detect in the source code, manifest themselves clearly in the executable code. Similarly, there are vulnerabilities that never manifest themselves until someone tries to exploit them. To perform this kind of check, real attacks are attempted against the suspected service or host. Banner checks only perform network "reconnaissance," while the exploit-check method enables you to simulate real attacks, instead of using banner information, thus detecting vulnerabilities more reliably (but at the same time, it runs slower). Attack simulation is a more reliable method of security analysis than banner checking, and is usually more reliable than active probing checks.
Sometimes, however, situations arise when exploit checks can not be implemented. These situations can be classified in two categories: situations when the test results in a DoS attack on the host or network being analyzed, and situations when vulnerability can not be detected by means of an attack simulation.
As a matter of fact, many security problems can not be detected without locking or even crashing the service or computer during the scan process. Therefore, in some cases, an exploit check is undesirable (for example, to analyze critical hosts for a business), because this might result in significant expenses and extended downtime for the corporate network components crashed by the test attack. If this is the case, it is appropriate to use other checking methods, such as active probing or banner checking.
Some vulnerabilities (for example, vulnerability to packet storm attacks) can not be detected without the danger of causing a failure of the service or computer being tested. In this case, the developers lock such checks by default and provide the user with the choice of enabling such tests optionally. For example, this approach is implemented in the CyberCop Scanner and Internet Scanner systems. In Internet Scanner, such checks are bundled within a separate category named Denial of Service. When the user enables any of the checks belonging to this category, Internet Scanner displays the warning message: "WARNING: These checks may crash or reboot scanned hosts."
Configuration Checks
This kind of check can be performed both by local and remote security scanners. However, they are most often performed locally. Security scanners use these checks to test various configuration files (for example, inetd.conf), startup files (such as autoexec.bat or config.sys), system registry and so on.
Security-Scanner Architecture
All security scanners can be classified in several categories. Security scanners belonging to the first category run remote checks from a single host (Fig. 6.7). SATAN is a typical example of such systems
Fig. 6.7. Security-scanner architecture (type 1)
Systems of the second type are based on another principle. All hosts are scanned from the so-called security-scanner server, where all templates and results of previous scanning sessions are stored. Checks are run from the console, which is installed on a separate computer (Fig. 6.8). Nessus and Internet Scanner are examples of products based on this type of architecture.
Fig. 6.8. Security-scanner architecture (type 2)
The CyberCop Scanner system utilizes an interesting architecture. As well as the main component of the security scanner, which implements the checks, there is a so-called "sentry" component, responsible for checking the results of the scanning (Fig. 6.9). Using this component, the system investigates the security level of firewalls and intrusion detection systems located between the main and auxiliary components of the security scanner.
Fig. 6.9. Security-scanner architecture (type 3)
Host-level security scanners are built using a somewhat different scheme. System agents responsible for performing the checks specified from the console are installed in the most critical points of the corporate network. All management tasks are performed from the centralized console, to which all alerts are sent in cases where vulnerabilities are detected (Fig. 6.10). System Scanner is a typical example of a product that uses this scheme.
Fig. 6.10. Security-scanner architecture (type 4)
Introducing just another checking level (Fig. 6.11) can extend the scheme explained above. The Enterprise Security Manager from Symantec Corporation is an example of a product that utilizes this architecture.
Fig. 6.11. Security-scanner architecture (type 5)
EAN: 2147483647
Pages: 152