For organizations that actively keep track of and manage their base operating system patches and configurations, a somewhat lofty goal is to try and tighten down third party patches. Organizations can have all Microsoft patches installed and their systems hardened to NIST, CIS and vendor recommendations, and still have major exposure and security issues issues tracking down open source, freeware and third party applications.

This blog entry discusses some of the pain points in managing these third party applications and some ways to scan for them with Nessus and the Passive Vulnerability Scanner.

The Pain Of Non-Standard Patching

I recently went through a security audit and patch upgrade on a personal Microsoft laptop. It had no Microsoft flaws or security issues and was locked down fairly tightly. Having said that, it still had major security issues with a variety of third-party applications. When scanned with Nessus using credentials, it found:

• VMWare Server was out of date a few releases
• Several versions of the JAVA Runtime environment were enabled
• My favorite FTP client (FileZilla) was a full major version out of date
• Quicktime had not been updated in long while
• An ActiveX control in FLEXnet Connect was also exploitable
• The APSB07-12 advisory for Flash

The upgrade process was anything like my typical smooth and silent Microsoft upgrades that happen during shutdowns and on Tuesdays. If you want to avoid my long list of things that were required to get the laptop secured, feel free to skip to the next section.

With VMware, I needed to reboot the laptop, and then reconfigure the virtual NAT environment after wondering why I couldn't ssh into my Linux VMs.

With the JAVA vulnerabilities, even though live updates had been enabled, multiple older versions of the JAVA runtime environment had been installed and were vulnerable to a variety of exploits.

When upgrading to FileZilla 3 from FileZilla 2, the older version was not uninstalled. Even though I ran the upgrade process, it didn't uninstall the older version and I had to manually check the 'About' link within the application to realize that the laptop treated these like two separate applications and not an upgrade.

The Quicktime install was very old, even though live updates were supposedly enabled. Performing a manual download from Apple fixed all vulnerabilities detected by Nessus. I was very tempted to try and figure out why the updates were not occurring, but there were other issues to patch.

Nessus plugin 25371 had also detected an issue with a FLEXnet ActiveX control. This is a vulnerability in InstallSheild. I didn't have time to figure out which application actually installed this issue, and the available patch from Macrovision seemed to focus more on developers than end-users. In the end, I had to manually set a registry setting as recommended by CERT.

And lastly, I had my biggest issue patching the Adobe APSB07-12 Flash bug. Our Nessus plugin checks for both a Flash plugin as well as an Active X control. Simply downloading the patch within Firefox isn't enough. To get the latest Active X control, you need to actually visit Adobe's update site with Internet Explorer.

The point of this exercise was that I was just one user. On an enterprise with dozens or 100s of users, if third party applications are in use, it can become very difficult to keep normalized configurations, let alone secure laptops and desktops.

Active Scanning with Nessus

With more than 17,000 plugins in its database of vulnerabilities it can check for, Nessus looks for a wide variety of non-Microsoft vulnerabilities on Microsoft platforms. These security issues include, but are not limited to:

• Issues with popular email and web clients such as Opera, Mozilla and Thunderbird
• Vulnerabilities in security specific products such as anti-spyware, anti-virus and even Secure Shell clients
• Backup and network management software from EMC, CA
• Media players from Apple and Real Networks
• A wide variety of Internet chat, video conferencing, FTP and other common applications such as Skype, Goggle Talk and FileZilla.

If these services have a "server" component of them (such as iTunes which does listen on certain ports even though it is a client application) Tenable's research team will attempt to write a Nessus plugin that can recognize these services and attempt to see what patch level they are.

However, the most reliable way to identify this type of software is with administrator credentials. Most modern Microsoft environments, an IT audit group can leverage the administrator account on Windows XP Pro, and Windows 2003 systems to audit all installed software and configurations with Nessus.

Another byproduct of auditing system with credentials with Nessus is the ability to enumerate all software installed on the network. When managed by the Security Center, the list of enumerated and discovered software can be analyzed with a variety of tools and even be used to categorize systems based on the type of software installed.

Continuous Network Monitoring with the PVS

Tenable's research group also focuses on the type of network traffic generated by these third party applications. The Passive Vulnerability Scanner rules are typically in lock-step with the type of client-side vulnerabilities discovered by a Nessus credentialed audit.

In the above example of third-party patching I went through, the PVS detected most of the issues with the exception of the Flex licensing security hole.

The PVS has the advantages of not requiring credentials to audit a host and being able to run 24x7, but does have a disadvantage that the software needs to be used on the target platform. This is not a large disadvantage when looking for software in use in your organization. Users who download these tools will likely use them at least once, which the PVS can see and record.

Some of our customers actually prefer to use what the PVS finds because those are the clients that are actually in use on the network.

Putting it All Together

The main advantage of exceeding a compliance standard is that your network configurations can have much more leeway before coming "non compliant". A more practical benefit of focusing on third party security issues is that your network will also be more secure and uniform.

We've blogged before about how Nessus and the PVS can be used to audit your patches (as well as your patching process). If this article was interesting to you, the following Tenable blog entries will also likely be of use:

• Testing the Effectiveness of your Patch Management System
• Knowing When to Patch
• Finding Vulnerabilities Oder than 30 Days
• Reporting Vulnerabilities in an IT Managed Environment

Tenable Network Security has received certification for the Nessus vulnerability scanner and Security Center to perform Center for Internet Security configuration audits of the Windows XP operating system. This blog entry discusses the new audit policies, an upcoming webinar on how to use these polices and making use of these with the Nessus Client and Security Center.

Certified Audit Policies for XP Pro

New audit files are available to all Direct Feed and Security Center customers at the Tenable Customer Portal. Four new audit polices are now available:

• XP Pro Enterprise Desktop
• XP Pro Enterprise Mobile
• XP Pro Specialized Security and Limited Functionality
• XP Pro Legacy

Each of these audit policies corresponds with a CIS profile for deploying Windows XP Pro. The 'Desktop' and 'Mobile' profiles correspond to a typical Windows XP Pro deployment on either a dedicated corporate desktop or a mobile laptop. For extra hardening, tighter security settings and offering the least amount of services, the Specialized Security and Limited Functionality profile can be used. This is an ideal setting to offer very limited and single purpose services. And lastly, for compatibility with Windows NT, the 'Legacy' profile is offered. This profile relaxes some encryption and authentication protocols to retain compatibility with older Microsoft protocols.

Upcoming Webinar

Tenable is offering an upcoming webinar which illustrates what these audit policies test for, how to use them for point auditing with Nessus and how to perform enterprise auditing with the Security Center. The webinar will be held December 12, 2007 between 2:00 PM and 3:00 PM EST.

    Title: Nessus 3 agent-less Configuration and Patch Auditing Windows XP
    Date: Wednesday, December 12, 2007

Space is limited. Reserve your Webinar seat now at: https://www.gotomeeting.com/register/340209530

Installing and Using these Audit Polices

Direct Feed and Security Center customers can immediately download these new polices.

Nessus users can save these audit polices to their scanning platform and make use of them when creating scan polices. With the Nessus Client, the audit polices can be specified when a scan policy is created.

Security Center users should download these polices and place them in the /opt/sc3/admin/nasl directory as owner 'tns'. These polices will then be available to any vulnerability policy.

For More Information

To see a list of all certified CIS configuration audit polices that can be performed by Nessus Direct Feed and Security Center users, please visit:

http://www.cisecurity.org/tenable_cert.html

I was recently forwarded a link to a BBC video which demonstrates how a user on a wireless network can attack another user and break into their system.

In the video, the attacker uses Nessus and Metasploit to identify some security issues in the remote computer, and then break into it. My favorite line is when the analyst points to the "big red X" in the Nessus report and says that "here is a problem". If only it were this simple when managing 1000s of computers or more in a large enterprise.

I would have rather seen them speak about how monitoring an unsecured wireless network can passively reveal passwords, user information, vulnerabilities and so on. Overall, this sort of news isn't really news to the readers of this blog or users of Nessus. I am thrilled that this BBC coverage will raise awareness to European technical business managers who aren't exposed to vulnerability scanners, penetration testers and IT security issues on a regular basis.

One of the powerful features of Nessus is its ability to perform patch auditing for many different operating systems over many different protocols. Most Nessus users understand that Nessus supports UNIX audits with the Secure Shell protocol and that it can also log into Windows systems. This blog entry will discuss using Telnet as a method for Nessus to perform patch auditing.

Who is Still Using Telnet?

More organizations use Telnet than the average IT security professional realizes. There are a wide variety of international, licensing and compatibility issues that may have forced organizations to deploy Telnet.

If an organization has a requirement to audit all remote access to sensitive UNIX systems, it is sometimes more efficient to require Telnet usage and then replay each of the sessions with a tool like NetWitness. The alternative would be to run 'process accounting' on each of the remote UNIX systems which could be a performance or administration burden.

At Tenable, when the remote Telnet exploit against Solaris 10 and 11 was publicized earlier this year, we received a wide variety of calls from government, Internet providers and commercial business who not only had Telnet enabled, but wanted to make sure they could detect this vulnerability as well as exploits directed against the vulnerable systems. A general rule seemed that if an organization did have Telnet, they were not confident to be able to patch the vulnerabilities quickly.

Performing Nessus UNIX Patch Audits With Telnet

For Nessus 3 to perform a UNIX patch audit, you must configure a vulnerability scan with at least three parameters:

• Credentials which can enumerate patches. This is a username and password of the remote system.
• You must select a Nessus plugin family of patch audits you want performed.
• You must force the patch auditing to occur over Telnet.
  

Below is a screen shot of configuring the NessusClient 3.0 interface to perform a UNIX audit through Telnet. Results of a scan against a CentOS system over Telnet are also shown.

Scan Configuration	CentOS Patch Results

When selecting a username and password, keep in mind that if you harden a UNIX system, the 'root' user might not be allowed to log in over Telnet. If you use a non-root user account, a hardened system might not allow a non-administrator to be able to enumerate patches.

When selecting a Nessus plugin family, be sure to enable the set of patches for the operating system you are targeting. For example, if you are auditing Solaris, a default scan won't automatically enable the Solaris if you provide credentials. You can enable more operating systems than you need and Nessus will automatically use the patch audits just for the particular system being scanned.

And lastly, if the vulnerability policy does not specifically say to perform patch audits over Telnet, the scan will attempt to perform them over Secure Shell. The screen shot above shows a checkbox item to force the scan to occur over Telnet. Nessus also supports other clear text protocols such as rlogin. If your Nessus client does not present these scan options for your vulnerability policy, you may be connecting to an older Nessus 2 scanner or one not produced by Tenable.

Telnet Security Concerns

This blog is not an effort to encourage people to switch to Telnet. However, if Telnet is your only option, Nessus can still be used to perform patch audits of those systems. Having said that, there are three really good security concerns you should be aware of when using Telnet:

• The username and password are in the clear and can be easily sniffed.
• The session itself is vulnerable to hijacking where a 3rd party can make it seem like you typed something you didn't.
• The contents of the session are viewable to anyone else with access to the network.

If your organization has good physical control over the network such that there are no compromised systems or potentially hostile networks carrying your traffic, these concerns can be mitigated. Being able to prove this assumption though is rather difficult.

For More Information

We've published several blog articles about performing patch auditing with Nessus and these are listed below:

• LM/NTLM Hash Support for SMB Credentials
• Testing the Effectiveness of your Patch Management System
• Knowing When to Patch
• Reporting Vulnerabilities in an IT Managed Environment

As part of the more than 17,000 plugins available in the Nessus Direct and Registered plugin feeds, many of these look for common user name and password combinations. They will attempt to find administrator accounts without passwords, simple passwords and vendor defaults. Although these checks aren't performing an exhaustive brute force password audit, they may cause enough login failures to "lock out" operational accounts.

Tenable's research group recently introduced logic into the body of the Nessus plugin checks to prevent guessing of accounts. If auditors are running Nessus in a sensitive environment, they can now easily disable the types of plugins which could result in login failures on Windows and Unix systems.

This blog entry discusses account "lock outs", how the new plugin changes work, and what sort of security vulnerabilities might not be checked with this setting enabled.

Understanding Account Lock Outs

As part of hardening a system, users should choose strong passwords that are complex enough to avoid brute force guess attempts. In some cases though, an organization may feel the need to further secure a system by limiting the number of times an account can be accessed unsuccessfully. This can limit the ability for a hacker or insider to try many combinations of user names and passwords to gain access to a system.

A problem that can occur with this type of security is that scanning for a common list of default backdoors, vendor accounts or simple passwords can render the account locked. A locked account could require a certain amount of time before it can be accessed again or it could require some other types of administrator action to "unlock" it.

In an operational environment, we'd like to avoid any type of impact to the availability of the systems that are being scanned. For example, having a Windows 2003 server with its administrator account locked out could prevent a help desk from performing their job. In sensitive environments, some organizations require every login failure to be investigated.

Auditing Password Policy With the Direct Feed and Security Center

Nessus Direct Feed and Security Center users can audit remote UNIX and Windows systems for poor password policies in seconds. Rather than testing 100s, 1000s or even more different username and password combinations, a remote operating system can be audited to see if its password policy is complex enough.

For example, password policies can specify a minimum password length and how often it should be changed. These variables are obtained performing direct queries against the operating system and have no side effects. Testing against a policy is more efficient than testing against a list of 1000s or more of known potential passwords. These audit policy tests require remote credentials to audit the systems.

These types of checks are included in many of the audit policies Tenable has produced to meet NIST SCAP, PCI and Center for Internet Security standards.

Performing Tests With This Setting

Under the current set of plugins being distributed as of November 1st, 2007, there is a new plugin preference variable. Its name is 'Do not log in with user accounts not specified in the policy'.

To access this under the Nessus Client, create a new policy and view the option under the 'Global variable settings' drop down option under the 'Advanced' tab as shown below:

If this setting is checked, then Nessus will not attempt to log into a remote host with anything other than the accounts specified in the Credentials section of the scan policy.

If you have not updated your plugins since November 1st, this setting will not be available. These checks have been made available to both the Direct Feed and Registered Feed customers. Also, if you are using the new Nessus Client, you must create a new policy for this item to be available in the user interface.

Knowing When to Use This Setting

The focus of this plugin change is to prevent unintentional use of plugins that attempt a login vis SMB for Windows systems or SSH for UNIX systems.

There are several "vulnerability" plugins which look for common user name and password combinations. For example, attempting to see if a Windows 2003 server has a blank administrator password is a great security check, but the act of measuring it may cause a login failure.

If you have manually installed Hydra on your Nessus scanner and you also select those plugins for execution, Hydra will run unaffected by this setting. 

For More Information

Information about the Direct Feed is available here. We've blogged in the past about how password auditing is accomplished much more efficiently buy auditing a policy than trying to brute force a password. Combining this new feature of not testing for user accounts specified with the scan policy along with the configuration auditing features of the Direct Feed is an excellent way to efficiently test your system configurations without impact.

If you are a Nessus 3.0.6 Windows user, the client distributed with along with the Nessus scanner does not support this new scan option. Instead, users should upgrade to the new Nessus Client 3.0.