Sample Vulnerability Assessment Report

Title Page


Sample Vulnerability Assessment
Report




Table of Contents

  1. Executive Summary
  2. Audit Goals and Objectives
  3. Audit Methodology
  4. Audit Context
  5. Technical Recommendations
  6. Process Recommendations
  7. Issues and Strategic Considerations

  8. Appendix
    Glossary

1. Executive Summary

The customer requested an external Penetration Test of its Unclassified network. YoyoDyne was tasked with providing recommendations for technical solutions, process improvements, resolution of major issues and strategy improvements.

A penetration test was conducted by YoyoDyne in two separate 48 hour phases. The first Phase consisted of a blind test, where YoyoDyne was given no prior information about the customers network topology or defenses. During the second phase, YoyoDyne conducted a penetration test with network topology, host information and defense structure provided by the customer.

In most respects the perimeter defense held up. Certain hosts were identified with potential vulnerabilities. Some of these vulnerabilities were corrected immediately after the completion of the test. The major vulnerabilities included DNS servers, FTP servers, and various electronic mail servers.

In the areas tested, the YoyoDyne team determined that most problems identified were easily corrected. A few of those (discussed below) warrant more immediate attention, due to the higher risk of external compromise. Where significant problems were identified, the staff was notified immediately upon completion of the test, and those areas are already identified as being corrected. Each of these areas is also discussed below.

Recommendations are presented in three categories: Technical, Process, and Issues and Strategic Considerations.

Technical Recommendations:

Process Recommendations:

Issues and Strategic Considerations:

Overall, the customer has demonstrated good security practices. The recommendations will help eliminate the weaknesses exposed during our tests.

The detailed information is given as electronic documents in the appendix.

2. Audit Goals and Objectives

The primary objective of this penetration test was to discover networking and security deficiencies in the customers publically exposed, unclassified, networks.

Once the full testing had been completed, YoyoDyne was expected to provide recommendations for technical and process improvements and assist in resolution of any major security issues and improvement in security strategy.

3. Audit Methodology

The audit consisted of two phases, a blind test and an informed test. These tests were preceded by information gathering processes.

YoyoDyne followed an industry standard approach:

The testing team used additional tools and methods tailored specifically for the customer's systems.

4. Audit Context

4.1 Testing Limitations

The following contraints were imposed under the terms of the contract.

These limitations were understandable due to the nature of the customer's business, since some of these options could have the opportunity to severely impact the staff and machines.

4.2 Data Collection

Auditing commenced with a data collection phase. The areas of concentration were:

These areas are discussed in the following sections.

4.2.1 Usenet posts and public forums

Usenet is one of the favorite resources of the social engineer. Usenet posts often contain technical questings revealing network, host, application and security information. Email and Usenet post headers can provide routing information, host names, IP addresses, operating system type and version, and client applications. Personal and Work information including phone numbers, fax numbers, addresses, project assignments can be found. Personal habits, hobbies and and social activity can be discovered and exploited.

An initial host/IP list and network topology was developed almost completely from Usenet posts.

Appendix item 1 contains a summary of information obtained.

4.2.2 ARIN

The American Registry of Internet Numbers (ARIN) maintains a database of all registered IPs for the Americas. Queries to the database can be made using the whois command or via the web. Information revealed via whois can include:

Looking up the IP X.X.X.X reveals:

bash-2.03$ whois -h whois.arin.net X.X.X.X 
Customer (ID)  
   111 West Street
   Anytown, CA 90210
   US

   Netname: CUST-NET
   Netnumber: X.X.X.X

   Coordinator:
      Customer Coordinator  contact@customer
      (800) 555-1212

   Domain System inverse mapping provided by:

   DNS1.CUSTOMER              X.X.X.3
   DNS2.CUSTOMER              X.X.X.4

   Record last updated on 05-Sep-2000.
   Database last updated on 27-Nov-2000 06:14:40 EDT.
    

and a lookup of X.X.X.X reveals:

bash-2.03$ whois -h whois.arin.net Y.Y.Y.Y
Customer (ID2)
   111 West Street
   Anytown, CA 90210
   US

   Netname: CUST-NET
   Netnumber: Y.Y.Y.Y

   Coordinator:
      Customer Coordinator  contact@customer
      (800) 555-1212

   Record last updated on 31-Jul-2000.
   Database last updated on 27-Nov-2000 06:14:40 EDT.
    

The significant findings of this data was:

Information provided by a whois lookup, including contact email and phone number, is beneficial to the adept social engineer. ARIN identifies the reserved netblock providing a range of IPs that an attacker can scan. The listing of name servers provides an attacker a starting point with DNS attacks and queries. The lack of an advertised name server for the internal network indicates that name servers must be internal and non-public.

4.2.3 nslookup

The nslookup command can provide host names given the host IP address. A simple script was wrapped around the nslookup command to dump the entire X.X.X.X network.

Analysis of the host list provided for the initial selection of targets. Hosts of particular interest included those whos names indicated that they were http, ftp, mail, and dns servers. Hosts whos names indicated that they were particular operating systems, architectures or devices (Sun/Solaris, Linux, FreeBSD, VAX/VMS, Macintosh, various Microsoft operating systems, switches, gateways, firewalls, file servers, print servers and dial-up servers) were targeted.

The dump of dns data also provided information on subnets and subdomains. It offered hints as to the structure of the dns records (capitalized host names). Host names implied functional work areas useful to the social engineer. Many host names included what appeared to be user names in various forms. Hosts with the same name but multiple IPs were also noted.

Appendix item 4 contains data obtained using nslookup. 1359 hosts were identified.

4.2.4 traceroute

The traceroute command provided the YoyoDyne team with a view of the network routing into the customer. It identified upstream providers and border devices. Later in the tests it provided information regarding internal routes and routing devices. It also revealed paths to the "hidden" Y.Y.Y.Y network.

4.3 Phase I

The first phase of the test was blind. The YoyoDyne team was given no information on the customer's network. An initial plan was developed: Phase I was commenced with the following strategy:

4.3.1 Phase I Highlights

The team started scanning backwards through the address space. It was assumed that scanning the lower IPs would trigger defenses. Backwards scanning would allow the team to gain as much information as possible before discovery. The team stair-stepped through, using multiple spoofed addresses to hide the scanning activity. The spoofed addresses were chosen based on past scanning activities. There was an exception. The team used the address of someone that had reported as scanning the customer's networks a few days before.

The spoofed addresses were very effective. The team verified through tcpdump on separate machines that there is no way to differentiate between spoofed addresses, and actual machines that may be attacking. The scanning triggered specific defenses. It was suspected that scanning activities were being blocked, and verified later. The team stopped scanning when it was determined that it was no longer effective. Scanning triggered defenses as early as it did because attack methods were chosen based on the (mistaken) assumption that the defenses were weaker than they were.

A total of 441 hosts were actively contacted and scanned in Phase I. Appendix item 5 contains this data.

4.4 Phase II

Phase II was conducted with a known network topology. Based on experiences from Phase I, the YoyoDyne team modified its approach to the following:

Certain basic assumptions were also modified:

Phase II tools included:

Some tools were specifically modified to bypass the customer's firewall access controls and to evade IDS detection. Traceroute had IPv6 capabilities included with ICMP in an effort to gain access to the inner network, and firewalk had entries removed so that sensitive internal equipment would not be disturbed.

Potential targets for Phase II included:

Phase II was conducted as a freeform test. Individual testers were allowed to select hosts, probe for vulnerabilities, modify tools, follow avenues of exploitation, and reselect hosts at will.

4.4.1 FTP Servers

The team used various packages and attempts against the known FTP servers. Scanned was accomplished through the source port for DNS (53) to bypass filtering, which was effective.

Unfortunately, the FTP exploits used could not get past the filters on the routers. Even though these exploits were ineffective, the machines should still be examined to ensure that the version of wu-ftp is the most recent version. Since exploits against this application are so common, it is recommended that a more secure version of FTP replace this application.

The trust model on the Macintosh is such that it is difficult to exploit, even with an older application. While exploits against Macs are hard to find in the wild, it seems advisable to update the older application we found with a more recent version.

4.4.2 Mail Servers

Mail servers and versions were of differing consistency. The most common server type was Unix sendmail.

Sendmail versions varied among machines. Most servers seemed quite up to date. There were only two that would respond to simple VRFY and EXPN commands, although several pretended to. The hosts that responded with real user information were mail1.customer and mail2.customer. It is preferred that valid email addresses are not available to outside users, since it will make it easier for an attacker to guess at passwords, send virus-loaded email messages, or even create mailling lists for spam. Since mail1.customer is one of the main machines, and in fact is an identified FTP server (running wu-ftp), it is suggested that it be configured so that information is not surrendered to outside sources.

Both Macintosh mail servers were visible, but did not respond to VRFY or EXPN.

The team was most concerned to see a machine that seemed to offer multiple services (victim.customer). Most of these vulnerabilities were repaired immediately upon cessation of the penetration test. In general, it is recognized that it is preferable to have servers providing one service only, to lessen the danger of unauthorized access or compromise.

4.4.3 DNS Servers

Domain Name System (DNS) provides information about the specific physical location of a machine on the internet. It is used to locate machines in much the same way that a nine-digit zip code is used by the post office to find a particular address. It provides a unique mapping between a physical address and a host name so that a user looking for the mail server only needs to know to send email to first.last@customer, which would then be automatically be translated to username@mail1.customer, or other translations as needed.

Several versions of BIND (Berkeley Internet Name Domain) have had vulnerabilities, and there is always concern that a DNS server might be running one of these vulnerable versions.

Lame server delegations may be entry points for masquerading by criminal intruders or vandals. The servers identified were lame.customer (with bad reverse entries), and victim.customer (with a bad forward entry):

Oct 14 20:49:33 predator named[288]: Lame server on 'victim.customer'
(in 'victim.customer'?): [X.X.X.X].53 'dns1.customer'

Oct 3 20:08:14 predator named[15025]: Lame server on 'X.X.X.X.in-addr.arpa'
(in 'X.X.X.IN-ADDR.ARPA'?): [X.X.X.X].53 'lame.customer'
    

An enlightened assault on the main DNS servers could render the customer isolated, since they are physically located on the same network as the customer themselves. A clever attacker could masquerade as an entry in one of the questioned blocks, and be accepted on the inner network as a valid packet or group of packets.

Zone transfers, like VRFY on sendmail, give up information that may not be for public consumption. Zone transfers between DNS servers are expected. If a server for the domain CUSTOMER provides a limited zone transfer of data to SUBNET.CUSTOMER servers, it is providing legitimate information that both machines need. This becomes a difficulty if this information is not properly protected. Machines which allow inadvertent or promiscuous zone transfers permit any malefactor on the internet to gain intimate information about the network, such as hidden gateways, filtering routers, and machines names that are otherwise difficult or even impossible to retrieve.

Part of a good security stance suggests that only information which is necessary should be offered, and only to validated recipients. An example of a server at the customer which gives up information to the casual user is below. Note that this command is just asking for machine nicknames (aliases). If it happens that there is a machine that servers as www.subnet.customer, this command will give up the true name of that machine, making it just that much easier for the attacker to attempt a compromise.


This is an example of the zone transfers possible from a specific
server with the customer's network.

> ls -a subnet.customer
[subnet.customer]
www-subnet               host1.subnet.customer 
macmail                  mmail.subnet.customer 
group1                   mac.subnet.customer 
macfiles                 filesvr.subnet.customer 
group2                   host2.subnet.customer 
pcuser                   host3.subnet.customer
    

4.4.4 SNMP

Simple Network Management Protocol (SNMP) is a protocol for managing, monitoring, and configuring network devices such as routers, switches, printers and some hosts. Data is accessed by providing "community strings" which are similar in use to passwords. Certain well known default community strings are used by various vendors of network devices. If these default community strings are left unchanged, an attacker can obtain information about the networks accessible to the device. If the community string has write access to the device, it could be subverted or compromised to the attackers advantage. SNMP information should never be allowed to traverse the enterprise firewall.

Community strings of various types were attempted with machines that would talk SNMP. The team was unsuccessful in obtaining any improper information from these devices. Either SNMP was blocked by the firewall or the team was unable to guess the appropriate SNMP community names.

4.4.5 SSH

Secure Shell (SSH) provides secure (encrypted) authentication and remote sessions. SSH is preferred above Telnet or RSH due to its security features. Certain earlier versions of SSH contained vulnerabilities which could allow unauthorized or privileged access to the SSH host. These versions of SSH should be upgraded.

During the audit the team found one machine that refused to handshake due to its version being out of date. This may have been an anomaly, or it may truly be a cause for concern. It is recommended that all machines be surveyed to ensure that none are running older versions of the SSH server.

4.4.6 Hosts of Interest

The following hosts were aggressively investigated during Phase II of the audit. These hosts were of particular interest due to their potential for vulnerabilities. Each of these hosts should be considered for an individual security audit to verify proper patch levels and to upgrade applications as needed. Each entry includes the host name, any services discovered and commentary.

victim.customer
lame.customer
mac.customer
host1.customer
mac2.customer
mail1.customer
www.customer
www.subnet.customer

4.4.7 Perimeter Defense

Positive features of customer's perimeter defenses:

This is a strong and effective defense structure, and should be maintained, but the routing rules that were used to block should not be activated without further testing for unexpected effects.

4.4.8 Inner Network

The customer maintains an inner "hidden" network. This network lives in the Y.Y.Y.Y netblock. It is located behind a proxying firewall which in turn is behind the firewall for the public network. Machines on this network have no direct connection to the internet. No externally accessible name servers are provided and routing is (supposedly) not advertised for this network. One would assume that this network could not be reached via the Internet.

The team discovered that a traceroute to the hidden network worked. The traceroute stopped at the filtering router/proxy service for the network but it is assumed that the packets themselves made it to the destination machine inside the network (outbound responses from these machines would have been blocked at the firewall). Since we had been told previously that this route was not advertised, we were naturally quite concerned to discover that it was.

Firewalk is a tool that exploits firewall/router idiosyncrasies to map and gain information about hosts behind firewalls. The team successfully reached a host that was internal to the Y.Y.Y.Y network with firewalk. After firewalk was successful, traceroute was tested, which was when we discovered the inadvertent advertisement of the network to the outside world.

The success of these probes hinged on the fact that routing information to the hidden Y.Y.Y.Y was publically advertised. After discussions with the customer a potential point of information leakage was identified. To maintain its isolation, routing information to the Y.Y.Y.Y network must not be publically advertised. It should be noted that this configuration does not protect from exploits executed from the inside of the network. This includes tunnels, worms or viruses.

5. Technical Recommendations

Technical recommendations can be summarized as follows (in order of priority):

  1. Do not use reactive perimeter defense without further testing
  2. Replace wu-ftp and NetPresenz as FTP servers
  3. Update Apache version on www.subnet.customer
  4. Upgrade mac.customer to current OS and WebStar

6. Process Recommendations

Process recommendations can be summarized as follows (in order of priority):

  1. Put a process in place to keep DNS records up to date and secure
  2. Devise a process to monitor true weaknesses
  3. Segregate intern accounts

7. Issues and Strategic Considerations

Strategic recommendations can be summarized as follows (in order of priority):

  1. Social Engineering is still a major vulnerability
  2. VPN and remote connections were an unaddressed issue

Employees should be educated in the risks of social engineering. They should be made aware that posting to public forums from the customer's network discloses information about the internal networks. They should be aware that disclosure of specifics about internal systems, networks or applications places these systems at risk and/or makes them available as potential targets to attackers. Employees should not disclose personal information in public forums such as phone numbers, fax numbers, addresses, or work areas. They should not disclose information about the company organization, reporting structure or internal processes. Public forums are archived in a distributed manner. Once data enters these archives it is impossible to fully remove it. A proactive approach is required.

It is recommended that phone networks are audited, searching for phones being misused as modems, or to make sure that phone lines identified as being connected to fax machines are only answering with fax machines responses, and have not been converted to modem use at night time, or on weekends. War dialing tends to uncover these problems, and to verify that any identified modem bank gives back only the responses expected. If one time passwords are in use, phone audits verify that all known modem lines respond correctly, and that there are no unknown modem lines into the enterprise.

One-time passwords are an effective mechanism to assist in securing a network. We recommend that additional measures be taken to buttress that security. Home users and other off-site users are not under the direct control of the technical staff, and may still cause needless exposure to possible problems. Consider using Kerberos or a similar solution to segregate external users such that any potential damage is limited to specific area.

Appendix

The following information is contained in online files that are linked from the online document. Due to the voluminous quantity of data, they are not currently available in printed form, except where noted.

  1. Usenet/Social Engineering Data

    This data is comprised of information retrieved online, in the Supplemental directory.

  2. Some original raw data collected prior to the penetration test

    Things of note were two malformed DNS entries, and information about the network itself.

  3. Interesting assumptions about collected network information

    Specific things were tested early, such as evaluation of known web servers.

  4. nslookup network dump of X.X.X.X

    Other Phase I data is listed in the Supplemental directory, in the directory PhaseI. The sorted list of the viable addresses in the network dump is listed separately. The perl scripts for gathering the data were grab.pl, scandns.pl, and a quick shell script to grab specific multiple addresses. The local DNS server was always used so that any errors would be logged locally (for further information).

  5. hosts up on Sunday (Phase I)

    Other Phase I data is listed in the Supplemental directory, in the directory PhaseI.

  6. Email conversations for Phase II

    Phase II data, and email records, are in the directory PhaseII.

  7. Routing data to various hosts

    Phase II data, and email records, are in the directory PhaseII.

  8. Physical reports made during Phase I and Phase II

    These reports and notes are part of the physical package returned to the customer as per the original agreement.

  9. The presentation made to the staff.

Glossary


shrdlu AT deaddrop DOT org

Last modified: Sat Oct 30 22:55:41 PDT 2004