Network Vulnerability Assessments: The Practical Examination of Your System

 < Day Day Up > 



Network vulnerability assessment is a hands-on approach in ascertaining your system's obvious vulnerabilities and their locations. There are many risks that are associated with these types of audits that go largely ignored by senior managers.

Experience Note 

An auditor was examining the business' network software development process for compliance to the company's policy and procedures. She discovered the programmers and engineers were not observing any of the policy requirements and were basically approaching their development phases in a haphazard fashion. She detailed her findings in a preliminary report to senior managers who told her that they had evolved past the SDLC and other quality methods. Instead, they were writing their code, installing it, and using the network vulnerability assessment as a quality control to determine any weaknesses existing in their software. Her audit report findings were lengthy and specific.

In conducting network and other types of practical vulnerability assessments, it is paramount that auditors adopt a holistic view of auditing. Auditing is the process by which prohibited, abusive, and irregular activities are found and reported. If a concerted auditing effort is adopted, the entire system consisting of the three pillars of human resources, data and physical facilities will be measured as part of risk management and operational efficiency.

Vulnerability assessments only measure those vulnerabilities that are within the scope of the rules of engagement, the knowledge of the auditors, and those system vulnerabilities that are present at the time of the assessment. It should be made clear that network vulnerability assessments must be considered as part of the whole audit picture. They are not a substitute for poor systems design and management.

Network vulnerability assessments are the part of the audit program whose purpose is the practical identification of system vulnerabilities. If vulnerabilities are found, and they will be found, they will be reported as findings, accompanied by recommendations in the audit report. It is a fair statement that you cannot repair system weaknesses, unless you locate them first. If during a comprehensive audit, senior managers fail to locate and repair system vulnerabilities, it is a safe bet that attackers inside and outside the organization will find and exploit them. The general goals and objectives of system vulnerability assessments are as follows:

  • Measure levels of system risks.

  • Ascertain practical compliance with organization's policies and procedures. (This usually involves a high-degree of employee and senior manager embarrassment.)

  • System vulnerability assessments comprise an important part of the comprehensive auditing effort and clearly demonstrate professional due diligence.

Audit team members should be carefully selected for their experience, people skills, communications skills, good judgment, system knowledge, and knowledge of software and intrusion and attacker tactics. It is recommended they have a good knowledge of programming in languages such as C, C++, Java, and PERL. Programming skills and network knowledge enable auditors to review open source tools, fix or modify them, and write their own programs, if necessary. It is worth remembering that running automated tools without an understanding of the underlying protocols and issues is dangerous and generally will not provide sufficient insight when documenting findings in the audit report. Skills such as persuasive sales are a valuable commodity if the audit team is going to engage in social engineering. Often the question is asked if this is "white-hat," "black-hat," or "gray-hat" system attacking.

Experience Note 

Personally, the author thinks the "hat" business is a bit of nonsense. Some organizations are caught up in the idea of hiring individuals of questionable character, but who have a great deal of skill. Many are convicted felons. Think of this example, "Would you hire a professional thief to make a security survey of your business?" Prudent business managers should engage professionals of known abilities with impeccable references, not soon-to-be indicted attackers.

Questions arise whether organizations should outsource system vulnerability assessments or develop the skills internally. Correct answers are not easily decided as there are advantages and disadvantages to both sides. There is some degree of risk in outsourcing vulnerability assessments unless a significant amount of research is done.

Experience Note 

There are many outside "system security consultants" that are reformed attackers. Some have even spent time in prison for their criminal behavior, while others have been defendants in lawsuits centered in their unlawful behavior.

So before contracting outside vulnerability auditors, it is prudent to discuss their backgrounds, experience, bonding, the length of time they have been in business, and references. Demand they provide a long list of satisfied clients and a few that were not so satisfied. Contracts should be carefully crafted enumerating liabilities and responsibilities.

It is strongly recommended that several lawyers, having experience with services of this nature, review the details of the contract before being finalized.

It is the practice of most consultants to spend an inordinate amount of time keeping skills current to explore and exploit system weaknesses. For some, their skills' improvement and bragging rights are something that borders on obsession. On their own time, they explore system weaknesses to the exclusion of other pursuits. Many consultants can tell you about successfully gaining root access to systems that were considered impregnable by its owners. Regardless, if the decision is made to use contractors, your sensitive assets are subject to capture by the outsiders. You are giving them the key to the business' crown jewels.

Experience Note 

It is quite likely that today's system audit consultant will not be employed by the firm for more than a short time. She knows your system's vulnerabilities when she decides to exploit them.

If the organization decides to develop inside talents, there are many suitable training courses available that can provide the skills necessary to perform a respectable system vulnerability assessment. Training of this nature is valuable and can be used as part of an employee development program. It is important to note that systems auditing skills are a serious commitment in that they require constant upgrading and expansion as new technologies emerge and new weaknesses are announced.

Rules of Engagement

Rules of engagement govern the level and extent of vulnerability assessment efforts. Develop a written agreement between the audit manager and appropriate levels of senior management, as the vulnerability assessment process is extremely invasive. In this statement the questions of who, what, when, where, and how should be thoroughly, but briefly addressed. For example, the purpose of this vulnerability assessment will be to test the effectiveness of procedures ensuring that attackers cannot obtain unauthorized access to the organization's critical assets of human resources, data, and physical resources.

Assessment procedures define the methods and means by which the various evaluation events will take place. These procedures can be expressed in the following areas:

  • Assessment standing. Determine and define when the assessment will begin, the scope of the assessment, and when the assessment will end.

  • Vantage point. What will be the vantage point of the assessment? Should the auditors consider themselves as outside the organization, or inside the organization? Obviously, the vantage point will affect the assessment objectives and the time involved. In the insider vantage point, the auditors are provided as much pertinent information as possible. For example, auditors will have the source code for CGI scripts, network topology and architecture, IP addresses, etc. With this degree of information, the auditors may test the system more thoroughly looking for subtle flaws that might otherwise escape notice. Besides, this approach saves time and resources.

On the other hand, outsider testing provides little, if any, relevant system information to the auditors in the anticipation their stance is that of an outside attacker. This approach requires a great deal of time and effort to complete an accurate and meaningful assessment. Proponents of this type of assessment claim it provides a realistic approach to system evaluation in light of the fact outside attackers will not have insider information. The fact of the matter is with the large number of attacks attempting to gain access, or extinguish services, this approach requires a significant time investment, and it is likely that new vulnerabilities will be discovered before they can be tested against the system.

There are two more vulnerability modes, passive and aggressive. Passive testing means the auditor can take only a distant view, essentially a "looking glass" approach. This is a safe way of testing, but it is not going to provide the type of detail that should be narrated in the "findings" section of an audit report. The auditor discovers a system's vulnerability and reports findings without further exploration and system exploitation. Aggressive testing takes the approach of exploiting all discovered vulnerabilities and exploring just how far the auditor can penetrate the system before coming to an end.

How far should the auditor pursue an exploit? The answer should be explicitly detailed in the rules of engagement. However, it is recommended that the auditor pursue a vulnerability to the extent possible without doing damage to the system. Only in this fashion can the risk potential be measured and reported. It is further recommended that in a system vulnerability assessment, the procedure should be to locate a weakness, exploit it, and leverage that weakness to gain wider access to the target system.

Social Engineering

Social engineering is the tactic of having contact with the organization or persons associated with the organization and through ruse, pretext, or misdirection, attempt to gain information that would facilitate an unauthorized intrusion. It is possibly the least most popular means of auditing a system and must be thoroughly addressed as a tenet in the rules of engagement for the vulnerability assessment. Social engineering tests employees and their training.

Experience Note 

When organizations suffer a successful social engineering attack, it makes banner headlines. Employee training and compliance auditing will help in avoiding these disasters.

Auditors and senior managers must be mindful that attackers are employing these tactics, so using them in a measured fashion has great benefits in probing vulnerabilities. In essence, social engineering involves getting employees to voluntarily surrender information that can be used to gain an advantage that would not be available without it. It can be as easy as a telephone conversation, going through someone's wastepaper basket, or using an unprotected workstation.

The primary tool of the social engineer is the telephone. Typically, a talented auditor can obtain more critical information and cause greater damage by working making a few telephone calls than the best network attacker. Among the most common approaches are:

  • Posing as a member of the target organization's technical support staff

  • Playing the role of a disgruntled customer/user seeking a password change

  • Calling the technical support staff and enlisting their aid in getting a workstation connected to their network

  • Going through the waste paper baskets located in open office areas after work hours and before it is collected

  • Using unattended workstations or servers

  • Going through the trash collected by the maintenance staff

  • Going through the organization's dumpster (consider this a major undertaking and avoid unless deemed necessary)

  • Making copies of notes and other materials left out on desks after hours

Experience Note 

One of the most interesting, inventive, and legendary social engineering activities was the new maintenance employee who was seen posting small signs around an office area. These signs announced a new telephone number for the company's technical support unit. When one of the senior managers asked the employee who it was that requested he post the signs, she responded that she was new and did not know the person who asked. The manager did not follow it up any further. After about a week, the company's technical support staff sent an e-mail to their manager asking what happened to all their calls. They had not received a trouble call in several days. It was discovered that when calls were made to the "new" telephone number for the technical support unit, a recorded message stated that all agents were busy; and requested the caller to verify his identity with network logon name and password. It was discovered that the callers' network accounts had been accessed and sensitive information taken through terminals located inside the company during off-duty hours. Additionally, the organization had not verified the identity and background of the maintenance person.

If the rules of engagement permit, auditor's can use social engineering for gaining access to the company's systems. For example, an auditor, not previously introduced to the target organization arrives early at the organization and loiters near the entrance. When an employee passes security and enters the office space, the auditor, acting as a new employee, offers the excuse they are new and have forgotten their identification badge, and follows the employee inside. Or an auditor telephones the network administrator and misrepresents himself as a member of the management staff and asks the administrator for her e-mail account password to be reset. The administrator provides a one-time use password without verifying the caller's identity and the auditor accesses the manager's e-mail account. Should such tactics be allowed? If the audit is going to test the risk management training provided to the employees, the answer is yes. Regardless, the use of social engineering tests must be addressed in the rules of engagement. If auditors do not test the system's vulnerabilities, attackers will. Again, it is not a matter of if an attacker attempts this type of intrusion; it is only a matter of when.

Senior managers and auditors must arrive at a level of understanding of whether the employees are going to be advised of the system testing or not. If employees are aware of system testing, they will likely be on guard and on their best behavior. However, if the rules of engagement allow the auditors to fully explore and exploit if the system crashes due to an attack, the administrators can take appropriate action without panic. But, not advising employees has advantages, in that auditors will observe the true performance of how employees react to system attacks and how recovery efforts are brought to pass. Obviously, telling or not telling employees of the system assessment is a matter for careful consideration by senior managers with the matter fully documented in the rules of engagement. Safeguards are typically deployed in the event of electing not to notify employees to avoid having embarrassing calls made to law enforcement.

The last area of preparation includes the area of permission. Appropriate levels of permission must be obtained before conducting this type of system vulnerability assessment. This is an area of good judgment. Auditors must do a thorough job, but they cannot damage any critical assets in any fashion including employee morale. On the other hand, the more realistic these tests are, the more useful will be their results. Use good judgment in crafting the rules of engagement and obtaining the appropriate levels of permission.

IP Address Confirmation

In this step, business functions must be mapped to physical system and information about how the systems operate must be recorded. It is a wise audit step to obtain a list of the organization's IP addresses, to whom they are assigned, and where they are assigned, including the type of device. DNS name resolution can be used, but if something happens to the name server, or if the IP address resolution is incorrect, the actions taken by the auditors could be slowed or result in the wrong systems being audited.

Ownership of the IP addresses should verified and confirmed before beginning the assessment. A very simple, but effective tool for IP resolution having a host of other features is available from: www.samspade.org. This tool is very intuitive, easily configurable, and will automatically select the correct Internet registration authority reflecting IP address ownership. Confirming IP addresses is good audit practice and serves to verify whether the organization has accurately completed their asset inventory.

Assessment Safety

Although auditors will have the best intentions, it is a wise practice to have a safety protocol for those moments when adverse things happen. When auditors download freeware/shareware or purchase their tools, it is a wise procedure to scan these utilities for malware being present. It only takes a moment to update the antivirus software and scan the product for worms, viruses, and Trojans.

During the audit is not the time to experiment with a new tool. An audit tool should be carefully exercised to ensure the auditor has a thorough knowledge of its use before using it in an audit. Additionally, assessment tools should be updated, as new versions become available. Newer versions will likely address newly announced weaknesses that may be missed by older pieces of software.

Auditors should have emergency contact information for appropriate management levels for each of the sections they are evaluating. These contacts must be 24/7. It is the experience of most system auditors that if anything can go wrong, it will at the least opportune moment.

Experience Note 

Murphy's Law will be in full effect during every audit step; plan on it.

Auditors should document all their actions and information captured during the assessment. Notes should be recorded to a central file for each member of the audit team. Some auditors go so far as to enable keystroke logging on their workstations to record all their actions. Record all IP addresses and netmasks targeted by your scanner tools. It is important to note when your system's IP address changes at any time during the assessment. This will help you keep directed and on track when performing the assessment. Additionally, it will simplify configuring the scanning tools. Using the IP addresses from the organization's inventory will shorten the time scanning tools are run. In this fashion, auditors only have to cover the territory once. Auditors should document the start and stop times of their tools. These documents will comprise a section in the auditor's work papers and will be referenced in the audit report.

Discovering the Character of the Audit Target

As a general first step, auditors will research public source information about the audit target. One of the most logical steps is to look up the domain registration information of the audit target. There are many manual Web sites providing Internet domain registration. These are just a few:

  • www.arin.net

  • www.networksolutions.com

  • www.allwhois.com

Domain registration queries will provide information similar to the sample shown in Exhibit 12.

Exhibit 12: Domain Registration Queries

start example

Registrant

Interexample Online LLC (INTEREXAMPLE-DOM)

100 Broadway

New York, NY 10007

  • Netname: INTEREXAMPLE-BLK-0

  • Netblock: 197.123.123.0 - 197.000.254.0

  • Domain Name: INTEREXAMPLEONLINE.COM

Technical Contact

  • Bob Robertson

  • P.O. Box 1234

  • New York, NY 10007

  • Telephone: 212-555-0000

  • E-mail: <Brobertson@webhosting.com>

Administrative Contract

  • Alice Wincelowitz

  • Interexample Online LLC

  • 100 Broadway

  • New York, NY 10007

  • Telephone: 212-999-0000

  • E-mail: <AliWincelowitz@Interexampleonline.com>

Billing Contact

  • Alice Wincelowitz

  • Interexample Online LLC

  • 100 Broadway

  • New York, NY 10007

  • Telephone: 212-999-0000

  • E-mail: <AliWincelowitz@Interexampleonline.com>

NS1.INTEREXAMPLEONLINE.COM 197.123.123.1

NS2.INTEREXAMPLEONLINE.COM 197.123.123.2

Record last updated on 10-May-2003

Database last updated 1-June-2001

end example

Tools

This is a good place to discuss tools such as SamSpade, and the audit features they offer. Most of these tools offer similar features and prove to be invaluable during a vulnerability assessment. SamSpade provides a GUI (graphical user interface) that expedites its configuration. It runs on Windows 9X, ME, NT, and XP. As part of its functionality, it performs queries such as whois, ping, DNS Dig (Advanced DNS request and zone transfer), traceroute, finger, SMTP mail relay checking, and Web site crawling. Using SamSpade and similar tools are intuitive and self-explanatory so it would be a waste of time to fully describe their features and configuration. However, before using this tool, and others, auditors are cautioned to become familiar with their capabilities and risks. Additionally, all the tools listed below include very well written help files as part of their product (Exhibit 13).

Exhibit 13: SamSpade

start example

click to expand

end example

Similar tools are easily found on the Internet, caution is urged in making certain with whom you are doing business, make certain the tools come from reputable vendors and locations. Examples of similar tools may be located at www.ipswitch.com (WS-Ping ProPack) and www.nwpsw.com (NetScan Tools).

Attentive auditors review the domain registration and notice the technical contact is not located at the same address and telephone exchange as the target enterprise. Several conclusions may be drawn from this information.

The Web host is a contractor or the company that has its hosting facilities located outside its headquarters.

The response also gives some insight into the e-mail naming conventions for the target. This information could be useful if an attacker wanted to find e-mail addresses she could target.

In discovering more of the audit target, the auditor will look to the Internet for more information. Using such resources as www.google.com or www.hotbot.com will locate information about the target, its employees, and publicly available information. Google may also be used to query newsgroups for postings made by employees using the organization's domain name. This technique can be useful if employees are posting information about their company's vulnerabilities while using the organization's e-mail system.

Frequently, attackers publish the company's network vulnerabilities in newsgroups or chat rooms. Experienced auditors will query newsgroups and participate in chat rooms to determine if relevant system vulnerabilities are available.

Auditors often search public information areas such as the Securities Exchange Commission database known as EDGAR (www.sec.gov) for information about the target's filings. Two of the most informative filings are the 10K and 10Q. The form 10Q provides visibility into the company's activities in the last quarter, while the 10K is an annual filing describing the company's previous year. Reviewing these documents can provide information about recent mergers and acquisitions. It is possible the entities recently blended to form today's organization may allow the auditor to discover already documented vulnerabilities and permit unauthorized entries.

Additionally, SEC filings and posted annual company reports provide a wealth of information for the attacker. It is not unusual for attackers to collect personal information about owners and senior managers, including private e-mail addresses, residences, financial holdings, automobile ownership, marital status, social security numbers, credit histories, etc.

In the case of smaller organizations, auditors may purchase subscriptions to services that provide detailed information about individuals on a query-fee basis. If the rules of engagement allow this type of review, the type of information available about the target's senior management is almost limitless. These agencies collect information from magazine subscriptions, real estate transactions, driver's permits, professional organizations, clubs, and innocuous areas such as dog and cat licensing. Companies using this type of information collection are legitimate and are easily locatable on the Internet. Not all companies use legal means of information collection; so be wary and deal only with reputable agencies.

Auditors must be fully aware that collecting private information is sensitive, but if the auditor can find the information, so can those who intend harm. It should be within the rules of engagement to discover available information. Auditors must make appropriate recommendations as to the information disclosed by employees that could result in jeopardizing their safety. If a regulatory agency or law does not require disclosure of information, do not do it. Making it a matter of audit programs will ensure its compliance with policy and procedures.

Auditors should carefully document their public information discoveries in a detailed schedule as part of their final report. Making a printout and including it as part of the work papers is an accepted practice. This information will become very useful as the vulnerability assessment continues.

If the rules of engagement permit the auditor to travel where attackers venture, it would be wise to enter the world of chat. Downloading a shareware chat client from, www.mirc.com will provide the means to speak with others about their knowledge of the audit target's vulnerabilities. Using this vehicle requires a fair degree of skill and is not going to be valuable unless the auditor has used this communication medium previously. However in the hands of a skillful professional, chatters frequently know an organization's critical asset vulnerabilities and exploits.

Experience Note 

At a credit card clearinghouse, an auditor discovered several chat rooms and Web pages providing free scripts targeting the clearinghouse's Web site as well as open chats about the audit target's credit card network vulnerabilities. These scripts were designed to verify credit card information using the clearinghouse's computing facilities. When the auditor queried the persons chatting and the persons supporting the Web pages, it was discovered they were located virtually everywhere: Brazil, Russia, Philippines, Malaysia, and the United States. Auditors should not underestimate the value of chat rooms in determining an organization's vulnerabilities.

What Parts of the System Are Alive?

One of the most basic steps in a network vulnerability assessment is the port scan on a range of IP addresses and network blocks in order to ascertain which systems are alive and functioning. There are many tools available to perform this function:

  • For UNIX, go to http://packetstorm.securify.com/Exploit-code-archive/fping.tar.gz for the fping tool.

  • Nmap, which is probably one of the most useful vulnerability tools for UNIX platforms, is found at www.insecure.org/nmap.

  • A Windows version of Nmap may be found at www.eeye.com/html.research/tools/nmapNT.html. Instructions for tool use are located at the corresponding Web sites.

  • Another ping scanner known as SuperScan can be found at www.foundstone.com/rdlabs/proddesc/superscan.html, Exhibit 14.

    Exhibit 14: SuperScan

    start example

    click to expand

    end example

Ping scanning will provide an inventory of active targets. While Nmap and other tools will provide many types of port scanning results, it is suggested that the results of ping scans be used to determine which devices should be port scanned.

Ping scans usually produce results similar to the following example:

  [localhost] $ fping -f discov.txt  194.168.2.154 is alive  194.168.2.168 is alive  194.168.3.2 is alive  194,168,3,104 is alive  194.168.3.209 is alive 

With the ping scan completed, auditors may compare the results with the organization's policy and procedure documentation. If the inventory and the ping discovery do not match exactly, there are several possibilities:

  • There is a rogue piece of equipment located on the system waiting to be exploited.

  • There are IP addresses showing as assigned to a particular piece of equipment.

  • It is possible the IP address-related equipment is disabled, misplaced, or stolen.

If a security-conscious system's employee has disabled the ICMP (Internet Control Management Protocol) ping function, there are some additional tools and techniques that may be necessary for system discovery.

Typical TCP (Transmission Control Protocol) ports and UDP (User Datagram Protocol) ports are numbered from 0 to 65534. Ports that have services listening on them are known as sockets. Services that are installed and active can lead to systems vulnerabilities and exploits. Depending on the rules of engagement and the thoroughness of the audit, a port scan of all TCP and UDP ports could take several hours for each hardware device to be examined. However, if there is sufficient time, a thorough end-to-end review of ports is recommended as part of any thorough vulnerability assessment.

Using Nmap can provide many options relative to the fashion in which the port scan is conducted. Some of these options include:

  • Ping sweep

  • SYN Stealth

  • FIN Stealth

  • UDP Port Scan

  • Fast Scan

  • Host name

  • ICMP Ping

  • Range of Ports

  • Use Decoys

  • Get indentd Info

For a sample of Nmap output and results, see Exhibit 15 and Exhibit 16.

Exhibit 15: Sample Output of Nmap

start example

Port

State

Protocol

Service

TCP Scan

21

open

tcp

ftp

22

open

tcp

ssh

23

open

tcp

telnet

79

open

tcp

finger

111

open

tcp

sunrpc

UDP Scan

53

open

udp

domain

111

open

udp

sunrpc

123

udp

ntp

 

137

open

udp

netbios-ns

138

open

udp

netbios-dgm

177

open

udp

xdmcp

1024

open

udp

unknown

end example

Exhibit 16: Sample of Nmap Results

start example

click to expand

end example

Look at the scanner output and guess which port an attacker would choose to exploit. Consider it the vulnerability of choice. If the attacker cannot find a host with open ports, it is a simple matter to find another host on your target network, run a port scan, locate the active services, and exploit them. If there are unnecessary services listening on ports, it is a simple matter for the attacker to research possible methods to gain entry and make her move.

In addition to the scanners listed above, the auditor has available the netstat command as part of UNIX and Windows NT platforms. Getting help with netstat is as simple as obtaining a command line from DOS or UNIX and inputting netstat?; entering this command results in the display of netstat's switches and functions.

Exhibit 17 is an example of netstat's output.

Exhibit 17: C:\ netstat -na

start example

Proto

Local Address

Foreign Address

State

Active connections

TCP

0.0.0.0:80

0.0.0.0:0

LISTENING

TCP

0.0.0.0:139

0.0.0.0:0

LISTENING

TCP

0.0.0.0:445

0.0.0.0:0

LISTENING

end example

Using the netstat command is an expedient means to determine the listening services on a single workstation or server. This practice assumes a reasonable sample is being taken by the auditors. Using this method is recommended when conducting individual workstation or server audits. The netstat output should be printed using the printscreen option located on the keyboard and saved as part of the audit work papers.

Identifying Operating Systems

Nmap can also be used to identify an operating system by examining its response to nonstandard TCP/IP packets. Nmap has this capability as a feature, by simply adding -O option. The output is similar to the example in Exhibit 18.

Exhibit 18: Localhost #nmap -O -sS

start example

Starting nmap V. 2.2 by Fyodor <<fyodor@dhp.com>,www.insecure.org/nmap/) Host (192.166.201.0) seems to be a subnet broadcast address (returned 1extra pings). Interesting ports on Interexample.com (192.166.201.0):

Port

State

Protocol

Service


22

open

tcp

ssh

111

open

tcp

sunrpc

1025

open

tcp

unknown

TCP sequence prediction: Class = random positive increments

Remote operating system guess: Linux 2.1.2-2.1.22

end example

For a good reference for TCP stack fingerprinting, go to www.insecure.org/nmap/nmap-fingerprinting-article.html. Stack fingerprinting is not foolproof, but it is a valuable method to confirm that a specific operating system is present on a specific IP address. Stack fingerprinting results should be included in the comparison between the actual inventory results and those created through the vulnerability assessment. Any disparities should be resolved before being listed as a finding in the audit report.

Such resolution actions will disclose the accuracy of the inventory and discover any prohibited activities.

Domain Name Server, DNS, and Zone Transfers

A frequent misconfiguration found in many DNS servers is allowing untrusted users to perform a DNS zone transfer. Zone transfers permit a secondary master DNS server to update its zone database from the primary master DNS server. This provides for redundancy when running DNS, if the primary name server becomes unavailable. It is similar to having expected redundancy. Normally, a DNS zone transfer needs only to be performed by secondary master DNS servers; however, many DNS servers are poorly configured allowing a copy of the primary master DNS server database to be transferred to anyone who requests it.

This is not necessarily a bad practice and if an organization were to keep their interior and open-ended DNS servers partitioned; it will not generally be a problem. The matter gains strength when an organization has only one DNS server for both the exterior open-ended networks and the sensitive interior networks. In this case, internal hostnames and corresponding IP addresses are revealed through the DNS zone transfer to an attacker. Providing internal IP addresses to an untrusted user is analogous to providing a complete architectural map of your interior network.

Experience Note 

Allowing zone transfers from the interior system's DNS to any exterior DNS is poor business procedure and should be addressed appropriately.

An easy way to perform a zone transfer is to use the nslookup client already provided as part of the UNIX or Windows NT installation. An example of using the nslookup is shown in Exhibit 19.

Exhibit 19: [bash] $ nslookup

start example

default server: dns2.interexampleonline.com

address: 197.123.123.2

>> server 197.123.123.2

Default server: [197.123.123.2]

Address: 197.123.123.2

>> set type = any

>> ls -d interexampleonline.com..tmp/zone-out

end example

This script allows nslookup to run in interactive mode. It should produce the default name server it is using. Under general circumstances, it should be the organization's DNS server, or the DNS server provided by the host. Setting the record type to any allows the zone transfer of any DNS records available. Exhibit 20 is an example of the zone transfer output.

Exhibit 20

start example

acct20

1D

IN

A

194.178.22..0

 

1D

IN

HINFO

"IBM" "WinWKGRPS"

 

1D

IN

TXT

"Location : Server Room"

ce

1D

IN

CNAME

gandolfo

au

1D

IN

A

194.178.22.1

end example

There are automated zone transfer features with the SamSpade tool that will speed the assessment process. There are several important records displayed as part of the zone transfer: internal IP addresses, names of hosts, locations, and other information useful for the attacker. Auditors should include DNS zone transfers as part of their audit program. Restricting zone transfers will definitely increase the time necessary for attackers to probe your network for IP addresses and host names.

Auditors should recommend that exterior and interior DNS servers be partitioned between a DMZ and firewalls. This architecture provides that the outside network connects to a packet screening firewall, the DMZ contains the outside DNS server to handle exterior addressing. The inside network connects to the DMZ and is protected by a firewall consisting of an application firewall (proxy). Interior name servers should never be used for exterior network name resolution and should be located on the inside of the proxy service. Interior DNS servers should be configured so they deliver and accept zone transfers from the interior network only, never from outside the DMZ. HINFO records can be used for identifying the system's operating systems. HINFO should be disabled on exterior DNS services.

Automated Vulnerability Tools

General-purpose vulnerability scanners will perform a wide variety of security tests against network resources. Some scanners combine host and network tests via local agents installed on the target. It is important to note that some tests performed by automated scanners will compromise the audit target in order to verify the vulnerability or to collect more information. It is essential to address these issues in the rules of engagement, and it is prudent to alert appropriate levels of management before executing these audits as they tend to send administrators into the stratosphere.

Once configured with a range of primary targets such as IP addresses or system names, automated scanners provide the following results:

  • Locate targets from the IP range.

  • Inventory services present on each target.

  • In some cases, automated tools infer new targets from gathered data.

  • Automated tools will launch individual tests for identified services. An example of this individual test is the tool's ability to relay e-mail through a mail server.

Experience Note 

Automated vulnerability tools have one significant advantage: if auditors do not use them in conducting vulnerability assessments, attackers will.

From a practical view, the results of an automated vulnerability scanner should be considered a minimum vulnerability baseline. During the execution of the scan, if there are many high-risk findings, then the network has serious issues, and senior management must be notified immediately. However, it is a fair statement that if the automated tool finds few, if any, high-risk issues, there may be many undiscovered potential exploits. They are not anywhere near perfect. For this reason, vulnerability assessments are only a part of the audit program.

There are some serious limitations of automated tools:

  • The results are merely a snapshot of the system at the time of the scan.

  • The tool only evaluates the system according to the tool's configuration.

  • The tool is only as good as its attack signature database. If the database is not updated continuously, the results of the scan will likely be poor. Because new vulnerabilities are announced frequently, the tool's database must be modified to reflect these new issues.

  • The tool does not evaluate compliance with specific policies, procedures, and standards.

  • The tool will only consider known vulnerabilities with Common Vulnerabilities and Exploits (CVEs) revealed almost weekly, automated tools provide only relative measurements.

  • False positives are common in the results of vulnerability scans. In other words, tools report too many false alarms. The test may have been flawed or the auditor used an excessively ambitious test numbering. In other words, the same vulnerability is reported with different names. It is only a tool and requires intelligent operation.

  • False negatives are also common and may be worse than the false positives.

There are two types of automated vulnerability scanners, network-based and host-based. Network-based scanners attempt to gain visibility into vulnerabilities from the outside. This type of scanner is generally launched from a remote system, outside the organization, without authorized user access. For example, network-based scanners examine a system for such exploits as open ports, application security exploits, and buffer overflows.

The host-based scanners usually require a software agent or client to be installed on the host. The client then reports back to the managing station vulnerabilities it finds. Host-based scanners look for features as weak file access permissions, poor passwords, logging faults, and so on.

Exhibit 21 lists some of the more-popular vulnerability scanners. The listed products are intended only to provide a small sample of available tools. These products are listed for reference and feature comparison only; none of the comments should be considered recommendations.

Exhibit 21: Vulnerability Scanners

start example

Target Host Platform

Network-Based

Host-Based

Windows NT

CyberCop, ISS Internet Scanner, NetRecon, Nessus

ISS System Scanner, Bindview

UNIX (HP-UX, Solaris, AIX)

CyberCop, ISS Internet Scanner, Nessus, NetRecon

Bindview, Enterprise Security Manager

AS/400

CyberCop, ISS Internet Scanner, Nessus, NetRecon

Enterprise Security Manager

Netware

NetRecon, Nessus

Bindview, Enterprise Security Manager

end example

These are dynamic pieces of software. Their features, capabilities, and sometimes existence change frequently, so do your research and comparison. Make certain your choice of automated tool fills your needs.

Of course, there are freeware vulnerability scanners that are also worth mentioning.

  • SARA was introduced in 1999 and has received Internet support. Visiting the Web site (www.arc.com/sara) reveals some vulnerability updates.

  • SAINT was introduced in 1998 and also has received Internet support. The Web site (www.wwdsi.com/saint) has software, documentation, and updates.

  • Nessus was introduced in 1998 and has received widespread Internet support. The Web site (www.nessus.org) has hundreds of updates, currently more than 1200 modules. This is a very powerful tool, primarily UNIX-based, but there is some Windows NT capability. Nessus is a free, open-source code, general-purpose vulnerability scanner. It is freely available to legitimate users as well as the attacker community. Nessus consists of a client/server architecture with modular plug-ins for individual tests. Nessus is typical of most sophisticated vulnerability scanners in that it is updated frequently, flexible in its configuration, and comprehensive in its vulnerability report functions.

From the auditor's perspective, the value of the tool's report is important; however, it frequently contains so much information that, unless boiled down to a useable document, it overwhelms the audit report. Before including the scanner's report as it is generated in the work papers is prudent, as it demonstrates the depth of the assessment. Only after testing the scanner's report results, eliminating false positives and negatives, should they be included in the body of the audit report (Exhibit 22 through Exhibit 26).

Nessus is open to development and freely available. It can be modified to fill specific requirements and is constantly being updated with more modules. As you can see from the list of vulnerability families (Exhibit 26), Nessus is a thorough and comprehensive scanning tool.

Experience Note 

It is important to notify senior managers before administering an automated vulnerability tool.

Their function mimics attacker-profiles, triggers intrusion detection equipment and causes a substantial exercise of firewall resources. If not properly configured correctly, automated scanners running at full-throttle can absorb all network resources acting like a denial or service attack. These are matters to be addressed in the rules of engagement.

Doing Your Homework

Auditors should carefully research vulnerabilities found after executing an automated scan. It is possible there are vulnerabilities that require immediate attention and it is quite possible there are repeated vulnerabilities. Auditors must be careful before hitting the panic button; it is possible the vulnerability may be a false positive. Verify the existence of all reported vulnerabilities before including them as findings.

Exhibit 22: Nessus Plugins

start example

click to expand

end example

Exhibit 23: Nessus Preferences

start example

click to expand

end example

Exhibit 24: Nessus Plugin Families [9]

start example

Backdoors

CGI abuses

CISCO

Denial of service

Finger abuses

Firewalls

FTP

Gain a shell remotely

Gain root remotely

General

Miscellaneous

Netware

NIS

Port scanners

Remote file access

RPC

Settings

SMTP problems

SNMP

Untested

Useless services

Windows

Windows : User management

 
 

end example

Exhibit 25: Nessus Report Sample

start example

click to expand

end example

There are a few essential places to research this type of information:

  • Automated scanner vendor Web sites

  • Antivirus software vendor Web sites

  • Specialty Web sites such as www.securityfocus.com/vdb, www.cert.org, and www.cve.mitre.org

Another useful Web site for vulnerability information is the ICAT Metabase. This database is a searchable index of system vulnerabilities. ICAT links users to a variety of publicly available vulnerability databases and software Web sites. It is a searchable index of resources and can be found at: http://icat.nist.gov/icat.cfm.

Exhibit 26: Nessus Scan Options

start example

click to expand

end example

[9]There are currently 1093 vulnerability-testing plug-ins in the database.



 < Day Day Up > 



Critical Incident Management
Critical Incident Management
ISBN: 084930010X
EAN: 2147483647
Year: 2004
Pages: 144

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net