The SANS organization released an update of the "Top 20" list of security issues organizations should be concerned about. The updated list includes many specific vulnerabilities, as well as generic guidelines. This blog entry shows how Nessus, the Passive Vulnerability Scanner, the Security Center and the Log Correlation Engine can be used to monitor for SANS Top 20 issues. Active vulnerability scanning policies for both Nessus 3 and the Security Center are also included here.

Specific Recommendations

The Top 20 guide is divided into different sections such as "W1 Internet Explorer" and "C5 Media Players". Some sections specify very specific vulnerabilities by CVE entry. In those cases, we've made sure to highlight the specific Nessus and Passive Vulnerability Scanner (PVS) plugins which can perform tests related to these issues. The specific active Nessus checks for the referenced CVE entries are included in the scanning policies below. Other sections are more generic and require interpretation by each organization. This blog entry also identifies strategies that can be used to generically monitor a network for these issues.

Patch Auditing with Nessus

Throughout this blog entry, we will make reference to specific Nessus checks to perform an audit. A majority of these audits (especially the client side tests) are accomplished with patch audits. If you are not familiar with using credentials to audit UNIX or Windows hosts to perform a patch audit, you should read the "Nessus Credentials Checks for UNIX and Windows" paper.

W1 - Internet Explorer

Microsoft has released many patches for IE. Performing a credentialed patch audit with Nessus will test for all security patches, including those for IE. Having said that, the "Top 20" policy specifies specific CVE entries and those have been used to map specific Nessus checks for testing IE in the scanning policies below.

There are no "remote" ways to identify IE issues without credentials with Nessus 3. Some of the issues identified in by the "Top 20" list can be monitored for passively with the PVS, but not all of them.

W2 - Windows Libraries

As with Internet Explorer, performing a credentialed patch audit with Nessus covers all of the security issues relating to Windows patch audits. Very few of the checks can be performed with network scans or passive monitoring. The specific Nessus checks related to the CVEs listed in this section are included in the scanning policies below.

W3 - Microsoft Office

Similar to the previous sections, the bulk of these checks is performed with patch audits. Some of these can be monitored for with the PVS, such as ID #3365.

W4 - Windows Services

Unlike previous entires, many of these checks can be performed with network scans that don't require credentials. In most cases though, Tenable provides both a network check as well as a patch audit for the Windows Services vulnerabilities identified here.

One vulnerability in particular was MS06-040. Tenable has previously blogged about how this particular security issue can be discovered with passive scanning, active scanning and patch auditing.

Nessus plugins indicated by the CVE entries in this section for both active scanning and patch auditing are included in the scanning policies below.

W5 - Windows Configuration Weaknesses

This section discussed password strength polices, default passwords as well as specific issues related to "NULL" passwords and Windows domains.  There were no specific vulnerabilities mentioned, just configuration issues. As such, there were no specific Nessus checks added to the scanning policies below.

Having said that, the entire Nessus "Windows: User management" plugin family as well as the generic "Windows" plugin family have checks which are very relevant to this section of the "Top 20" report.

For Security Center or Direct Feed subscribers, Nessus 3 can be used to audit the password policy for specific Windows servers. Tenable has blogged about this sort of testing in the past.

M1 - Mac OS X

The "Top 20" report identified a variety of client and server side issues specifically for Apple's OS X operating systems. All of these issues can be tested for with a credentialed patch audit of OS X. Tenable has previously blogged about how to accomplish this here.

All of the CVE issues identified with this section are covered with active Nessus checks, Nessus patch audits and PVS rules. All related Nessus active scans and patch audits are included in the vulnerability polices below.

U1 - Unix Configuration Weaknesses

This section combines several concepts for hardening and locking down UNIX systems, as well as tips for monitoring them once they are installed. Since no specific vulnerabilities were mentioned, there aren't any specific Nessus checks added to the scanning policies below.

This section specified many strategies and recommendations for locking down and monitoring UNIX servers. Tenable customers should keep in mind:

• The Log Correlation Engine (LCE) can be used to monitor UNIX logs as well as network activity to discover SSH, Telnet and FTP brute force attacks.
• Security Center and Direct Feed customers can perform configuration audits of UNIX servers to see if they have been hardened to CIS standards, as well as NIST and NSA recommended configurations. This includes password strength policies.
• In addition to network vulnerability scans, Nessus can perform full patch audits of most major UNIX OSes.
• For monitoring all network ports in real time (in lieu of performing a full port scan) consider using the PVS.

C1 - Web Applications

This section detailed issues with Cross Site Scripting, SQL Injection and many other issues relating to web applications. There are 1000s (if not more) of specific web application vulnerabilities that have been publicly disclosed. A Nessus active scan can find most of these, however, to find all issues with your specific applications, SANS recommends a source code review. Having said that, keep the following in mind:

• Nessus has a specific plugin family for Web Server vulnerabilities.
• Nessus also has specific plugin families for both CGI abuses, as well as abuses due to Cross Site Scripting.
• Tenable writes network checks for Nessus, as well as for the PVS, for most publicly disclosed web application issues.
• The PVS includes plugin families for Web Servers as well as CGI issues.

C2 - Database Software

SANS identified major vulnerabilities in most available Database solutions. These have all been cross linked with Nessus plugins and have been included in the scanning policies below. Most of these checks do not require credentials, but some Microsoft SQL checks do require credentials.

C3 - P2P File Sharing Applications

The "Top 20" list also identifies ways to enumerate and monitor P2P software in use on your network. They did not specify specific vulnerabilities to scan for, however, Tenable customers can accomplish the following actions:

• The PVS has an extensive library to identify P2P applications as well as their vulnerabilities, regardless if there are any local firewalls in use.
• Nessus has an entire family dedicated to P2P application and vulnerability discovery.

C4 - Instant Messaging

As with P2P, the "Top 20" list also identifies security issues with instant messaging applications like Trillian and AIM. Tenable customers can approach monitoring IM applications very similar to what has been recommended for P2P apps.

C5 - Media Players

The "Top 20" list also includes a wide variety of issues with media players. During 2006, many viruses and malware was able to propagate by exploiting vulnerabilities with various media players. SANS specifically sites several dozen CVE entries which relate to these issues. Nessus can perform checks for all of these, but often requires credentials to perform a host audit. The PVS can also be used to monitor for many of these issues.

C6 - DNS Servers

SANS does not specify specific vulnerabilities related to DNS servers. However, they do address DNS recursion. Tenable has previously blogged about how both the PVS and Nessus can be used to identify mis-configured DNS servers here.

C7 - Backup Software

During 2006, many vulnerabilities were identified in enterprise backup solutions, some of these were also discovered by Tenable. SANS identified several CVE entries, most of which can be tested for with Nessus. These checks are included in the scanning policies below.

C8 - Security, Enterprise, and Directory Management Servers

As with backup software, SANS has also identified many issues surrounding enterprise software. This includes corporate anti-virus software, authentication software and even patch management systems. The Nessus checks which perform these audits are included in the scanning policies below.

N1 - VoIP Servers and Phones

A new category into the SANS "Top 20" list covers vulnerabilities associated with Voice Over IP technologies. Tenable researches vulnerabilities in these applications and has Nessus checks for the items identified by SANS. Many of these checks are also available for the PVS.

N2 - Network and Other Devices Common Configuration Weaknesses

Both Nessus and the PVS can be used to monitor network devices for vulnerabilities. SANS specifies example vulnerabilities in printers, routers, firewalls and many other devices. However, the database of equivalent checks available for Nessus and the PVS is much larger. When auditing a network device, consider the following:

• Nessus has two entire families Cisco and SNMP, which focus on network security issues.
• The PVS also has a family dedicated 100% to SNMP monitoring.
• Active and passive OS fingerprinting includes network device discovery.
• Nessus includes a wide variety of checks for network printers.

H1 - Excessive User Rights and Unauthorized Devices

SANS stresses that organizations should strive to remove unneeded devices and unneeded user privileges. This will be a very subjective process for each organization. Active scanning, credentialed scanning, passive network analysis and log analysis can be used to build a monitoring solution for almost any situation.

Tenable has blogged about this related subject several times. Perhaps, the most relevant blog entry would be about how all Tenable products can be used to monitor generic IT controls.

H2 - Users (Phishing/Spear Phishing)

Tenable does not specifically perform research or checks to look for users who have been victimized by a phishing attempt. Having said that, Tenable does help in many areas:

• The PVS can be used to monitor network activity in realtime for potential "abuses" of the network. This includes systems (that have likely been compromised)  which send bulk emails with "The Bat!" software.
  
• Both Nessus and PVS can be used to monitor the susceptibility of the network's email and web clients to client side attacks.
• The LCE can be used to analyze web proxy logs and network traffic logs to analyze phishing instances if and when they occur. 

Z1 - Special Section: Zero Day Attacks and Prevention Strategies

SANS also identified several CVE entries which were used as "Zero Day" exploits throughout the year. The Nessus checks related to these vulnerabilities are included with the scan policies below. When monitoring for "Zero Day" vulnerabilities, Tenable customers should keep the following in mind:

• Direct Feed customers (and Security Center users) have immediate access to the latest vulnerability checks.
• PVS users also have access to the latest checks. Since PVS monitors 24x7, Tenable customers often have "early warning" of new vulnerabilities from the PVS.
• Both the PVS and the LCE can be used to look for changes in network behavior. For example, one the the LCE's correlation scripts, the windows_crashes_and_restarts TASL, can alert when there has been a large number of "failed", "crashed" or "restarted" programs.

Nessus 3 Scanning Policy

Below is a text file that is a Nessus 3 scanning policy. The Nessus plugins enabled in this policy were derived from the SANS references to specific CVEs.

Download SANS-2006-Q4.conf

On UNIX, this policy can be invoked from the command line with the "-c" option to specify a Nessus "rc" file. Windows Nessus 3 users can save this file in their Nessus configuration directory which will have a path as follows: Documents and Settings / {User Name} / Tenable /  Nessus / Config

The "{User Name}" is the account name of the person using Nessus under Windows. Restarting the Nessus 3 Windows scanner will allow the user to see (and edit if desired) this policy under the "Manage Policies" link. This file is named SANS-2006-Q4.conf and will show up as a policy named "SANS-2006-Q4".

Security Center Scanning Policy

Tenable has also produce a vulnerability policy which reflects the Nessus checks outlined by the SANS Q4 2006 "Top 20" list. The files below should be downloaded to your /opt/sc3/admin/vpolicy directory.

Download 0024.ep

Download 0024.info

Download 0024.prefs

The polices are indicated as "0024". If you already have a policy using number 24, you should download these to a different directory, and rename then to something else, such as "0025". Once these files are in place, make sure they are owned and readable by user "tns" and the value "0024" is added to the vpolicy.txt file. The Security Center can make use of this file immediately and does not need to be restarted.

Using These Scans

Nessus and Security Center users should perform these scans using credentials. A majority of the Nessus plugins specified in these policies are patch audits or require host-based access to analyze local files and registry settings.

Over the next few months, Tenable will be interviewing many different industry leaders in the information security field. Our first interview is now available. Our guest was Thomas Ptacek of Matasano Security.

Mr. Ptacek's background includes development of one of the first commercial vulnerability scanners, ground breaking research in network intrusion detection evasion as well as network anomaly and DDOS detection. His current company, Matasano Security, specializes in vulnerability assessments of products such as operating systems, network appliances and software applications. I got to ask Thomas Ptacek some questions regarding recent trends in network security including:

• changes that vulnerability scanning technology has gone through since the late 90s
• the impact of evasion in modern NIDS/IPS products
• recent technical advances in the security of operating systems such as Vista
• issues with Network Access Control deployment on enterprise networks

Listeners who find the interview interesting should subscribe to the Matasano BLOG.

Click on the link below to listen to the interview.

Download thomas-ptacek-interview-nov27-2006.mp3

The Security Center can use the vulnerability data obtained by Nessus scans, Nessus patch audits and the data obtained by the Passive Vulnerability Scanner (PVS). Combinations of specific IDs, DNS names, results content and open ports can be used to create a "dynamic" asset list. These lists are updated each time a new scan is completed or passive vulnerability data is processed.

This blog entry will consider two examples of dynamic asset list creation which are more advanced than a typical user might need, but illustrate the flexibility of the type of rules which can be created.

Detecting Potentially infected Nugache Instances

The Nugache virus is a classic type of worm which opens up a backdoor (in this case on port 8) and also connects out to IRC servers for commands.

If the PVS is configured to watch a network, it will see many types of applications in use and it will also see basic open ports and browsed ports. The PVS logs "open port" data to plugin #0 (the same as Nessus open ports). It also logs "browsed port" data to plugin ID #2.

So in Nugache's case, and active infection should have an open port on port 80, as well as having connected out to IRC on port 6667. A dynamic asset rule to detect this is shown below:

Having a TCP port number of 8 open is very simple. Basically, any vulnerability can contribute to an open port, and if the port is 8, the first part of this rule matches.

The second clause is more tricky. In this case, we want to find hosts that have the presence of plugin ID #2 (browsed ports) but also on a specific port of 6667.  Plugin ID #2's data looks like this:

1.2.3.4 -> 80

That would mean that host 1.2.3.4 browses on port 80. Knowing that the port is at the end of the data, we can write a regular expression that looks plugin ID #2 with data that ends in " 6667". The text in the above image says "2: 6667$" which means to look for plugin ID #2 that ends with a space and the string "6667".

If you are not familiar with regular expressions, the dollar sign is used to indicate the end of the match. Without it, the pattern could be matched anywhere. The expression "2: 6667" could match " 6667" as well as " 66677" or " 66671" or any other type of number which started with "6667".

Users that are new to writing dynamic asset rules might want to write this rule as follows:

This is incorrect. The spoken logic for this rule would sound like this:

"Find any hosts for port 8 open, and then make sure that they also have at least one vulnerability on port 6667 AND they also have at least one instance of plugin ID #2 for browsed ports".

So when the dynamic rules say that ALL rules must match, they must indeed match, but they are each evaluated individually across all of the available vulnerabilities for a given host.

We could make this dynamic asset rule a bit more generic by changing the rule for watching network browsing on port 6667, to a more generic PVS rule which finds and identifies IRC clients. These are PVS IDs 3101 and 3471. These rules have the advantage of being port independent. IRC servers can run on many different ports, and the PVS can recognize them through protocol analysis. We will use these rules in our next example.

Detecting the IRC Browsing Web Server

Once users get the hang of writing dynamic asset rules, we often see them create very creative rules that identify a wide variety of potential security issues as well as configuration issues.

One common idea we see often is to look for IRC activity from a server. The idea is to see an attacker's use of IRC after they have compromised a server.

Consider the following rule:

Plugin ID #1442 is a PVS rule to generically find a web server on any port. Plugin IDs #3101 and #3471 find systems that use IRC clients. This rule, spoken in plain English, would say:

"Find any system which runs a web server on it (plugin #1442) and also uses an IRC browser (with either plugin #3101 or #3471 being present)."

Now, consider what we find what we ran this on a large test network:

We can see that plugin ID #1442 (Web Server) is present and that also plugin ID #3101 is also present. However, based on the other passively discovered vulnerabilities such as Media Player and various versions of Mozilla, this might not really be a "server".

Further analysis (not shown here) shows that the web server is indeed a P2P application known as Lime Wire. PVS accurately identified a service that spoke HTTP, but it wasn't really what we intended to seek out in the first place. The Lime Wire server wasn't even running on port 80 in this case.

If we wanted to make our dynamic rule more accurate, we could try adding a regular expression to the rule clause for plugin ID #1442 to match "Apache" or "IIS". Such a rule would look as follows:

Instead of simply matching for plugin ID #1442, we now have a rule which looks at the text of the vulnerability results and does a simple pattern match for "IIS" which occurs in most Microsoft web server banners. If we wanted to add support for Apache or restrict the port, we could add more rules to this initial clause.

For More Information

The Security Center documentation contains many more examples and ideas for creating dynamic asset rules.

Note: This blog was first posted on November 27, 2006. Since then, plugin ID #11777, which enumerates files that potentially represent copyright violations, has been rewritten.  It is now dependent on plugin ID #23973 which enumerates files hosted on SMB shares and checks for a much broader range of file extensions. 

Nessus includes three plugins to look for systems containing movies and music files being served through web servers, ftp servers and SMB shares. This blog entry will discuss why this is something you might want to look for, how these plugins work and how you can use the Security Center to analyze these results.

Background

Plugins #11777, #11778 and #11779 look for files with the following extensions:

.mp3
.mpg
.mpeg
.ogg
.avi
.wma
.vob

These files are normally associated with movies, music and DVDs that have been obtained from the Internet through P2P file sharing such as Bittorrent, BearShare, eMule, Kazaa and WinMX. 

Having a movie or music file on a computer is not a crime, however, having data that is copyrighted can be a crime. If users on your network are sharing this sort of data illegally, they may be exposing your organization to potential investigations from the Recording Industry Association of America (RIAA) or the Motion Picture Association of America (MPAA).

Tenable's university customers (and even our corporate customers) regularly tell us that if a user starts to blatantly use the network for sharing files with music or movie content, that they can expect to get a letter from the RIAA or MPAA. This can take time for the IT staff to respond to.

Internally, any organization that hosts a file server containing copyrighted material may be open to lawsuits or even embarrassment if news of this leaves the organization.

There are also a great deal of security threats from shared illegal content such as this. The SANS Q4 Top 20 list identifies both media players (C5) and P2P applications (C3) as being targeted by malicious users. An attacker who wishes to compromise a large number of systems could create a music or movie file with very appealing content, such as a popular song or movie, and also include an exploit which attacks iTunes, Media Player or Quicktime.

The NASL Scripts

Tenable has produced three different plugins to search for files with these extensions in SMB shares, on FTP servers and on Web servers.

#11777  SMB share hosting copyrighted material

This plugin uses the current scan credentials to find file archives of movies and music on SMB shares. For performance reasons, the script only looks for three levels of recursion deep.

#11778 Web Server hosting copyrighted material

This plugin is dependent on the webmirror.nasl script. The webmirror.nasl script creates a virtual archive of all content on the scanned web server. Plugin #11778 then searches this archive in the Nessus knowledge base for any file extensions which match those of movies and music.

Typically, users will find web archives on port 80 servers, but if a user is more savvy, they may try to hide their web server on a high port. If Nessus is performing a full port scan, it will find this port, identify it as a web server and log in. If performing a full port scan is not an option for all systems, using the Passive Vulnerability Scanner (PVS) to monitor network traffic to find web servers on non-standard ports is suggested.

#11779 FTP server hosting copyrighted material

This plugin logs into detected FTP servers and traverses the directories of hosted files for archives of movies and music. For performance reasons, the script only looks for three levels of recursion deep.

As with off-port web servers, if Nessus finds an FTP server not running on port 21, it will still attempt to perform this analysis. The PVS will also find off-port FTP servers.

Interpreting The Results

Finding a movie or a music file does not imply that the host is indeed violating someone else's copyrighted material. Many of the following situations occur on modern enterprise networks:

• legally obtained content is being shared unintentionally
• content intended for downloads (such as podcasts, movie trailers, .etc) is found
• content included with applications and operating systems is found

When analyzing systems with this data on them, consider the following concepts:

• Is this data something required for normal usage?
• Is this data consuming network bandwidth or storage?
• Does this data contain offensive material or subjects?

Analyzing Results with the Security Center

Below is an image of a server at 192.168.20.23 that was hosting copyrighted material over an SMB share:

This system had a few movies (Cars and Monster House) as well as some MP3s. If we had many hundreds (or even thousands) of servers with this condition, how could we use the Security Center to narrow these down into different groups? There are several things we could do:

• The Security Center has a "Search Vuln Text" field. If we wanted to find just movies, just music, .etc we could refine our search there. For example, we could type "cars.avi" and we'd find just systems that had that movie.
• We could extend this concept to look for "dirty" words which were associated with pornographic material. This would find systems potentially hosting adult entertainment content.
• We could also extend this concept to look for music of popular bands and title such as "ColdPlay", "U2" and "Madonna". 
• These filters could also be used to create a Security Center dynamic asset list. These rules could either simply match plugins #11777, #11778 and #11779 or have a more refined algorithm by also performing a text search to look for specific content. 
• Lastly, once these dynamic asset rules were in place, the Log Correlation Engine could be used to analyze network traffic (via direct sniffing or netflow) going to and from these devices to look for who has been accessing this data and how long they've been accessing it. 

For more Information

If this type of monitoring is interesting, Tenable customers should request a copy of our "Realtime Compliance Monitoring" paper. It has a section for strategies on dealing with RIAA and MPAA inquiries. All request for the paper should be sent to sales@tenablesecurity.com.

Also, both the PVS and Nessus have extensive families for detecting P2P applications in use. The Nessus plugin family for identifying P2P apps is available for analysis online. The PVS is a commercial product. If there is interest in that, please contact sales@tenablesecurity.com.

Lastly, we've previously blogged about using the PVS for corporate monitoring. 

Many corporations, particularly in the financial industry, impose an end of year "freeze" on all network changes. This means that no new products or systems may be deployed and any exceptions must be authorized by executive management. This mandate provides unique challenges to an IT director: maintaining a secure network; ensuring compliance with the freeze policy; and evaluating exceptions. Tenable's Passive Vulnerability Scanner can help.

There are no industry standards or requirements for end of year freezes. Many companies impose them to ensure that there are no activities that will impact operations that provide fiscal and/or calendar end of year accounting. Processing problems caused by changes in the environment could impact that capability. The more complicated the financial structure of the organization, the more likely it is that management will impose a freeze on IT activities.

A freeze can last anywhere from two weeks to a month. Anything longer would impact productivity. Some companies have a two level freeze - a soft freeze and a hard freeze. The soft freeze prohibits major implementations that can impact books and records systems. New product applications, transaction processing applications, application modifications or new feeds into core systems are some of the activities that would be restricted in a soft freeze. Any major network implementations or modifications would also be restricted. The hard freeze is a moratorium on all implementations. Exceptions to these restrictions usually must be in writing from the executive level - and few managers want to take responsibility for the consequences of permitting an exception unless they are certain the risk of a network impact is low.

The Passive Vulnerability Scanner (PVS) behaves like a security motion detector on the network. It maps new hosts and services as they appear on the network and monitors for vulnerabilities, providing virtual real-time security monitoring. The PVS does this without generating any traffic, which makes it compliant with network freeze restrictions. It behaves like a hybrid of an active scanner, such as Nessus, and an Intrusion Detection System (IDS). The PVS analyzes the traffic generated from its defined focus network and reports any anomalies or vulnerabilities observed. Unlike an active scanner, it does not target network devices with port scans or queries - it simply observes the traffic that these devices are generating as a normal part of their operation. An IDS looks at traffic targeting the network and reports the parameters of the attack. It does not report the parameters of the target. While attack information is useful to know, it says nothing about the actual state of the network.

Since the PVS maps new network devices as they appear on the network, it can help ensure compliance with the corporate freeze policy. Freeze conditions mandate that no changes be made to the network, so any new devices that appear should be investigated. The PVS also has built-in checks to determine if a port scan has been launched from the focus network. This could indicate that an administrator or user launched a network scan in violation of the freeze policy. Another useful aspect of the PVS is the ability to write custom plugins for the PVS to identify applications that may be prohibited from running during the freeze.

For example, you may have an application to test failover to a disaster recover site, called ‘disaster_recovery_test’. This example application begins by sending a broadcast message to all hosts on the broadcast domain. The protocol used is UDP with a source port of 5155 and a destination of 255.255.255.255:5155. Within this initial broadcast packet is the command string 'DRP:Switch:BackupDataCenter:CommandIP:TargetNet:Mask'. The PVS plugin to detect this application could look as follows:

name=Disaster Recovery Test initialization detection
daddr=255.255.255.255
sport=5155
dport=5155
clientissue
udp
family=Generic
description=Synopsis :<br><br>The remote host has just initiated a disaster recovery protocol to switch production servers to the backup datacenter<br><br>The remote server - %L - just initiated the Disaster Recovery Test. Ensure that this command was not issued during a freeze period or outside of a valid change control window.
solution=Ensure that this behavior is authorized for your network.
risk=HIGH
match=>DRP
match=DRP:Switch:BackupDataCenter:
regex=DRP:Switch:BackupDataCenter:([0-9]+\.){3}[0-9]+:

A plugin like this wouldn't just be limited to 'freeze' periods. It could also be used to detect any change which occurs outside a change control window or within a highly secured environment .

For more information on writing PVS rules, please refer to the online documentation.

The PVS can also aid in evaluating when it is necessary to authorize an exception to the freeze policy. The PVS is updated daily with plugins from Tenable, similar to how an IDS or Anti-Virus system is updated with signatures (an activity that is normally permitted during a freeze). During the course of passively observing network traffic, the PVS could provide an alert on a system that is vulnerable to a new exploit. Depending on the nature of the exploit and the vulnerability of the system, it may be determined that there is a greater risk of a network impact if the system is left unpatched than if it is patched.

Many security applications generate so much network traffic that they themselves become part of the problem. A major challenge in the IT security field is to get a handle on all the data that is generated. Tenable's Passive Vulnerability Scanner is a versatile tool that can be a valuable aid for a variety of security challenges. Its key aspects are that it provides real-time event monitoring without generating traffic. This aspect is critical in situations, such as a freeze, where it is important that network activity remain as static as possible.

For over a year now, Tenable has been including CVSS base scores in the plugins we write for Nessus as well as Passive Vulnerability Scanner (PVS) to give our customers an objective way to assess the risk of flaws those plugins test for. We've been calculating these scores in-house during the course of investigating vulnerabilities and how to test for them. Until recently, our efforts have been largely independent of NIST's own work in this area.

Since early November, though, Tenable has been using the CVSS scores that NIST calculates and includes in its National Vulnerability Database. We still calculate our own scores initially, as our plugins are often released at the same time -- or even slightly before -- CVE ids are issued. But a daily synchronization process reports differences and updates the plugins as necessary.

About once a month, Tenable gets a call from an MSP, IDS vendor or SIM vendor that wants to take the output of a Nessus scan and do "correlation". The concept is to do something more intelligent with the IDS events with the knowledge of what is actually on your network.

Tenable has several products in this space and has also written several white papers on this topic. Over the past few years, we've also seen several approaches in SIMs and IDS/IPS solutions that have used techniques which can very misleading. This blog entry discusses some of the issues we've seen and how we've overcome them in Tenable solutions.

Correlating based on the Target OS

One of the easiest concepts to understand is to use the idea of the detected operating system of a target to "throw away" or "decrease the severity" of IDS events which won't have any effect. For example, if you have a "UNIX" attack heading to a "Windows" server, the attack is less likely to succeed.

Although, easy to understand, this can be very misleading. Consider the following implementation details:

• How accurate is the OS detection? We don't want to mis-classify IDS events because our Solaris server was misclassified as a Linux server. This occurs more often than people realize because there aren't enough ports open to identify an OS or there are true "proxies" in place.
• What do you do with cross-platform applications such as Apache, MySQL or even iTunes?
• If I am running a 100% UNIX network, or 100% Windows, .etc, this technique may help throw away some IDS events, but, a good NIDS administrator would have disabled the attack rules for the OSes not running on their network.

Perhaps the most misleading implementation of OS detection is to derive the vulnerabilities associated with the OS purely based on its signature. For example, one could actively or passively fingerprint an OS X server and then associate all vulnerabilities ever released for that OS as being "live". If someone patches these vulnerabilities, the OS fingerprint never changes and IDS events could be incorrectly elevated or de-emphasized.

Correlating based on the Application version and/or known Service

I feel very comfortable with solutions that accurately measure the presence of specific applications and then associate their known vulnerabilities. The key here is how accurate these applications can be determined. Consider the following technical implementation issues:

• How often is the system being assessed for the presence of an application? Using an out of date list can incorrectly effect the severity of a correlated IDS event.
• If the solution is scanning based, how does it handle applications from vendors such as Red Hat which provide patches to services without revising the revision level?
• Also if the solution is scanning based, does it find off-port services such as SSH running on port 2200 or web servers running on port 8000?

This last issue is very important. We've seen some correlation systems that even throw all IDS events to these ports because they were not in the scanner results. If your correlation system believes that what your vulnerability scanner gives to it is an accurate representation of the network, you should make sure to scan all ports, scan often, and to make sure you are using the latest vulnerability checks.

If you are using Nessus, this means that users should update their Nessus plugins very often and consider using the Direct Feed. If you are using a product other than Nessus, don't assume it is self-updating. make sure you perform an update of the vulnerability checks before performing and inputing a scan into your IDS or SIM solution.

De-emphasizing critical events with old vulnerability data

One theme we've seen in the past two examples is the de-emphasis of IDS events in an incorrect manner. What we would hope for is to correlate accurate vulnerability information with accurate IDS event data.

Consider a typical NIDS solution. It gets updated almost daily with new signatures based on the latest public vulnerability information. If it detects an attack that involves a vulnerability disclosed in the last few days, this could be quite serious. But what happens if the correlation system doesn't have evidence of the corresponding "serious" vulnerability from a network scanner?

A well made correlation system should leave the IDS event as-is since it doesn't have any information to raise or lower its severity level. A correlation system which removed the IDS completely could have very misleading results.

Not using Patch audit data

Something that surprises us at Tenable is the lack of interest in third parties to correlate patch audit data with IDS events. Patch audit data gives some unique types of vulnerability data as compared with a traditional scan. This includes:

• Extremely accurate vulnerability information, sometimes much more accurate than can be determined with a remote network scan.
• Client side vulnerabilities, such as security issues with Outlook, Mozilla and Eudora.

More and more IDS/IPS solutions are performing network monitoring for client-side exploits. Using a correlation system which doesn't accept or consider client-side vulnerabilities won't be able to help mitigate "false positives" IDS events or correctly identify serious compromise events.

Not using "Passive" Vulnerability Data

The last technique that many IDS/VA correlation implementations are missing is to make use of passively obtained vulnerability data. By "passive" we mean the process of monitoring the network traffic to accurately conclude vulnerability data. Passive monitoring has several advantages over network scanning and credentialed auditing when it comes to VA/IDS correlations.

Passive scanning is "always on" and sees all network traffic. Often a passive monitor will be exposed to the same traffic an IDS/IPS sees. This means at worse, a passive solution sees vulnerability information as soon as it is discovered by a remote hacker. If this data is fed into a correlation system, then the vulnerability data will always be current.

Passive scanning will see all traffic, including activity on ports not normally scanned for. If a server runs a web administration interface on a high port, a passive scanner will learn about this and report on it over time.

Lastly, passive scanning will also see client information which is in use on the network. When network users surf the web, check email or even use P2P software, all of this activity can be identified, usually down to the specific applications and their associated vulnerabilities being used.

IDS/IPS and SIM solutions which overlook the rich data obtained by passive network monitoring miss out on using valuable data for more accurate IDS event correlation.

VA/IDS Correlation with Tenable Solutions

Tenable's Security Center can accept vulnerability data from:

• scheduled Nessus network scans
• scheduled Nessus credentialed scans for patch auditing
• realtime vulnerability data from the Passive Vulnerability Scanner

This allows many forms of vulnerability detection to be used for accurate detection of all network vulnerabilities. It can also accept realtime IDS events from Snort, Tipping Point, Dragon, the Cisco IDS/IPS, NFR's Sentevist and IntruSheild. When these events are received, they are correlated in realtime with any relevant vulnerability on the target port or client of the attacked system.  A video demo of this process can be seen here.

If your organization is running Snort IDS sensors, the Security Center can also be used to push signatures from the Sourcefire VRT signature set and/or the Bleeding Snort signature set. The Security Center can push either the latest available signatures, or only push the Snort rules for which you network has vulnerabilities. This allows your Snort sensors to run with less rules.

If this was useful to you ....

Tenable has several white papers and available webinars on this topic.

• White Paper - Correlating IDS Alerts with Vulnerability Information
• White Paper - Security Event Management
• Recorded Webinar - Network and Behavioral Anomaly Detection (recording available)
• Live Webinar - Interview with Richard Bejtlich, Founder of Tao Security (Nov 17, 2006)
  Mr. Bejtlich is a noted author on network security monitoring.
• Live Webinar - Interview with Thomas Ptacek, Founder of Matasano Security (Nov 28, 2006)
  Mr. Ptacek was a pioneer in NIDS evasion research.
• Live Webinar - Correlating IDS events with Vulnerabilities (Dec 1, 2006)

As always, if there is interest in learning more about Tenable product offerings, please contact us at sales@tenablesecurity.com. Besides VA/IDS correlation in the Security Center, Tenable also offers a variety of correlation solutions for many log and network sources in the Log Correlation Engine.
 

Most companies have some sort of policy in place which defines network or computer activities which are considered 'Acceptable computer usage'.  Such policies are often difficult to enforce.  The Tenable Passive Vulnerability Scanner (PVS) can help companies detect and report on inappropriate usage. This blog post discusses how the PVS can be used to look for policy violations and items such as credit card numbers, social security numbers and other types of sensitive content in motion.

Tenable ships PVS with (at the time of this writing) about 3,000 distinct checks.  The primary focus of these plugins is to discover hosts, applications and their related client/server vulnerabilities. The entire list of built-in PVS checks can be perused here.  As you will note, there are already many plugins (or even entire families) which detect and report on what many corporations would consider 'Inappropriate usage'.  These categories or plugins include, but are not limited to,:

• Game server detection
• Botnet client and server detection
• Peer to Peer file serving
• IRC server/client
• Chat clients
• tunneling software or applications like Tor, gotomypc, and logmein
• and more

Below is an example screenshot of PVS discovering an internal system which is allowing external, remote access via logmein.com. It is being viewed under the Security Center.:

Detecting Custom Activity Prohibited by Policy

What if, however, you are a company that would like to look for something specific with respect to your corporate policies and guidelines? Creating your own PVS policy file may be a good investment of your time. 

Tenable has created detailed documentation on writing custom plugins.  The documentation can be viewed here.  The documentation details how to write detection rules for the PVS which are saved as files referred to as "prms".

If, for example, you wanted to view all users who were accessing a competitor's mail service, or all users who were managing their myspace.com web page from the corporate network, etc.,  you could create a custom prm policy file to detect and report on these issues. 

Let's walk through a quick example.  Our first plugin will detect users logging into myspace.com accounts.  We will first create a unique plugin ID of '9000'.  So, the first line of our plugin will be:

id=9000

Next, we will want to have a description of what the vulnerability detects.  So, we will create a description of:

description=The remote client was observed logging into a myspace.com account.  You should ensure that such behavior is in alignment with corporate policies and guidelines.  For your information, the user account was logged as:
  %L

The '%L' will be the results of our regular expression statement which we will create later.  In a nutshell, we want to log the source address of the offending computer as well as the UserID that they used to log in.  Next we will create a distinct name for our plugin.

name=POLICY - myspace usage detection

Note that I begin the name with the string 'POLICY'.  This will make all POLICY violations easily searchable from the Security Center interface.  In addition, you could actually define a Security Center dynamic asset list which contained only POLICY violators. 

Our next field will be a family.  As this is a client web application (a browser), we choose the family ID of:

family=Web Clients

And, since this is a web browser, we can assign a dependency which will tell PVS to only look at clients which have been observed surfing the web:

dependency=1735

Further, since we are looking at client traffic, we will define:

clientissue

Next, we will assign a risk rating for the observed behavior:

risk=MEDIUM

In the final section we will create 'match' and 'regex' statements which PVS will look for passively.  We want all of these statements to be true before we flag the client for inappropriate usage:

match=>POST /

The web request must begin with a POST verb.  This will weed out all those 'GET' requests right off the bat.

match=^Host: login.myspace.com

We want to ensure that they are posting to the host 'login.myspace.com'

Finally, we have a match and regex statement which detects their login credentials: 

match=email=
regex=email=.*%40[^&]+

Putting it all together, we have a single plugin which reads like:

id=9000
description=The remote client was observed logging into a myspace.com 
account.  You should ensure that such behavior is in alignment with 
Corporate Policies and guidelines.  For your information, the user 
account was logged as:  %L
name=POLICY - myspace usage detection
family=Web Clients
dependency=1735
clientissue
risk=MEDIUM
match=>POST /
match=^Host: login.myspace.com
match=email=
regex=email=.*%40[^&]+

You could name this plugin myspace.prm and add it into the /usr/nevo/var/nevo/plugins/ directory.  Or, for central management of PVS policy plugins, you could log into the Security Center as the 'tns' user and upload the plugin into the /opt/sc3/proxy/outbound directory. 

When the behavior is caught, it will generate a Security Center entry like:

If you wish to create a policy file which included multiple checks, you will need to use the reserved word 'NEXT' within the policy file.  Example:

id=9000
rest of plugin

NEXT

id=9001
etc

Detecting Confidential Data In Motion

Finally, many organizations will want to ensure that confidential data does not leave the network.  PVS can look at binary patterns within observed network traffic.  So, for example, if the security group had the ability to modify or specify modifications for critical corporate assets, then PVS will have the ability to detect these files being passed outside the network.  Example:

Create a document which has a binary string of:
0xde1d7f362734c4d71ecc93a23bb5dd4c and
0x747f029fbf8f7e0ade2a6198560c3278

A PVS plugin could then be created which looked for this pattern

id=9005
trigger-dependency
dependency=2004
dependency=2005
hs_dport=25
description=POLICY - Confidential data passed outside the 
corporate network.  The Confidential file don'tshare.doc was 
just observed leaving the network via email.
name=Confidential file misuse
family=Generic
clientissue
risk=HIGH
bmatch=de1d7f362734c4d71ecc93a23bb5dd4c
bmatch=747f029fbf8f7e0ade2a6198560c3278

How were these binary codes generated?  They are just md5 hashes of the following strings:

"Copyright 2006 BigCorp, file: don'tshare.doc"
"file: don'tshare.doc"

The security compliance group maintains the list of mappings (confidential file to md5 hash).  The md5 hash would be embedded within the binary file and could then be tracked as it traversed the network.   

You can do similar checks against ascii strings (if, for example, the attacker cut-and-pasted confidential data into an email).  You just create text watermarks which appear benign to the casual observer and map to a specific file name.  For example:

"Reference data at \\192.168.55.2\c$\shares\employmentfiles for HR data regarding Jane Mcintyre" could be a string which maps to Finances.xls.  A PVS plugin could look for the string like:

id=9006
trigger-dependency
dependency=2004
dependency=2005
hs_dport=25
description=POLICY - Confidential data passed outside the 
corporate network.  Data from the confidential file Finances.xls was just 
observed leaving the network via email.
name=Confidential file misuse
family=Generic
clientissue
risk=HIGH
match=Reference data at
match=192.168.55.2\c$\shares\employmentfiles
match=for HR data regarding Jane Mcintyre

The two plugins above (id 9005 and 9006) would detect files leaving the network via email.  Most corporations have a list of ports which are allowed outbound access.  SMTP is typically one of these ports.  Other ports may include FTP, Messenger client ports (AIM, Yahoo, ICQ, etc.), Peer2Peer (GNUTELLA, bittorrent, and more).  Depending on your specific network policy, you may wish to clone plugins 9005 and 9006 to detect these strings on other outbound protocols.

Policy Abuse Files

Tenable is releasing four policy files which look for Social Security Numbers, Credit Card numbers, surfing of Pornography, and generic policy violations.  The two examples, from above, are included in the 'policy.prm' file.  Any one of these files could be used as a template for creating a specific, corporate policy file.  The four files can be found at:

• http://www.tenablesecurity.com/pr0n.prm
• http://www.tenablesecurity.com/policy.prm
• http://www.tenablesecurity.com/cc.prm
• http://www.tenablesecurity.com/ssn.prm

After creating your custom policy files, the Security Center can be used to centrally manage and disperse these policy files to all PVS instances.  To do this:

1. Log in as user 'tns'
2. Upload the policy files to /opt/sc3/proxy/outbound

That's it!  The Security Center will disperse the policy files and begin reporting on policy infractions.

Nessus 3 users who have subscribed to the Direct Feed service can audit the configurations of many OSes, including OS X. This blog entry will show the basic configuration of an OS X device to allow auditing by Nessus 3.

Configuring Remote Auditing for OS X

The first step to auditing an OS X system with Nessus is to allow remote SSH access. To do this, as an administrator of the OS X system, under sharing, enable "Remote Login" as is shown below:

By default, your firewall settings should allow inbound SSH to the OS X system. If you've modified your firewall configuration to stop SSH or block certain IP addresses, this may effect your Nessus scanning.

Next you must create a user and configure it for use with Nessus certificates.

Note: Actually, Nessus supports usernames and passwords for SSH authentication, but this means you need the same username and password combination on your systems, so we recommend creation of shared SSH keys.

Add an "audit" account as shown below:

At the command line, copy the SSH public key you've created for your Nessus scanner into the audit account's home .ssh folder.

You will likely need to create the hidden .ssh directory as well as set the permissions of the directory as indicated in the "Nessus Credentials Checks for UNIX and Windows" paper.

Since we are on OS X, these commands need to be accomplished with administrator privileges which requires the sudo command.

Configuring Nessus 3 for Windows to Audit OS X

To then scan the OS X system, create a scan policy which takes advantage of the existing credentials, as well as specifies a UNIX compliance .audit file. Each Nessus client is slightly different, and below is a screen shot of how Nessus 3.0.4 can be configured to audit an OS X system:

Note that the SSH username (the username of "nesssus") for the OS X server has been specified as well as both the public and private SSH keys (which become blocked out once loaded). To configure a .audit file, obtain one from the "Nessus 3 Agent-less Compliance Checks" web site and download it to the system where your Nessus client is running.

Configuring the Security Center to audit OS X Systems

Under the Security Center, auditing an OS X system is no different than auditing another other UNIX system.

First, you need to create a vulnerability policy which specifies credentials for the target OS X system(s). Second, that same vulnerability policy should be configured with the desired .audit tests to be performed.

Note: The Security Center can also maintain separate credentials per asset group which overrides the credentials in the vulnerability policy.

After running a scan, OS X compliance results will look similar to the screenshots below:

Results Summary	Compliant Results	Non-compliant Results

Moving Forward

The National Security Agency has published a guide for hardening OS X systems. Tenable will be releasing a .audit file for Nessus 3 to perform configuration analysis specific to OS X servers. Since OS X is based on UNIX though, many of the current .audit files generate very good results.

If this sort of auditing is interesting to you, please feel free to contact Tenable's sales staff to inquire about the Direct Feed or the Security Center. Also, Tenable has also made a video demonstration of Nessus 3 performing configuration audits available to the public.

Tenable continues to offer interesting content. We've added three new presentations and interviews to our list of webinars.

Interview with Thomas Ptacek, Founder of Matasano Security
November 28, 2006 -- 2:00 PM - 3:00 PM EST
https://www.gotomeeting.com/register/140139085

The Six Dumbest Ideas in Computer Security - By Tenable CSO, Marcus Ranum
December 11, 2006 -- 2:00 PM - 3:00 PM EST
https://www.gotomeeting.com/register/544902356

Active and Passive SCADA Network Monitoring
December 12, 2006 -- 11:00 AM - 12:00 AM EST
https://www.gotomeeting.com/register/320188680

Next week I'd like to remind readers that I'll be interviewing Richard Bejtlich of Tao Security.

Interview with Richard Bejtlich, Founder of Tao Security
November 17, 2006 -- 10:00 AM - 11:00 PM EST
https://www.gotomeeting.com/register/313888669

Also, the previous "Network Based Anomaly Detection" and "Future of Vulnerability Management" webinars have been recorded and posted. If you missed the original talks, you can get to the recorded webinars at your convenience here:

Network and Behavioral Anomaly Detection
https://www.gotomeeting.com/register/115997810

The Future of Vulnerability Management
https://www.gotomeeting.com/register/646873749