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.

This is the first post in a two-part series that will cover how to configure Nessus and/or SecurityCenter to integrate with Microsoft's patch management software.

WSUS Patch Management Integration

Windows Server Update Services (WSUS) is available from Microsoft to manage the distribution of updates and hotfixes for Microsoft products. WSUS server 3.0 SP2 supports management of patches for the products listed here, as well as Windows 7 and Windows server 2003 SP2 patches. If you are not familiar with WSUS it is freely available to Microsoft customers as part of your Windows server licensing agreement. A great article that covers all aspects of planning, deployment, and configuration is Windows Server Update Services Learning Roadmap Community Edition.

Nessus and SecurityCenter have the ability to query WSUS to verify whether or not patches are installed on systems managed by WSUS and display the patch information through the Nessus or SecurityCenter. When performing scans with the WSUS patch management plugins enabled and configured please note the following:

• Credentials entered into the policy take priority - If you've entered credentials into the scan policy and they are valid for a target system, Nessus will login and perform credentialed scanning without querying the WSUS server data.

• WSUS is queried when credentials fail - If credentials are not valid for a target system, or credentials are not entered at all into the policy at all, the WSUS server will be queried to obtain patch information for those targets. This also applies to other policy settings that may cause a credentialed scan to fail, such as the remote registry or administrative shares settings.
• The WSUS plugin communicates only with the WSUS server - The WSUS plugin makes a connection to the WSUS server IP/hostname and port specified in the policy configuration (see below in the "Patch Management WSUS Preferences"). This is an important point, as the Nessus server(s) will require access to your WSUS server, which could mean making firewall rule changes to allow the connections. However, this is a significant advantage as your target systems do not need to communicate with the Nessus server directly, which means host firewalls and remote registry settings will not get in the way of a patch audit.
• Patch information is only as up-to-date as your WSUS server - The data returned to Nessus by WSUS is only as current as the most recent data that the WSUS server has obtained from its managed hosts.

Today, Tenable Network Security announced integration between Nessus and a variety of patch management systems that will simplify scanning in cases where credentialed scans are difficult or impossible. The integration allows Nessus and SecurityCenter users to establish direct links to patch management systems. This simplifies patch audits as the systems in your environment do not all have to contain credentials in order to be scanned. You simply need to give Nessus credentials to your patch management server. This integration enhances compliance programs and helps eliminate confusion about the patch status of systems between IT operations and network security teams.

With Nessus patch management integration, you can:

• Retrieve patch manifests and status information from Red Hat® Network Satellite Server, Microsoft® Windows Server Update Services (WSUS) and System Center Configuration Manager (SCCM), and VMware® Go (formerly known as Shavlik).
• Quickly generate patch compliance reports in Nessus and SecurityCenter, based on the data returned from patch management systems. Presentation of records in the well-known Nessus format can speed auditors’ reviews, and simplify resolution of discrepancies between management systems.
• Retrieve accurate patch status information for systems that can’t be fully scanned by vulnerability assessment tools because of a lack of credentials. Credentials are only required for access to the patch management system.
• Retrieve patch status in environments where scanning is not available due to other constraints, such as limited networking.
• Help eliminate false positives caused by back ported patches in Red Hat Satellite environments.

This integration is available today in the case of Microsoft and VMware Go (Shavlik) systems, and is expected no later than Friday of this week for Red Hat. You’ll find the plugins in the ProfessionalFeed. Configuration documentation is available in the Patch Management Integration documentation. If working with patch management systems is a challenge for you, watch this space – I’ll be posting more details on how this integration works, and you can take advantage of it in your environment.

In a perfect world, there would be no vulnerabilities.  In a perfect patching world there would be a patch for every vulnerability and we would always be able to patch all of our systems as soon as a patch was available. In the real world we do the best we can and struggle with testing cycles, incompatibilities, and legacy applications which means sometimes we have to leave insecure and unpatched systems in production.

There are a variety of situations that can cause exposure:

• Some patches break needed applications or cause compatibility problems
• Patches may not yet be available for a vulnerability but the systems must stay online and exposed Legacy applications or operating systems may still be required (for example Internet Explorer 6 may be required to access a legacy web application, probably running on a legacy web server)
• A maintenance window may not be immediately available when patches are released
• Systems in development environments may be vulnerable during development and testing phases

Keeping Tabs On Patches

Let’s face it; we all have to deal with patches. Everyone from an IT systems administrator to your grandma has to face the challenges of patches. Whether you have a home computer that you use to browse the web, a phone that you occasionally check email from, or 10,000 enterprise desktops spread across three continents, you're dealing with patches. Regardless of your situation, you need to be able to answer two basic questions:

• Which patches are missing?
• Which patches have been successfully installed?

If you only have one computer in the house, it probably annoys you to some degree when it’s time to apply patches, indicating that you are in fact missing patches. This answers the first question above, but the operating systems themselves have few measures for success. There are many situations that cause patches to fail, or leave vulnerable software behind after an update, that can easily be missed by the average user. Your so-called "smart-phone" is even worse. Since most users do not connect their phones to their computers, or the carrier is blocking operating system updates, you may never be able to answer the first question (I guess that's one reason why RIM maintains a prominent presence in the enterprise, as they answer both questions very well with respect to Blackberry users in your environment). Never knowing that you even require patches to be installed is a big problem, as well as knowing if they even applied successfully.

A Much Larger Problem

Enterprises with 10,000 or more desktops exacerbate the problem of patch tracking. With so many devices that require patches, things are bound to go wrong! Lately I've been using dashboards in Tenable's SecurityCenter, and thanks to Tenable CEO/CTO Ron Gula, I have some interesting SecurityCenter 4.2 "dashboards" to help me track patches. Here's just one example:

Click for larger image

It's very exciting (depending on your perspective) when there is a record-breaking Microsoft Patch Tuesday! April 2011 is the largest Patch Tuesday release in history, with 17 bulletins covering 64 different vulnerabilities across several products. While everyone is beating the "Microsoft Patch Tuesday Crisis Drum", attackers are continuing to have success breaking into major organizations using the "exploit du jour", some social engineering methods or a combination of both.

What I would like to suggest is a weekly, or even daily, "patch rally". Patching needs to be an ongoing process of checking to see if patches are available, applying the patches, and then verifying that the patches have been applied and installed properly. I don't think we need to "take time to stop and patch"; we just need to patch as a normal, everyday, regular business operation. It's sad that we have to install more software to fix broken software, but it has become the way of the IT world. If your business cannot sustain being patched, the you've probably chosen the wrong software and configurations and your business will likely be negatively affected. The negative effects happen in two ways: 1) you install the patches and your system and/or software fails as a result of a bug in either the software or the software patch or 2) you don't apply the patch and attackers compromise the system and ruin the integrity of the system and the data contained therein. So, hence my cry to "rally to the patch"!

I've recently been doing a bit of research into the history of Nessus. I discovered that the first version of Nessus was published in 1998, and any time software has been around for that long there are bound to be some myths and misconceptions that develop as fast as new features over the years. This post will explain some common myths and set the record straight.

Attackers have been very naughty, IT departments have been mostly nice and Microsoft has fulfilled the role of “Bad Santa”. This holiday season, Microsoft has filled your stockings with 17 security bulletins fixing 40 vulnerabilities. But where does that leave us?

What Else Could You Say?

Note: The word "could" appears in the title of all 17 security bulletins this month

I could say a lot of things about this month's Microsoft Patch Tuesday release. I could say that you should apply patches (except that my boss hates the word “should”). I could say that despite all of the patches released, there are still most likely to be 0-day exploits for several unpublished vulnerabilities. I could also say that your organization needs a solid patch management program. I could say, well, you get the point. After more than a year of writing up each one of the Microsoft Security bulletins, there's a lot I could say. The fact remains that several trends continue in the Microsoft "Black Tuesday" madness:

Don't Fall Off The Stool

When I developed the course "Advanced Vulnerability Scanning Techniques Using Nessus", I wanted to mention some of the trade-offs we make when we perform vulnerability scans using different configurations. Nessus creator Renaud Deraison helped point out that it seems to come down to three factors: speed, intrusiveness and comprehensiveness. What I found was that these three factors were extremely important throughout the duration of the class, and I realize that for vulnerability scanning and vulnerability management, these factors must be taken into consideration.

This month's Patch Tuesday has been described by some as a "hot mess of vulnerabilities". This record-breaking Patch Tuesday contains 15 security bulletins that fix 34 vulnerabilities. While many people have been quick to classify which of these are "critical", I believe that criticality and risk are best determined by the affected organization, not third parties. However, I do recommend that everyone review the information presented, especially the resources prepared by the Internet Storm Center and the Open Source Vulnerability Database. Both of these sources pull in all of the relevant information about each security bulletin, providing a more complete picture to help evaluate your own prioritization efforts. The bulletins prepared by Microsoft are still not exploring the various aspects of each vulnerability and specifically do not always specify whether or not vulnerabilities can be exploited.

The "Mitigating Factors"

In the MS10-047 and MS10-048 security bulletins, which cover eight separate vulnerabilities, Microsoft states the following as a mitigating factor:

"Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability. The following mitigating factors may be helpful in your situation:

An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users."

I don't like to point fingers or call people out, but Microsoft’s statement is not true. The statement that an attacker "must have" valid logon credentials is a bit concerning. If "logon credentials" are something that you have in your possession, such as a pen or a mouse, then the attacker does not need them. An attacker can certainly convince an already logged in user to execute the code to perform the privilege escalation. In this scenario, the attacker does not "have" the logon credentials. They are currently able to execute code as a non-privileged user, which is a completely different situation. The vulnerability can be executed remotely, provided you have already exploited a vulnerability that has granted you permissions to execute code as a non-privileged user. This is a very common method of attack, as users can be tricked into running all sorts of programs, code from a web site, email attachments and more. There are certain advantages to being logged in to a system as an administrator or with SYSTEM privileges, such as accessing files, installing keystroke loggers and sniffing the network.

Which Vulnerabilities Are You Looking For?

When Microsoft releases their patches each month, I find it interesting to review the criticality of each vulnerability. Microsoft has, in their typical fashion, used some very interesting wording to describe the latest batch of vulnerabilities. When reading each security bulletin, I try to imagine the worst-case scenario and look at the glass as half empty. Microsoft seems to paint a picture and believes the glass to be half full by using phrases such as:

In MS10-042: "The vulnerability cannot be exploited automatically through e-mail." - I believe what they are stating here is that the user can't just open up an email to have the exploit trigger. Instead, the user has to either open an attachment or click on a link. I can tell you from first-hand experience that it’s not difficult to get someone to click on a link. Typically, you just need to tell them that they've qualified for a free iPad. Getting the user to open an attachment is a little bit trickier, and usually requires more research about the target audience and/or organization. However, this does not mean the attack can't scale to trick thousands of people, as did an email appearing to come from the World Cup with an Excel document attached. The Excel document posed as a schedule for the World Cup, but really contained malware that attempted to infect the end-user's computer.

Oracle has implemented a quarterly patch release cycle for its customers. Patches for all Oracle products are released on this schedule, and typically fix dozens of vulnerabilities in their database software, Sun Java (recently acquired) and other enterprise products.. They have a similar rating system to other major vendors (such as Microsoft and Cisco) with regular patch release cycles. Oracle describes the severity of each vulnerability using the Common Vulnerability Scoring System (CVSS): "Access Vector", "Access Complexity", "Authentication", "Confidentiality", "Integrity" and "Availability". It is a great way to categorize vulnerabilities; however, this still leaves you with the important task of scheduling, testing and applying the updates.

Tenable's Research team has added the ability to perform an Oracle patch audit into the Nessus vulnerability scanner. A new plugin was created (oracle_rdbms_query_patch_info.nbin) that logs into an Oracle database and runs a set of queries to determine which patches are missing:

• Query 1 - Determines the hostname of the system the database is running on (important when Nessus is testing an Enterprise Manager Grid Controller that contains patch information of other hosts).
• Query 2 - This query pulls the installed "PatchID" and the "Oracle_home" it is installed in.
• Query 3 - If Nessus found any PatchIDs in Query 2, it looks up all the bugs that were superseded by each PatchID that was found in Query 2.

The patch information comes from the same tables that are used by Oracle Enterprise Manger and Oracle Enterprise Manager Grid Controller for patch management.

The SANS Penetration Testing Summit was held this year at the Hyatt Baltimore in Baltimore, MD on June 14 - 15 and was focused on “What Works in Penetration Testing".

The event was held just across from Camden Yards, home of the Baltimore Orioles.

Tips For Penetration Testers

I participated in a panel discussion with Joshua Wright, Vincent Liu and Joshua Abrams titled, "Most Effective New Technique You've Applied in the Past 12 Months". We started by having each of us share two fun, new or interesting penetration testing techniques that we've applied in the past year. It was a great discussion, covering topics such as wireless, vulnerability assessments and what tools to get started with.

I shared a story with the audience about lock picking. The story details the travels of my friend (let's call him "Bob") who was put into a situation where he had to pick a lock. Bob did not have his lock-picking set and was forced to use more crude tools. In the end, Bob ended up prying off the entire doorknob with even more rudimentary and crude tools. I then circled back around to the lessons learned and how they apply to both lock picking and penetration testing:

With the release of Nessus 4.2.2 a new method of credential elevation has been included for Unix-based hosts that have sudo installed: “su+sudo.” This method allows you to provide credentials for an account that does not have sudo permissions, su to a user account that does, and then issue the sudo command. 

This configuration provides greater security for your credentials during scanning, and satisfies compliance requirements for many organizations.

To enable this feature, simply select “su+sudo” in the “Elevate privileges with” section under the credentials/SSH settings as shown in the following screen shot:

Under the “SSH user name”, and “SSH password” tabs, enter the credentials that do not have sudo privileges. In the example above, the user account is “raven.” From the “Elevate privileges with” pull-down menu, select “su+sudo.” Under the “su login” and “su/sudo password” tabs enter the user name and password that do have privileged credentials, in this example “sumi.”

No other scan policy changes are required.

It’s A Bird, It’s a DoS, It’s Remote Code Execution!

I've always cautioned people about the danger of disregarding vulnerabilities that are labeled as "Denial of Service" (Such as MS10-014 from February) for a couple of reasons. First, when a bug exists in the code that allows something to "crash", there is usually a potential that the "crash" could somehow allow for code execution (remember that a buffer overflow is just a controlled crash). Second, when code is being analyzed so that the bug can be fixed, the surrounding code is often analyzed to be certain there are no other bugs or vulnerabilities. This analysis could lead to the disclosure of other vulnerabilities or a new way to turn a DoS into remote code execution. This appears to be the case with MS10-20, which was first publicly disclosed as a DoS bug in the SMB client. Microsoft is now reporting it as a vulnerability that "could” allow remote code execution. Upon further inspection, the security bulletin reports five vulnerabilities related to the SMB client that are patched in MS10-20. The first is the original DoS bug reported by Laurent Gaffie to the Full Disclosure mailing list on November 11, 2009. The general consensus was to dismiss this bug because it was "just a DoS".

"What Am I Doing Wrong?"

I am often asked, "What am I doing wrong in regard to security?". This question is usually in reaction to some event, such as a failed audit, a network outage as a result of malware or worm or a breach that was detected in the environment. I ran into this situation while doing incident response for a large university. It was my job to monitor the network and respond to the major incidents that were occurring (it was also up to me to determine what was "major" and what was not). I worked with many different network and system administrators on campus to help them improve the security of their respective departments. However, this was an academic environment full of students and professors who wanted to work in a free and open environment, which turns out is one of the most difficult to secure!

If a department had a compromise, I would do my best to help them figure out what happened and take measures to prevent it from happening again. A comprehensive assessment would next be performed to gain a better understanding of the security shortcomings and appropriate remediation measures. These types of assessments can be a daunting task for any security professional. Nessus was one of the primary tools we used to get a handle on the vulnerabilities in the environment. While it is important to scan for vulnerabilities such as missing patches or buffer overflows, assessments need to go deeper than that because attackers will use any approach they can to breach a system. A mis-configured system does not necessarily have a CVE or BID entry. The more comprehensive the audit, the better chance I had of making a recommendation that would effect change and result in better security (which really boiled down to me not having to come back in “incident response mode”).

Stinky, Aged Operating System?

It’s that time of the month again - Microsoft patch Tuesday of course! This month I expected to research several different vulnerabilities, how they work, methods to detect them, etc. However, Microsoft is only patching one vulnerability this month. I can’t believe there is only one vulnerability this month! In any case, this month's vulnerability occurs in the way applications handle Embedded OpenType fonts. I was a bit puzzled as to why so much effort was going into font rendering until I discovered that it is common for web sites to implement different languages and have them display correctly to the end user (primarily for “non-English” languages). The vulnerability is triggered when a user renders fonts on a web page or by opening a Microsoft Office document that contains embedded fonts. An interesting fact about this bulletin (which only covers one CVE entry, CVE-2010-0018) is:

"This security update is rated Critical for Microsoft Windows 2000, and is rated Low for Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2."

Another Tuesday, another round of security bulletins from Microsoft. Are you patched? Nessus contains credentialed local checks for all security bulletins, and a network-based uncredentialed check for MS09-064.

Severity is a Matter of Perspective

What struck me as interesting this month are the severity ratings. Microsoft publishes these ratings as a guide to help customers evaluate the vulnerability risk. In many cases, they seem to be doing their customers a disservice. For example, a remotely exploitable vulnerability in Microsoft Word or Excel could be leveraged by attackers to compromise desktop systems. These types of vulnerabilities are frequently exploited by attackers and penetration testers alike to gain access to sensitive information. The advice I always give to organizations is to evaluate each vulnerability with respect to how it affects your business, not what has been published by the vendor.

In addition, if the evaluation of severity is coming from a vendor, it should adhere to some industry accepted standard calculation, such as the CVSS score. Nessus plugins use this scale (1-10, with 10 being the most severe) as a rating for the severity of the vulnerability. While Microsoft rates MS09-067 (a vulnerability in which arbitrary code can be executed as a result of opening an Excel file) as important, Nessus gives it a CVSS score of 9.3. Use these ratings as a guide to develop your patching strategy. For example, if you heavily use Excel, you will need to patch right away. If you do not use Excel, then it is not as critical to patch. You could employ a temporary solution for mitigation by blocking incoming Excel file attachments while you focus on vulnerabilities that pose a bigger risk.

Windows 7 - a "Shiny" New Operating System

Most experts agree that producing Windows Vista was not a shining moment for Microsoft. It was plagued with problems from the start, including performance and stability issues. Many organizations flat out refused to upgrade from Windows XP to Vista, deeming it not worth the investment of resources and overall cost of the upgrade. Windows 7 is now here to replace Vista and XP, and the reviews have been positive from the beginning. In my own environment, I stayed away from Vista and jumped right into Windows 7. I believe that as Windows XP comes to its end of life, Windows 7 will step right in to replace it, despite the upgrade costs. Most people will likely skip the Windows Vista upgrade and gravitate towards the "shiny" new Windows 7 operating system.

An example of the "shiny" new OS, Windows 7 makes several improvements to the end user interface.

Last week Microsoft released 13 security bulletins covering 34 vulnerabilities, much to the delight of overworked system administrators who now have to roll out and test the patches in their environment. Organizations are most likely at different stages in the patch deployment process, some may still be testing and some may have the patches rolled out to the entire environment. What all organizations have in common is the need to verify that patches have been installed properly. Nessus has several features, including credentialed scanning and plugins that list missing patches and can assist in the patch verification process. We have produced a short video that demonstrates how to run this type of scan:

I recently had a customer report they were experiencing Nessus “over reporting” when compared to his Windows patch auditing tool. This blog reviews some of the many reasons you can get different results with different tools, especially on Windows operating systems.

Recently, Tenable’s Research group added the ability for Nessus credentialed scans to automatically start and stop the Windows Remote Registry service. This blog entry discusses the technical and political ramifications of this new feature.

Scanning Systems without the Remote Registry service running

The Remote Registry service allows remote computers with credentials to access the registry of the computer being audited. If the service is not running, reading keys and values from the registry won’t be possible, even with full credentials.

Here is a screen shot of a Windows 2003 server that does not have the Remote Registry running:

You can see that although it is "Automatic" and should be running at boot, for some reason, it has not been started. When scanning this Windows 2003 server with a credentialed Nessus scan policy, plugin #26917 will generate a warning that the registry could not be read:

This can be an issue when scanning Vista workstations, as Vista disables the registry service by default.

Nessus is usually very accurate because it performs file level checks for patch auditing However,  the registry is a vital part to performing a complete audit as many vulnerability checks in the Tenable Home and Professional Feeds leverage registry access to determine the remote version of the Windows system, the location of system files, etc.

You can enable the Remote Registry service during the scan

Recently, Tenable added the ability to start the Remote Registry service during a credentialed scan. This requires auditing Windows servers with an Administrator account. Note that this feature is disabled by default.

To configure a Nessus scan policy,  enable the four plugins in the “Settings” plugin family that start and stop the Remote Registry service and determine if the service was started or stopped correctly. A screen shot of these plugins (#35703, #35704, #35705 and #35706) is shown below:

Enabling these plugins is not enough. A scan preference is also required and is available under the Advanced scan policy tab as shown below:

If the plugins are enabled and the scan preference is also set, then Nessus will attempt to start the Remote Registry service (if it’s not running already) before attempting a credentialed audit of the Windows computer.

All Windows OSes (Windows XP, 2003, Vista and 2008) are supported by these plugins.

Political and Audit Ramifications

There are several non-technical issues to consider when using these new plugins in your infrastructure.

Is this secure?

If your organization has a policy that restricts running the Remote Registry service on Windows platforms, this new functionality provides the option to keep this service disabled.

The concern over running this service could come from external sources. There are many public and government regulations that recommend that the Remote Registry service be disabled.  Some organizations turn these recommendations into required baseline configurations.

If leaving  the Remote Registry service running in your organization is considered a security risk, these new plugins provide the ability to only run it for a few minutes during an audit and then turning it off. This enables you to get the essential information while limiting the security risk of leaving the Remote Registry service running all the time. Note that starting and stopping the Remote Registry service may come under your organization’s Change Management Policy.

Also note that if Nessus has the privileges to start the registry service remotely, any attacker with the same privileges could do the same.

Is this compliant with my security policy?

If you are using Nessus to perform FDCC, DISA STIG or Center for Internet Security Windows configuration audits, it is very likely that these policies will test to ensure that the Remote Registry service is not running. If this is the case the audit will fail during the scan.

However, the results of the scan will show the following two informational vulnerabilities:

These records show that the service was stopped before the scan was completed.

If this did not meet the criteria for a particular type of audit, you could follow up this scan with a second scan that showed the registry service was indeed disabled.

How Does This Impact IT?

As with all things in IT, it is strongly recommended that you test this functionality in your environment. Tenable performed extensive testing of this technology prior to releasing it, but there are many issues to be considered:

• Starting and stopping the Remote Registry service generates Windows event logs. If you run a SIM or log management tool that can detect change purely through log analysis, inform your security monitoring team about this new type of audit so they do not become alarmed.
• If your IT group has any third party tools that continuously monitor and “force” the registry off, the Nessus scans will still run, but at some point when the registry gets disabled, the scan results that require registry access won’t run.
• If you perform a scan and lose connectivity in the middle of an audit, or if you manually stop the scan in the middle of an audit, you could end up leaving the Remote Registry Service running on the scanned server.
• If you are auditing servers that are extremely short on available CPU, memory or disk I/O, starting the Remote Registry service could take long.

Typically though, the impact on IT from performing these types of audits is very low. The screen shot below shows a full patch audit with the dynamic enabling and disabling of the Remote Registry service on an underpowered Windows 2003 virtual machine:

That is less than a minute for a full patch and vulnerability audit on a Windows 2003 server. During the scan, there was very little CPU or memory usage as a result of the audit.

For More Information

This functionality is available to all Nessus users, including those using the Home Feed to audit their personal computers and networks, as well as to Professional Feed subscribers who can make use of this technology to audit corporate, university and government networks.

If the topic of IT auditing interest you, we have many other excellent blog entries on this subject listed below:

• Knowing When to Patch
• Testing the Effectiveness of your Patch Management System
• Finding Vulnerabilities older than 30 Days

Tenable's Research group recently added support to the Nessus ProfessionalFeed and HomeFeed to audit missing 64 bit Windows 2003 security patches via file version checks.

File version checking is the most effective way to test a Windows system for missing patches. Nessus has been able to do this on most Windows OSes (including 64 bit Windows Vista and Windows 2008) for a long time and due to customer demand, we've added support for Windows 2003 64 bit systems.

Tenable also recently improved the performance of the smb_hotfixes.nasl plugin to reduce network traffic. This will decrease the amount of time it takes to perform patch audits of all Windows systems. 

To make use of this functionality, simply update your Nessus plugins and then perform a credentialed audit of a 64 bit Windows 2003 system with the "Windows : Microsoft Bulletins" plugin family enabled as shown below:

If you are unfamiliar with performing credentialed patch audits with Nessus, please refer to the documentation and example video which show how to perform these types of audits.

If you perform patch auditing with Nessus, these previous blog entries will be of interest:

• Knowing When to Patch
• Testing the Effectiveness of your Patch Management System
• Finding Vulnerabilities older than 30 Days
• Full SU/SUDO Support for UNIX Patch Audits

Tenable Network Security has released PatchDiff2 for the IDA disassembler. PatchDiff2 can be used to compare the differences in patches provided by vendors in order to understand what has been modified and where previous security holes existed. In some cases, such as the recent MS08-030 release and re-release for Windows XP, a tool like PatchDiff2 can show that a patch update didn't actually modify anything.

PatchDiff2 is provided FREE to the community in the hope that it will help research engineers to better analyze patches.

Tasks performed by PatchDiff2 include:

• Display the list of identical functions
• Display the list of matched functions
• Display the list of unmatched functions (with the CRC)
• Display a flow graph for identical and matched functions

The main PatchDiff web page, which includes a download, is located here.

A demonstration video is also available:

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