Episode #85 of Risky Business is now available and features an interview with Tenable's CSO Marcus Ranum. Also featured are a discussion with H.D. Moore about Metasploit 3.2's new features and license as well as a senior Microsoft executive who discusses last weeks out-of-band MS08-067 patch release.
5 posts from October 2008
Yesterday, Microsoft released an out of band security patch (dubbed MS08-067) which fixes an overflow in the ‘server’ RPC service.
Tenable’s Research group has released two Nessus plugins to detect Windows systems that are vulnerable to this vulnerability, which allows almost any Windows 2000, XP and 2003 system to be easily compromised without any credentials. Plugin #34477 named “Vulnerability in Server Service Could Allow Remote Code Execution (958644) – Network Check” identifies Windows systems that are vulnerable to this issue. It verifies the vulnerability by connecting to Windows systems on port 445 or port 139 and reliably and non-destructively performs a check for it. This plugin has the advantage of being fast and not requiring credentials. This plugin is distributed as part of the generic Windows plugin family.
Plugin #34476 named “Vulnerability in Server Service Could Allow Remote Code Execution (958644)” performs a credentialed patch audit for the same vulnerability. This plugin performs file level analysis to ensure that the right system DLLs have been patched. This technique is more accurate than relying on registry checks alone and can also identify system that have been patched, but perhaps are waiting on a system reboot for them to truly be effective. This plugin is distributed as part of the Windows : Microsoft Bulletins family.
Monitoring Your Networks
This particular vulnerability can be reliably exploited. If you have any Windows computers that have direct access to the Internet (without any firewall), they will likely be subject to attacks from worms and botnets. You should use network and host based firewalls to limit traffic to these ports. If you are unsure of which ports you are open to on your network, you should consider performing remote network vulnerability scans with Nessus or monitor your network traffic in real time with a product like the Passive Vulnerability Scanner.
Internally, your networks can be audited with Nessus. If you have a large number of servers to audit, you can also make use of the Tenable Security Center to schedule your scans, analyze the results and share them securely across your various IT organizations. A key feature of the Security Center is the ability to efficiently combine one time scans with ongoing scans as well as credentialed patch audits, regular network scans and real-time results from the Passive Vulnerability Scanner. This allows any size organization to understand when a host was first added, when it was first found vulnerable and when it was remediated with high accuracy and flexibility.
Lastly, since this vulnerability will be likely targeted by malicious users, you should consider your organization’s overall technical ability to detect compromises and react to them. Existing Nessus checks that we’ve recently blogged about such as the ability to detect executables, fake services, Windows systems that have had their HOSTS file modified and even enumeration of each running network service, can all contribute to effective monitoring for compromised systems. If you do run a SIM or NBAD solution such as Tenable’s Log Correlation Engine, I would also recommend review of concepts such as monitoring your network for systems that have connected to known “bad guy” blacklisted IP addresses, finding out which systems on your network have begun sending spam email and finding out when you have systems that suddenly become very communicative with other hosts.
Plugin Usage
To obtain Nessus plugins 34477 and 34476, Nessus ProfessionalFeed and Nessus HomeFeed users should manually update their plugins. Security Center users who wish to perform a scan immediately should choose the “Request Plugin Update” tool under their “Polices” menu.
If you are using Nessus alongside a different patch auditing or network scanning technology, keep in mind that since Nessus has two checks for this, you will get different results in different situations. For example, an agent-based patch auditing tool will be able to identify the vulnerability on a host that is firewalled from a remote Nessus scan. Similarly, Nessus will likely identify this security issue over the network while another scanner that is only performing local patch audits will not. And lastly, if your other scanner or patch auditing tool is only performing registry checks, Nessus will identify this issue much more accurately because of its use of file analysis to verify patch deployments.
For More Information
The following Tenable blog entries are very informative for auditing your network for compromised hosts and general malicious and suspicious activities:
Use Nessus and the Security Center to find out which processes are listening on the remote ports :
Use Nessus and Security Center to detect Windows hosts which have been compromised :
- Detecting Microsoft Executables Being Served by an Unknown Service with Nessus
- Boss, I Think Half of our FTP servers are Fake!
- Detecting Compromised Windows Hosts
Use the Log Correlation Engine and Passive Vulnerability Scanner to detect network anomalies :
Tenable’s Research Group has released three new beta plugins to all ProfessionalFeed and Security Center users that automate the process of preparing a PCI-DSS audit. The three new plugins available are:
- PCI DSS compliance: tests requirements
- PCI DSS compliance: passed
- PCI DSS compliance
These plugins evaluate the results of your scan and the actual configuration of your scanner to determine if the target server could be PCI compliant. The plugins don’t perform actual scanning – they just look at the results from other plugins.
Tenable chose to audit and report on the actual scan configuration so that Nessus users can still perform basic scans and get actionable results. This helps them understand if they have some glaring vulnerabilities that need to be fixed without performing a full audit, which can include onerous tasks such as full UDP and TCP port scans.
Configuring a Scan
A system will only be reported as being seemingly PCI-DSS compliant if the scan is compliant. PCI-DSS requires many different types of thorough testing. The PCI-DSS plugins report that your scan was not configured correctly if any of the following settings are not invoked:
- Enable all plugins
- Enable “thorough tests”
- Enable “experimental scripts”
- Enable TCP scanning of all 65535 ports
If these scan settings are not invoked, plugin 33931 will report the required settings. If this plugin reports anything, it will also prevent Nessus from actually designating a machine as being seemingly “PCI” compliant.
When configuring a port scan, please keep in mind that the credentialed method enables you to enumerate all ports, as well their listening processes, without actually scanning for all ports on the network. PCI-DSS requires that an audit of a web server be performed without any filtering. If there is no filtering between Nessus and the audited server, there is no reason to perform a full port scan.
One last point for configuring port scans – if you want to use the credentialed scanning options, be sure to disable the network scan options. If you don’t, Nessus does not report anything extra and the scans will only take longer. Tenable also provides a UDP port scanner for Nessus. This plugin is available for download from the Tenable Support Portal.
The PCI plugins are located under the Policy Compliance Nessus family as shown below:
To invoke the PCI-DSS compliance analysis, under the “Advanced” tab of your Nessus scan policy, there is a “PCI-DSS compliance” option with a single checkbox. Enabling this scan preference tells the three PCI plugins to perform their analysis as shown below:
Analyzing the Results
PCI-DSS audits will generally fail for three classes of items:
- Detection of any vulnerability with a CVSS score greater than or equal to 4
- Detection of any Cross Site Scripting or SQL Injection vulnerabilities
- Older versions and mis-configured SSL encryption
Because of the logic of our plugins, a scanned system will be in one of four states:
- It should be ready to obtain PCI-DSS compliance.
- The scan was good and we found information saying we were not compliant.
- The scan was bad and we still found information saying we were not compliant.
- The scan was bad and we didn’t find any information to prove we weren’t compliant.
Below is an example results output for plugin 33929:
The output shows the specific vulnerability IDs that determined that the system was not compliant.
Enterprise PCI Auditing
Tenable has many different solutions that can help with PCI reporting and auditing requirements on an enterprise level. The following general PCI requirements can be easily managed, monitored and reported on with Tenable solutions:
- PCI Requirement 1 – Nessus, the Passive Vulnerability Scanner and the Log Correlation Engine can be used to monitor firewalls access control lists, activity and configurations.
- PCI Requirement 2 – Nessus and the Passive Vulnerability Scanner audit for hundreds of default vendor settings as well as best practice system configurations.
- PCI Requirement 3 – Nessus and the Passive Vulnerability Scanner can audit systems for data containing credit card or customer information.
- PCI Requirement 4 – Nessus and the Passive Vulnerability Scanner can identify all SSL daemons and many different types of encrypted protocols.
- PCI Requirement 5 – Nessus can identify the running anti-virus solution and also identify if it has been disabled, mis-configured or has out-of-date signatures.
- PCI Requirement 6 – The Security Center is the premier tool to manage scanning data, patch audit data, configuration data and passively obtained network data. With the Security Center it is trivial to schedule scans, identify changes that impact PCI, find vulnerabilities older than 30 days and report on compliant and non-compliant systems.
- PCI Requirement 7 - The Log Correlation Engine can be used to analyze audit trails from servers to identify access to systems with cardholder data.
- PCI Requirement 8 – Nessus can be used to audit configuration settings required by PCI. Tenable offers several “audit” policies for Nessus which can be used to audit AIX, Solaris, Windows, FreeBSD, HP-UX and other operating systems.
- PCI Requirement 10 - The combination of the Security Center, Nessus, Passive Vulnerabiltiy Scanner and the Log Correlation Engine allows for tracking of all access to network resources and systems with cardholder data.
- PCI Requirement 11 - Nessus and the Passive Vulnerabiltiy Scanner can be used to regularly test systems for security issues and correct configurations. If the Log Correlation Engine is also deployed, it can be used to log the vulnerability scanning activity to prove that systems are being audited.
For More Information
During the beta period, customers are encouraged to provide feedback to Tenable by emailing us at beta@tenablesecurity.com. Support for scanning with these plugins is not currently available in the Security Center, but Nessus results can be manually imported.
The following blog entries will be of interest to anyone who uses Nessus or the Security Center to monitor a network for compliance and security issues:
Most large enterprise networks have a few legacy systems around – either because they were “forgotten” or because they support an old application that was never ported to a newer release. Such legacy systems can be the Achilles heel of network security.
The following sanitized screen shot comes from one of Tenable’s research sites:
What we are looking at (click on it to see a high resolution image) is a Windows NT 4.0 system that has been “forgotten” and is also being controlled as part of a botnet. This blog entry will discuss how the above Security Center screen shot can be analyzed to arrive at this conclusion.
Analyzing IDS Events
The Security Center can process network IDS events from a wide variety of sources including application specific detections from the Passive Vulnerability Scanner (PVS). The primary focus of the PVS is to passively identify all client and server applications in network traffic and generate an alert when there are specific vulnerabilities associated with them. In the case of botnet traffic, a certain percentage of HTTP, IRC and other client detection rules implemented by Tenable for the PVS will often highlight compromised systems.
In the above screen shot, the Security Center user has listed IDS events and focused on a system that had multiple “Generic BOTNET Client Detection” events. Regardless of what type of network monitoring solution you use (Snort, TippingPoint, etc.), I tend to find the signatures that look for “known” botnet and command and control events to be very reliable with a low false positive rate.
Another example of this was detected by the Snort sensor also running in this environment, with the Emerging Threats signature set. One of the interesting rules in that signature set is to look for IRC traffic on ports not normally associated with IRC, such as port 80:
The above screen was generated by analyzing logs gathered with the Log Correlation Engine (LCE).
How do we know it is an NT 4 System?
Nessus has a very sophisticated operating system identification system designed for IT audits. It uses the most reliable forms of system fingerprinting available.
In this case, the remote system was detected as being Windows NT 4.0 through interaction with the MS RPC service as shown below:
This same network also had the PVS running on it, and it also fingerprinted it as NT 4.0:
Looking at the Windows User Management set of plugins (shown below) we can see a few that have been protected. In particular plugin 10907 checks if the Guest account belongs to a group, which was very common on NT 4.0 default installations.
How do we know it is forgotten?
Determining that a computer has been “forgotten” is more a matter of opinion than something that can be detected with a plugin. Let’s ask some questions:
Why would a Windows NT 4.0 system still be around? Perhaps the server is part of an embedded device such as a medical system, printer or other legacy service. In this case however, there were no unknown services on this host and no other “odd” devices on the network this computer was on.
Why would it not be in DNS? If you notice on the popup “System Information Summary” screen, the DNS name for this IP address is unknown. If a system on a large corporate network is not part of DNS or the AD, there is a good chance that the IT group does not know about this system.
How Could this System Have Been Exploited?
The LCE was running on this network for some time, but the botnet activity was only recently discovered. There were no inbound network connections that resulted in “attack” events or other types of correlated activity. One day, the “guest” account simply was part of a group.There are many “LAN” aware worms such as SirCam and Nimba variants that look for local network shares in an attempt to exploit more computers. It is quick likely that this NT 4.0 system was victim to a worm-style attack.
For More Information
Nessus is very effective at identifying a wide variety of “Unsupported” operating systems. These include Windows NT 4.0, Windows 95/98/ME and a variety of unsupported Linux and UNIX systems.
Microsoft runs a web page of their products which have been “end of lifed” (EOL) here:
http://support.microsoft.com/gp/lifesupsps
In particular, Windows NT has been EOL’ed since December 31st 2004. It contains many vulnerabilities that Microsoft has not offered patches for.
There may be many good reasons for having an older computer system on your network. A great example would be to run older software application that was never ported to a newer OS platform. You might not have a choice either. It is possible that Windows NT comes as part of your printer, phone system, security camera or other type of embedded applications.
Regardless, being able to identify these types of systems on an ongoing basis is very useful. If the system is needed, you can develop a risk mitigating strategy to compensate for any vulnerabilities associated with these unsupported operating systems. If the system is not needed it be removed from the network, thus closing the security exposure.
One of the most important goals of forensic analysis and system auditing is to determine what a system is actually running – not what appears to be running. A static review of installed system binaries may show results that are perfectly benign while the process that is actually running is not. It is important to correlate the running process with the program stored on disk to really determine what it is doing.
“Listening Process” Auditing with Nessus
Nessus users that perform credentialed audits of Windows or Unix servers can obtain a list that shows which specific processes are listening on which ports. Previously, Tenable introduced the ability to enumerate all open ports on a host with a credentialed audit. Now you can also determine the actual names of the processes with plugins 34252 and 25221.
Simple and Comprehensive Auditing
Network security audits are performed to identify vulnerabilities and security issues. Configuration audits attempt to identify issues with particular settings that are required by policy. Both result in very useful information that is invaluable in any type of audit.
However, if you know that a particular system is missing a security patch or has an incorrect configuration setting, how do you know that the system is actually running this software in the first place? For example, a CentOS web server might be missing an Apache RPM and the httpd.conf file can have all sorts of configuration issues, but if it is running a manually compiled Apache binary or even a different web server such as lighttpd, the security and configuration audit conclusions may be misleading.
Backdoor Detection
Intruders commonly replace system programs with custom versions that perform malicious operations and evade detection. These custom versions, referred to as “Trojans”, are often difficult to detect since they seem to behave in the same manner as the original program.
If a Trojan program, virus or other type of malicious software gets installed on one of your computers, it will often communicate with another computer either over the Internet or through the local network. By visually inspecting the actual list of listening software and ports an analyst maybe able to spot the actual malicious program. This can be a very tedious process. Tools such as the Security Center can be used to quickly enumerate the open ports, and browse and search the actual process names. These process names can also be exported as a spread sheet where they can be further analyzed.
Tenable customers that operate the Security Center, Nessus and the Passive Vulnerability Scanner have the ability to view a list of open ports obtained through active and passive scanning. If a system was indeed compromised and modified to “hide” a listening network daemon that communicates with other systems, connections to this daemon can be observed through passive scanning.
Example Reports
Below is a screen shot of an MacOS X NessusClient scan report which has identified the lsass.exe process listening on port 500:
For Windows systems, the services offered by the svchost.exe process are individually identified as well:
And lastly, below is a screen shot of the Security Center that shows a list of ports and process opened on a Security Center system that has not been hardened (telnet is offered through xinetd):
This particular Security Center also has access to a Log Correlation Engine (LCE). If the LCE were configured to collect netflow data, proxy logs or directly sniffed sessions, a Security Center user could identify an open port and process with Nessus and then view and investigate all of the connections to that service. This can help tremendously to identify what the service is and what Internet or local systems it may be communicating with.
For More Information
Please refer to the following Tenable blog posts for more information on this topic:
- Detecting Manually Compiled Network Daemons
- How to perform a full 65,535 UDP and TCP port scan with just 784 packets
- Detecting Microsoft Executables being served by an Unknown Service with Nessus
- Enterprise Software Discovery with Nessus
- Boss, I think half of our FTP servers are fake!
- Detecting Compromised Windows hosts
- Detecting “Off Port” Services
