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.

IT auditors, penetration testers, and incident responders often ask if a system they are analyzing is managed. A managed system is one that is being looked after, updated and maintained by an IT staff of some sort. An unmanaged system is one that is on the network, but perhaps has been forgotten, isn’t authorized or has some other reason for it not to be there or updated by anyone else.

Security findings for managed systems and unmanaged systems are reported differently. For an unmanaged system, the recommendation is to make the system managed and bring it into a secured state. For security issues with managed systems, the recommendation is to alter the current management processes to make them more secure.

Unfortunately, there is no “under management” test that can easily be automated. This blog entry will describe some of the different types of data that can be gathered from logs, Nessus scanning and Passive Vulnerability Scanner sniffing that can help identify systems with and without management.

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.

As a vendor, Tenable has to demonstrate compliance in many different types of categories. The Payment Card Industry, the Center for Internet Security and US government's FDCC program all have certification standards and procedures for vendors like Tenable. Since Tenable is certified in most of these these categories (we're in the process of becoming an ASV), I though it would be interesting for our blog readers to share some of our insights into the differences and misconceptions between them.

Recently, I had the chance to work with several larger Tenable enterprise customers who were charged with figuring out what the perimeter of their network really looked like.

I showed them how multiple Nessus scanners and Passive Vulnerability Scanners deployed throughout their infrastructure could be leveraged to provide near real-time visibility into every boundary or enclave.

With the rise in popularity of the SANS Consensus Audit Guidelines, which specifically call out "Boundary Monitoring", and the increased number of Tenable federal customers deploying 20+ active and passive scanners to perform CyberScope scanning, I decided to write a best practices paper on how network boundaries can be monitored and understood.

The paper starts out with simple concepts such as comparing what a scanner on the inside of a firewall can find compared to what one on the outside scanning inbound can find. It finishes with how distributed scanning and sniffing can help identify trust relationships and poor firewall rules between enclaves. There is also a lot of great artwork that facilitates understanding of these complex ideas:

 The paper is available for a free download here. If you have feedback or want to send me a note about it, feel free to post comments to our Tenable Discussions Forum and reach me on Twitter @RonGula.

When a virus infected one of my Nessus scan targets, I did what any sensible CEO of a SIEM company would do - let it run and see what types of logs and alerts it generated!

Over the 30 days that I let it run, I was able to collect a wide variety of interesting data. This included suspicious Windows application logs, internal network scans, communication anomalies, attempts to break into other lab computers and "classic" outbound connections  to various IRC channels. It even modified how logins worked, breaking my Nessus patch audits. 

Attendees of this webinar will learn about various detection methods that can be used with SIEMs to look for malicious software and computers infected with hostile code. 

Putting a Virus under the SIEM Microscope
Wednesday, January 26 2:00 PM EST
https://www1.gotomeeting.com/register/178513273

Metrics that show risk are an excellent way to communicate security information to different people and groups within an organization. However, trend lines can hide a lot of details and nuances. This blog entry discusses an example network where a month’s worth of scan data is used to trend overall vulnerabilities, those that have been around longer than thirty days and correlating systems needing a reboot with residual security issues.

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.

One of the advantages of Tenable’s suite of Unified Security Monitoring products is that continuous vulnerability monitoring can be used to find reintroduced security issues. Vulnerabilities that were once mitigated but are now back again represent process and organizational issues that must be handled differently. Simply reporting the vulnerability again and waiting for it to be patched does not address the fundamental flaw in the process. This blog entry discusses how recurring vulnerabilities are detected, some of the reasons why they may be recurring and how you can track and report on them with Tenable’s SecurityCenter.

I recently had the opportunity to write an in-depth article for issue #22 of (IN)Secure magazine. The article discussed how the results and reports from your real-time network monitors can be used to make better decisions on how your vulnerability scanners are used.

In short, there should be a feedback loop between your scanners and your event monitors. Both processes can help refine each other and ensure you are performing the correct level of montioring. This is also a basic component of our Unified Security Monitoring strategy. Read the full article here.

Recently I gave a presentation at the “SANS Penetration Testing Summit ” titled "Zen and The Art Of An Internal Penetration Testing Program". This presentation outlines the steps required to create a successful program and perform internal penetration testing. There are several key components that must exist to create a successful program:

• Getting Management Buy-In - This is the first and most important step. Management must understand the testing strategy and be kept in the loop on the results and remediation. Business units must also be consulted to determine the impact scanning will have on their environment to establish a schedule for scanning. It does not matter what kind of testing you plan to perform, from vulnerability scans with Nessus to full-blown penetration testing, you must get the approval from management.

How do you know that the software being executed on your network is authorized and acceptable? Many organizations struggle with this concept or ignore it altogether. There are generally four approaches to enabling or preventing software usage:

• White listing of software - A third party application or very tight operating system configuration settings is used to only enable specific authorized program names. Everything else is denied by default.
• Black listing of software - A third party application specifically controls what programs cannot be run. Anything not on the list is allowed by default.
• Ignorance – Some organizations simply do not have the staff, resources, technology or concern to attempt any type of analysis of what software is allowed.
• Auditing – Using one or more methods, an organization takes no immediate action on software usage, but it does track and analyze what programs are available and in use to help make better policy decisions, to have a more intelligent incident response process and to help IT troubleshoot issues.

Many different types of malware and botnets require some sort of exploit payload. This payload can be obtained through traditional compromised services such as HTTP, FTP and even TFTP. Payloads can also be delivered by highly customized or proprietary protocols designed by the malware and botnet creators. 

Tenable’s research team has encountered some ports that can't be fingerprinted and appear to start an executable download when they are connected to. This is a tactic that some of the botnets use to infect additional machines.

Any program that can make a simple TCP connection and save any received data to a file can be used to retrieve these types of files. For example, a program such as netcat can be used to connect to one of these services to obtain the malware or exploit program being distributed by redirecting the data to a file. The following command line uses netcat to connect to a host on port 9002 and save the resulting data into a file named “executable.bin”.

nc 192.168.20.100 9002 > executable.bin

If you suspect this to be a malicious file, you can have it analyzed by an anti-virus tool such as ClamAV or even uploaded to a service such as Jotti's malware scan.

Nessus Detection

Plugin 33950 named "MS Executable Detection" attempts to connect to any service that has been identified as being "unknown". Nessus has an extensive database of application banners and fingerprints. If an open port is identified but cannot be fingerprinted, Nessus will place it into the knowledge base marked as an "unknown service". All services marked in this way will be probed by the new plugin to see if they are distributing an executable.

Tenable's research team has encountered these types of servers running on many different ports, primarily on ports much higher than 1024.

To have Nessus look for these services, configure your scans with the following settings:

• Ensure the MS Executable Detection plugin (which is in the Service detection family) is enabled.
• Perform port scans that target ports higher than 1024. For a complete audit, consider scanning all ports.
• Ensure that the Service Detection (2nd Pass), Service Identification (2nd Pass) and Service Identification are all enabled.
• Make sure that the "Probe services on every port" setting under the Advanced tab and "Global variable settings" is enabled.

Below is a Nessus scan policy that you can download for use with your Nessus client. It has a pre-configured scan policy, which can be used to scan networks to look for these services hosting potentially hostile executables.

Download MS-Executable-Scan.nessus

Below is a screen shot of scan results from an infected system:

When the plugin detects an executable, it will display a binary hex dump of the contents. It will also generate hash values of the obtained file that can be submitted to http://www.virustotal.com/buscaHash.html for analysis and other organizations such as Bit9. 

For more Information

Previous blog posts have discussed using Nessus, the Passive Vulnerability Scanner and the Log Correlation Engine to look for compromised or infected hosts:

• Boss, I think Half of our FTP Servers are fake!
• Detecting Compromised Windows Hosts
• Hunting Symantec Worms
• Using "New Port Browsing" Events to find Worm/Trojan/Rootkit Activity

The current DNS cache poisoning issue is a great example of a vulnerability that must be tested with both patch auditing as well as network scanning. Nessus is ideally suited to perform both types of   audits. This blog entry discusses the advantages of using an auditing tool like Nessus as compared to pure patch auditing or network scanning.

NAT and DNS Cache Poisoning

A key part of exploiting this vulnerability is the ability to predict the source ports of replies from a DNS server you wish to inject malicious data to. Consider the following sequence of source ports for queries to a DNS server that randomized its responses:

request 1 - 51256
request 2 - 56277
request 3 - 54798
request 4 - 58272
...

Now consider the same set of queries performed against the same server, but this time the DNS server connectivity is going through Network Address Translation (NAT) (e.g. a firewall) that is port forwarding port 53:

request 1 - 46093
request 2 - 46094
request 3 - 46095
request 4 - 46098
request 5 - 46099
...

Clearly the responses are not randomized and the issue occurs due to the network address translation process not using randomization to translate queries across this interface.

Performing a patch audit of the DNS server would show that it was indeed patched and in this situation, would give a false sense of security. Of course, performing a network scan on the inside of the network would also show a DNS server with randomized source ports and give a similar false sense of security. However, performing an audit outside of the NAT device would show that the ports were not randomized. Clearly, a network scan in this case was a convenient way to discover the security issue where other methods would fail.

Patch Auditing vs. Network Scanning

If an organization only does patch auditing or they only do network scanning, they are missing network nodes and information that could be vital to finding highly vulnerable systems or non-compliant systems.

We have a white paper that can be downloaded (without requiring registration) that details the strengths and weaknesses of each technique and also includes a discussion of continuous network monitoring as well. The paper is titled "Blended Security Assessments".

I frequently ask our customers how they perform such monitoring and remind them of the value of extending their coverage. For organizations that just perform un-credentialed network scans, I encourage them to obtain credentials for their target systems and start to perform patch audits. Similarly, for organizations that don't have a network scanning solution and are entirely relying on some form of patch management or software distribution system, a network scan will often discover many other network devices and systems which are not under control of the patch management system.

Exposing More Vulnerabilities with Network Scanning

If a NAT device can directly impact a major DNS vulnerability, what other types of interaction from the network can result in more exposure for an organization? This is not an exhaustive list, but consider the following "network" or infrastructure devices that can have a major impact on your security posture:

• Unknown Firewall Rule Changes - From an internal perspective, you may feel comfortable that your systems are patched, thinking that insecure services like SNMP, RPC, TFTP, .etc are blocked by your network firewall. If this changes though, you may end up exposing vulnerable services to the Internet. External network scans help to look to see what is really exposed.
• Load Balancer Rule Changes - I've encountered many hosting organizations that have sophisticated fail-over, load-balanced and out-of-band managed web and content servers. When these systems have unauthorized changes or partial outages, they can expose management ports that rely on the firewall shielding them from public to protect them essentially.
• Virtual System Managers - More and more organizations are relying on VMWare and Xen. Sometimes these  virtual systems are simply migrated from one physical server to another. This can have unanticipated exposure if the previous system was firewalled or secured in some manor. Virtual servers also have their own NAT technology which can also make it difficult to identify their exposure without performing a network scan.
• IPv6 - Performing an IPv6 scan with Nessus can identify which systems in your network run this protocol. Those types of systems may be able to communicate with each other and bypass more traditional IPv4 filtering and access control techniques.

For More Information

We've visited the topic of scanning and patch auditing several times in this blog. Below are relevant blog entries that may be of interest:

• Testing the Effectiveness of your Patch Management System
• Knowing When to Patch (a.k.a. - Don't let your scanner tell you when to patch)
• Reporting Vulnerabilities in an IT Managed Environment
• Finding Vulnerabilities Older than 30 Days
• Security Metrics - Differentiating new Vulnerabilities from Change
• Security Metrics - How often should we scan?

Tracking the hardware network address of Ethernet devices can be a daunting task for an enterprise network operations group. The ability to track Ethernet (or MAC) addresses can have tremendous value for tracking changes to the network, user activity and access control. This situation can be exacerbated in a dynamic IP address environment.

Over the years I've spoken with many different customers who used scripts and other techniques to crawl switches, sniffers, agents  to scour their network to keep their list of MAC addresses up to date. Each of these usually worked well, but the data ended up in only one organization's solution and often, these solutions didn't detect changes in real time. 

This blog entry describes the various methods that can be used with a Tenable Unified Security Monitoring solution to collect and track Ethernet address information from scans, network monitoring devices and log analysis tools.

Scanning and Credentialed Audits

Nessus vulnerability scans will discover the Ethernet address of a remote host under the following conditions:

• the host is in the same collision domain as the scanner AND  an ARP 'ping' is enabled
• the remote host is Windows AND it can be queried for its MAC address through SMB (plugin #10150)
• the host is being scanned with credentials AND it is a Linux or Windows computer
• Plugin #10551 attempts to enumerate all network interfaces via SNMP
• Plugin #33276 (Enumerate MAC Addresses vis SSH) logs the MAC address from credentialed UNIX scans

It's important to realize in these audits that sometimes a host may have multiple addresses if it is running more than one hardware or virtual interface. Also, for credentialed testing, Nessus only logs the Ethernet address of the primary network interface. Below is a screen shot from a Nessus Client showing the scan results of plugin 10150:

If you run a tool like the Security Center, the MAC addresses obtained by Nessus scans can be used for filtering and asset list creation. For example, you could use the MAC prefix assigned to Cisco devices to automatically create a dynamic asset list of all Cisco devices. Below is a zoomed in screen shot of MAC addresses being displayed under the Security Center:

As you can see, not all IP addresses have had their MAC addresses identified. This could be because the device was in a different VLAN, wasn't scanned with credentials, or was not a Windows, OS X or Linux device. MAC addresses can also be used in a search field so that you can immediately discover the vulnerabilties and configuration of a host with with just its MAC address.

Passive Network Monitoring

The Passive Vulnerability Scanner (PVS) will log the MAC address of any "New Host" that is discovers. This is an excellent way to look for changes in DMZs, server farms and other locations where you don't normally get a new host that often. 

Below is a screen shot of some New_Host event logs from the PVS as seen under the Log Correlation Engine:

When reporting a new host, the PVS will log the Ethernet address of the IP packets it sees. If your PVS is deployed on the perimeter of your network, such as if it were monitoring all inbound and outbound traffic, then the MAC address logged will likely be that of your firewall, router or NAT device. Deploying the PVS on the span port of a core switch or router is an effective method for sniffing unique MAC addresses.

Log Analysis

If your network generates logs from the use of DHCP, arpwatch, the Passive Vulnerability Scanner and other sources that contain Ethernet addresses, the Log Correlation Engine (LCE) can be used to parse these and generate alerts when new hardware addresses become active. For example, consider the following arpwatch logs:

Jun 23 19:05:45 localhost arpwatch: new station 192.168.20.207 0:c:29:dc:e7:ad
Jun 23 19:05:45 localhost arpwatch: new station 192.168.20.12 0:11:43:fd:73:33

Not only is arpwatch letting us know it found a new host, it has also logged the MAC address.

The new_mac.tasl TASL script for the Log Correlation Engine will automatically track a wide variety of log sources from various Unix, Windows and network devices. When it gets a log, it will extract the MAC address and then compare it to a list of previously discovered MAC addresses and issue an alert if a new one has been found. Below is a screen shot of what this looks like when viewed under the Security Center:

Notice that the original log message is retained and that the vendor prefix of the MAC address has been used to identify the vendor. This can help identify if there was a new VM, a new router or simply a new laptop that has been added to the network.

Tenable has also extended this concept further with automatic recognition of usernames and associating them to their MAC addresses. The user_to_mac.tasl TASL script watches DHCP logs as well as authentication logs to build and associative array of usernames and MAC addresses. We've blogged about this concept in depth previously. The feature is extremely useful to detect changes in a user's behavior, such as logging in from another user's computer or using a new laptop.

For More Information

The following previous blog posts will likely be of interest to readers:

• Auditing and Finding Virtual Machines
• Wireless SSID Enterprise Discovery
• Improper Network Segmentation Testing With Nessus
• Access Point Detection
• Asking Vista for its List of Network Interfaces

Several new plugins for Nessus were recently introduced which can detect FTP servers that are fake:

• Fake FTP server accepts a bad sequence of commands
• Fake SMTP/FTP server (backdoor)
• Fake FTP server does not accept any command
• Fake FTP server accepts any command

The basic concept is that a hacker, botnet, malware or virus needs to have some sort of method for communication, to receive commands, to transfer data or provide continued access so they use a backdoor. But rather than use some sort of custom or proprietary command and control, they use a service that looks like an FTP server.

By "looking" like an FTP server, connecting to the daemon port (usually TCP port 21, but could be any port really) results in an FTP banner. Some of the fake FTP daemons that have been encountered even implement some of the actual FTP protocol. However, most fake daemons don't support all of the FTP options and error codes which is what the above Nessus plugins try to ferret out.

Below are two screen shots of different real-world systems that had an FTP service discovered on a port other than 21. One even claims to be a Microsoft server.

These plugins are available in the FTP and Backdoors Nessus plugin families. If you are doing a complete audit of a system or network, including these checks is a good idea. If you would like to simply scan your network for these checks, the following Nessus policy file can be used to quickly run your scans with the Nessus Client.

Download ftp-backdoor-scans.nessus

It includes three polices that enable the four FTP checks and "Experimental" NASL plugins. One policy performs a full TCP port scan, the other a generic scan and the last one just looks at port 21. To use this policy, download this file to your system and open it up with the Nessus Client and then connect to your Nessus canner and add your target network ranges. If you have not performed a plugin update recently, or don't have automatic updates enabled, make sure you grab the latest plugins (which you should be doing anyway) before trying this policy.

These plugins were also built to minimize security warnings. For example, if a fake FTP server always logs you in this can end up mis-identifying it as a valid Anonymous FTP server.

The hunt to find these types of backdoors should throw into light how your organization can detect these types of changes:

• Do you have some sort of realtime network monitoring that can alert on new services? Products like the Passive Vulnerability Scanner sniff your traffic in real time and can send an alert when they find new hosts, services and vulnerabilities.
• Do you have some sort of way to compare ongoing active vulnerability scans with each other and identify what is new? Products like the Security Center and Nessus automatically produce reports about what is new for every scan and also keeps a historical history for each vulnerability for when it was first found and last seen.
• Do you have some sort of process to identify services that are unauthorized? Most Nessus users tend to think about finding vulnerabilities and mitigating the critical ones, but for compliance and consistency, many organizations simply want to know if a server or service is authorized or not and if it is being managed.
• And if you do find such a backdoor on your network, being able to turn to netflow, firewall logs, IDS logs or whatever you have generating logs is also important. Products like the Log Correlation Engine can show you potentially how this system was compromised and if any other local systems have been communicating with it.

These plugins were written by long time Nessus plugin contributer Michel Arboi. Michel has his own blog, which includes lots of very good Nessus information such as a recent post on how to configure Nikto within a Nessus scan.

We've blogged before about hunting backdoors and detecting compromised hosts with Nessus. If you are hunting for these types of issues, also keep in mind that any high-port FTP service should be suspected, as that is a very common backdoor file transfer technique. If this topic is of interest to the reader, the older blog postings are listed here:

• Detecting Compromised Windows Hosts
• Detecting "Off Port" Services
• Hunting Symantec Worms
• Using "New Port Browsing" Events to find Worm/Trojan/Rootkit Activity

Apple recently gave Windows iTunes users the option to download the Safari web browser. This move was criticized by many bloggers and security experts. What we will be discussing in this blog today is detection of the Windows Safari application and also examine how organizations could react to this situation.

Detection

Nessus plugin #31788 named "Safari Detection (Windows)" looks for Safari installed on a Windows platform. This plugin requires credentials to analyze the Windows system to see if the browser has been installed. If credentials are not available, this plugin won't report an issue.

The Passive Vulnerabiltiy Scanner can also be used to generically report the active web browser being used on any host it sees web traffic originating from. In the Security Center screen shots below, all user agents detected by the PVS have been listed:

In the screen shot on the left, only Safari browsers on Mac OS X computers are shown. On the right screen shot, a host that has a single Windows Safari client is shown among several different other browser types. The PVS also has a unique plugin (#3705) which detects the Safari browser.

Analysis

I've had a few conversations with our customers about this issue and there are a few themes:

• In organizations that banned the use of iTunes, this event gives them much more evidence to support this decision. The organization should be in charge of what software gets run on a network, not the application vendor. This also gives them reason to ban other applications that might include a software delivery method.
  
• In organizations where iTunes use is allowed, but there is still a requirement for a standard browser such as Internet Explorer, some leniency was given to users who have been educated to accept security updates from their vendors. It could be argued that the Safari push looked like a security update.
• Some organizations are modifying their acceptable use policies to more explicitly state that unauthorized software should not be installed, even if it is from the vendor of an approved application. I've heard several comments from customers basically expecting other major software and operating system vendors to use this sort of technique.

For More Information

We've bloged in the past about enumerating various applications and finding software that should not be there on a corporate network:

• Enterprise Software Discovery with Nessus
• Detecting the Apple iPhone
• Exceeding NIST and CIS Benchmarks
• Security Metrics - Differentiating New Vulnerabilities from Change
• Active and Passive Tor detection

Over the past few months, there have been a few vulnerabilities in ActiveX controls from MySpace and FaceBook. Nessus users can audit Windows systems running Internet Explorer with the following plugins:

• #30219 myspace_uploader_1_0_0_6_activex_overflow.nasl
• #30152 facebook_photo_uploader_4_5_57_1_activex_overflows.nasl
• #30134 image_uploader_4_5_70_activex_overflows.nasl

These plugins require credentials for Nessus to log into the Windows computer and analyze which ActiveX controls and versions are available. The plugins are available to all Nessus Direct Feed, Registered Feed and Security Center users. These vulnerabilities are unique because they can affect a Windows system that has had its Internet Explorer and Windows operating system fully patched.

If you'd like to know which computers and users on your network are visiting MySpace or FaceBook, this type of monitoring is performed by both the Passive Vulnerabiltiy Scanner and the Log Correlation Engine. The PVS will identify which hosts log into MySpace and FaceBook along with the account username. The Log Correlation Engine can take these events from the PVS and use the usernames to associate with a source IP address for tracking of users with mobile IP addresses. This capability was previously discussed here.

For more information about ActiveX controls, please consider the following links:

• http://isc.sans.org/diary.html?storyid=3929
• http://isc.sans.org/diary.html?storyid=3931
• http://blogs.zdnet.com/security/?p=846

Recently, Tenable Network Security introduced Nessus plugin #29871 which looks at the content of a web site to see if it is hosting potential hostile javascript code. There have been several recent mass defacements and infections of 1000s of web sites through SQL injection attacks. Plugin #29871, named "Web Site contains links to malicious javascript files", specifically checks web sites for links to the "uc8010.com" addresses used in this recent wave of infections.

When performing CGI scans, Tenable recommends several strategies:

• By default, Nessus will only mirror 200 pages for a scanned site. If your site has more pages than this, you should increase this value to a relative amount.
• Plugin #29871 is dependent on the webmirror.nasl script so this plugin (#10662) should either be enabled, or the test should be performed with dependencies enabled at runtime.
• If you are scanning web servers that run on ports other than 80 or 443, be sure to include these in your scan policy.

Tenable also introduced a plugin for the Passive Vulnerability Scanner (#4334), which also detects web sites that are hosting this type of content based purely on traffic analysis.

Plugin #29871 is currently available to Nessus Direct Feed and Security Center users.

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.

Tenable's research group has recently released several updated plugins for both the Nessus scanner and Passive Vulnerability Scanner to detect Tor in operation and waiting for connections.

Tor is a self organizing peer-to-peer network application. It encrypts network communications and also randomly spreads it across other Tor nodes to prevent traffic analysis.

Tor can be used for anonymous network browsing. It has recently been reported as being used by the Storm worm to connect to other potential victims as well as obtain command and control instructions.

Hostile "Tor users" have been running a Tor network "end node" in order to monitor and sniff unencrypted exit traffic for sensitive information.

Detecting Tor

Nessus plugin #26026 (currently available to Direct Feed customers) can be used to scan a network for systems configured as a Tor server.

For the Passive Vulnerability Scanner, several plugins exist

• 2542 - Tor Tunnel Detection (detects on start of Tor communication)
• 2543 - Tor Tunnel Detection (detect ongoing Tor communication)
• 4212 - Tor Tunnel 'End Point' Server Detection

When analyzing a network that contains Tor applications, you should ask yourself the following questions:

• Does carrying this anonymous traffic expose my network to risk?
• Does the presence of Tor indicate that the network has been compromised?
• Has there been an increase in the amount of virus, IDS or other types of alerts from the systems running the Tor software?
• Does the host running Tor consume noticeable network bandwidth?
  
• Does Tor open up any unauthorized or un-auditable connections into our network?

Below is a screen shot of a node discovered to be running Tor as viewed under the Security Center. This particular host also has a version of Firefox which is fairly outdated.

This site also was running the Log Correlation Engine with a Tenable Network Monitor. When viewing the last 25 days of network connections from this node, several were made to ports in the 9000-9100 range which is common for Tor communication. Below is a bar chart port summary of all TCP and UDP network connections.

This discovered Tor node was a client. If it were a Tor end server, the Log Correlation Engine and Tenable Network Monitor agent could have been used to analyze all "outbound" network connections.

For More Information

Nessus active network scans do not discover clients with installed Tor software. Tor clients don't have open ports which can be identified with traditional network connection requests and fingerprints.

If this is a requirement, consider performing a credentialed network scan and enumerate the installed software. Keep in mind that if you want to find out this sort of information in real time, you should use a network IDS or monitor the network with the Passive Vulnerability Scanner.

For other thoughts on passive network monitoring, we've blogged before about several different methods such as watching for new ports being browsed on, detecting network proxies and monitoring traffic for known and unknown encryption.

"30 Days" seems to be the default amount of time organizations look for vulnerabilities to be patched by. Version 1.1 of the Payment Card Industry standard specifically states a 30 day time period. Of course the actual age of a vulnerability has nothing to do with how easy it may or may not be to exploit, but politically, old vulnerabilities can indicate broken policies, bad IT processes and lapses in compliance.

This blog entry discusses how networks can be monitored for vulnerabilities with Nessus, the Passive Vulnerability Scanner and the Security Center in such a way, that vulnerabilities older than 30 days can be easily identified.

The Vulnerability and Patch Life Cycle

IT organizations that "get it" run their networks with the expectation that there are vulnerabilities in their required technology that have not been found or publicized yet. As such they use compensating controls such as firewalls, auditing, system hardening and intrusion prevention to mitigate these risks.

When a specific vulnerability is discovered and a patch has been published, a political "clock" can start ticking which measure how long it takes to get this security patch applied.

In some organizations, all security patches are required, even if there are other mitigating controls. I've seen organizations require applying a patch for Apache on a production Red Hat server, even though the system wasn't actually running the web server. The idea is that if a web server is enabled one day, it should be patched ahead of time. Other organizations only require security patches for technologies they are exposed to.

Ensuring Nessus has the Most Recent Checks and Credentials

If you are scanning with Nessus to look for out-of-date vulnerabilities, you should realize two major concepts:

• If you are using the registered feed, your checks are already 7 days old
• If you are not using credentials you won't be able to do a patch audit

If you are measuring the age of your vulnerabilities, you should be doing this with the most recent plugins available to you. I've spoken with customers who only update their plugins once a month or even less often. They take comfort in that Nessus gives them very useful data without being updated. This is sort of like getting your car's brakes checked, but then telling the mechanic not to check the oil.

Just because Nessus is finding very useful information, doesn't mean that it is testing for everything that  it could. Regardless if you are using the real-time Direct Feed or the seven-day delayed registered feed, updating your Nessus plugins before a scan will always provide a more complete audit than not doing so.

If you are updating your plugins and using the registered feed, all of your checks are one week old. There is great value in the more than 15,000 plugin checks Tenable provides for free to the Nessus community, consultants and MSPs, but if you are using it to find vulnerabilities older than 30 days, you need to actually look for vulnerabilities older than 23 days.

And lastly, when you use Nessus to audit a host or network, unless you give it credentials of the target systems, it won't perform a full security patch audit. Depending on the vulnerability, Nessus may identify a specific missing patch, but it is not performing a full audit. Other security patches may only be found with credentials, especially client-side applications such as Internet Explorer or Thunderbird.

Using Nessus to audit missing patches is a great way to see if your patch management system is working, to perform a more complete vulnerability audit and to also gather many configuration parameters which also impact security.

Manually Finding 30-day Old Vulnerabilities With Nessus

There are many manual methods for using Nessus to find vulnerabilities older than 30 days.

Determining this strictly from one single scan is doable but difficult. Technically, someone can take the results of a scan and check when each plugin ID was first released. This can be manually intensive and actually tests when Tenable releases a plugin and not when a vulnerability was first discovered. Consider a situation where someone enables an older Apache 1.3 server for which has vulnerabilities that are several years old. Your organization may still allow this system to be patched within 30 days. If you are being governed by PCI, compliance requires all security patches to be installed  based on patch availability, not on discovery of vulnerabilities. 

A more common technique is to look at how a network's discovered vulnerabilities changes over time. Differential analysis from two or more scans measures what has been fixed (patched), what vulnerabilities are still present and which are new.

If you are performing these types of scans, remember to scan often. If your scan period is once a week, and you are looking for 30-day old vulnerabilities, a new vulnerability may have been discoverable the day after your last scan.

On larger networks, which have many different types of assets, manually keeping track of which scan policies go with which targets, which credentials go with which targets and how often each target can be scanned can be difficult. I've spoken with several organizations who've developed their own scan tracking and management solutions, and I've also worked with many Tenable customers who use the Security Center to tackle this problem.

Some Nessus clients support some level of scan differential reporting. This process takes the results of two scans and shows what is different about them. This is helpful if you are scanning the same target, with the same plugins. If you are not performing the same type of scan (such as performing a basic OS fingerprint scan as compared to a full patch audit), then your results will certainly be different.

Below is a screen shot of the Nessus 3.0 scanner for Windows:

Multiple reports can be selected and a differential report produced.

When differences are found, the systems with older vulnerabilities or missing patches should be tracked in a report, spreadsheet, ticketing system or some other method.

Manually Finding 30-day Old Vulnerabilities With the Passive Vulnerability Scanner

The Passive Vulnerability Scanner (PVS) can also be used to monitor networks for 30-day old vulnerabilities. Compared to active scanning with Nessus, the PVS has very little configuration or on-going management and it does not require credentials or scan management. Once set up, it continuously sniffs vulnerabilities in your servers, applications and clients.

The Windows version of this tool can be used to take a "snapshot" of the existing vulnerability report. Any two reports can be "diffed" to see what has changed. Choosing two reports that are 30 days apart can easily show which vulnerabilities have not been addressed.

Below is a screen shot of the Windows PVS report differential options:

Automatically finding and reporting 30-day Old Vulnerabilities with the Security Center

Performing this process of discovery on the Security Center (SC3) is very easy. SC3 can be used for automated scan scheduling. Multiple scan policies, scan targets (networks or assets) and scan schedules can be configured and automatically spread across multiple Nessus scanners. The results of these scans are always automatically "diffed" with the current cumulative set of discovered vulnerabilities.

The "cumulative database" inside SC3 is its key to making vulnerability discovery, trending and reporting very simple. It uses the results of different types of one-time and ongoing scans to build up an accurate model of the entire set of vulnerabilities on the network. 

When analyzing this set of vulnerabilities under SC3, there are simple  filters which can be used to display when a vulnerability was first discovered. Since only "live" vulnerabilities are stored in the cumulative database, this filter is an easy way to show which vulnerabilities are 30 days old. Below is a screen shot all existing vulnerabilties which were discovered on a live SC3 system more than 30 days ago:

Also in the above screen shot that the [CVS] link can be used to get a list of all vulnerabilities older than 30 days into a convenient spreadsheet.

This sort of filtering can show which assets are out of date, can be used to download a list of hosts as a spread sheet, and can be combined with other filters such as Nessus plugin family or vulnerability severity.  If your assets are aligned with your political organizations, this can also show which groups aren't patching on time. And lastly, SC3 can be used to automatically email reports of this type to one or more recipients and asset owners.

If multiple Nessus scanners or multiple Passive Vulnerability Scanners are used, SC3 automatically combines the results of these into one cumulative view. This can help compensate if network monitoring or network scanning isn't as comprehensive as it could be.

The ability to find systems with vulnerabilities discovered within a certain set number of days can also be used to create a Dynamic Asset List. These lists can be used for reporting, filtering vulnerabilities and also scan scheduling. Having SC3 perform full daily scans of just the systems with older vulnerabilities is a good way to automatically clean up older vulnerabilties. With this sort of asset list, automatic ticketing or even re-casting of existing vulnerabilities can be accomplished.

For More Information

If you felt the content of this blog was useful, please consider these other blog entries:

• Testing The Effectiveness of your Patch Management System
• Security and IT Controls
• Reporting Vulnerabilities in an IT Managed Environment
• Knowing When to Patch

While reading the 'Declaration of Interdependence' series of articles in the July 1st issue of CIO Magazine (including an additional online article named 'Users Who Know Too Much and the CIOs Who Fear Them'), the term "Shadow IT" was used to describe the aggregate amount of personal, walk-in and employee owned software and hardware that makes its way onto corporate networks and computers.

This blog entry discusses strategies to look for applications that should not be running on your network as well as understanding which "unsanctioned" applications may be the most popular. It also discusses how the Passive Vulnerability Scanner can be used to detect Apple iPhones connected to the local IP network.

Review of Active and Passive Software and Device Enumeration

In a previous blog entry we've discussed how Nessus can use credentials to find UNIX and Windows installed software. Without credentials, Nessus can also scan for a variety of "client side" software that has open ports such as iTunes. It also finds a wide variety of operating systems, applications and network devices.

And lastly, the Passive Vulnerability Scanner (PVS) watches network traffic 24x7 and can identify client applications, servers, operating systems and network devices. The PVS is a bit more stealthy than Nessus in that it might be able to fingerprint that a host is running Ubuntu Linux, simply by watching how it makes queries for software updates.

When Nessus's advanced active scanning and credentialed methods to determine operating systems is combined with the PVS's 24x7 monitoring, a very accurate form of blended discovery can occur.

Each of these technologies can be used to look for authorized technology, as well as looking for those comprising your "Shadow IT" organization.

Supporting Un-supported Technology

Also in the CIO Magazine series of articles, there was a pie chart presented under a title named, 'If You Can't Win, Don't Fight'. The data reflected how surveyed IT departments dealt with unsupported technology.

• 42% said they'd monitor the activity for risk.
• 30% said they'd study the business case for mainstreaming the technology.
• 28% said they'd shut it down as soon as it was detected.

Reading this sort of data tells me that 70% (42% + 28%) of those surveyed need to monitor their networks for something they perceive as "bad" software. And for the remaining 30% that are interested in mainstreaming the technology, there still needs to be some sort of montioring solution to detect when certain technology becomes popular enough to mainstream.

We'll see in the next few sections that deciding what is indeed "bad" or even "not good" isn't as easy as we'd like it to be.

What is your policy? (What isn't on your White List?)

Unless your organization has a policy of what sort of software and devices have been authorized for use, the process of trying to detect "illegal" things can be very difficult. This is because there are millions of software titles and network devices available. It is much easier to enumerate what is allowed. Anything not on the list, by definition, isn't allowed and worth tracking.

There is no "Shadow IT" help desk that you can go to or open a trouble ticket with to see what has been deployed "outside" of normal channels. Instead, one needs to collect information many different ways to discover what has been deployed on their network.

Regardless of your technical or political environment, I recommend going "up the stack" when reporting things that are odd or unauthorized as outlined below.

• Networks and Devices. Audit any networks, devices or infrastructure that isn't documented or authorized. Your organization should be able to control which devices such as firewalls, wireless access points, SANs or routers are in place and even which IP addresses are in use. Sniffing with the PVS may be the easiest way to find which IP addresses are in use. Scanning with Nessus is also an option, but you will need to decide how deep of a scan you wish to perform.
• Operating Systems. Audit all discovered operating systems to ensure that authorized ones are deployed into the correct locations. Perhaps you have an AIX data center, but there should not be any AIX servers within the payroll IT closet or for the "development" lab. Consider the results of the audit by asset group (i.e., what are the OSes deployed in the DMZ?) as compared to trying to consider everything deployed across your organization.
• Server Applications. When auditing network services such as Web, Email, file sharing and so on, keep in mind that many products will OEM commercial solutions and also make use of open source projects. Don't be surprised if your new router is using a web server for the management interface which isn't on your list of approved servers.
• Client Applications. More an more client applications have a server component. P2P, chat tools, video conferencing tools and others open up a port to enable certain types of communication. These are discovered by Nessus network scans as well as by the PVS when these ports are used for communication. Traditional "client only" applications like web browsers, RSS readers, SSH clients and mail clients are identified by Nessus through the use of credentialed scanning, and by the PVS by observing network traffic and performing protocol analysis.
• Non-Internet-Connected Software. For software that does not connect to the Internet, it can still be identified by a credentialed Nessus scan. Plugin #20811 performs an audit of all Windows software and plugin #22869 audits all installed UNIX software.

Separating the "discovered" applications into these five groups can help simplify communication with senior management. There may also be some correlation between these groups such as detecting the presence of both Linux distributions, Apache web servers and Mozilla web clients in a supposedly 100% Microsoft environment.

If you are managing this active and passive security data with the Security Center, then using the dynamic asset filtering can help ensure that you are looking for the right software on the right asset. For example, if you have a "Data Center" asset group, then performing a list of operating systems within that asset can be accomplished with a few clicks of the Security Center interface.

Enumerating "Bad" Software, Devices and Operating Systems

I've run into several organizations that need to keep certain types of software or devices off of their network. They need a way to find it on existing computers, alert when it is in use and report that computers are "clean". Also, some organizations have active programs to keep certain OSes and network devices out of their networks too. Perhaps they've not paid maintenance on a previous network-wide license, perhaps there is a licensing issue with the vendor, perhaps the CIO is just anti-Microsoft, anti-IBM, anti-RedHat or so on.

With Nessus and the PVS there are really three strategies that you can use to look for things that are "bad".

• Monitor network traffic with the PVS to find evidence of a client or server protocol.
• Scan networks with Nessus to look for fingerprints of the particular software, operating system or network device.
• Log into the various OSes or network devices with a credentialed Nessus scan and look for the 'bad' software.

Starting from scratch, if you wanted to find out if Nessus could find a certain type of device, a good place to start is the Nessus plugin search tool located here:

http://www.nessus.org/plugins/index.php?view=search

If a plugin does exist, you should read the available description to see if this is a network check or if credentials are required. If you wanted to perform testing with the script by itself, you should considering using the 'nasl' command line tool. Also, the new Nessus 3 Client BETA makes it very easy for Windows, OS X or Linux users to select just the plugin in question and run it against multiple targets.

Also for Nessus, there are three plugins (find_services.nes, find_services1.nasl and find_services2.nasl) which will identify a wide variety of devices and services. If you have access to your "illegal" software, OS or device, scanning it with Nessus may likely produce a result that identifies it.

If you wanted to see if there are rules for the Passive Vulnerability Scanner to find your "Shadow IT" technology, you can check the list of published plugins located here:

http://www.tenablesecurity.com/tenable_plugins.pdf

This PDF file is updated daily and contains a list of all plugins available. Using the search tools available in most PDF readers, you can see if there exist rules for software products you are interested in.

Detecting the Apple iPhone

So what does all this have to do with detecting the brand new Apple iPhone? The iPhone is a classic example of a technology that can walk into any organization in any employee's laptop case or shirt pocket. It may or may not be sanctioned for use, can save data, connect to the local network and so on. It is on many people's "must have" lists and starting to show up on many organization's "must not have" lists.

When the iPhone is used to connect to a local IP network via wireless 802.11, it gets a real IP address and the email and web clients are easily fingerprinted. PVS rules #04134 and #04135 identify IP addresses that are likely iPhone by performing protocol analysis on port 25 and port 80 network traffic. Below is a screen shot of such a detection in the Windows PVS user interface:

At Tenable's demo sites, we've been seeing more and more iPhones used to connect to the local wireless networks and surf the Internet and send email.

Conclusion

The iPhone is just the latest type of technology to come to the forefront of many organization's "must/must-not have" lists. If we had written this blog post at various points during the past few years, we may have used the Google Toolbar or Skype as examples.

Regardless if your organization needs to monitor technology to see if it is being adopted by your users, or to see if it should be blocked, using a combination of active, passive and credentialed auditing can help identify what is in use and what has been widely adopted.

Detecting a "Shadow IT" organization within your organization is doable if you know where to look and have some sort of monitoring program in place.