11 posts from March 2007

 

Detecting Credit Cards, SSNs and other Sensitive Data at rest with Nessus

Note: This blog entry was originally posted in March, 2007 and was updated on May 28, 2009

Tenable Network Security has released a new Nessus plugin named "Windows File Contents Check" (plugin ID #24760). It is available in the Nessus ProfessionalFeed and has the ability to find a wide variety of sensitive data at rest on Windows computers. This blog entry describes how the checks work and how Nessus ProfessionalFeed users can benefit from them. This new plugin is also supported in Security Center which is covered in a separate blog entry.

Why Find Sensitive Data?

Finding and identifying where your sensitive data is within an organization allows better prioritization of security issues and can find systems (and users) that are not authorized to possess that data. 

When sensitive data is identified, an analyst can ask one of two questions:

  • Is this data authorized to be on this server at all?
  • Does the system that holds this data have proper access control, patch management and overall security?

When combined with Nessus' ability to find systems with vulnerabilities and systems that are not being managed, detecting sensitive data can focus an IT organization's efforts to remain compliant and reduce risk of data loss.

  • Unauthorized systems and users with access to sensitive data can be detected and rectified.
  • Authorized systems with sensitive data and vulnerabilities or mis-configurations can be given priority over similar systems that do not hold sensitive data.

What kind of Data is "Sensitive"?

Every organization has a wide variety of data that is important, but few organizations have built a data dictionary or a classification scheme.

Most readers are familiar with the government's use of the terms "SECRET" and "TOP SECRET". There have also been many cases of financial, academic and commercial institutions losing large volumes of customer credit card numbers, social security numbers, addresses and phone numbers.

Your organization most likely has its own list of things that it considers "intellectual property". Perhaps it is source code or a copy of  a manuscript that has not been released.

This new Nessus check can help find many different types of this kind of data.

Here is an example screen shot of detecting the word "Tenable" in any Word file on a remote Windows system:

Contentnessus32

For this example,  the offending data was not actually shown because we were looking for just the word "Tenable". If we had matched on a more complex pattern, such as a social security number, the report would display the actual data.

How does it work?

The current check supports credentialed scans of a Windows server. Like all Nessus credentialed scans, it does not require an agent but it does require an account that has login credentials and the ability to read the disk. A domain administrator account can be used to perform these checks.

Each scan is given one or more ".audit" files that have the same type of format and structure as Nessus's compliance checks. Here is a short example that looks for a Social Security Number:

<check_type:"WindowsFiles">
<item>
        type: FILE_CONTENT_CHECK
        description: "Determine if a file contains a SSN"
        file_extension: "txt" | "doc" | "xls" | "pdf"
        regex: "([^0-9-]|^)([0-9]{3}-[0-9]{2}-[0-9]{4})([^0-9-]|$)"
        expect: "Social Security Number" | "SSN" | "SS#" | "Social"
    max_size : "50K"
</item>
</check_type>

When invoked, the remote Windows host will compute a list of all local files with extensions for text, Word, Excel and Adobe files. It will then send the first 50K bytes of each file to Nessus over a secure SMB link. All data obtained by the plugin will be searched for the data patterns in the .audit file. In the above case, any of the strings "Social Security Number", "SSN", "SS#" or "Social" are required to be present. The regular expression is used to look for at least one SSN.

If the system is scanned and no sensitive data is found, it is logged as a "PASS". Otherwise, it is logged as a FAILURE.

Other technical details include:

  • Any file extension can be used.
  • For PDF files, the Nessus plugin automatically decodes the PDF encoding.
  • A regular expression statement is optional, however, the "expect" statement that contains basic string matches is always required.
  • There is an additional keyword named "only_show" which only shows the last "n" bytes of a matched file.

Protecting the Auditors

Below is an example of a .audit policy to search for American Express credit card numbers:

<check_type:"WindowsFiles">
<item>
        type: FILE_CONTENT_CHECK
        description: "Determine if a file contains a valid American Express Card Number"
        file_extension: "xls" | "pdf"
        regex: "([^0-9-]|^)(3(4[0-9]{2}|7[0-9]{2})( |-|)[0-9]{6}( |-|)[0-9]{5})([^0-9-]|$)"
        expect: "American Express" | "CCAX" | "amex" | "credit"
        max_size : "50K"
        only_show : "4"
</item>
</check_type>

As an auditor, you might think it very interesting to start collecting credit cards, personal data and so on, but organizations that are trying to limit where this type of data goes do not want to compound the problem.

Rather than making your audit team part of your "sensitive" data controls, all of the audits performed by Nessus can limit the amount of data that is displayed. The "only_show" keyword in the audit file will display the last "N" bytes of data. For example if an example credit card of "1122-3344-5566-7788" was found, it would only display "XXXXXXXXXXXXXXX7788".

Obtaining and Running These Checks

Nessus ProfessionalFeed users on Red Hat, Solaris and OS X can simply update their plugins. Along with the new plugin, a new plugin preference named "Windows File Contents Compliance Checks" will be available. The new plugin will also be available under the "Policy Compliance Family".

To run a check, download a .audit file (or write your own), build a scanning policy that includes the new plugin and your .audit file and then perform a scan against a Windows host with the proper credentials.

Tenable is adding more and more example .audit files at the Tenable Support Portal. These files are listed alongside the configuration .audit files for NIST, NSA and CERT audit standards and many more. Currently, the Sensitive Content Audit Policies .audit files are offered for discovery of:

  • Employee Identification Number
  • Employee Salary List
  • Financial Statement
  • International Wire Transfer
  • Non Disclosure Agreements
  • Source Code Leakage
  • Classified Documents
  • EDI Claim Information
  • Credit Card Number
  • Driver’s License
  • Social Security Number (Generic)
  • Social Security Number (by State)

Optimizing These Checks

While BETA testing these .audit files, there were several trade-offs than any organization needs to consider:

  • Which extensions should we search for?
  • How much data must be scanned?

The .audit files do not require the "max_size" keyword. In this case, Nessus will attempt to retrieve the entire file and will continue until it has a match on a pattern. Since these files traverse the network, there is more network traffic with these audits than with typical scanning or configuration auditing.

Searching for more extensions may encounter unexpected results. For example, Trillion chat logs are saved as .txt files. If you have a user who placed an SSN or a credit card number in a chat session once, that may show up.

Searching for less data, such as just the first 5000 bytes is much faster than searching for the first 50K bytes, but is much less in depth.

For More Information

There is a separate blog entry that describes using this plugin in an enterprise network as part of a comprehensive vulnerability, configuration and sensitive data audit environment.

Information on purchasing the ProfessionalFeed ($1200/year per Nessus scanner for end users) is available here.

 

New Nessus Configuration Auditing Features for Windows Servers

Tenable has added several new types of configuration and security audits that can be performed by Nessus 3 against Windows servers. This blog post explains the new items.

New Auditing Options

There are four new types of audit types available for Windows:

  • GROUP_MEMBERS_POLICY
  • FILE_AUDIT
  • REGISTRY AUDIT
  • SERVICE_AUDIT

The new types allow for close analysis of file, registry and service audit policies as well as which specific users are members of of a group.

GROUP_MEMBERS_POLICY

If you would like to perform audits of a Windows server and make sure that there is a specific list of users present in one or more groups, it is now very trivial to accomplish. The template for this type of audit is as follows:

<custom_item>
type: GROUP_MEMBERS_POLICY
description: ["description"]
value_type: [value type]
value_data: [value] | ([value2] | (...))
group_name: ["group name"]
</item>

When using this type of audit, the following items should be considered. The "value_type" variable must always be "POLICY_TEXT".  The "value_data" variable is a list of user accounts in quotes, separated by a pipe character. User accounts can also refer to their domain prefix such as "MYDOMAIN\John Smith". Lastly, the "group_name" specifies a single group for auditing.

A single Nessus .audit file can specify multiple different customer items, so it is very easy to audit lists of users in multiple groups. Here is an example .audit policy which looks for the "Administrators"
group to only contain the "Administrator" and "TENABLE\Domain admins" user:

<check_type: "Windows">
<group_policy: "Audit Administrators group">
<custom_item>
type: GROUP_MEMBERS_POLICY
description: "Checks Administrators members"
value_type: POLICY_TEXT
value_data: "Administrator" | "TENABLE\Domain admins"
group_name: "Administrators"
</item>
</check_type>

When scanning a Windows 2003 server that was not on the Tenable domain, the results under Nessus 3 look like this:

Audit2group

FILE_AUDIT

On Windows server systems, any file or directory can have auditing enabled. This can create logs when authorized or unauthorized users attempt to access or delete content.  The new type requires the specification of a Windows access control list someplace else in your .audit file. The template for this check looks like:

<custom_item>
type: FILE_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
file: ["filename"]
(optional) acl_option: [acl_option]
</item>

The "value_type" feild must always contain a FILE_ACL. The "value_data" field should name an Access Control List defined elsewhere in your .audit file.  The "file:" keyword should indicate either the full path to the file or directory of interest, or make use of one of the following supported PATH keywords:

  • %allusersprofile%
  • %windir%
  • %systemroot%
  • %commonfiles%
  • %programfiles%
  • %systemdrive%

When using this audit, please consider the following. The "file" field must include the full path to the file or folder name (ie: C:\WINDOWS\SYSTEM32) or make use of the above PATH keywords. The "value_data"  field is the name of an access control list defined in the policy file. The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success/error if the file does not exist. Also, the "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events.

Here is an example .audit file that implements the FILE_AUDIT function, including an example access control list rule named "ACL1".

<check_type: "Windows">
<group_policy: "Audits SYSTEM32 directory for correct auditing permissions">

<file_acl: "ACL1">
<user: "Everyone">
acl_inheritance: "not inherited"
acl_apply: "This folder, subfolders and files"
acl_deny: "full control"
acl_allow: "full control"
</user>
</acl>


<custom_item>
type: FILE_AUDIT
description: "Audit for C:\WINDOWS\SYSTEM32"
value_type: FILE_ACL
value_data: "ACL1"
file: "%SystemRoot%\SYSTEM32"
</item>

</group_policy>
</check_type>

REGISTRY_AUDIT

Similar to FILE_AUDIT, registry settings can have auditing enabled to log when attempts to add, change, delete or modify them occur by specific users or groups. The prototype for this type of audit is this:

<custom_item>
type: REGISTRY_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
reg_key: ["regkeyname"]
(optional) acl_option: [acl_option]
</item>

When using this type of audit, please keep the following items in mind:

  • The only supported value for "value_type" is REG_ACL
  • The "value_data" field specifies the access control list name
  • The "reg_key" field specifies the registry key name for auditing
  • The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success or error if the key does not exist
  • The "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events

Also, the "reg_key" value can also make use of a predefined registry path value of :

  • HKLM (HKEY_LOCAL_MACHINE)
  • HKU (HKEY_USERS)
  • HKCR (HKEY_CLASS_ROOT)

Here is an example portion of a .audit file which audits the registry key of "HKLM\SOFTWARE\Microsoft" against an access control list named "ACL2" which is not shown:

<custom_item>
type: REGISTRY_AUDIT
description: "Audit for HKLM\SOFTWARE\Microsoft"
value_type: REG_ACL
value_data: "ACL2"
reg_key: "HKLM\SOFTWARE\Microsoft"
</item>

SERVICE_AUDIT

Similar to auditing files and registry settings, Windows also has the ability to audit when authorized or unauthorized users attempt to start, stop or restart a process. The prototype for this is as follows:

<custom_item>
type: SERVICE_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
service: ["servicename"]
(optional) acl_option: [acl_option]
</item>

When using this audit, please keep the following items in mind:

  • The "value_type" field is always SERVICE_ACL
  • The "value_data" field contains the name of the access control list to test against
  • The "service" field identifies the service to be audited.
  • The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success or error if the service does not exist
  • The "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events

Here is an example portion of a .audit file for auditing the "Alerter" service.

<custom_item>
type: SERVICE_AUDIT
description: "Audit for Alerter Service"
value_type: SERVICE_ACL
value_data: "ACL3"
service: "Alerter"
</item>

Version 1.0.8 of the "inf to audit" (i2a) tool

Tenable has also released version 1.0.8 of the i2a tool to take advantage of these new features. The i2a tool converts Microsoft .inf policy files directly to a Nessus 3 .audit file. If you have previously generated a .audit file with the i2a tool, and it had audit policies for these new settings, you can rerun the i2a tool on your .inf policy file to get an updated audit policy.

Obtaining The New Audits

Nessus 3 Direct Feed or Security Center users should update their plugins. If daily plugin updates are normally performed, you will already have these new audits available to you.

At the time of this blog writing, the latest version of the compliance_check.nbin file was 1.20. On UNIX, you can test this by invoking the nasl binary test tool.

[root@megalon bin]# ./nasl -V /opt/nessus/lib/nessus/plugins/compliance_check.nbin
Script ID : 21156
Script Name : Windows Compliance Checks
Script Version : $Revision: 1.20 $
Copyright : This script is Copyright (C) 2006 Tenable Network Security
Family : Policy Compliance

 

Log Correlation Engine Rules Update

Several new PRM libraries and one TASL script have been updated and are available for download and use with the Log Correlation Engine. The list below shows what has changed. Each PRM or TASL links to the URL for downloading.

To install these files, simply download them and place them in the /usr/thunder/daemons/plugins directory and then restart the thunderd process.

Customers are encouraged to periodically monitor their notmatched.txt file, which contains a list of all logs that were collected, but did not match a known pattern. Please contact Tenable if one of the supported applications or products is missing logs in your environment.

 

Tenable Wednesday

Most readers should be familiar with the concept of "Microsoft Tuesday" as the day when Microsoft, and many other OS vendors, release security patch information. These releases occur on a regular basis. Because of this, we've had many Tenable customers configure their Security Center to automatically update Nessus and Passive Vulnerability Scanner plugins, perform a scan and then email a report on the following Wednesday. This blog post discusses how this is accomplished.

Research of Vulnerabilities

Tenable's research team publishes all new plugins to this RSS feed. This information is publicly available to anyone. Anytime we release a remote check or patch audit, it shows up there. Patch audits are usually the first (and easiest) plugins to produce, and then more complex remote "service" audits come next. Checks that can be accomplished purely through sniffing are also produced for the Passive Vulnerability Scanner (PVS) which also has it's own RSS feed of new plugins as well. Typically, within the first 12 hours of major bug releases, the checks will be available for Nessus Direct Feed subscribers, and Security Center and PVS users.

Automatic Monitoring with the Security Center

If your Security Center is updating the Nessus and PVS plugins on a nightly basis, than scheduling a scan for early "Wednesday Morning" can give you very good insight as to how open your network is to the immediate vulnerabilities. If the PVS is also deploiyed on the network, then it will also alert to new vulnerabilities without the need for a scan.

Scans can automatically be scheduled to perform patch audits of certain types of network assets such as all of the domain controllers, all of the mail servers, all of the server farm and so on. The Security Center manages the updating of each Nessus scanner as well as the credentials required for a full audit of each asset. Security Center users accomplish this with a "vulnerability policy" and a "scan policy".

The vulnerability policy specifies what you want to scan for. This includes scan configuration settings, such as credentials and target ports, as well as which Nessus plugins (by family or individual plugins). Since the Security Center uses the Nessus Direct Feed for its source of plugins, you can also create a vulnerability policy that makes use of the most recent plugins in each family. For example, you could create a policy to scan for just "Windows Patches" and only those, including the latest patch audits, would be executed.

Scanning polices can be very simple or quite sophisticated. For example, a scanning policy could launch a credentialed scan against the "Windows Servers" everyday at 5:00 AM. Scans can also occur at specific days of the week, weekends, certain days of the month and so on. Scans can also be chained together such that the results of the first scan can be used to update a dynamic asset list which is scanned by the second scan. Scan policies can also select which Nessus scanners (or groups of scanners we call "zones") perform the audit.

If the PVS is deployed on the network, the Security Center will update those sensor with the latest vulnerability plugins. No policies, scan schedules or credentials are required to configure the PVS. It just montiors the network and accurately reports client and server side vulnerabilities to the Security Center.

Automatic Reporting

For active Nessus scans, each scan policy also has the option to generate an email of any vulnerabilities found, or just "new" pieces of information. When these scans occur immediately after a "Microsoft Tuesday", they will identify all of the systems which have the "brand new" missing security patches.

The Security Center can also automatically create a scheduled PDF report of vulnerabilities which can be emailed to you. This report is generated from the Security Center's "cumulative" vulnerability database. This database includes any passively discovered vulnerabilities from the PVS. 

A very useful part of the cumulative database is the filtering of vulnerabilities based on when they were "first seen". A "Tenable Wednesday" report could easily be limited to all vulnerabilities that have been discovered within the past day. This is a very convenient way to automatically report on all "new vulnerabilities" identified by multiple Nessus scans and PVS monitoring.

For some customers who do not scan that often, but use the PVS, the passively discovered vulnerabilities are their first indication that there may be new security issues. 

Conclusion

Reporting on the most recent vulnerability information available is a method of finding out the "bad news" as quickly as possible. This is a completely different process than our previous blog post, which suggested reporting about vulnerabilities based on classes of systems that were managed or un-managed.  The intent of scanning for the latest and greatest vulnerabilities should be to discover any critical security issues that will impact your business in the short term.

 

Webinar -- "HIPAA Compliance - What can Nessus do for you?"

Tenable Network Security will be hosting a webinar on March 21, 2:00 PM to 3:00 PM EST. This presentation will consider how configuration auditing and vulnerability monitoring can be performed by the Nessus vulnerability scanner when managed by the Security Center.

It will be led by Dave Breslin who is Tenable's Director of Sales Engineering. Dave is a Certified HIPAA Professional and a Certified HIPAA Security Specialist.

To register for the webinar, please use the following URL:
https://www.gotomeeting.com/register/486062528

If HIPAA Compliance auditing is of interest, readers should request a copy of Tenable's HIPAA Application Notes and Product Evaluation guides which detail how specific HIPAA requirements can be monitored and reported on with Tenable products.

 

Trimming the FAT

Tenable's research group today released a check for Nessus which discovers systems not-running NTFS file systems. For example, a system running on top of FAT32 would be detected by this plugin. The plugin is named "Insecure Logic Drive FileSystem" and has a Nessus ID of 24871.

If you have a Windows Server system not utilizing NTFS, then there is very little security offered at the file level. NTFS offers the ability to set permissions on user files and folders and also makes it more difficult to gain access to system files.

The check considers every file system on the remote Windows server, not just those being shared over SMB.

This check is accomplished through Nessus 3 Windows WMI queries and is currently available to Nessus Direct Feed and Security Center subscribers. Tenable releases many Nessus plugins each day and offers this RSS feed for users and customers to remain informed.

 

Nessus 3.2 BETA -- Example WMI library usage

The Nessus 3.2 BETA includes many new features, including a library that allows users to program their own WMI queries to Windows systems. This blog entry discuses some example WMI NASL scripts that make use of the new library and identify interesting asset and configuration information about Windows Hosts.

Tenable has already released several Windows security audits based on Nessus 3's WMI implementation. These checks are only available as Nessus 3 .nbin files. The ideas discussed in this blog may be released as future Nessus 3 .nbin files. However, if readers want to experiment with WMI today, they can try the BETA.

Installing Nessus 3.1 and the WMI .nlib library

The BETA of Nessus 3.2 has a designation version of "3.1". At the time of this blog draft, Tenable had released version 3.1.2. It can be obtained at nessus.org. The BETA can be installed over an existing Nessus 3 installation, but you should keep in mind that it still has the BETA designation and shouldn't be placed into production.

The WMI library can be downloaded from here. The file wmi_func.nlib should be installed into the plugins directory such as /opt/nessus/lib/nessus/plugins on Red Hat Linux.

Running A First Query -- Getting the System Name

Remote WMI queries can get a wide variety of asset information about a Windows server. Consider the following Visual Basic code which enumerates a system name:

'ENumerates System Name
On Error Resume Next
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Processor",,48)

WScript.Echo "SystemName: " & wbemObject.SystemName

The same set of code in NASL with the WMI library looks like this:

import("wmi_func.nlib");
wmiObject = WMI_ConnectServer("root\CIMV2");

if ( isnull(wmiObject) ) exit(0);
res = WMI_ExecQuery(wmiObject, "SELECT * FROM Win32_Processor");
info = WMI_GetNextElement (res);
display(info["SystemName"], "\n");
WMI_ReleaseObject(res);
WMI_ReleaseObject(wmiObject);

Here is an example running from the command line using the nasl binary:

[root@demo3 plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 wmi_test1_name.nasl
Login : Administrator
Password : *******
Domain :
TENABLED-9U86TO

The name "TENABLED-9U86TO" was obtained through a WMI query. Also note for readers not that familiar with running the nasl binary from the command line, it will ask you for credentials as well as other items and preferences at run time.

Second Query - Get the OS and Patch Level

Using WMI to obtain the specific operating system release and patch level is a simple query.

import("wmi_func.nlib");

wmiObject = WMI_ConnectServer("root\CIMV2");
if ( isnull(wmiObject) ) exit(0);

res = WMI_ExecQuery(wmiObject, "SELECT * FROM Win32_OperatingSystem");
repeat {
info = WMI_GetNextElement (res);
display(info["Caption"], " ", info["ServicePackMajorVersion"], "\n");
} until (isnull(info));

WMI_ReleaseObject(res);
WMI_ReleaseObject(wmiObject);

And here is the output:

[root@demo3 plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 wmi_test2_os_patch.nasl
Login : Administrator
Password : *******
Domain :
Microsoft(R) Windows(R) Server 2003, Standard Edition 1

Third Example - Listing Recent Windows Events

WMI can also be used to remotely obtain Windows events. The following code shows how to obtain the last 10 events out of the Windows "Application" log file:

import("wmi_func.nlib");

wmiObject = WMI_ConnectServer("root\CIMV2");
if ( isnull(wmiObject) ) exit(0);

res = WMI_ExecQuery(wmiObject, "Select * from Win32_NTEventLogFile Where LogFileName = 'Application'");
info = WMI_GetNextElement (res);

records = int(info["NumberOfRecords"]);
display("Number of Records : ", records , "\n");

last10 = 0;
if (records > 10) {last10 = records - 10;}
for (i=last10; i<records; i++)
        {
        querry_string = "Select * from Win32_NTLogEvent Where LogFile = 'Application' AND RecordNumber =" + i;
        res = WMI_ExecQuery(wmiObject, querry_string);
        info = WMI_GetNextElement (res);
        display("ComputerName:", info["ComputerName"], "\n");
        display("EventCode:", info["EventCode"], "\n");
        display("Message:", info["Message"], "\n");
        }

WMI_ReleaseObject(res);
WMI_ReleaseObject(wmiObject);

and here is an example run of the code:

[root@demo3 plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 wmi_test4_events.nasl
Login : Administrator
Password : ********
Domain :
Number of Records : 2307
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: accepted: 192.168.20.199::3139
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: closed: 192.168.20.199::3139 (Clean disconnection)
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: accepted: 192.168.20.199::3520
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: closed: 192.168.20.199::3520 (reading version failed: not an RFB client?)
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: blacklisted: 192.168.20.199
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: blacklisted: 192.168.20.199
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: blacklisted: 192.168.20.199
ComputerName:TENABLED-9U86TO
EventCode:1
Message:HTTPServer: untrapped: End of stream
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: accepted: 192.168.20.199::1549
ComputerName:TENABLED-9U86TO
EventCode:1
Message:DeviceFrameBuffer: BitBlt failed:5

There are many possibilities for performing security audits based on Windows event logs.

Enterprise Security and Compliance Relevance

The WMI technology on Nessus allows for very close inspection of many 1000s of Windows servers without an agent. Tests to look for specific configurations can shed light on any organization's IT management practices as well as to look for unauthorized configurations.

For More Information

Microsoft has an MSDN site with many very useful examples of Visual Basic scripts to query just about anything on the remote computer through WMI.

Tenable is actively developing .nbin plugins to perform a variety of audits using WMI. With the Nessus 3.2 BETA and the WMI .nlib library, anyone can quickly prototype queries and test them out. Please feel free to discuss these on the Nessus mailing list, or to send your ideas to Tenable.

 

Reporting Vulnerabilities in an IT Managed Environment

If you are performing some sort of vulnerability monitoring program or audit, you are most likely finding a large volume of information. Making sense of this information and presenting it to other users who may be less technical than you (or at least less familiar with the vulnerability discovery process) can be a challenging task.

Continue reading "Reporting Vulnerabilities in an IT Managed Environment" »

 

Detecting Change -- Part II

Tenable has previously bloged about how change can be detected through log analysis. Network change can be detected many other ways, including scanning and passive network monitoring. This blog entry will discuss why detecting change is important to security and compliance, the different types of change that can occur on the network and how they can be detected with Tenable solutions.

Types of Network Change

You might think of a network as always being in motion. There are different users logged on, different traffic loads and over time, new services are supported by the network. Having discrete methods to detect certain types of change is extremely useful. Consider the following lists of potential changes that can occur on a network:

  • adding a new server
  • adding a new client or server application
  • creating a new user account
  • changes in a system's configuration
  • changes in a system's network activity

Obviously, there are many more types of change than these, but the above list will catch a majority of changes that do occur. Each of these items can have dramatic ramifications for an organization's IT compliance or security postures.

Security and Compliance

Regardless if your organization follows ITIL, COBIT or some other form of IT management, any type of change which hasn't been authorized is against policy. If your organization allows undocumented changes as needed, over time, your network will become unmanageable since each system will likely have a very unique configuration.

This can also impact security by dramatically increasing the cost of performing system administration. If systems are not managed in a known state, then performing routine tasks like patch management can become very tedious.

Also notice that nowhere on the above list of "change" was detecting a new vulnerability. Very often, "new" vulnerabilities are discovered when they are disclosed, and Tenable's research team writes a Nessus or Passive Vulnerability Scanner plugin for them. The same exact system from the day before is now deemed vulnerable. However nothing really changed in the system except we have a more accurate test to enumerate a security issue.

Detecting a New Server

Tenable offers many ways to detect when a new system has been added.

Actively, subsequent Nessus scans can be used to identify new hosts. When managed by the Security Center, asset owners can be alerted after each active scan if there are any new systems. If the same system has been scanned several times, the Security Center will also track when issues surrounding it have been first seen, last seen and how many times they have been observed.

For passive alerting of new hosts, the Passive Vulnerability Scanner (PVS) will alert in real time if it sees a new host. When managed by the Security Center, all "new hosts" can be automatically placed into a dynamic asset list and scanned with Nessus once per day.

Detecting a New Client or Server Application

For active network scans, if the new application has listening daemons, Nessus will likely identify the system, or at least the presence of new open ports. All "server" applications have some sort of listening port which can be fingerprinted. The Security Center can alert individual asset owners when any new data, including new services and open ports, is discovered. Many "client" applications such as iTunes or eMule also have open ports which can be identified by a network scan.

Client and server applications also generate network traffic. This traffic can be observed by the PVS. At a minimum, if a system has not even browsed on a certain port in the past, the PVS will alert on this change. Typically, the PVS will identify the new application as it performs a handshake with its server or reaches out to the Internet for a potential self update.

If the Log Correlation Engine (LCE) is in use, Tenable has produced many normalization rules which detect when new client or server software has been installed or has been upgraded.

Detecting New Users

If a new user is added to an operating system, the Log Correlation Engine is able to parse these logs and gather them. Similarly, LCE rules exist to look for changes in user privileges. A variety of LCE correlation rules named TASLs are available. One in particular tracks active directory authentication requests along with DHCP queries and can alert when an individual user's MAC address has changed. Other TASLs can automatically learn any account used for most OSes (UNIX and Windows) as well as applications such as VNC.

With active scanning, Nessus is also able to list users on Windows operating systems, detect accounts which haven't been used and a variety of other types of information. 

Detecting Changes in a System Configuration

Nessus Compliance Checks can be used to audit UNIX and Windows systems against a known good policy. These checks look at user privileges, permissions of objects, file permissions and many different parameters including the content of UNIX and Windows configuration files. If there are any changes that violate an IT configuration policy, the next audit will highlight the issue.

The Log Correlation Engine also has the detect_change.tasl script. This script is constantly updated with new types of logs which indicate changes in users, changes in system configurations and software being added or removed.

Detecting a Change in Activity

The Passive Vulnerability Scanner constantly builds up a model of all systems on the network. For known systems, if it sees a new port being used for network browsing or a new port being used to serve an application, it will alert this new activity in real time.

The Log Correlation Engine also has a statistical anomaly engine that models all network and log events. This model includes frequency of events as well as internal, external and inbound connection activity. If there are statistical changes in any event (like web browsing) or connectivity (more connections between a server and a domain controller) it will log the anomaly.

For More Information

For more information on detecting change to look for compliance, IT management exceptions, and security incidents, please consider the following resources:

  • Request a copy of Tenable's "Real Time Compliance Monitoring" paper.
  • Read the "Security and IT Controls" blog entry
  • Download a copy of the "Network Implications of Visible Ops" paper which discusses using Tenable products to monitor networks in an ITIL framework
  • List of User and Compliance Monitoring TASL Scripts for the LCE

For more information on Tenable's products, please visit our web site, browse our "demos" page or consider pricing for the Direct Feed, Security Center, Passive Vulnerability Scanner or Log Correlation Engine.

 

Using Manufacturer Information For Automatic Dynamic Asset List Creation

We've blogged in the past about how the Security Center can use any data obtained by Nessus or the Passive Vulnerability Scanner to automatically classify a host into one or more political or technical asset lists. Information gathered by the 13,000+ Nessus scanning, patch auditing and compliance checks and the 3000+ Passive Vulnerability Scanner plugins can be used to automatically find and categorize your networks and systems by Windows domain, installed software, location on the network and so on.

With the recent introduction of the "Computer Manufacturer Information" Nessus check (plugin ID #24270), it is now possible to use this information to classify your Windows assets based on hardware manufacturer information. This blog entry shows what sort of data can be obtained by this plugin and how it can be used to create lists of existing Dells, HPs and ThinkPads, as well as existing portable, tower, rack mount and other types of systems.

Computer Manufacturer Information Example

Plugin #24270 can query the remote Windows device and ask it which manufacturer made it, the model of the unit and what sort of type it is. Let's look at two examples:

Computer Manufacturer : Dell Inc.
Computer Model : Latitude D820
Computer Type : Portable

Computer Manufacturer : Dell Computer Corporation
Computer Model : Dimension 8200
Computer Type : Mini Tower

This text comes from two scans against a laptop and an older tower. The plugin provides information on the manufacturer and the specific vendor computer model. Both of these values are controlled by the manufacturer.

The type indicates the physical form factor of the device and can have the following values:

  • All in One
  • Bus Expansion Chassis
  • Desktop
  • Docking Station
  • Expansion Chassis
  • Hand Held
  • Laptop
  • Low Profile Desktop
  • Lunch Box
  • Main System Chassis
  • Mini Tower
  • Notebook
  • Other
  • Peripheral Chassis
  • Pizza Box
  • Portable
  • Rack Mount Chassis
  • Sealed-Case PC
  • Space-Saving
  • Storage Chassis
  • SubChassis
  • Sub Notebook
  • Tower
  • Unknown

Asset Classification

The Security Center can make use of the output from this plugin and automatically create dynamic asset lists based on the manufacturer or type. Below is a screen shot of a basic rule that matches the word "Dell" as a manufacturer:

Dynamicassetexamplesmall

Each time Nessus performs a scan of this plugin, with the above dynamic asset rule, the Security Center will automatically create a list of all "Dell" computers.

Any of the information in this plugin can be used to create a dynamic asset list.  With this plugin and Security Center,  it is very trivial to scan a network with credentials and create lists for many different items such as unique manufacturers, unique device types and specific deployed models .

Security, Compliance and IT Management Implications

Being able to categorize assets based on manufacturer, model and type can have a variety of implications for IT monitoring. These include:

  • Discovering manufacturers which have been purchased against corporate acquisition policies. For example, you might be an "HP" shop. If so, why are there a few "Dell" laptops in the network?
  • Remotely identifying if a device is a mobile device or not. Laptops, hand-helds and even mini-towers can be easily moved. Being able to determine what a device actually is without physically touching it is very valuable.
  • Having the ability to identify just the models from a specific IT purchase or from a recent merger/acquisition is also extremely useful. Occasionally, a computer vendor will ship computer units with different default Windows settings, different BIOS settings, hardware that requires replacing and so on.
  • Rapid counting of assets. Being able to scan with Security Center or Nessus and then quickly report on the number of unique manufacturers, number of laptops, specific model counts is very valuable to IT.

For More Information

Tenable has released this plugin under the Nessus Registered Feed. It is released for Nessus 3 as a .nbin file and makes use of Tenable's implementation of agentless WMI technology. Users who wish to write their own WMI queries for Nessus should consider the current Nessus 3.2 BETA which supports a library for rapid development and testing.

 

Monitoring Telnet Security

With the advent of the current Solaris Telnet Worm, Tenable has had many requests and comments about not only finding the specific associated vulnerability, but how to monitor Telnet in general. This blog entry discusses the worm, how to scan for the Solaris 10 in.telnetd vulnerability and how to monitor your network for Telnet activity.

Scanning for the Solaris in.telnetd Vulnerability

Tenable has released three checks to discover this vulnerability on Solaris systems:

  • Plugin #24323 Solaris 10 Telnet Authentication Bypass
  • Plugin #24343 Solaris 10 (sparc) : 120068-02
  • Plugin #24342 Solaris 10 (i386) : 120069-02

Like most of Nessus's active scans, plugin #24323 confirms the presence of the vulnerability by actually attempting to interact with it. In this case, the NASL script tries to obtain the /etc/passwd file. Plugins #23434 and #24342 are both patch audits which require SSH credentials to audit the presence of the related missing patch to secure in.telnetd.

Looking for Telnet Worm Compromised Hosts

There are several techniques available to look for any evidence of Solaris systems on your network that have been compromised by this worm.

A simple way would be to use a Nessus scan and the "Trojan horses" plugin (Nessus ID #11157). This plugin was recently updated with a common back door port associated with the Telnet worm. To effectively use this, make sure you either perform a full port scan or at least target TCP port 32982.

Using the Security Center, a dynamic asset list can be created of all Solaris devices based on either a TCP/IP OS fingerprint with Nessus, passive TCP/IP fingerprint with the Passive Vulnerability Scanner (PVS) or even based on known SSH keys. Once the list of "all Solaris" servers is known, several things can be accomplished:

  • If a PVS is configured to detect outbound port scans or a source of networks IDS events is available, any Solaris assets performing port scans could be infected with the worm.
  • If any of the Log Correlation Engine's NBAD TASL scripts are enabled, such as the Shell Proxy or Suspicious Shell Proxy scripts, these will fire when there is an inbound connection quickly followed by an outbound connection. Considering these events for just your "Solaris" assets is also a useful filter. Like many worms, this Telnet worm makes many connections.
  • The Security Center can correlate attacks from many different network IDS devices with the vulnerabilities scanned for by Nessus. This includes the Solaris 10 Telnet vulnerability. Security Center customers had automatic coverage for this correlation with Snort VRT, Bleeding Snort, Tipping Point and many other NIDS.
  • If an attack has compromised a Solaris device they will undoubtedly create new logs. The LCE has a TASL script named "Never Before Seen" which highlights new log events that haven't occurred before. It is very likely that an attacker will generate firewall logs, host logs or event IDS logs that have not been seen yet. Filtering these alerts for just the Solaris assets also can give a sense of how much is really "new" in the system logs.
  • CERT advisory TA07-059A mentions several files and directories that are commonly created by users and worms that compromise Solaris systems. Nessus scanners subscribed to the Direct Feed or managed by the Security Center can perform an audit of the Solaris hosts to see if these files exist with permissions indicative of a hacker or worm.

One last example is a combination of the PVS's ability to generate alerts when it sees new activity, specifically a system that begins to browse on a new port for the first time. These events can be sent to the LCE and trended. Here is an image of new port browsing events for port 23 at a small university:

Telnetnewport23

Each of these events indicates a single host that has never been previously observed to send any network traffic on port 23. This activity started a few weeks ago and is indicative of a worm. The graph clearly shows that hosts that have never ever browsed on port 23 started to about a week ago. We've previously blogged about using this technique to find evidence of Symantec worms.

Auditing Telnet Use In General

There are many techniques an enterprise can use to audit protocol or application usage. For Telnet, Tenable offers many different ways to perform one time audits or continuous monitoring.

  • Nessus Scanning Simply scanning a local network and finding all of the Telnet daemons that are open can highlight where these hosts are at.
  • Distributed Scanning If multiple Nessus scanners are being managed by the Security Center, a scanner on the "outside" of a network can be tasked to scan for open Telnet servers. By scanning from the outside on a regular basis, the entire security posture of firewalls, screening routers and the systems potentially running Telnet can be routinely monitored.
  • Passive Scanning If a PVS is in use, then it will automatically log not only which servers are running Telnet servers, but which ones use Telnet clients to reach other servers. If the PVS is deployed at a network boundary, then this can also indicate Telnet activity in and outside of your network.
  • Host Configuration Assessment If the Security Center or a Nessus Direct Feed is in use, UNIX configuration files and running processes can be checked. This can ensure that TCP Wrappers is/isn't installed and that the Telnet service is/isn't running.

Conclusion

Telnet on Solaris 10 is the current worm of interest, but many of the concepts discussed here can be applied for day-to-day monitoring of your network. Tenable products are very useful for looking for the needle in the haystack when you know what to look for, but they also can shed a lot of light on network activity before they become public knowledge.