If you are a Nessus user, you are no doubt familiar with the process to subscribe your Nessus scanner to the Direct Feed or Registered Feed to automatically receive new vulnerability plugins produced by Tenable's research group.

With Nessus 3.2 (currently in beta and available for download as Nessus 3.1.5) a similar process is available to upgrade the Nessus scanner itself. This blog entry will show how users who have installed one of the Nessus 3.1.x beta releases of Nessus 3.2 can automatically upgrade.

Automatic Upgrades

To update the release of Nessus, the scanner must be subscribed to either the Direct to Registered plugin feeds. If your Nessus scanner is automatically receiving plugins then you will be able to upgrade when new releases are available.

The update process is run from the command line with the new command 'nessus-update' which is located in the ~/sbin installation directory. While in the ~/sbin directory, you can check your version of Nessus by invoking the Nessus daemon with the -v command:

[root@cosmic sbin]# ./nessusd -v
nessusd (Nessus) 3.1.3. [build A567] for Linux
(C) 1998 - 2007 Tenable Network Security, Inc.

To check for a new build of Nessus, and to install it, simply run the 'nessus-update' command:

[root@cosmic sbin]# ./nessus-update
Nessus 3.1.5 is available. Do you want to upgrade to this version ? [y]

The program checks to make sure that Nessus is subscribed to either a Direct or Registered feed and that a new build is indeed available. If both of these conditions are met, the package will be downloaded and installed.

The update download is signed and the signature of the update is checked against the nessus.org public key that is in place.

If your Nessus scanner is set to also update its plugins, a plugin update will be invoked right after an upgrade is completed.

Current Nessus 3.2 Beta Status

The latest release of the Nessus 3.2 beta is version 3.1.5 and is available for download from the Nessus web site. Nessus 3.2 beta downloads are available for Linux, FreeBSD and Solaris. Windows and OS X versions are currently in development. The Nessus 3.2 beta supports IPv6 scanning, a library to write custom WMI queries and also a command line program to initiate a complete vulnerability scan.

If you have also started to use the NessusClient 3.0 to manage your scans, if you connect to a Nessus 3.2 beta scanner, you will notice two new things. First, the login process is much faster. And second, during a scan, you now have an option to pause an on-going scan, as shown below:

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.

Tenable Network Security's research group has released a new Nessus plugin which can make use of the Remote Desktop Protocol (RDP) to accurately detect Windows Vista, 2000 Server, 2003 Server and XP Professional. The Remote Desktop Protocol is also sometimes referred to as Terminal Services. This protocol allows remote users and administrators to view the desktop of a Windows system offering this service to control the mouse, keyboard, run applications and otherwise run the system remotely.

Being able to communicate with RDP (which runs on port 3389) to determine the Windows operating system is very useful. Windows systems that are not part of a domain are often managed through RDP. If they have been hardened with a firewall to only offer the RDP service, this technique is an efficient way to identify the operating system.

As a form of detection, this type is perhaps the easiest for a human to perform, yet requires a high degree of skill and sophistication to perform this with a computer. You and I can usually simply look at a login screen and recognize the "Windows XP Pro", "Windows 2003" or other types of visual queues to identify an operating system. However, performing this type of analysis with a computer is non-trivial.

Consider the following login screen below:

You could probably tell this was some sort of Windows system before even trying to enlarge the above image.

Can you tell which version of Microsoft it is?

Can you tell which language this OS has been provisioned for?

Attempting to do this via RDP was an interesting challenge. The RDP protocol offers a variety of information including bitmaps and streams of text (which are really more bitmaps). One could imagine performing optical character recognition on the login screen bitmap logos or even creating a table of checksums for known bitmap images. Both of these techniques aren't reliable as many organizations and third part vendors (like Novell) can change the login bitmaps. Tenable was able to develop a technique to reliably fingerprint the information used to render text during the login process. This text can be used to identify and discriminate Windows XP Pro, Windows 2000, Windows 2003 and Vista operating systems.

Output from this plugin has also been integrated into the os_fingerprint.nasl script, which combines a wide variety of credentialed and non-credentialed operating system guessing techniques to accurately determine a remote operating system.

The plugin is currently available to Direct Feed and Security Center customers and works with the Nessus 3 vulnerability scanner on all available versions. Updating your plugins will automatically make this check available to your Nessus scanner.

John Lampe, a senior security researcher for Tenable Network Security, will be presenting a talk and demonstration about passive network monitoring and web application vulnerability assessments. John's co-presenter for the seminar will be Matt North, formerly from ISS, Spi Dynamics and now with AT&T.

The talk location and date is:

Southern Polytechnic State University, Marietta, GA
Thursday, November 8, 2007, 6:00 PM until 7:20 PM
Building J -102 (campus map)

The talk is open to the public and pre-registration is not required. For more information, please visit SPSU's Center for Information Security web site.

Tenable Network Security has officially released the GA version of the NessusClient 3.0.0. This new client can be used to manage scans and results from UNIX and Windows Nessus daemons. The major new features of the NessusClient include:

• Real-time results. No need to wait until the end of a scan to start analyzing the findings of Nessus. As your scans occur, the results are displayed and updated in real-time.
• Document based. Save your policies, scan results and scan targets into a single file.
• New XML based report format. The new '.nessus' file format saves into a single XML file for your scan policies, scan targets and scan results.
• Multiple connections. The NessusClient can connect to several Nessus scanners at the same time.
• Consistent interface. The same interface exists on Mac OS X, Windows and Linux. This makes working with other users who have a different operating system much easier.

The NessusClient is available for Windows, Ubuntu Linux, Debian Linux, Red Hat Enterprise Linux 4 and 5, Fedora Core 6 and 7, and OpenSUSE 10.2. It can be downloaded from nessus.org.

We've blogged about the Nessus Client (and provided many screen shots) in the past here.

The NessusClient can be used on Nessus 3 and Nessus 2 scanners, is compatible with the Direct Feed subscription for performing configuration and content audits and can also be used on Nessus scanners being managed by the Security Center.

It's time once again to vote for your favorite security companies and products with SC Magazine.Tenable has submitted the Nessus 3 Vulnerability Scanner for the 'Best Audit/Vulnerability Assessment' award as well as the Tenable Security Center and Log Correlation Engine solution for the 'Best Event Management' award.

If Tenable has helped your organization manage its security and compliance, or helped your service provide value to its customers, casting your vote at SC Magazine can help recognize the hard work, research, support and development performed by Tenable employees every day.

To cast a vote for Nessus 3, click here.

To cast a vote for the Security Center and Log Correlation Engine, click here.

After reading Richard Bejtlich's "Be the Caveman" blog post about the convicted hacker Robert Moore, I felt it would be interesting to show how unifying vulnerability monitoring, configuration auditing, passive network discovery and log analysis helps organizations detect intruders. This blog post focuses on the techniques mentioned by Moore and Bejtlich, and how tools like Nessus and the Security Center can make this easy to do for any size organization.

Testing for Default and Weak Passwords

During his interview, Moore was quoted saying that default and common passwords were used on most of the networks they penetrated.

Both Nessus and the Passive Vulnerability Scanner (PVS) identify network services such as Telnet, Secure Shell and web based administration access. These services can be scanned by Nessus for a variety of vulnerabilities, including default passwords. Nessus also includes the ability to run the Hydra password guessing program which performs brute-force password guessing on many different types of applications. Both Nessus and the PVS also identify web based services which don't use encryption for passwords. And lastly, Nessus Direct Feed or Security Center users can audit UNIX and Windows OSes for basic password policies such as minimum length and how often they should be changed.

Performing this type of analysis on a periodic basis will help identify which services may be vulnerable to remote attacks, and which systems have been configured incorrectly. If this type of analysis and monitoring was accomplished on the networks attacked by Moore, he would have not been able to gain access with simple password attacks. If your organization has external "Internet reachable" devices, they are likely being probed right now for weak and default passwords.

Auditing Routers and Switches

Many of the targets that Moore exploited were also routers and switches.  Both Nessus and the PVS can be used to audit vulnerabilities and mis-configurations in a wide variety of routers and switches.

For example, the Nessus vulnerability scanner has an entire family dedicated to Cisco device checks.  Many of these can be performed without credentials and some can take advantage of the SNMP management protocol. Tenable has also produced Nessus checks for non-Cisco network vendors including 3Com, Alcatel, Nortel, Avaya and others.

Passively, the PVS can monitor network traffic for detection of a wide variety of routers and switches, as well as analyzing the packets going to and from these devices to see if there are any known vulnerabilities present.

Both Nessus and the PVS also identify basic routing services and protocols such as BGP, RIP and OSPF. Nessus and the PVS can also identify SIP enabled devices for Voice Over IP applications.

Having a clear picture of where a network's routers and switches are located and if they are secure is a vital step in keeping remote hackers from obtaining access to these systems. Once again, if the organizations attacked by Moore knew where all of their routers were and knew if they had any vulnerabilities they could have monitored them for exploitation or attempted to mitigate any security issues.

Network and System Logging

When analyzing logs, we'd like to see many things, but if we were looking to identify Robert Moore's alleged activities, we'd want to be able to determine:

• which routers and systems did NOT have logging or coverage
• which devices had login failures from external sources
• if there had been any suspicious changes in bandwidth or activity

As was said before, Nessus can be used to audit the configuration of a remote system. This can be used to see if logging is indeed enabled. If Nessus is unable to obtain this type of information, logs can still be analyzed by an asset basis. Below is an image of all log events by asset type:

This view comes from the Security Center managing a Log Correlation Engine (LCE). The default view encompasses all log sources such as netflow, syslog, windows events and IDS events. The above log shows a complete lack of any type of log for an asset group known as the 'Switch'. This could indicate that logs from this group of systems are not available, the switch isn't configured to generate them or perhaps an IDS or firewall isn't in place to see attacks against the switching infrastructure.

Looking at your log sources by asset group with the Security Center enables quick determination of logs (or lack of) for different types of network and system events. This same query could be extended to show logins and login failures across all asset groups. Not seeing any login, logout or login failures for an asset group is a good way to recognize that you don't have any useful logs for a critical asset.

Presence and coverage can include actual logs from the monitored devices, but also implicit logs from network IDSes and firewalls. For example, being able to view all of your IDS logs across each asset (including the 'Network' assets) can indicate if you have any events occurring against those assets.

Robert Moore also performed basic default account exploitation. It's difficult to actually say what this would look like without more details but surely there would be at least one successful login event. It's also possible that this login event may have been proceeded by login failure events. Tenable has four TASL correlation scripts for the Log Correlation Engine (LCE) to look for intruders like Moore. They all subscribe to generic network login and login-failure events from many types of sources such as VNC, Windows systems, SSH logins and also routers and switches.

• activity_during_off_hours.tasl
  Subscribes to any login or login-failure event and alerts if this occurs during nighttime.
• brute_force_password_guessing.tasl
  Subscribes to all login-failure events and alerts if there is a spike in this activity.
• login_from_external_network.tasl
  Looks for any successful login event and alerts if the source occurs from outside the local network.
• successful_login_after_multiple_failures.tasl
  This script subscribes to successful login events as well as the events from the brute force password guessing TASL and alerts if a login occurs after multiple login failures have occurred.

And lastly, monitoring general activity for any types of change is useful to not only find remote hackers, but also to understand the mechanisms of your network. Keep in mind that during his interview, Moore said he targeted corporate networks with "lots of traffic" because it was less likely they would notice a few additional calls. Organizations that only monitor the total aggregate amount of network bandwidth, IDS events, firewall logs or so on will miss the fact that a resource doubled its log output or had IDS events where there were none before. Tenable approaches this type of analysis with three different techniques.

First, for any type of log source (netflow, syslog, firewalls, .etc) these logs can be analyzed by a human for trends. This process is very fast. Users can analyze billions of log events with several clicks of the web interface and instantly see trends, ports used and systems and assets involved. Second, regardless of log types, the LCE can alert when any host performs a "new" type of event that has Never Been Seen before and also when the overall amount of activity or unique events from that host is statistically significant. And third, both the LCE and PVS can detect and make sense of system changes in real time.

In the case of Robert More, it is very likely that as he compromised routers and VoIP applications that he made changes to them and also increased their amount of work. Both activities are likely something that would have been alerted on with both log analysis as well as network monitoring.

Passive Network Monitoring

And, almost as a parting shot, Richard makes a final comment in his blog entry about using passive network monitoring to discover hosts if active scanning is politically unacceptable.

Tenable has offered the Passive Vulnerability Scanner product for more than four years. It finds new systems, new hosts, new applications and the vulnerabilities associated with the corresponding clients and servers 24x7 by watching a network tap or spanned port.

We see it as a great complement to an organization that performs vulnerability scanning without credentials. And even if an organization does scan with credentials, there are still many different targets that might not support remote logins, active scans might not occur that often and if a new host or network is added without telling the audit team, it might never be scanned.

In the case of Robert Moore, the Passive Vulnerability Scanner would have been able to identify all externally facing systems, SIP/VoIP applications and routers, determine which ones had exploitable or critical vulnerabilities and also which ones connected to the Internet, as well as each other. And even if these systems had never been alerted in the past because they had never been scanned, as soon as they were scanned, the PVS would have provided relevant data and identified these systems as "new" resources.

In addition to the PVS, the Log Correlation Engine can also be used to watch all network traffic passively. This can be accomplished through a netflow agent, through a direct network sniffing agent or even through firewall logs that log all 'accept', 'permit' or 'allow' connections.

Conclusion

For whatever reason, the organizations compromised by Robert Moore were exploited with relatively simple techniques. If these organizations had any notion of vulnerabilities or intrusions they did not act on them. Tenable's approach to unifying security monitoring makes it easier for any size organization to understand their risk while at the same time monitoring their network for abuse and compromise.

Dave Breslin, Tenable's Director of Sales Engineering, was recently interviewed by Stephen Northcutt, President of the SANS Technology Institute, about recent advances in network security and describes the benefits of passive vulnerability scanning.

Tenable has recently released version 2.0.3 of the Log Correlation Engine (LCE). This blog entry will highlight the new features as well as recent enhancements to the log parsing rule sets and the event correlation algorithms.

Daemon and Agent Enhancements

The main log processing daemon has enhanced performance. Several optimizations were added which drastically increase the overall events per second throughput. LCE customers should notice substantially lower CPU utilization as well.

Additionally, the stability of the remote LCE clients (such as the tail agents, netflow, network sniffing or OPSEC agents) has also been enhanced.

We are encouraging all customers to upgrade their daemon and clients to 2.0.3.

Log Parsing Rule Enhancements

The entire signature library of log parsing rules has also been analyzed and rewritten for higher performance and accuracy. This new library is roughly ten times more efficient than before which also leads to much higher events per second rates and lower CPU utilization.

Tenable has also added more unique event 'types' which enhances analysis and reporting. The current list of supported event types, with new event types indicated with an asterisk, is as follows:

• application - Logs from generic applications and daemons.
• backdoor (*) - Primarily normalized network IDS events indicating a backdoor or covert channel. Events from the blacklist.tasl correlation script which correlate with Arbor, SANS, Bleeding Threats and other types of blacklisted IP addresses.
• compliance - Events which violate PCI, SOX and other types of compliance issues.
• compromise (*) - Primarily network IDS events which are critical in nature or indicate a successful attack.
• connection (*) - Firewall 'accept', 'allow' and 'permit' events which indicate a network connection.
• correlated (*) - A generic type for a variety of correlated events.
• detected-change - Indicates a change detected on the network, at a host, with a user or with an application.
• dhcp (*) - Covers all DHCP logs such as IP address leases.
• dos - Primarily network IDS events that indicate some sort of denial of service attack.
• dns - Logs from DNS servers such as Bind.
• error (*) - A generic type to catch error log messages from a wide variety of applications and network devices.
• firewall - All network deny firewall events as well as system changes.
• ftp - Logs from a variety of file transfer protocol network daemons.
• hids - Logs from host based IDS programs.
• honeypot - Logs from a variety of network and system honeypots.
• intrusion - Generic normalization of non-critical IDS events.
• lce - Status and connection logs from the Log Correlation Engine.
• login (*) - Generic type for successful logins from a wide variety of OSes, network devices and applications.
• login-failure (*) - Generic type for failed logins from a wide variety of OSes, network devices and application.
• logout (*) - Generic type for logouts from a wide variety of OSes, network devices and application.
• mail - Logs from Sendmail, Postgres and other mail daemons.
• mysql (*) - Logs from MySql.
• nbad - Logs from network based anomaly systems such as Stealthwatch.
• nessus - Logs from the Windows or UNIX Nessus 3 daemons.
• network - Logs from the Tenable Network Monitor or Tenable NetFlow Monitor agents.
• p2p-activity (*) - Generic network IDS or firewall logs which indicate P2P activity.
• pup-activity (*) - Generic network IDS or firewall logs which indicate some sort of spyware or undesired software.
• radius - Logs from  various radius authentication devices.
• reboot (*) - Logs indicating network devices, OSes or applications which have been shutdown or restarted.
• router (*) - System logs from network routers.
• scanning (*) - Logs from firewalls, network IDSes and other sources that indicate a host is performing port scanning.
• spam - Logs from mail applications and network monitors that indicate spam activity.
• stats - Logs from the LCE's statistical event daemon (the stats daemon).
• switch - Logs from a wide variety of network switches.
• system - Generic type for all system events such as time changes, new hardware discovery and software installation or removal.
• user-activity - Events for new users, changes to user privileges and many other user related activities.
• virus (*) - Logs from network IDSes, firewalls and host-based programs which indicate detection of a virus infection.
• vmware (*) - Logs from VMware systems including startup and shutdown of virtual machines as well as addition of new virtual machines.
• vpn (*) - Events such as VPN to VPN connections, successful remote connections of users and modifications of VPN configuration.
• vulnerability (*) - Normalizes real-time logs from the Passive Vulnerability Scanner.
• web (*) - Logs from Apache, IIS and many different web proxy devices.
• wireless (*) - Logs from a variety of wireless access points.

These new event types are also made use of heavily by the updated TASL correlation scripts which is covered in the next section.

If you have not upgraded to version 2.0.3 yet, these plugins are available by doing a manual plugins update. If you do upgrade to version 2.0.3, we recommend doing an additional plugin update to get the very latest available rules.

Updated TASL Correlation Scripts

Also with this release of LCE 2.0.3, Tenable has enhanced the accuracy, performance and ease of use of the existing library of TASL correlation scripts.

Many of the TASLs which perform similar algorithms on different events have been combined. Some TASLs which performed analysis on specific event sources (like just the Dragon IDS) have been made more generic to work on any source. This generalization occurred through the use of the new 'types' in the log parsing rules.

In addition, a performance analysis of each TASL was also accomplished and many optimizations were made.

And finally, with the new 'type' tagging in the underlying log parsers, several new classes of TASLs were written to generically look for a wide variety of interesting compromise and suspicious activity.

There are currently 35 TASLs available. The main TASL download site has also been re-categorized with new sections for easier comprehension of what they do.

New and updated TASLs that I would like to point out include the following:

• attack_and_connect_to_blacklist.tasl - Any system which is attacked as detected by a critical IDS event and then connects to a blacklisted IP address will have an alert generated. This finds systems which have been compromised and are part of or being controlled by a botnet.
• blacklist.tasl - This script has an external helper Perl script which downloads publicly available blacklisted IP address from sources like Arbor, SANS and Bleeding Threats. For any firewall connection events or sniffed or netflow sessions, it evaluates in real-time, any connections to or from a blacklisted IP address.
• crowd_surge.tasl - Detects when a large number of local systems reach out at the same time to a remote system. This can indicate spyware, rootkit and botnet activity. The script now supports firewall 'connection' type events as well as Tenable netflow and network monitor logs.
• new_network_user.tasl and new_system_user.tasl - These scripts subscribe to any login events and automatically learn the current network users as well as current system users. Previously the new_network_user.tasl was known as thew new_nw_usr.tasl script and it has been renamed to be more clear.
  
• nids_compromise_detection.tasl - Looks for any host which has been attacked with a critical NIDS event and then attacks a different system. This can indicate a compromised system.
• nids_compromised_server.tasl - This script automatically learns (through Passive Vulnerability Scanner real-time events) where your servers are and if any of them attack another system, an alert is generated.
• long_term_scanning.tasl - Detects several conditions such as systems performing continuous scanning for at least three hours, systems that have been attacked which have started to scan and systems that have been scanned which are now scanning others as in a worm outbreak.

Many of the older TASLs also have new types of functionality. If you are running additional TASLs on your LCE, we strongly recommend checking to see if it has been updated and if the new functionality is relevant for your environment.

Below is a screen shot of an alert generated by the attack_and_connect_to_blacklist.tasl script:

This script alerts when a host is attacked, and then the host reaches out or is connected with an IP address on one or more suspected "black lists" of IP addresses. In this particular case, a host was attacked and this event was detected by an IntruSheild IPS and then an outbound network connection was detected with a Tenable Network Monitor. This connection was found to terminate with an IP address tracked by the SANS Internet Storm Center.

Many of the TASL correlation scripts perform this level of analysis in real time.

For More Information

Installation and upgrade instructions are available on the Tenable Support Portal. After upgrading to version 2.0.3, users should perform a plugin update and then manually audit their TASLs to see if they want to remove or replace any of them with the new ones which are now available. Tenble LCE customers should contact Tenable Support if they have any questions regarding the upgrade to 2.0.3

Tenable's research group recently added checks to both Nessus and the Passive Vulnerability Scanner to detect HTTP authentication which occurs over plain-text. This blog entry will discuss why this is an issue, and how the detection methods work.

HTTP Plain Text Authentication Security Risks

If you are new to security and you were analyzing how logins to an HTTP server worked, you would not observe your password. Instead, the HTTP protocol will send an encoded string of your password such as this:

Authorization: Basic cGFzc3dvcmQ=

The form of encoding used is not strong encryption, it is just a way to keep the information from being directly recognized by a human. The algorithm used by web servers is known as "Base 64". Encoding and decoding Base 64 passwords is very easy, which makes it very insecure. There are even online forms where you can encode and decode strings. If you copy the above "cGFzc3dvcmQ=" string into a base 64 decoder, you'll see it is the word 'password'.

Security Risks of Plain Text Authentication

Obviously anyone who can sniff a login session to a web application can gain user name and password information. What is more interesting is why these logins occur in the first place. There are several reasons:

First, security is often added later on in the development of web applications. A very stereotypical view of unsecured application development is to imagine someone working on the core functionality of the application and then worry about authentication later.

And secondly, many applications and web management consoles don't care if they are running over HTTPS (a secured web server) or over plain text. When systems are put into production, unsecured access to the plain text web server on port 80 can be forgotten to be disabled or blocked at the firewall. Application and firmware upgrades can sometimes roll back changes and end up re-enabling the unsecured web server.

Detecting Web Servers and Clients Using Plain text Authentication

Nessus plugin #26194 "Web Server Uses Plain Text Authentication Forms" detects remote web servers that have one or more forms which contain a field named 'password'. This script is dependent on the results of the web_mirror.nasl script which performs a wide variety of web site analysis.

PVS plugins #3018 and #4225 detect both web servers and clients which use plain text HTTP authentication. Since the PVS sniffs both sides of any network session, it can see which web servers accept plain text HTTP authentication as well as which clients are also using this.

Both the Nessus and PVS techniques will discover and observe web servers on port 80 and will also recognize web servers running on non-standard ports.

When analyzing the results from both Nessus and the PVS, consider the location and environment where the test is performed. For example, being able to connect to the web management interface of a router from an internal network is not the same as being able to log into a web application interface from the Internet. Both targets might use plain text HTTP authentication, but have different levels of access to potential attackers.

When analyzing large numbers of systems in an enterprise, tools like the Security Center can help make sense of which assets accept plain text HTTP authentication and may be at higher risk.