Penetration tests are typically a point-in-time exercise to determine if a remote adversary or malicious insider can compromise systems that contain sensitive data. Most organizations do not conduct penetration tests on a daily basis. Instead they schedule them annually, quarterly, or in some cases monthly. Penetration tests procured on a consulting engagement are often limited to key systems and assets rather than the entire network of systems. This diminishes the value of the penetration test as the results quickly become outdated and may not be relevant to new systems or recent network changes. However, by correlating the availability of exploits with a continuous monitoring program to identify vulnerabilities, an organization can have a better idea of how “exploitable” they are on a real-time basis.

Assessing the security of SCADA devices has always been a challenging task. SCADA devices are used in several critical infrastructure industries, including power plants, manufacturing, chemical processing, and nuclear reactors. Thus, the high availability and security of these devices are of the utmost importance. The challenge lies in assessing the security of SCADA devices without causing any adverse effects. The special purpose-built systems often operate within a limited scope and use protocols that are specific to the tasks being performed, such as Modbus, OPC, and DNP3.

In 2006, Tenable Network Security released the first Nessus® vulnerability scanner and Tenable Passive Vulnerability Scanner (PVS) SCADA plugins (you can read the original release notes for PVS in a post titled "SCADA Network Monitoring" and the original release for Nessus titled "SCADA Checks For Nessus 3"). In April 2011, a new round of SCADA plugins were released for Nessus (covering devices from Movicon, 7-Technologies, and more).

Tenable is now pleased to announce the availability of additional SCADA plugins for Nessus ProfessionalFeed, Tenable SecurityCenter, and PVS users. Tenable's research team worked alongside SCADA experts from Digital Bond to test and identify a wide variety of common SCADA devices. The plugins were announced at Digital Bond’s S4 Conference on SCADA security held on January 19, 2012. Note: Digital Bond’s Dale Peterson joined us on the Tenable Network Security podcast episode 110 and spoke about the new plugins and SCADA security.

Below is a sample of some of the new SCADA plugins:

Note -- this blog was updated on Feb 2, 2012 to highlight detection of the Symantec advisory SYM12-002 as well as new additional Nessus local checks to audit pcAnywhere installations.

With the recent news from Symantec that their source code theft has left pcAnywhere open to attack, it makes sense to audit your network for instances of this desktop sharing software. 

Nessus has many checks that identify the presence of pcAnywhere, the type of network access supported by it, and some vulnerabilties in the application. A current list is shown below for reference:

• 10006   Symantec pcAnywhere Status Service Detection (UDP)
• 10794   Symantec pcAnywhere Detection (TCP)               
• 10798   Symantec pcAnywhere Service Unrestricted Access       
• 20743   Symantec pcAnywhere Launch with Windows Caller Properties Local Privilege Escalation
• 32133   Symantec pcAnywhere Access Server Detection Service
• 35976   Symantec pcAnywhere CHF File Pathname Format String Denial of Service
• 57795   Symantec pcAnywhere Installed (local check)
• 57796   Symantec pcAnywhere Multiple Vulnerabilitities (SYM12-002)

In addition, running a credentialed scan with Nessus plugin 20811 provides the ability to detect installed software on Windows computers, which can be useful to find instances of pcAnywhere that may be installed, but not actively running. Note that strings and versions vary from release to release. An example string as reported by a recent Nessus scan is “Symantec pcAnywhere [version 11.5.0]”.

Network traffic can also be monitored with the Passive Vulnerability Scanner to identify instances of pcAnywhere on the network. A current list of passive plugins to detect pcAnywhere is shown below. 

• 03306 Symantec pcAnywhere Detection
• 06087 Symantec pcAnywhere Detected

Finally, Tenable’s Log Correlation Engine, will normalize logs from the PVS for observed pcAnywhere sessions in real-time with an event name of “PVS-PCAnywhere_Detected”. These sessions are automatically detected and analyzed for anomalies and connections from known botnets.

External Nessus scans can be performed to determine if your network has any Internet facing instances of pcAnywhere. The Nessus PerimeterService is ideal for this type of scanning as it can scan an unlimited number of Internet-facing IP addresses very rapidly. Users of the Passive Vulnerability Scanner have automatic detection of any Internet-facing service, including pcAnywhere.

An in-depth Nessus Discussions Forum post details how SecurityCenter, Passive Vulnerabiltiy Scanner and Log Correlation Engine users can track pcAnywhere vulnerabilities and usage in realtime.  

Do you know how many mobile devices reside on your network? Is your security architecture designed to secure the mobile platform and protect your users and the network from the threats they pose?

Mobile devices are a security concern for many reasons. Mobile devices are typically unmanaged – meaning they may or may not be running AV software, a firewall, or conform to enforceable security policies. Yet, whether they are provided to your employees as part of your operations or not, they are likely accessing resources on your network. To compound the problem, many mobile devices connect to your local network and the Internet directly on two separate mediums. For example, the device may associate to a wireless belonging to your organization and a 3G/4G connection to the Internet.

Why is "Cloud Storage" So Appealing?

Services such as DropBox use the cloud to enable users to share files with others and transfer work from office to home and back. The challenge is two-fold:

1. Determine how this and other cloud-based technologies align with the organization’s security policies and compliance mandates.
2. Monitor use of these solutions to ensure compliance and limit exposure while preserving benefit.

Users often turn from sanctioned file sharing methods when they reach the limits of email and internal file sharing capacity, performance, and functionality. Email was not intended to share large files, and very often restrictions are implemented on the size of an individual email and how large your inbox can grow. Users can put files on an internal file sharing service, but that limits access to local users and VPN connected users. Employees who travel or third-parties may not have access to the internal network to retrieve the files. Many IT departments do not offer an easy way to share files through more traditional methods such as public FTP servers because of security concerns.

Dropbox overcomes many of these issues and has become quite popular, as evidenced by a recent influx of $250 million additional dollars in funding. The price is right too, as you can get 2GB of storage for free and manage access to your files.

The problem is, DropBox security and usage often violate corporate policy and security best practice. Corporate policy must protect sensitive information, such as customer data and intellectual property. If this information is being transmitted insecurely to a service such as Dropbox your policies and network defenses should detect this behavior and monitor for violations and information leakage.

For example, Dropbox relies on SSL for encryption. Several attacks released this year have been reported that can circumvent SSL security, and SSL certificate authorities have been compromised, breaking down the trust that SSL relies upon for security and integrity. Client software can become the weakest link as well, even if SSL is implemented properly. The Dropbox client software has contained vulnerabilities that, when exploited, could lead to your data in the wrong hands.

To solve this problem we need to implement encryption at the file level to protect sensitive data. I have to admit, I am a Dropbox user. However, I use it with caution and implement my own security policy. Any sensitive data is sent to DropBox using file encryption (PGP in this case). Any non-sensitive information is not encrypted and I am careful to distinguish between the two.

Tenable’s Passive Vulnerability Scanner (PVS) performs protocol analysis on network traffic to discover vulnerabilities and log the sessions that have occurred. Unlike network forensic systems which log the actual packets and session content, the PVS creates a single syslog message for each identified network session. These logs are ideal for consumption by a SIEM or log analysis tool such as Tenable’s Log Correlation Engine. This blog entry describes what types of applications are logged and how they can be used for alerting and analysis.

"The Untouchables"

An untouchable system is one on which you cannot install software (such as agents) or apply security fixes regularly. I have come up with several different examples of such systems, and tried to use examples here from my own experiences to define why they may fall into the "untouchable" category:

• Select SCADA systems - This is a broad category, but it boils down to computers that are used in control systems networks. While many may be considered to be "air-gapped" (physically disconnected from any other types of systems), that may not actually be the case since connectivity is required to manage the devices (especially those deployed in the field). I was once approached to perform a vulnerability assessment against one such system. I was told that network access would be provided, but that the system in question was responsible for providing power to thousands of people. This is a scary endeavor, as not only could you put thousands of people in the dark, but potentially damage infrstructure if the power is turned on and off too quickly. This situation requires a different approach than a traditional network vulnerability assessment or penetration testing.
• Traveling Laptops - It can be difficult to control the software and patches on systems that rarely connect to the corporate network. The concern is what happens when a laptop that has been connected to airport, hotel and other potentially hostile networks comes back to home base and plugs into your network. It may already be infected, and may not be up-to-date with patches. You can try to force users to connect back to your network via a VPN, but not all users may do this on a regular basis. During the user’s travel, the system is "untouchable".
• Network Devices – Let’s face it, no matter how redundant your network is, you just can't blast out a firmware update to your network gear at will. This leaves a good percentage of network systems that are "untouchable" for certain time periods. Routers have a bit more flexibility, but the physical switches that your systems are connected to cannot be taken down at will, or users will lose connectivity as flashing the device with new firmware requires that the system become unavailable for short time period (or longer time period depending on the device and software).

An off-port web server is one that doesn't run on the common ports of 80 or 443. Management consoles, development systems, devices that speak HTTP for their protocol and many other systems can run on any port, typically 8080 or 8443.

Nessus plugin 29871 has been updated to look for the presence of malicious JavaScript on a remote web site.

(See Attack on ASP site that uses a SQL server database)

Below is an example of the plugin report:

Click for larger image

Successful Attacks from Automated Malware

Recently, malware dubbed "LizaMoon" (named after the first web site found distributing it) has been popping up in the news:

Dubbed LizaMoon, unidentified perpetrators of the scareware campaign inject script into legitimate URLs, so when people try to access the website, they get redirected to a page warning them that their PCs are infected with malware that can be removed by downloading a free AV application called Windows Stability Center.

From LizaMoon SQL Injection Attack Hits Websites

LizaMoon scans web sites for easily exploitable SQL injection vulnerabilities, then uses that to put redirects on the web site that take users to a site which installs malware. This is not a new form of attack, however the "Lizamoon" malware has been surprisingly successful. Google searches for infected sites report that over 1.5 million pages have been infected. The important thing to not about the numbers of infection is "pages" does not refer to sites, as a site can have multiple infected pages. This type of attack typically works as follows:

There are a variety of indicators that a system has been compromised, ranging from the obvious to the very subtle.

Less obvious indications of a compromise include increased bandwidth, subtle IDS alerts (such as those indicating anomalous behavior) and mysterious configuration changes on systems. The questions that are typically asked include "How did they get in?" and "What did they do?" Tenable's Passive Vulnerability Scanner (PVS) provides useful information for answering these questions. Following are some of the alerts PVS may generate during an intrusion:

It's 4:55 PM on a Friday and you are looking forward to an enjoyable dinner with your family. Your Blackberry starts buzzing from across your desk while your inbox starts filling up with alerts from your SecurityCenter along with frantic emails from Human Resources. It seems a disgruntled employee named Jack Black quit today and nobody remembered to tell the IT group to disable his accounts until after important files started disappearing. Suddenly, you are stuck in Incident Response mode, gathering data on the user's activities. Do you cancel your reservations?

Fortunately, you have deployed Tenable Network Security's Unified Security Monitoring products, and have a wide array of resources[1] at hand to streamline the response process. These resources include SecurityCenter, the Passive Vulnerability Scanner (PVS) and Log Correlation Engine (LCE). At a high level, what can these resources do for you?

SecurityCenter

SecurityCenter provides a unified view of both vulnerability and event data along with the alerting, ticketing and reporting required for thorough user forensics.

Passive Vulnerability Scanner

PVS not only tracks vulnerabilities, but logs user and network activities detected in real-time on the wire. These activities include:

Based on customer demand, Tenable Network Security is introducing two new license types for the Passive Vulnerability Scanner. These are: 

• Unlimited PVS sensor deployments within a Class B
• Unlimited PVS sensor deployments within a Class C

Tenable will continue to offer an unlimited network monitoring license for a single PVS sensor. 

The additional license types allow an organization to consider deploying passive network monitoring without having to know exactly how many sensors they need. Tenable has many customers that deploy PVS sensors on the perimeter of their network before realizing that they could also benefit from direct passive monitoring of internal systems. 

We've received requests for a PVS license of this type to help monitor SQL databases, VPN termination points, virtual server farms, web sites subject to PCI DSS, segmented VLANs and users or offices deployed behind NAT devices.

If you would like to learn more about PVS pricing for these new license models, please contact our sales staff. 

Tenable Network Security recently received a patent for monitoring network traffic and analyzing it to perform discovery of systems, applications and vulnerabilities. This is the core function of Tenable's Passive Vulnerability Scanner and also a core component of our Unified Security Monitoring strategy. 

Web application auditing is really difficult if you don’t know about the presence of a website or specific application. You may not know about a web server. You may not know what applications run on that single web server. You may even have malicious websites installed on your network by malware or Trojans. Nessus is great for scanning and finding web servers, even on uncommon ports, but you need to scan often to get the most benefit. Fortunately, Tenable’s Passive Vulnerability Scanner (PVS) can discover new web servers and all of their active web sites in real-time and without any impact to your network. This blog discusses how the PVS can be used to audit networks to find all authorized and malicious websites in use.

Tenable Network Security is proud to announce the release of version 3.2 of the Passive Vulnerability Scanner (PVS). This product is a network sniffer that scans for real-time vulnerability data and transmits it to Tenable’s Security Center management console along with real-time user and forensic activity transmitted to Tenable’s Log Correlation Engine (LCE). This blog entry describes many of the new features and enhancements in this release.

Airport "Security"

Those of us who travel through any U.S. airport are used to the inconvenience of airport security - the long lines, metal detectors, having to take off your shoes, belts, earrings, and of course the ominous "liquids and gels" inspection. While most people accept these inconveniences as an unfortunate necessity, much of what has been implemented shares some of the common pitfalls found in many computer and network security programs. Using the U.S. airport security model as an example, let’s take a look at some of the security being implemented and relate it to security gone wrong in the enterprise:

The dreaded long lines at airport security are a by-product of the current security model at U.S. airports.

Defeating Zombies

Attackers have a number of avenues leading directly into your network, and more importantly, into your data. Each week I read about new data losses, phishing scams and the release of hundreds of new vulnerabilities and exploits. Organizations are employing a rear guard action that is not necessarily tuned to today's attack techniques.

Tried and true defensive measures such as firewalls, anti-virus software, Intrusion Detection Systems provide "operational security", but even if this is running flawlessly, it is typically not enough. Security programs need to evolve with the latest attack trends and Internet technologies. A great blog post by Tim Mugherini titled, "Don't be the Smelly Kid" sums this up nicely. This defines a shift from attackers targeting network services, and moving towards attacking web application and client software. These new methods require updated education for management and the implemention of new and different security projects to protect your infrastructure.

Considering Halloween is around the corner, your security strategy can be compared to the situations in typical horror movies. When the defenseless victims are under attack from whatever threat is posed (zombies, Jason, Freddy, Michael Meyers, etc.), they often make common mistakes such as taking all of the furniture in the room and piling it in front of the door and leaving the windows unsecured. Shooting zombies in any other location other than the head is another good example (those who have read "The Zombie Survival Guide: Complete Protection from the Living Dead" know that the only way to destroy a zombie is to destroy the brain!).

When analyzing network traffic it’s typically not as important to look at the contents of the packets; rather the information about them, where they are going and how they got there. This “network metadata” (often referred to as NetFlow data) can reveal interesting information about your network and often uncover misconfigurations, policy abuses and security incidents. I relate it to the movie "The Matrix". In the movie there is a scene where the characters are looking at computer screens displaying “the matrix”. Those who are not accustomed to looking at the matrix will not see "The Blonde" or the "Brunette", but will just see a bunch of green characters.

SQL injection is a class of vulnerabilities that can plague web applications in your environment, often with devastating consequences. They can be difficult to detect and validate and are sometimes the cause of major data breaches. This is a deadly combination. Databases contain the information that attackers are after, including SSN, credit card numbers and other information associated with an individual’s identity such as name, address, phone number, mother's maiden name and more.

Conficker Attacks UPnP

The Conficker worm behavior has been analyzed by many security professionals who have shared their findings with the community (the paper from SRI is a great example). One of the common findings is that Conficker will connect to the local route/gateway via UPnP and make changes to the firewall, if the firewall supports unauthenticated UPnP. If so, it uses UPnP to open a high numbered port in the firewall, allowing access to that port from the Internet. It then opens the same port on the infected host, and uses it to distribute the worm further across Internet. The use of UPnP as well as insecure UPnP devices can be detected by Tenable's Nessus and PVS products.

Getting In The Middle

Un-patched and out-of-date software is a common attack vector for penetration testers and attackers alike. Applications such as Adobe Reader and Microsoft Office are popular targets due to their widespread use on Windows systems and user’s willingness to click on just about anything. They both have the ability to perform self-updates, similar to the operating system, but limited to one particular software package. However, what happens when the software update process itself is insecure? Enter a program called "evilgrade", which exploits this process to install software of an attacker's choosing. For this attack to succeed, the victim machine must be the victim of a Man-In-The-Middle (MITM) attack.

Passive Detection

Monitoring networks for potential security violations can uncover some interesting events and surprising aspects of applications.
Base64 encoding is used by many applications to "obscure" the password when it travels across the network. Base64 encoding does not implement a cryptographic algorithm to protect sensitive information, yet is often used in many networks and end-user applications.

This blog entry concerns passive network monitoring with both the Passive Vulnerability Scanner (PVS), as well as the Log Correlation Engine. Tenable's research group has recently introduced PVS rules to identify mail clients and end nodes which are likely sending SPAM.

This blog entry will discuss this technique as well how the Security Center and Log Correlation Engine can be used to analyze traffic from hosts that are sending SPAM. None of the examples shown below provide a "smoking gun" of a detected SPAM server on purpose. The focus of this blog entry is to show how different types of analysis techniques can be used to understand network activity.

SPAM Analysis with PVS

PVS plugins #4122 through #4127, as well as plugins #4184 and #4185, detect potential email clients and end nodes that are engaged in SPAM activity. For example, the PVS will log a system as a potential SPAM source if an email is sent and a "551. Relaying Denied" message is returned. Other techniques are used as well. Below is an image of a detected SPAM server report:

These alerts can be sent in realtime via SYSLOG or consumed by the Security Center to see which of your internal organizations may be sending SPAM messages.

It's important to note that normal email activity can result in behavior that might be flagged as a potential SPAM source. For example, we've all sent email to an address which is incorrect, but we are not a SPAM server. However when SPAM emails are sent, very often they will attempt to email accounts that are no longer active. The idea with these PVS rules is to help classify which systems might be SPAM servers in order to more easily analyze them as we will do in the following sections.

Creating an Asset List of all SPAM systems

With the PVS rules detecting potential SPAM servers, we can use the Security Center to create a dynamic asset list of just these hosts. This will create a unique list of just the IP addresses that the PVS thinks might be a SPAM server.

To do this with the Security Center, go to the "Assets" button, and then choose "Dynamic Assets" and then "Add new". Choose a name of "SPAM Server" and create an empty list. From the list of existing rules, then select the rule for "SPAM Server" by clicking on the 'R' icon. From there. click on the large 'A' and then add a plugin ID match for 4122 which is the first PVS SPAM rule we will match on. Click on the 'A' and repeat for 4123 through 4127 and then also add in 4184 and 4185. When finished, you should see a rule which looks similar to this:

Once this rule is set, the Security Center will automatically process this and create an updated asset list. If one is not created, you can force this to occur by clicking on the "Update Asset List" button. When finished, clicking on the "Asset List Control" button can give you a list of all IP addresses that are suspected to be SPAM sources. As new data from the PVS arrives at the Security Center, it will also dynamically update this asset list.

Analyzing Traffic From SPAM Sources

Now that this asset list is created, it can be used to analyze data we've received from the network. Customers who have deployed the Log Correlation Engine can use the "SPAM Server" asset list to effectively find SPAM sources on their local network. This can be used to isolate port 25 network traffic, connections with known "blacklist" sources and focus on IDS events directed against these systems. The idea is to use the list of known SPAM servers as a potential filter on the immense amount of data typically collected by the Log Correlation Engine.

Example 1 - Connecting to a Blacklist

We've blogged before about how any type of event or network connection can be considered by the Log Correlation Engine for interaction with a published "black list" of IP addresses. If we have all of the network events for a large organization with suspected SPAM servers in it, a useful filter would be to see which blacklist events may have occurred to or from our list of SPAM servers.

Below are two examples from a test site which uses network IDSes, and the Tenable Network Monitor along with the Security Center, Nessus, PVS and Log Correlation Engine.

Blacklist Events	All Events

In the example on the left, a list of all matching "blacklist" event types has been produced for the "SPAM Server" asset list. It is interesting to note that there have been correlations with not only the SANS ISC list of scanning hosts, but also the Bleeding Threats list of Botnet Sources as well as the Spamhaus list of known spammers.

I would not consider the SANS correlations that significant, as this report came from a small university environment which is often scanned by hosts tracked by the SANS ISC. However, having an asset list of known potential SPAM servers connect to a list of botnets or SPAM sources is very interesting.

Both detection techniques (the PVS analysis to find potential SPAM servers as well as the blacklist correlation) are independent of each other. Knowing that some of these hosts may be under control of a botnet and being put to use for sending SPAM can help plan out a course of action and response. In this example, it is also interesting to note that two different forms of network IDS monitoring were in place and neither detected any odd infection, compromise or SPAM activity. 

The second example on the right was a list of all events recorded by the Log Correlation Engine for the "SPAM Server" asset list over the past 24 hours at the same location. All network sessions, blacklist events and PVS events are listed. There were even a few Never Before Seen and Crowd Surge events.

Example 2 - Activity Analysis

Considering the last five days of pure "network" activity for the "SPAM Server" asset list, the Security Center can produce activity graphs and port usage statistics as shown below:

Port Summary	Network Activity

In the port summary, as expected, the most common port used was 25. What is interesting is that the second most used port is port 80. It is very likely that some of these systems are desktops or servers which have been compromised and are also being used for regular web browsing.

In the second image, for the same five days of activity, all network activity on any port is graphed out. The three initial peaks correspond with the previous Wednesday, Thursday and Friday and are followed by two smaller peaks for Saturday and Sunday.

Being able to perform this sort of analysis can help identify trends and "top talkers". Keep in mind that with a dynamic asset list, this analysis is always looking at the activity for the most recent lists of IP addresses of interest reported by the PVS.

From a SPAM detection point of view, it would have been interesting to see if there was a spike of port 25 traffic or one or more hosts in particular that sent a disproportionate amount of spam. At this demonstration site, such traffic was not observed though.

Example 3 - Connection Activity

With the "SPAM Server" list in place and the PVS and LCE continuing to monitor the network, it would be interesting to analyze the connections to and from this suspected list of SPAM servers.  There are several types of connection tracking available to us:

• The PVS logs any internal IP address that has completed one or more TCP connections.
• The PVS logs any "browsed" UDP or TCP ports.
• The LCE can graph out the start time, stop time and total bandwidth of any TCP connection.

For the site in this demonstration, doing a summary on PVS plugin #00002 (Client Side Port Usage) shows us the following graph:

This is interesting as ports such as 3724 (used by World of Warcraft) , 5000 (well known for many Trojans), 6001 (X Windows) and 7000 (also well known for many Trojans) are more closely associated with client side applications or compromised nodes.

Knowing that these systems are email servers or systems that are sending email, it is also interesting to consider which ports are open on the "SPAM Server" list of IPs and accepting external connections from the Internet. Such as query produces the following graph:

It is understandable that many of these systems receive email on port 25 and also be a web server. The  other "high" ports are most likely web management interfaces. Using the 3D Tool, we can analyze which ports are open on which IP addresses with the "SPAM Server" asset list. Doing a query for the "SPAM Server" asset list as well as PVS rule #14 (Accepts External Connections) renders a port to IP address display such as this:

The bottom column (left to right) is ports and the axis moving away from us graphs matching IP addresses. The vertical line of columns is on port 25. This tells us that each matching IP address had accepted a port 25 connection from the outside of the network at least once. The other columns show the distribution of open ports across the other IP address. The address in the first row has accepted connections on port 22, 25 and several other high ports.

Performing this analysis in 3D with a few dozen IP addresses may seem like overkill, but the same techniques can be applied when analyzing 100s or even 1000s of nodes.

Any of these ports could be legitimate traffic, or it could also be a command and control channel for a botnet.  To dig into this further, we could analyze these browsed ports and open ports with traffic collected by from the Log Correlation Engine. We could also look at the clients and banners reported by the PVS on these ports in question. And lastly, we could try to do some active scanning on these hosts and see if that turns up any particular vulnerabilties or other open ports.   

For More Information

If this blog entry has interested you, Tenable has previously blogged about how basic passive network monitoring can be used to identify SPAM servers.

The Passive Vulnerability Scanner's plugin rule base was recently updated with new logic to recognize a variety of client-side account information for services such as AIM, MySpace and many others. This blog entry discusses the new rules and how they can be used for auditing a network.

Current User ID Rules

The following decodes are currently available in the live plugin update feeds for the Passive Vulnerability Scanner:

• 1329 return email addr
• 2341 POP3 User
• 2600 MSN Messenger UserID
• 2609 PGP Sender email
• 3018 HTTP Base64 encoded credentials
• 3954 IDA Pro UserID
• 4082 AOL Instant Messenger user enumeration
• 4098 IMAP UserID enumeration
• 9000 Myspace UserID
• 9001 Facebook UserID
• 9003 Xanga UserID
• 9005 gmail userID
• 9006 XM Radio UserID

These plugins identify a variety of specific user names and accounts that are active on any given host in a monitored network. For example, below is a screen shot of a PVS detect of a Tenable email account as
viewed under the Security Center:

Uses of This Information

If using any of these services is against your corporate policy, then obtaining the actual user name of the account and the IP address from which it originates is very useful. If this data is combined with active data from Nessus scans, such as the NetBIOS or DNS name of the source computer, this can also be useful for identifying which network users are associated with which types of external accounts.

When performing incident response and starting out with nothing more than a list of potentially compromised IP addresses, or IP addresses that are behaving oddly, being able to obtain a list of external resources and user names used on those systems is also useful. Knowing that a potentially compromised system may have been used by certain users can help incident responders prepare for what they might encounter or give clues to access vectors that a system was compromised with.

Lastly, another use of this data is to associate users to IP addresses. Being able to associate an account that "lives" on the network with a specific IP address can also track when a user gets a new IP address. In networks where centralized domain and DHCP logs aren't centralized, this can be a very useful audit trail for tracking when certain users have obtained an IP addresses or a new IP address.

Limitations

There are three limitations to this approach.

First, all email and chat user accounts are logged, regardless if they are associated with your network or not. This means you may see personal user IDs like "kungfun1nga", "rjg1969" and so on. You may also see real user names like "rongula". Mapping these accounts back to real users on your network is not a trivial task, but the data is very useful if you are responding to an incident or tracking the same private user moving around your local network.

Second, if the PVS is deployed outside of a NAT or VPN device, it won't differentiate specific IPs behind that device. For example, if you had 100 students deployed behind a NAT firewall, the PVS will only log the first email address it sees and associate it with the IP address of the NAT device.

And lastly, the PVS can detect encrypted client and server sections, but it does not decrypt them. If your users are checking mail with secure POP, secure IMAP or through a VPN, the PVS will likely be able to identify this sort of client-side activity, but won't be able to discern user names.

Using these on Your Network

A majority of these decodes are already available in the PVS updates. If you've manually synchronized your plugins lately or have your PVS managed by the Security Center, you will have these latest decodes.

Plugins 9000 through 9006 are available as a manual download under the Corporate Policy Plugins. These rules are available in the policy.prm library. If you are running the PVS in standalone mode, download the policy.prm file and place it in your /opt/pvs/var/pvs/plugins on RedHat. If your PVS is being managed by the Security Center, place the policy.prm file in the /opt/sc3/proxy/outbound directory and it will be pushed out automatically.

Disabling This Type of Collection

If gathering these user IDs is against your corporate policy, they can be disabled. On the Unix versions of the PVS, inside the /opt/pvs/etc/pvs.conf configuration file, there is a line (disabled by default) which identifies the file containing a list of plugin IDs to be disabled. The section of the pvs.conf file looks like this:

    #disabled-plugins "/opt/pvs/var/pvs/disabled-plugins.txt";
    plugins-directory "/opt/pvs/var/pvs/plugins";
    fingerprints "/opt/pvs/var/pvs/osfingerprints.txt";

Uncomment the line, create the /opt/pvs/var/pvs/disabled-plugins.txt file and place the IDs you don't want the PVS to use one to each line like this:

1329
2341
2600
2609
3018

The PVS process must be manually restarted for these settings to take effect.

For More Information

If you'd like more information about the Passive Vulnerability Scanner, please consider the following demonstration video and previous blog entries:

• (video) PVS and the Security Center are used to monitor a network of more than 10,000 nodes
• (blog) Proxy and Firewall Detection with the PVS
• (blog) Using the PVS to detect Corporate Policy Violations and Data Leakage
• (blog) Finding Interactive and Encrypted Sessions on your network

Wouldn't it be interesting to know which places you go to on the Internet or in your corporate network that have major vulnerabilities in real-time? How many of those customer portals, web sign-up forms or even the corporate blog web servers are vulnerable to recent or even not-so-recent security issues? You might think about scanning them with Nessus, but performing scans all the time or trying to obtain permission to scan isn't practical. However, there is plenty of information contained in raw network traffic that can be used to discover many different types of vulnerabilities.

This is the basis for the Passive Vulnerability Scanner (PVS) product from Tenable. In this blog entry, we will discuss how the PVS can be turned "outside" to gain knowledge of vulnerabilties throughout the Internet just by interacting them with everyday protocols.

Looking for Vulnerable Web Sites

Normally, when the PVS is deployed on an enterprise network it is told to focus "inwards" on vulnerabilities for specific addresses such as 10.10.0.0/16 or 192.168.10.0/24. However, one of the of the ways we test the PVS here at Tenable is to simply surf the web, send email, chat, use P2P CLIENTS and so on and let the PVS watch our traffic.

What we found interesting is that many common Internet sites had vulnerabilities that could be discovered just through traffic analysis. We're not talking about web application vulnerabilities, we're talking about older web servers, older versions of PHP and even unpatched 3rd party applications.

I call this "Vulnerability Tourism" because it can really show which sites are locked down and which sites have issues. It can even identify the underlying technology used at almost any site and show which sites are more "complex" than others.

What is the Passive Vulnerability Scanner?

Several years ago, Tenable released a product named "NeVO" that stood for the "Network Vulnerability Observer". It was renamed to the Passive Vulnerability Scanner (PVS) in early 2006. The PVS sniffs network traffic and produces vulnerability reports that rival what you can obtain from a credentialed Nessus scan. Nessus has advantages over the PVS when it comes to performing detailed and interactive tests as well as configuration audits, but the PVS has an advantage of silently watching your network 24x7.

Turning the PVS Inside Out

A very interesting exercise with the PVS is to set it wide open, and then start surfing the Internet or Intranet, sending mail to your contacts, chatting with folks on IM and so on. PVS has the ability to stream "new" pieces of vulnerability or network information via SYSLOG

So as you visit places like common news, search, and e-commerce web sites, send mail to your contacts, FTP product updates from your vendor or interact with anyone on just about any Internet protocol, you can see in real-time what the PVS has discovered in the network traffic.

Typical Results

By no means did we do an audit of the entire Internet; however, after surfing to many different news, search, merchandise, entertainment and other types of sites and using the PVS to analyze the traffic, several trends can easily be seen. We also visited a variety of "security" and "technology" company web sites and viewed their customer support login screens as well as various forms to request white papers and product demos. We didn't post specific results here because often the content on these web sites was copy-written, and we also didn't read each of these site's acceptable use policies.

The following general trends were very easy to observe:

• Many of the advertising servers that render marketing campaigns, click through images and other types of commercials seem to run with older versions of Apache and PHP. For example, visiting major newspaper and TV stations web sites "looked" like they were very vulnerable, but in fact it was the web servers hosting dynamic marketing content that seemed to be insecure.
• Doing Google searches for e-commerce sites claiming to be PCI certified showed basic vulnerabilities in many of the web portals, especially to newer vulnerabilities. It could be argued that this makes sense because PCI audits are only required quarterly and a site might not scan that often. I'd like to think that sites which accept credit card information would patch things like PHP quicker than what we saw.
• There is usually a disparity in security levels or technology between a hosted web site and something interactive such as a support portal, ticketing system or white-paper request form. Very often we'd visit a web site and the PVS would discover the web server of the site, but when submitting a web form, a different server would be used that was missing security patches.

Identifying Underlying Technology and Complexity

Even when no vulnerabilties are found, the PVS is looking at the network traffic to the visited sites and attempting to enumerate web servers, mail servers, the open ports and even guess the operating system. This may also yield some surprising results such as a few IIS web servers in a sea of Apache systems, or some Linux devices at a place you'd expect to be 100% Microsoft.

Another thing we ran into was that some sites are very, very complex. Visiting a simple news site could cause content to be loaded from more than 10 unique web servers. This is likely a form of load balancing, but when evaluating these unique web server types, they usually were not all of the same application. We also saw this occasionally at some smaller technology vendor sites where the blog, the main web server, the white paper request form and the e-commerce site were all different systems and different technologies. In today's environment where different functions can be outsourced, this may be understandable. However, when these systems all have similar IP addresses and are on the same network, it may be overly complex.

Enterprise Monitoring

If finding Internet vulnerabilities simply through watching "normal" network traffic seems interesting to you, then consider what can be discovered when all traffic within an enterprise network can be analyzed. The Security Center can manage multiple Passive Vulnerability Scanners the same way it manages multiple Nessus scanners.

All information from the PVS is available for reporting, consumption via spread sheets, alerting, etc. by any Security Center users. Information from the PVS can also be used to identify new assets, sort them into various asset groups and even schedule active or credentialed scans of newly found hosts with Nessus.

The PVS can also search your network traffic for evidence of documents and data in motion that contain sensitive data such as credit card numbers. It can also point out which servers host "office" files such as PDFs, Spread Sheets and Word documents.

For More Information

Qualified customers who wish to evaluate the Passive Vulnerability Scanner or wish to evaluate Nessus or the Security Center should contact our sales staff.

Multiple demonstration videos are available online.

To learn more about Tenable's strategy to use active scanning, credentialed scanning and passive network monitoring, please consider reading the Blended Security Assessments white paper. The paper outlines both the advantages and disadvantages of active and passive scanning and how using both in a blended manner is more accurate than just using one technique.

Tenable has added two new plugin families for the Passive Vulnerability Scanner. Previously, all of the Corporate Policy plugins belonged to the plugin family of "Policy". However, with plugin updates occurring today, they will now be in one of the following families:

• Abuse - Detection of pornographic activity being downloaded or served on a host.
• Data Leakage - Detection of Credit Cards, SSNs, wire transfers, HIPAA content and other types of sensitive data.
• Policy - Use of services such as YouTube, FaceBook, Gmail and so on.

In addition the following PVS plugins are also now included in the Data Leakage family:

• 3822 Office files .xls detection
• 3823 Office files .doc detection
• 3824 Office files .ppt detection
• 3825 Office files .csv detection
• 3826 Office files .rtf detection
• 3870 Detection of .xls file attachment in an email
• 3871 Detection of .zip file attachment
• 3940 Detection of .pst file attachment in an email
• 3941 Office files .pst detection
• 3943 Detection of .ost file attachment in an email
• 3944 Office files .ost detection
• 3946 Office files .uni detection
• 3963 Office files .pdf detection

Below is an example screen shot of PVS Data Leakage plugin detection as viewed under the Security Center:

For More Information

All PVS plugin families and descriptions are available in the following PDF document which is updated daily. In addition, new PVS plugin information is available in this RSS feed.

Tenable has also previously blogged about using the PVS to detect sensitive data leakage and corporate network abuse. 

When deploying the Log Correlation Engine (LCE), Tenable's support group often is asked which is better for network monitoring: using netflow from a router or performing some sort of direct network monitoring. This blog entry will help users choose a strategy and discuss some of the technical and political aspects associated.

Netflow and Direct Sniffing

If you only have access to netflow or direct network sniffing, you should not feel as if your monitoring is lacking because you are doing one or the other.

Both of Tenable's LCE agents, the Tenable Network Monitor (TNM) and the Tenable Netflow Monitor (TFM), produce a record of each network session. This record includes ports, source and destination IP addresses and total number of bytes transfered. Each of these records is consumed by the LCE for normalization, statistical profiling and for event correlation by many different TASL scripts.

There are minor differences between the TFM and the TNM. The TNM uses the libpcap library and can accept any type of valid "pcap" packet filter. The TFM also performs filtering, but it is not as sophisticated as the TNM. The TFM, as of release 2.0.2, also differentiates client and server bandwidth, whereas the TNM logs aggregate bandwidth for each session.

The TFM is available for RedHat ES3 and ES4 and it can receive netflow records from multiple sources. The TNM is available for RedHat ES3, Fedora and FreeBSD, and must be deployed on a system that has a network interface exposed to network traffic.

Leveraging "Sniffing Platforms"

If you have deployed the Passive Vulnerability Scanner (PVS) on RedHat ES3 or ES4, you should consider deploying the TNM on the same system. Tenable has monitored many large networks with servers that ran both the PVS and the TNM with very good results. Compared to the PVS, the performance requirements for the the TNM are negligible.

If your organization has deployed UNIX based NIDS such as Snort, Dragon, Bro or even dedicated network monitoring applications such as TCPDUMP or NTOP, these may also be a candidate to deploy the TNM on.

Leveraging Netflow

The TFM supports netflow records (version 5 and 9) from Cisco devices. A single TFM can accept records from multiple devices.

Since netflow is a UDP based protocol, any CPU contention at the TFM or network congestion between the routers and the TFM could cause some session loss. The TFM does have logic to reconstruct full session data if some netflow records have been missed.

The Business Case for Network Monitoring

As a security auditor or network security monitor, considering network sessions alongside system logs and NIDS events is relevant for a variety of "compliance violation" and "compromise alerting" activities.

If the organization providing access to the network (such as a routing, infrastructure or backbone group) does not have a security component, presenting them with data through the Security Center and the Log Correlation Engine may be very useful to them. If they are already collecting netflow data, perhaps for performance and availability monitoring, sending an addition stream of network session information to a TFM may not be difficult.

If direct sniffing of a data center or network is desired, you will likely need to use switch span ports, network taps or tap concentrators. This is very dependent on your network architecture, the technology of your routers and switches and how reliable your monitoring must be. For more information on this topic, readers should consider the TaoSecurity blog which discusses various aspects of this in depth as well as vendors such as NetOptics.

Filtering for Performance

As with any log aggregation and analysis exercise, you should consider the purpose of the monitoring and what sort of traffic is required. If not, you will likely over-log and record data that isn't relevant. You may also dramatically increase your storage requirements.

If the purpose of network monitoring is to identify hosts, where they connect to, which ports they browse on and what ports are being served, the LCE can tell you this, but you may be better off with the Passive Vulnerability Scanner (PVS).

For example, let's say a new application listens and browses on TCP port 7003. A user of the Log Correlation Engine may run a report for all sessions on port 7003 and then sort by IP address or network. All network sessions would need to be stored by the LCE for it to perform these tasks. However, with the PVS, it maintains a list of all ports that are both open and browsed. The application may have made 1,000,000 network connections on port 7003, and the PVS will only log this once, whereas if the LCE is tracking these, then all 1,000,000 sessions will be stored.

For More Information

Readers who would like to learn more about log analysis should consider the Tenable paper "Security Event Management" as well as the "Network and Behavioral Anomaly Detection" webinar.

The Passive Vulnerability Scanner (PVS) has the ability to discover network services which have the characteristic of being "interactive" or being "encrypted". The PVS can analyze traffic in real-time and recognize when the size and frequency of packets is indicative of an "interactive" session. The PVS can also look at the traffic's randomness and determine if the data is encrypted. This blog post helps PVS users understand how to analyze this data, where false positives can occur and what these events mean.

Native PVS Event IDs

The Passive Vulnerability Scanner has several thousand plugins which detect a wide variety of client and server applications. It also has several "built in" plugins which detect many low-level items. These are:

• #00000 Detection of open port The PVS has observed a SYN-ACK leave from a server.
• #00001 Passive OS Fingerprint The PVS has observed enough traffic about a server to perform a guess of the operating system.
• #00002 Client Side Port Usage The PVS has observed client-side network browsing traffic from a host.
• #00003 Show Connections The PVS has logged a unique network trust relationship of source IP, destination IP, and destination port.
• #00004 Internal Interactive Sessions The PVS has detected one or more interactive network sessions between two hosts within your focus network.
• #00005 Outbound Interactive Sessions The PVS has detected one or more interactive network sessions originating from within your focus network and destined for one or more addresses on the Internet.
• #00006 Inbound Interactive Sessions The PVS has detected one or more interactive network sessions originating from one or more addresses on the Internet to this address within your focus network.
• #00007 Internal Encrypted Session The PVS has detected one or more encrypted network sessions between two hosts within your focus network.
• #00008 Outbound Encrypted Session The PVS has detected one or more encrypted network sessions originating from within your focus network and destined for one or more addresses on the Internet.
• #00009 Inbound Encrypted Session The PVS has detected one or more encrypted network sessions originating from one or more addresses on the Internet to this addresses within your focus network.
• #00012 Host TTL Discovered The PVS logs the number of hops away each host is located.

Vulnerability IDs 4,5 and 6 look for "interactive" sessions inside, outbound and inbound to the network being monitored by the PVS. This allows to identify all types of "human typing" that is both legitimate and perhaps, illegitimate.

Similarly IDs 7,8 and 9 look for "encrypted" traffic inside, outbound and inbound to the network being monitored by the PVS. This will not only identify things like SSH and HTTPS services, but also services that are not natively recognized by other PVS rules.

Once the PVS flags a device as having a particular open port, encrypted session, interactive session or trust relationship, this will show up in the vulnerability report. Typically, network and security analysts are accustomed to seeing these sorts of alerts in logs or real-time. However, with the PVS, this data has state. If an e-commerce site has 1,000,000 SSL connections to port 443, the PVS will only have report one encrypted session record for that report.

Interactive Session Analysis

Based on the frequency and size of packets between two hosts, the PVS can identify a session that is interactive. By interactive, the PVS is looking for data that is sent by a user typing at the keyboard. Example sources of data include Telnet, chat and SSH. By default, the PVS will ignore ports with well known interactive services such as 23 for Telnet.

There are a variety of false positives that can occur with these algorithms. If there are network performance issues which cause packets for any service to flow at a trickle, it is possible that an incorrect match will result. However, most "slow services" still put 1500 bytes into their packets and this won't cause a match.

When matches do occur, they will be reported for analysis. When considering a large network for monitoring, this data can be very useful.

Port summaries for inbound, outbound and internal interactive traffic can indicate common services used. For example, one might be able to discover that all of the routers on a network have had a "telnet" service put on a high port.

When specific ports of interest are found, the results from recent Nessus scans as well as other PVS plugins should be considered. Both Nessus and the PVS are very good at identifying services.

Also, when analyzing the open ports, the system under consideration should be taken into account. For example, a router won't likely be participating in a P2P file sharing network or running a VoIP application whereas a desktop would.

If your Security Center has been configured with assets for your business and technology in use, choosing vulnerability IDs 4-6 and then conducting an Asset Summary query can give you an at-a-glance view of which assets have interactive sessions occurring.

For example, in this listing below, the only 3 "interactive sessions" reported have occurred for assets labeled "Clients", "FTP Servers" and "SMTP Clients". 

Encrypted Session Analysis

Based on the "randomness" of the monitored data, the PVS will report that a monitored system is communicating inbound, outbound and internally on certain ports with encrypted traffic.

There are several "naturally occurring" random data sources. Any time compressed files (.zip, .gz, .etc) are moved around on the network, there is a good change the network session will flag as being encrypted. We'll see in an example below how email can be the source of some "encrypted" sessions.

Analyzing the results of traffic is also accomplished with the Security Center. Port summaries, lists of matching IP addresses and reporting which assets have made "encrypted" sessions can shed light on what these detected services are doing.

Below is an example listing of a set of assets that have had at least one occurrence of PVS ID 7,8 or 9:

Two things should jump out to an analyst looking at this data:

• Of the 16 reported devices with encrypted sessions, many of these occurred on SMTP clients or servers. The PVS will trigger on messages that are encrypted with PGP or GPG. There content will also match on specific plugins designed to identify hosts sending PGP and GPG encrypted emails.
• There were 4 matches on the Symantec_Worm group. In a previous post, it was discussed how to create a dynamic asset list in the Security Center that matched hosts likely compromised with a worm targeting the Symantec AV engine. It is interesting that these hosts are also communicating on encrypted ports.

Configuring the PVS

While searching network sessions for encrypted or interactive data, the PVS can be configured to ignore specific ports or even hosts that have certain plugins already detected on them. On UNIX, this is accomplished by editing the pvs.conf file located in the /opt/pvs/etc  directory. The PVS Windows version has GUI elements to select specific plugins and ports to ignore.   

Conclusion

The PVS can be used to identify devices which are the source or destination of interactive or encrypted network sessions. This data can be used to look for policy violations or perhaps backdoors and rootkits.

If you are performing network monitoring on a large network that is infected with any number of worms or botnets, there are many different techniques you can use with Tenable products to identify infected hosts. This blog entry considers a variety of worms/botnets that attack Symantec anti-virus agents. Many of the techniques identified here can be used to look for other worms that attack other applications and are active on different ports. For this post though, we will focus on port 2967 activity, which has recently dramatically increased, as reported by the SANS Internet Storm Center.

Signature Content Analysis

If you run an NIDS, there are typically rules which identify "known" botnet/worm/virus exploits. Here is a screen shot of Snort IDS events running the Bleeding Threat signature database:

We've highlighted the event by darkening it and also obscured the real IP addresses in questions. The event shows a remote host (69.16.196.189) sending traffic to port 2967 on host X.X.21.147 which matches a signature for an exploit against Symantec anti-virus agents. The other various "TNM" events show sessions starting and stopping on port 2967. These events are being viewed under the Security Center and have been collected and normalized by the Log Correlation Engine (LCE).

If this were a network you were defending, you should be asking yourself what else can be learned about this threat and if there are any other ways to detect compromised hosts. One of the things that would be concerning in the above image is that out target host X.X.21.147 is not only being scanned, it is also actively reaching out to other hosts on port 2967.

Combining Open and Browsed Ports

If you have the Security Center and the Passive Vulnerability Scanner (PVS) monitoring a network, you can query your cumulative vulnerability database for hosts that are listening on port 2967 and also browsing on port 2967. The  PVS records open ports as vulnerability ID #0 and browsed ports as vulnerability ID #2.  Within the Security Center, a query for a list of IP addresses that both browse and serve on port 2967 looks like this:

The IP addresses have been obscured. In the "port" filter, the value 2967 has been entered and in the plugin ID area, both IDs #0 (for open ports) and #2 (for browsed ports) have been entered.  In the chart on the right of the image, the IPs with the most vulnerabilities have been listed. Any of the IPs with two vulnerabilities have both a port open on 2967 and also browse on port 2967. The other IPs with only one vulnerability have either port 2967 open or they browse on it, but not both.

These hosts may not be compromised. Perhaps that do have port 2967 open for the Symantec anti-virus engine and also browse on port 2967 for some P2P, VoIP or other application. On the other hand, the chance of this occurring may be low on your network and hosts which both browse and serve on port 2967 may indeed be infected.

SANS has also recorded an increase in port 2968 traffic. Port 2968 is also associated with the Symantec anti-virus application. Similar queries for these ports can be accomplished with the Security Center.

Using Dynamic Asset Lists to Track Behavior

The Security Center can be used to create an automatic list of IP addresses based on the vulnerabilities and information discovered by Nessus and the PVS. We've blogged about this sort of capability in the past here. In the above example, since we only have three IP address of interest, perhaps a static asset list could be more quickly entered, but if new hosts became infected the list would not be automatically updated.

To create such a list, add a rule to match on port 2967 being opened, and a second rule to perform a regular expression search for vulnerability ID #2 ending in the content " 2967" (the space is on purpose). Examples of a similar dynamic asset rule are covered here. If you wanted to look for a host that browsed on either port 2967 or 2968, you could use a regex rule such as this:

2: 296[78]$

Such a rule searches for PVS vulnerability ID #2 records that end in a space followed by either "2967" or "2968".

On one of Tenable's large test networks which has been having issues with various Symantec worms, we created a Dynamic Asset List that considered systems that browsed and served on port 2967. This list was named "Symantec Worms". We then compared the trends of events and logs on port 2967 with just the events for the "Symantec Worms" systems and got the following results:

"Symantec Worm" hosts	All Port 2967 traffic

In the above graphs, there was a clear spike in traffic from our hosts which is easy to see. However, by just trending for port 2967 traffic, there is so much background noise, these particular hosts didn't register with any sort of spike or anomaly. (In this case, it was because these compromised hosts were performing large port scans on ports other than 2967).

For more analysis of the pure "port 2967" traffic, different queries could have been performed with the Security Center to compare "inbound" vs. "outbound" events.  Also, doing a "top talker" or "top destination" query of IP addresses for port 2967 could identify some problem hosts. And lastly, any "Crowd Surge" events on port 2967 would surely be indicative of many hosts scanning at the same time for this port.

Looking for Backdoors on Potentially Compromised Hosts

Once you have identified a list of hosts which may be part of a worm or botnet, it could be interesting to look for potential backdoors. One of the things both Nessus and the PVS do really well is identify applications, regardless of the port they are on. Consider the following list of vulnerabilities found on our "Symantec Worms" asset list where we are specifically excluding detected port 21 issues:

In the above image, we've highlighted PVS vulnerability ID #3222 which detects FTP servers on any port. This one happens to be on port 50126. Sniffing traffic to the system yields a hit such as this:

Clearly, this is an FTP server set up by someone who exploited the server, perhaps using an exploit for the Symantec anti-virus agent, perhaps with a different exploit. Regardless, we were able to use a combination of information to lead us to this host.

A different analyst may have chosen to look for all "non-port 21" systems running FTP servers on a daily basis an use the LCE or PVS to alert when a new system was added to the list.

Summary and More Information

These examples can be applied to many different types of worms and general log and event analysis. Knowing which vulnerabilities and network browsing activity occurs on your hosts can be used to help focus on specific events and systems. If this blog was of interest to you, the following entires will also likely be interesting:

• The Security Center can be used to push Bleeding Threat signature rules to your Snort sensors, as well as just enable the specific signatures that match existing vulnerabilities and applications on your network.
• The Log Correlation Engine can be used to match all of your network connections against "blacklists" published by SANS and Bleeding Threat . This includes matching traffic to or from known botnets.
• If you are using credentialed scans, the Nessus vulnerability scanner can find compromised Windows hosts that have had their ability to reach out to various anti-virus disabled.
• When the PVS finds a new port being browsed, the alerts can be sent to the Log Correlation Engine and used to find worm outbreaks.

Version 3.0 of the Passive Vulnerability Scanner (PVS) dynamical alerts when it finds "new" pieces of information about the network. Potential information includes open ports, browsed ports, OS fingerprints, client applications and network services. This blog entry discusses how the occurrence of "new browsed port" events can be used to look for various types of malicious behavior.

Browsed vs. Open Ports

Obviously, both Nessus and the PVS can tell you which systems have ports that are open for services such as http, smtp, ftp and so on. What is unique about the PVS though, is that it can tell you which systems on your network have been known to browse on a certain port at least once. It uses ID #00002 and is labeled "Client Side Port Usage" by the Security Center. Consider this screen shot for a single IP address of 192.168.20.16:

This server has only browsed on ports 5900 (vnc), 80 (http) and 443 (ssl). It may have used the VNC client one time, 50 times or more. From this report, we don't know how many time this host was active on a certain port, but could if we had configured a Log Correlation Engine (LCE) to grab netflow or network sessions.

Consider this host which performs "heavy" network browsing, P2P file downloads and uses the Skype chat tool:

This host has reached out to 32 unique ports at least once while the Passive Vulnerability Scanner was monitoring it.

Real-time Notification of New Port Browsing

The PVS has the ability to alert when something "new" has been added to it's model of the network. This includes alerting when a host begins browsing on a certain network port. Under the Log Correlation Engine, these events look like this:

For this particular demo network, the PVS has generated 42 "PVS-New_Port_Browsing" events in the last 24 hours. These events are used by many LCE TASL scripts to look for network change, and even look for events from various NIDS which may be followed by a host performing "new" types of network activity.

Looking for Worms and Trojans in "Live Data"

When systems are compromised by some sort of rootkit, botnet agent, maleware or some other type of malicious software, they tend to use their own network channels to communicate for command and control. Obviously, some bots are more stealthy than others, but the large bulk of them open up network connections to someplace else to report home and receive commands. If these connections are on ports not normally visited  by a system, they "stick out" in the traffic.

Consider the following list of "new browsed ports" for all systems on a large network being monitored by the Passive Vulnerability Scanner for the past 5 days:

Many of the ports involved (7000, 7777, 22, 6667, 8008, .etc) are very common server ports to host maleware and control botnets with. This information needs to be analyzed. Just because a server connects to port 6667 (irc) for the first time, doesn't mean it is not used for IRC chatting and is a bot.

Someone who wished to analyze this data further could use the Security Center and simply query for the number of "browsed ports" that the PVS has detected for a specific network. Such a query could look like this:

These are all of the ports that the network has reached out on at least once. Port 80 is web traffic and many of the other ports are chat or P2P specific.

Those listed ports in the above image are just the top ports. If we wanted to get a listing of all systems that had browsed on port 7000 or some other port, we'd just select plugin ID #00002 and the port or ports of interest, and then perform a "Summary by IP" or "Summary by Class C" report. This is also an excellent way to figure out if your outbound firewall or proxy configurations are being effective.

For worm and trojan analysis, it can be more interesting to track the "new" port events in the Log Correlation Engine. For example, considering port 7000 "new port browsing" events over the past 25 days produces a graph like this:

These spikes indicate that large numbers of hosts all began browsing the network at the same time on port 7000. This can correspond to worm outbreaks, use of P2P and chat applications and also initial botnet infections.

It's important to understand that there are legitimate reasons for spikes in everyday network activity and to consider other environmental factors. For example, consider your DHCP lease times. If you have a large user population that gets brand-new IP addresses every few days, then their normal traffic will show up as a spike of new port browsing events.

For More Information

Tenable has posted several items in this blog which discuss virus and worm analysis with Nessus scanning and passive network monitoring. They are listed below:

• Detecting Compromised Windows Hosts
• Finding Patched/Infected MS06-04 Systems
• Detecting Zombie/Botnet Crowd Surges
  
• Blacklist Event Correlation
  

Tenable Network Security has released version 3.0 of the Passive Vulnerability Scanner (PVS). This version supports realtime vulnerability alerting, enables monitoring of corporate networks for data leakage and completes the re-branding from "NeVO".

A major new feature of the PVS is the ability to stream new vulnerability information in realtime to the Security Center and to the Log Correlation Engine. As the PVS finds new data about the network, it is sent in realtime in logs such as this:

Apr 20 19:58:21 pvs: 192.168.20.22:0|0.0.0.0:0|17|13|new-host-alert|00:11:95:89:d4:8a
Dec 21 10:56:04 pvs: 162.21.99.99:53|192.164.141.12:36788|17|1016|DNS server detection|||INFO
Dec 21 10:56:04 pvs: 169.31.24.219:80|0.0.0.0:0|6|0|new-open-port|INFO

The PVS realtime alerts include:

• new vulnerability and network data with low, medium and high severity levels
• new hosts, new open ports, new "browsed" ports, new systems that perform
  Internet browsing and new trust relationships between internal devices
• evidence of compromised systems and serious attacks, such as against SCADA devices
• detection of internal hosts performing port scans
• support for detecting a variety of sensitive data in motion and at rest

Example Screen Shots

Below is a screen shot of PVS events on a large enterprise network under the Security Center:

Each of the "events" listed above occurred when the PVS encountered new vulnerability data that it wasn't previously aware of. The LCE normalizes the 1000s of potential PVS vulnerabilities based on their severity levels. In the above screen shot, 26 new vulnerabilities with "HIGH" severity levels have been discovered.

Although not a network IDS, the PVS does discover very useful events which can be fed into the Security Center, the Log Correlation Engine or most SIM products. Below is a screen shot of several PVS events intermixed with IDS events from an Intrusheild IPS. There are several different port scan events as well as two Windows error event detections.

Log Correlation Engine Support

With this release, a separate Log Correlation Engine library for PVS events has been produced, and several of the existing correlation scripts have been updated to take advantage of the new events. These include:

• tenable_pvs.prm log normalization library for PVS events
• botnet_with_scan.tasl correlates detected IDS Botnet events with the same host performing a port scan
• detect_change.tasl now also processes new host and new open port events from the PVS (Note: this script can be extended to alert on new trust relationships, new Internet browsing and new client side port browsing if desired.)
• ids_event_followed_by_change.tasl considers changes in host configurations or behavior after being attacked. Now supports detected attack events from the PVS.
• new_host_portscanning.tasl uses PVS events which identify new hosts and port scan events to discover when a new device immediately begins port scanning.
• portscan_spike.tasl now uses port scan and host scan logs from the PVS, along with any portscan log from supported IDS and firewall devices to look for short term spikes in scanning activity.
• windows_crashes_and_restarts.tasl now makes use of PVS ID #4722 which sniffs Windows error messages being sent back to Microsoft. The script considers this event along with Windows OS events such as crashing applications and system restarts to look for failed worm attacks and even failed compromise attempts.
• lce_tasl.prm is the LCE PRM library which normalizes events from the TASL scrips. This file should be updated on your LCE if any of these modified TASL scripts are implemented.

Obtaining PVS 3.0

Versions for UNIX and Windows are both currently available. Tenable recommends that both products are recommended to be managed with the Security Center. Existing NeVO 2.2 customers can upgrade to PVS 3.0 as long as their maintenance is up to date. New customers should contact Tenable's sales staff.

The Passive Vulnerability Scanner (PVS) can be used to discover web servers hosting files which may be copyrighted or as potential sources of data leakage events. Such material may contain sensitive intellectual property that is not intended for public release. By passively sniffing traffic to and from web servers, the PVS can discover hosted content that may be in violation of corporate policies.

Finding Potential Copyright Violations

Several plugins are available to discover movies and music files being hosted on a web server. These files may be subject to inquiries from the RIAA or the MPAA.

Typically, if a user on your network is sharing copyrighted content, they are either physically bringing it into your network, or they are using your bandwidth to download content via P2P file sharing. A user that attempts to share their movies or music using a web server could be a liability for your organization.

The following PVS plugins are available to discover hosted entertainment content:

• 3827 Web Server hosting .mp3 file(s)
• 3828 Web Server hosting .wav file(s)
• 3839 Web Server hosting .ogg file(s)
• 3840 Web Server hosting .wma file(s)
• 3847 Web Server hosting .avi file(s)
• 3848 Web Server hosting .mpg file(s)

Tenable considers these plugins very complementary to the Nessus plugins which perform scans for similar content. Tenable has blogged about using active scanning with Nessus to discover potential copyrighted content on web servers, SMB shares and FTP servers.

Finding Potential Data Leakage Files

Many enterprise organizations have experienced inadvertent or malicious disclosure of sensitive corporate data and sensitive customer data. Many of these cases resulted from having sensitive data "too available" to employees who didn't really need access to it.

One way to help combat this is to simply take an inventory of which web servers are hosting typical corporate documents. The PVS has the following rules available to detect web hosted files:

• 3822 Web Server hosting .xls file(s)
• 3823 Web Server hosting .doc file(s)
• 3824 Web Server hosting .ppt file(s)
• 3825 Web Server hosting .csv file(s)
• 3826 Web Server hosting .rtf file(s)

The intent of finding these files isn't to find data leakage incidents, it is designed for organizations to discover if they have any web servers hosting this sort of content. Since the PVS watches 24x7, it can also act as an alerting mechanism when new servers or new content are available.

Tenable has recently made rules available for the PVS which can look for patterns of credit card and social security numbers in network traffic. We've also blogged about how the PVS can be extended to look for proprietary tags of sensitive data.

Comparing with Nessus Active Scanning

Since the PVS is 24x7, it does have an advantage of seeing data in motion. The PVS is also monitoring all unencrypted web servers, regardless of port. It will also see unencrypted web servers hosting this content that are protected by a password. Obviously, Nessus scans can be configured with credentials to perform a scan, but an IT auditor might not have the right password for a rouge web server containing movies or music files.

For active scans, Nessus may be able to find files that are available, but have yet to be downloaded. Nessus can also "log on" to SSL encrypted web servers (providing there is no password) and discover files.

Working With the Security Center

Since the output of these PVS plugins can be used by the Security Center's dynamic rules engine, there are many possibilities for reporting, analysis and alerting. The Security Center can be used to create an asset list of each web server that is hosting potentially sensitive content. Once this occurs, the following activities can take place:

• All systems which have been passively discovered could be automatically (or manually) scheduled for an in-depth active Nessus scan.
• The vulnerabilities of all web servers hosting sensitive content can be analyzed, trended and reported on. This may be a quick way of simply discovering where all the main "servers" with corporate data are located.
• If the Log Correlation Engine is in use, an analysis of who has accessed this data and from where can occur. This can be accomplished using netflow, firewall or sniffed network sessions.
• If intrusion detection logs are available, a separate report or analysis of all attacks against these servers can occur.
• If these assets hosting sensitive data are being managed, the Log Correlation Engine can be used to track changes to the local system, users and supporting network devices.
• If the RIAA or MPAA makes an inquiry to your organization, the PVS can help provide data for the investigation. The Security Center can keep this data on record for "historical" evidence as well.
• The Security Center can be used to find servers that are hosting movies AND music or perhaps PowerPoint AND Spread Sheet files. These correlations can help find a more likely source of interesting files for analysis.

Tenable has made an RSS feed of vulnerability plugin updates available for the Passive Vulnerability Scanner. The feed is located at:

http://www.tenablesecurity.com/pvs.xml

Tenable customers who manage their PVSs with the Security Center automatically synchronize with the latest checks daily. However, if a new vulnerability check is available that is of interest, you can force an update under the "Force Nessus Plugin Update" link under the "Policies" tab.

Tenable also offers a feed for Nessus plugins located at:

http://www.nessus.org/rss-plugins.xml

This includes information about plugins from both the direct and registered feeds.

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.

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.

During the past year, the Passive Vulnerability Scanner's rules were modified to detect network proxies and firewalls. This process also involved the reduction of reporting multiple browser types for different hosts running behind a NAT device or proxy.

As an example, what happens if PVS (or any sniffer, IDS, etc.) see's the following string in a packet leaving the network?

GET/StageOne/msnmsgr_exe/6_2_0_137/hungapp/0_0_0_0/00000000.htm?OS=5.1.2600.2.00010300.1.0&...
User-Agent: MSDW
Host: watson.microsoft.com

Well, most folks would think that:

1. The source IP is running MS Windows version 5.1.2600.2.etc and,
2. An error just occurred in MSN Messenger version 6.20.0.137 and,
3. The client is now sending an error message to Microsoft

And, a year ago, the PVS would have flagged the machine for the items denoted above.  However, within the last six months, Tenable has been undergoing a process of detecting where and why false positives are occurring within PVS.  One of the problem areas was that PVS was flagging firewalls and proxies as the actual client.  Mind you, I'm not talking about known NAT devices, as you can always turn off alerts going to/from those devices via the configuration file. 

We decided to find a generic way of detecting proxies and firewalls on the network.  The primary goal of this was to weed out false positives.  A tangential benefit has been that companies can now detect firewalls and proxies that are deep within their corporate network. 

Why does finding these NAT or proxy devices matter for a larger enterprise network? Consider the following issues:

• What happens if a remote business unit (connected to your internal network) is dual-homed to another network? 
• What happens if a user decides to set up an access point within your corporate network? 
• What happens if a user sets up a 3G connection to their corporate laptop, enables routing, goes home, and then uses the laptop as a remote router when they want to connect to corporate resources?

Finding firewalls and proxies within large, complex networks can be a daunting task. The good news is that these firewalls and proxies all leave their fingerprint as they pass NATed traffic around the network - and the PVS can detect these.

So, how do we detect firewalls and proxies? We modified the PVS rules to look for anomalies within the client-side applications and OS behaviors that only occur if multiple hosts are behind a NAT device or proxy. Here are a few examples currently implemented in the PVS signatures:

• The PVS looks for applications which are specific to an operating system.  PVS then finds mismatches.  Example: A host running the Firefox browser on the Microsoft platform AND a Safari browser on MAC OX X coming from the same IP.
• PVS looks for anomalous operating system updates. Most OSes and many applications have automated software for figuring out when an update is available.  The PVS looks for mismatches on the same IP.   
• Multiple versions of the same application. This is very straightforward. It's "odd" to see three versions of Firefox coming from the same IP.  This is also accomplished with MSN Messenger, AIM, Zonealarm, etc. etc.

By searching for the applications of multiple individual hosts occurring on "one" public IP address, the PVS can identify where NAT devices and proxies are located with a high degree of accuracy.

If passive network monitoring to find vulnerabilities is a new concept to you, please feel free to download the "Blended Security Assessments" whitepaper. This shows how both active and passive vulnerability analysis provides much deeper coverage and monitoring of your network than either technology by itself. There is also a video demonstration of PVS data being managed by a Security Center.

Tenable has released an update to the blacklist.pl script and corresponding lce_tasl.prm library and TASL script. The new script uses input from the Internet Storm Center, Spamhaus and BleedingSnort to create a list of IP addresses and networks which may be of interest to your network. Any time the Log Correlation Engine detects one of these remote IP addresses or networks interacting with your network systems, an alert is generated. This can help find when your computers are interacting with SPAM or Botnet networks, or when you you have been scanned by a known hostile network. 

Previously, Tenable had released a PERL script which would periodically receive updates from the SANS Internet Storm Center and then use the isc-blacklist.tasl script along with netflow or sniffed TCP sessions (from the TNM or TFM agents). As of today though, the isc-blacklist.tasl has been replaced with the more generic blacklist.tasl and the original blacklist.pl script has been upgraded.

The new process allows for the blacklist.pl script to periodically go to three sources to obtain a list of IP addresses and networks that have been determined to be "hostile" or "malicious".

• The Internet Storm Center tracks IP addresses and networks which perform broad Internet scanning.
• Spamhaus releases their top 25 list of SPAM generators for free.
• The Bleeding Snort project also reports IP addresses and networks involved with large-scale Botnet command and control. This sub-project there is known as the ShadowServer Foundation.

This architecture lends itself to being more easily extended. As new lists of "bad" networks are published, they can be added to the blacklist.pl script without modification to the blacklist.tasl script.

The blacklist.pl script can be configured to connect to each of these sources and build a template list of "known bad" IP addresses and networks. The blacklist.tasl script uses this list of "known bad" sources and destinations and subscribes to your network and netflow sessions. When an IP address hits your network, a single alert is generated to minimize alerting for every scan, connection or email sent. Below are some example screen shots of this technology running in a variety of environments.

This network had 2462 "Blacklist_Conenction" events in the last 24 hours.

A sanitized list of some connection events going to many ports, including 6667, commonly used for IRC.

When the TASL script fires, it uses the data about the host obtained by the blacklist.pl script and a DNS lookup to generate the following type of log message:

Blacklist_Connection src - X.X.X.X dst - 1.2.3.4 , following is known about 1.2.3.4 , source of information - http://www.shadowserver.org , message - BleedingSnort-Bot , dns_lookup - example.network.dns.address.com

These messages can be used by other TASL scripts as well as LCE's statatisitcal engine.

Installing The blacklist.pl Script

Download the latest blacklist.tasl, blacklist.pl script from the Tenable Support site. Also make sure to update your LCE (Thunder) plugins to get the latest version of the lce_tasl.prm file.

Once this is accomplished, uncompress and untar the blacklist file distribution someplace on your LCE. There will be a file named blacklist.cfg inside the distribution and this needs to be edited.

The first part of the blacklist.cfg file specifics URLs to public sources of IP addresses or networks of interest. There are settings for ISC, BleedingSnort and Spamhaus. The format of these settings is as follows:

IP Address,Source of information,Message or info about the IP address,Country/Location,Email address to contact to report abuse,dns

If you have access to other sources of IP addresses, you can add it like this:

1.2.3.4,tenable.com,RIAA Abuser List,US,test@test.com,S2-ESR-69-61-191-47.someplace.com

This allows you to extend the actual "Black Lists" file with IP's other than the ones listed on the above three sources.   

The second parameter is the THUNDER_SERVER= keyword. The IP address of the Thunder Server (Log Correlation Engine) should be added. If the blacklist.pl script is installed on the same server, then 127.0.0.1 should be used. If this is running on a different server, then the remote IP address of the LCE should be used.

Lastly, the script will lie dormant for a period of time and then reach out to the Internet to update the lists of networks. This period is specified by the FREQUENCY keyword in an amount of seconds. Whenever there is a new list of networks, a special message is sent to the LCE which causes the blacklist.tasl script to re-hash it's list of networks.

Note: If you happen to manually edit the list you need to restart the LCE.

I was very excited to read Joel Snyder's review of Sourcefire's RNA and our Passive Vulnerability Scanner (PVS). (The article requires registration). He makes a lot of very good points about the accuracy of passive network analysis and does a very good job of contrasting the Sourcefire 3D system for managing IDS events and our Security Center for managing security. There are some points I would like readers to take away from the article though:

• During the evaluation, our PVS mis-identified an anti-spam appliance as having several client-side vulnerabilities. We had an error in the logic of some of our PVS signatures and have fixed it. This single fix would have drastically lowered the number of issues dealing with false positives during the evaluation.
• There are major design differences between RNA and PVS. To quote the article, "If Tenable uses an "innocent until proven guilty" approach to marking vulnerabilities, Sourcefire considers every system "guilty until proven innocent." Basically, as soon as RNA guesses your OS, it attaches any potential vulnerability it knows about it. I think this approach is great for IDS event correlation, but for vulnerability management, it is too broad. At Tenable, the same team that writes the Nessus host based and scanning checks writes the PVS checks. Our Security Center does do IDS/vulnerability correlation with many NIDS including Snort, but since we're more application focused, there are less correlations.
• I wished the article went into more of the benefits of doing continuous and passive analysis as a compliment to active scanning. Joel gives the impression that these tools are only good for large networks. Tenable has many customers putting the PVS in places that A) can't be scanned that often or B) simply can't be scanned. For more information, I highly recommend our papers "Security Event Management" and "Correlating IDS Alerts with Vulnerability Information" available in the White Papers section of our web site.
• Lastly, the article didn't evaluate our Log Correlation Engine product. This would have allowed the evaluators to search all Snort logs for the duration of the evaluation, as well as add in logs from our passive network monitor. The combination of knowing the sort of information that PVS can discover along with having a record of all of your firewall, network sessions, user logs, .etc is very compelling.

If you haven't seen a product like RNA or PVS before, please feel free to take a look at the demonstration video we have here.

As you might expect, I would really like to see more evaluations like this. Tenable has been offering our PVS solution for several years now. We have many different enterprise customers that run our vulnerability detection solutions in credentialed, scanning and passive modes. The more sophisticated customers use different combinations of these technologies across their enterprise as dictated by political and technical network limitations. I think articles like this, although good for Tenable, can also get network users out there to consider other sorts of tools to perform network discovery.

Tenable has produced a set of plugins for our Passive Vulnerability Scanner (PVS) based on the publicly available SCADA IDS signatures from Digital Bond. This allows the PVS to discover which devices speak SCADA protocols in addition to more than 3000 other server and client vulnerabilities. This monitoring is done in real time and without any network impact. Along with Tenable's Security Center, Nessus scanner and Log Correlation Engine, this can become a very powerful tool for security monitoring of SCADA networks.

The Department of Energy recommends 21 separate activities for monitoring and securing SCADA networks. All of Tenable's products can be used together for a comprehensive analysis of SCADA network devices, protocols and traffic. Tenable also has published a paper (free for download) about how each of the DOE's 21 recommendations can be accomplished with Tenable active, passive and log analysis solutions.

Tenable has recently added several TASL correlation rules which detect a variety of network changes. These rules automatically detect:

• Changes to servers such as new software and added patches
• Changes to users such as adding/removing a user, changing their passwords and disabling their accounts
• Changes to network devices such as saving new configs of a router or switch
• Changes to the network such as new hosts being added

Here is a screen shot of what these look like under the Security Center:

These new TASLs also compliment the existing scripts which detect user account to host relationships and alerting when new Ethernet addresses are discovered in DHCP logs and logs from Tenable's Passive Vulnerability Scanner.