Recently, I saw a spike in “compliance” violations in the logs of one of the large research deployments of Tenable’s network and log monitoring products. At first glance, a web server appeared to be sharing content that matched our passive adult media data rules. On further analysis, we discovered that this was actually a worm infection. This blog demonstrates many of the techniques to use network analysis to identify the worm’s activity.

Initial Detection on port 25109

The Passive Vulnerability Scanner (PVS) focuses on finding information about hosts on the network by identifying their vulnerabilities. As it sees new traffic, its database of known systems and their vulnerabilities is updated and sent to the Security Center.

Some of the PVS’s rules are set in “real-time” mode and will generate a syslog entry when the PVS encounters events such as new vulnerabilities or in this case, compliance violations. In this particular case, the logs were sent to the Log Correlation Engine (LCE) and from February 16th through the 19th, had this type of consistent activity:

This particular research site has many university students and occasionally a student server will get compromised and be used to host movies, music and other types of media that has been infected with viruses.

Looking at the actual passively sniffed vulnerability (shown below) it could be seen that the web server was hosted on port 25109.

Hosting web servers on ports other than 80 or 443 is a common way to share content that might not normally be blocked by a firewall or monitored by security tools.

Activity Profile

Now that we know a host is sharing some sort of pornographic content on port 25109, the next step is to profile the activity. This particular environment has the Tenable Network Monitor which is an LCE agent that sniffs packets on a span port and logs network session information.  Snort is also running with the Emerging Threats signature database.

For the last few days, the overall activity profile for the host in question and port 25109 looked like this (click for a high-res image):

The blue area is the past weekend activity for Saturday and Sunday. I’ve indicated where some backdoor events (these are normalized logs from Snort) as well as the PVS’s indication of a new open port occurrence.

We could conclude that sometime on Monday, a compromise took place and then port 25109 was opened as a new service. Once the service is open, many different hosts on the Internet started to connect to it and, at the time of the screen shot, the activity still seemed to be ongoing.

All of the above traffic was related to port 25109. There could be a lot more activity occurring on other ports. Below is the screen shot of the same host’s time period but without the port 25109 filter (click for a full screen shot):

There was a little bit of activity before the initial compromise, but most of the continuous activity and constant communications occurred from Monday onward. There were a few more “never before seen” events on ports other than 25109 as well. These events indicated that the IP address in question had never been attacked like this in the past.

Traffic Analysis

How can we pull apart all of these logs and get a sense of what is occurring? Let’s start by comparing inbound versus outbound traffic.

The Security Center has a tool that can graph all matching events over time based on their direction. In the case of our worm outbreak, the following graph was shown:

There is slightly more inbound traffic than outbound traffic. The traffic loads are also linked. If you look at the spikes and valleys, they correspond almost identically. This means that whenever this host increased its inbound traffic, it also increased its outbound traffic.

This could mean that the compromised server was part of a network of nodes that communicated with each other. This is unexpected since typically, when you have a worm or server controlled by a remote “command and control” node, there is much more scanning and probing traffic than actual command traffic. Based on other worms I had looked at under the Security Center and the Log Correlation Engine, I expected to see a huge amount of outbound connections and only a few inbound connections.

What ports are being used here? The Security Center also has a tool to quickly sort this information and perform a port summary. Below is an example screen shot:

That was my second surprise in this analysis. I was expecting to see a lot of outbound port 445 sessions. Port 445 is a port used by the Conficker worm to infect Windows servers that are still vulnerable to MS08-67.

However, in this case we saw traffic from port 444. Port 444 is commonly known as the Simple Network Paging Protocol (SNPP) service. Sniffing port 444 traffic showed it to be nothing like the paging protocol. Instead, when we graphed out the port 444 activity over the same time period for this infected host, we saw the following:

Reading this from left to right, we can see that the PVS identified new Internet activity for this host on port 444. This was the first time the IP address in question had browsed on port 444. After that, there was a wide variety of almost continuous network sessions of various lengths and bandwidth. The largest percentage of logged connections was “TNM-TCP_Session_Timedout” events. These events indicate TCP sessions that started but didn’t complete. These logs show that our host was involved with almost 60,000 attempted connections over a two day period that did not complete.

Port 25 (SMTP) was also on the list of ports (shown below). This had a similar profile of activity starting shortly after being compromised on Monday. Sniffing this traffic showed that the host was repeatedly sending rejected email and was likely being used to send SPAM.

Although this is conjecture, you can see an initial spike of TCP sessions that taper off within a day. It’s very possible that the content of the SPAM message was fingerprinted by anti-spam vendors and the email messaging attempts were immediately denied.

I thought it would be interesting to compare the amount of traffic and destination for both port 25 and port 25109. The Security Center has a tool that will use the source and destination Class A IP address of each matching event and generate a graph. This is an easy way to see where and how much traffic is occurring. Below are two screen shots for port 25 and port 25091:

Port 25	Port 25109

The X and Y axes are not shown (which would give away our general location). What can we conclude from these graphs? The large circles indicate that there have been more events on port 25109 than on port 25. In addition, port 25 traffic seems to be limited to just a few class A address spaces and not as many as the ones used by port 25109. The large grey circle in the port 25 graph could indicate a Class A address space that was targeted or was particularly successful at sending spam email.

The Compromise

What do the compromise IDS events look like? Consider these sanitized logs:

<158>snort[11035]: [1:2001099:6] ET EXPLOIT Attempt to execute VBScript code [Classification: Misc Attack] [Priority: 2]: {TCP} xxx.yyy.135.66:80 -> aaa.bbb.72.123:1822

<158>snort[11035]: [1:2008803:1] ET CURRENT_EVENTS Possible Downaup/Conficker-A Infection Checking Geographical Location [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} aaa.bbb.72.123:4477 -> xxx.yyy.69.70:80

<158>snort[11035]: [1:2008335:3] ET TROJAN Beizhu/Womble/Vipdataend Controller Keepalive [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} xxx.yyy.121.146:15648 -> aaa.bbb.72.123:25109

<158>snort[11035[1:2001689:6] ET WORM Potential MySQL bot scanning for SQL server [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} aaa.bbb.72.123:1151 -> xxx.yyy.59.186:3306

What we have here is a set of exploit steps. VB Script is downloaded, a potential geo-location attempt is launched by a worm and then we have some potential Trojan and scanning activity. The first two alerts occurred within a minute or so of each other. The other scanning alerts started about an hour later.

End Game

Although fun to watch, the worm had to go. After making the appropriate contacts, the host was turned off as shown below (click for hi-res):

It is easy to see the complete drop off in activity across all log sources. The two spikes of lone “SnortET-Trojan_Activity” events were UDP based worm probes from external hosts.

For More Information

If this type of analysis is of interest to you, you may want to review all of the blog entries in our “Event Analysis Training” category. There are many example articles including working with blacklisted IP addresses and an example Windows NT 4 system being infected. There are also many example demo videos of using Tenable solutions to look at anomalies, network traffic and intrusion detection logs. If you are interested in learning more about the Security Center or Log Correlation Engine, please contact us at sales@tenablesecurity.com.

I need to preface this with a disclaimer: I am not criticizing SANS for carrying the article. It's instructive, and that's always useful. I wish, however, that technology journalists were a bit more skeptical or clueful - and - as they say, "that's our story."

The article:

Reports of Cyber Incidents on the Rise
(February 17, 2009)
The number of cyber security incidents at federal civilian agencies reported to the US Department of Homeland Security's US-CERT has tripled since 2006. In fiscal 2008, 18,050 incidents were reported, compared with 12,986 in fiscal 2007 and 5,144 in fiscal 2006.
Agencies are required to report cyber security incidents under the Federal Information Security Management Act (FISMA); such incidents include unauthorized access, denial of service, malicious code, improper use, scans, probes and attempted unauthorized access. The significant increase over the last several years can be attributed to both an increase in malware and a heightened awareness of and ability to detect incidents.
http://fcw.com/Articles/2009/02/17/CERT-cyber-incidents.aspx
http://www.usatoday.com/news/washington/2009-02-16-cyber-attacks_N.htm

And

Small Businesses Want Centralized Cyber Incident Reporting Organization
(February 19, 2009)
A report from the Federation of Small Businesses says that 54 percent of small businesses have experienced fraud or cyber crime over the last year. Although more than one-third of respondents do not report the incidents to police or to banks because they believe it would not make a difference, 53 percent of those surveyed would like specific information about how and where to report the incidents. Eighty-five percent of respondents said that they would make use of organizations established specifically to gather the information and use it to combat fraud. The average annual cost of cyber crime and fraud to small businesses in the UK is GBP 800 (US $1,140).
http://www.scmagazineuk.com/Small-businesses-hit-by-cybercrime-do-not-intend-to-report-it/article/127576/
http://www.theregister.co.uk/2009/02/19/cybercrime_small_business_survey/

Let's start with the second article first, because it's less interesting. The headline should have said "UK small businesses" but that's a minor detail. Does this set off your stealth marketing alarm? It pegged the needle on mine; so I'd like to make a prediction: someone is out beating the bushes, right now, to start up that reporting center. Let's see if I'm right and, within the next year, someone announces that they're either member-funded (in which case they will quickly vanish) or government-funded and are offering that capability. Those of you who've been around information security since the early 1990's will remember the spectacular rise and fall of break-in reporting in the US, with attrition.org, CERT, and CSI/FBI publishing various statistics that meant - uh - various things. Usually, what they meant, to me, was "security reporting is a hard problem."   ... And that's the topic of the first article.

I often tell Nessus users that patch auditing is more efficient and accurate than network scanning. And for the most part, this is absolutely true. However, there are several cases when patch auditing, or a lack of understanding of how patch auditing works, can actually give you bad data. This blog will describe the many subtle nuances to conducting patch audits.

Where do patches come from?

When I have the opportunity to interview potential new employees for Tenable, I often ask many questions about the differences between un-credentialed network scanning and credentialed patch auditing. I’m usually looking for a good grasp on the vulnerability disclosure process as well as operating system internals. A typical exchange goes like this:

Of course this is obvious, but it's not something people say right away. Having a patch to test against in the first place is the ultimate point in performing a patch audit. I’ve found a lot of people who understand this basic concept, but don’t apply it to their auditing process or overall security assessments.

End Of Life = No More Patches!!!

At Tenable, we often get requests to write a “patch audit” on a security issue for a platform that no longer has new patches available. Companies such as Apple (OS X), Novell (SuSE) and RedHat stop producing patches for older releases of certain operating systems and declare them “End Of Life” (EOL). This creates a situation where an OS is indeed vulnerable to  security issues, yet no patch will be available for it.

This can manifest itself in many different ways. If you had a vulnerability that was recently disclosed for an application such as Secure Shell or the Apache web server, you will likely be able to determine this vulnerability from an un-credentialed network scan. However, when you perform the patch audit on the same system, you don’t find any missing patches because there aren’t any available to address this problem. If you were only performing patch auditing in this situation, you might not ever know you had vulnerabilities!

Tenable’s research group has produced a Nessus check for older versions of Windows operating systems that are no longer supported as well as one (plugin #33850) that checks for a wide variety of
Unix OS that are no longer supported.

The Patch is Not Applied

If you work with a large enough sampling of computers, you will run into situations where patches seem to have been applied, but in actuality they are not. There are lots of reasons for this. We’ve blogged about this in the past. Lack of disk space, buggy patches, too much security preventing the patch form installing, loss of power during patch application, incorrect backup methods, systems not being rebooted and many other reasons can contribute to a patch that seemed to get installed, but did not complete.

On Windows computers this really become evident if you compare what has been recorded in the registry and what files are actually on the disk. Most software installations will mark some sort of setting in the Windows registry during installation. If this occurs before the installation is fully complete, and the patch fails, you will have a situation where a patch looks like it has installed when reading the registry, but it really hasn’t.

With Nessus, all Windows patch audits look at the file system directly to read exactly what has been installed on the computer. This sometimes puts Tenable in a defensive position when we have a Nessus user claim that they are receiving a false positive for a patch audit when “they know” the patch has been applied.

In product evaluations, this functionality can also show through. We once had an evaluation where
Nessus was the only product that “missed” a patch. All other scanning vendors “correctly” identified the patch being applied. That was until the system in question was successfully penetration tested with Core Impact. At that point they found there had been an error delivering the patch and the other scanning vendors were in fact “incorrect”.

A common reason that patches have not been fully applied on Windows systems is that the system requires a reboot. Tenable’s research group recently added a check (plugin #35453) in Nessus that checks if the Windows computer is in a state that requires a reboot.

Only doing an OS Patch Audit

Consider this conversation ….

Conversations like this likely occur each day in many different IT organizations. When someone says they have applied “all of the patches” do they include:

• Third party browsers and email clients like Opera, Thunderbird and Mozilla?
• Software updates for your Anti Virus and Anti Malware agents?
• Library updates for Java, Quicktime and Flash?
• Software updates for your network management agent from CA, Tivoli or HP?
• Firmware security updates for your wireless card, network card, motherboard or CPU?
• Popular desktop applications such as iTunes, Blackberry and Skype?
• Non-critical / non-security patches from Microsoft that fix reliability issues and other bugs?

The list could go on. The point is that if you audit a Windows computer for Microsoft patches you will likely miss a lot of software that is installed and potentially vulnerable. The same is true for OS X, Solaris, Red Hat Linux, etc, etc.

At Tenable, we try to help detect as many of these issues as possible. Users who perform full credentialed scans with Nessus on Windows and other systems usually see all of the missing Flash, iTunes, Java and other “third party” security issues that don't come directly from the operating system vendor. If these products have listening network ports, we also make an effort to scan for these issues from the network, so that you don’t have to rely on credentials. Some anti-virus agents and applications such as Skype and iTunes fall into this category.

What about manually compiled services?

Last, if you are in an IT environment where you are auditing patches and not systems, you can run the risk of missing manually-compiled software installations.

Consider a scenario where you are working with a flavor of Unix where the choice has been made to design a service offering based on a hand-compiled distribution of a server such as Apache, MySQL, Sendmail, .etc. This can create a situation where you have two versions of an application installed except that one application was compiled by your IT staff and the other came with your operating system distribution.

We’ve blogged about this situation before. Nessus credentialed checks (plugin #33851) have the ability to audit all running processes against the list of installed packages and see if there is a difference that may indicate that a manually-compiled service is running.

The core issue is one of false confidence. If you have an audit technology that looks at Linux RPMs or some other type of Unix packaging for system updates, it does not know to look in other non-standard places and won’t report on your manually-compiled services. This can provide you a false sense of security.

This problem is stereotypically one concerning Unix networks, but I’ve seen people run into this problem running Apache and MySQL, built from source and on Windows platforms as well.

For more Information

We’ve blogged several times in the past few years on the topic of performing patch and security auditing for networks. The following previous blog posts touch on similar issues:

• Testing the Effectiveness of your Patch Auditing System
• Knowing When to Patch (a.k.a. don’t let your vulnerability scanner dictate your patch policy!)
• How did you test for MS08-067? (compares credentialed and un-credentialed methods)
• “But I patched our DNS servers …” (when network issues trump system patches)

If you are new to network scanning, Tenable has many free videos to watch that that show how easy it is to perform comprehensive Windows and Unix audits with Nessus. We also offer many free white papers that show how different types of network auditing can be unified for easy enterprise security and compliance monitoring.

Tenable staff had a great time at Schoocon this year and picked up some interesting data in the process. As we did in 2008 [http://blog.tenablesecurity.com/2008/02/shmoocon---dont.html] we ran our Security Center, Passive Vulnerability Scanner and Log Correlation Engine on the production Shmoocon 2009 network. This blog entry discusses the type of data that was obtained and also shows many different examples of log analysis and passive traffic analysis.

Initial Passive Vulnerability and Application Detection

Conference attendees stopped by the Tenable Shmoocon booth to play some poker and ask about our findings on the Shmoocon network. We found that there were not a lot of services being offered on the network. Most of the traffic we were profiling came from the attendees themselves. Having said that, the PVS was able to sniff the following vulnerabilities and services:

Since the PVS is usually deployed on the network perimeter, it flags any detected SQL databases as a potentially high severity level. Overall, nothing too startling was detected. 

The above screen shot was a sort based on severity level. Sometimes on a network like Shmoocon, the basic application data can be more interesting as shown below: 

Notice PVS vulnerability ID 3930 which identifies a Qualys vulnerability scanner appliance. The PVS includes rules to passively identify a variety of security tools such as Metasploit to see if they are installed on your network.

Another interesting set of data collected by the PVS was a profile all of the SSH daemons observed on the network. This table shows the type of SSH banners that PVS was able to observe on both the production network and the attendee traffic:

Obviously, Ubuntu seems to be the choice of OS for many of the attendees.

Profiling Interactive and Encrypted TCP Sessions

A neat feature of the PVS is to identify any server that hosts an interactive or encrypted TCP service. This automatically picks up on traffic such as Telnet sessions and SSL web services. Many backdoors and rootkit applications try to obscure network sessions by using non-standard ports and custom protocols. For example, consider the following “full detail” vulnerabilities detected by the PVS for hosts that had encrypted sessions:

172.16.10.18 -> 10.10.0.10:80|PVS detected a port used for one or more internal encrypted sessions. The data in this session had a high degree of randomness. Most likely, this is normal legitimate network traffic, but a variety of backdoors and compromised tools will also utilize encryption

172.16.10.20 -> 172.16.10.254:4343|PVS detected a port used for one or more internal encrypted sessions. The data in this session had a high degree of randomness. Most likely, this is normal legitimate network traffic, but a variety of backdoors and compromised tools will also utilize encryption

PVS detects encryption by testing for a sufficient amount of randomness in the data traffic. This technique also identifies compressed traffic on some protocols. For example, in the above screen shot, the host 172.16.10.18 has had at least one encrypted session with 10.10.0.10 on port 80. This is likely a web server offering content which has been compressed.

What is more interesting is port 4343 on 172.16.10.254. The PVS identified this traffic as some sort of TLSv1 traffic. This is likely a high-port SSL server of some sort as shown below:

Looking at each one of these ports one at a time can get tedious, so we used the Security Center to summarize all of the ports that were discovered which hosted some sort of encrypted session. This is shown below:

As the above screen shows,  there were hits on some interesting ports such as 9099 and 4343 and a few hits on some other ports.

If we wanted to, we could analyze this data further by considering each unique host, all of their sniffed application data and use the LCE to see how much traffic was passed over these ports.

As previously noted, the PVS can also sniff TCP sessions to look for interactive sessions. By “interactive” we mean that the latency between packets is likely to indicate that a human is typing away at the keyboard.

Below is an example PVS data record from the Shmoocon network:

172.16.10.226 -> 172.16.17.13:23|PVS has detected a port used for one or more internal interactive sessions: there were a large number of small packets relative to the number of packets in the session and the timing characteristics of the packets match user keystroke frequencies

172.16.12.123 -> 172.16.12.2:3050|PVS has detected a port used for one or more internal interactive sessions: there were a large number of small packets relative to the number of packets in the session and the timing characteristics of the packets match user keystroke frequencies

The first record is very straight forward. The PVS has detected an interactive shell on port 23. However, the second host has an interactive shell on port 3050.  If we wanted to investigate this further we could consider what other ports and applications were detected on host 172.16.12.123 or look at the realtime network and log activity collected by the LCE.

Realtime Log and Event Analysis

For the conference duration, the overall log profile can be summed up with this screen shot (click for a full screen):

Every system log, firewall record, network flow and other data gets normalized into a high-level type. These types are showed in the “Type” column above and have names such as “connection”, “firewall” and “router”.  

For example, one of the types is “errors”. Drilling into this type in the Security Center shows us this set of data:

In this screen shot, none of the errors seem too extreme. The FreeBSD syslog crash might be worth investigating, but the other logs seem fairly innocuous.

Let’s consider the firewall logs:

In this case, the firewall in use was a Cisco ASA firewall. It was configured to log “deny” events. Using the Security Center to summarize all of these logs by port displays the following data:

The main ports being denied were 80 and 443.

The LCE was also able to obtain Cisco logs for the routes and switches. Consider the following events from the “router” type:

There was an early spike of “Cisco-Configured_From_Console” events towards the beginning of the conference, but then only a few odd port up/down events that were balanced.

Any of the logs obtained by the LCE are fully searchable. For example, here is a list of “sudo” log events that are part of the “login” type:

Conclusion

Overall, these logs and traces were very typical of a security conference. A lot of the servers were not directly accessible to conference attendees, so there was not much suspicious activity to analyze.

We appreciate being able to gather logs and traffic on a live network. During the show, we were able to show various attendees about different aspects of log analysis and passive network monitoring.
If this sort of analysis was interesting, the following previous blog entries discuss similar types of data:

• Shmoocon 2008 Network Monitoring Notes
• There are many different posts in this blog's Event Analysis Training section

The article:

 Number of Banks Affected By Heartland Breach: 160 and Growing
(February 6 & 12, 2009)
According to the Bank Information Security website, nearly 160
financial institutions have acknowledged that they were affected by
the Heartland Payment Systems data security breach. Banks in 40 US
states as well as in Canada, Bermuda and Guam have reported that
some of their customers' cards were exposed. It is not known how
many card accounts were compromised; Heartland says it processes 100
million transactions a month.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9127822&source=rss_topic17
http://www.bermudasun.bm/main.asp?SectionID=24&SubSectionID=270&ArticleID=40389&TM=28150.45
http://www.theregister.co.uk/2009/02/12/heartland_data_breach_latest/
http://www.bankinfosecurity.com/articles.php?art_id=1200&opg=1

One of the underlying realities of computer security is the problem of transitive trust.

(Note: This Blog was originally released in 2007 and was updated in March of 2009 to reflect an additional form of OS detection based on HTTP banners.)

Tenable's Research group recently introduced a highly accurate form of operating system identification. This new method combines input from various other plugins that perform separate techniques to guess or identify a remote operating system. This blog entry describes this new process and shows some example results .

Why a new process?

Two reasons.

First, although we feel that TCP/IP fingerprinting to guess a remote network stack is useful, there are too many variables and limitations involved to be considered 100% reliable. TCP/IP fingerprinting techniques send specially crafted packets which trigger a different reaction from one OS to another. These different reactions are used to identify if the host is Windows, Linux, Cisco IOS and so on. Many variables on the network and on the host can influence how a stack behaves and cause unmatched or inaccurate guesses as to what exactly the remote OS actually is. And even when TCP/IP stack fingerprinting works 100%, it often can only guess the remote kernel, but not the specific Linux, Windows or other types of distributions. 

Second, many Nessus users perform full credentialed scans and in-depth analysis of various applications.  While logged into a UNIX or Windows system, or performing certain types of application queries, it is trivial to accurately determine the remote operating system. This information was previously reported, but contained in the results of many separate plugins. This type of information is extremely accurate compared to TCP/IP fingerprinting techniques. For example, Mac OS X systems can be accurately identified through their network time protocol (ntp) daemon without credentials. Running commands like "uname" on UNIX or looking up certain registry settings for Windows can yield highly accurate results.

This new process elegantly combines the best of each of these approaches, plus adds many new techniques which contribute to Nessus's guess of what a remote operating system really is.

How the new process works

Plugin #11936 (OS Identification) is still the main ID Nessus users should use to perform OS enumeration of their scanned systems. Prior to the recent change, this NASL script performed TCP/IP fingerprinting of OS stacks and also targeted a few Windows and Mac OS X protocols to increase the accuracy of the reported OS. The new process now takes input from the following other NASL scripts, which each reports their own OS guessing:

• os_fingerprint_ftp.nasl Uses the remote FTP banner to attempt to identify the underlying operating system. (Note, this functionality was added in Feb 2009)
• os_fingerprint_html.nasl Uses the HTML content returned by certain HTTP requests to fingerprint the remote OS. (note, this functionality was add in Feb 2009)
• os_fingerprint_http.nasl Uses the remote web server signature to infer the version of Windows or the Linux distribution running on the remote host.
• os_fingerprint_mdns.nasl If an mDNS server is present, will perform a highly accurate identification of Apple OS X systems.
• os_fingerprint_msrprc.nasl Identifies the remote version and service pack of Windows by making certain MSRPC requests against the remote Windows box.
• os_fingerprint_ntp.nasl Queries the Network Time Protocol daemon to perform a highly accurate OS guess.
• os_fingerprint_sinfp.nasl Implements the SinFP TCP/IP fingerprinting algorithm. Only requires one open port to fingerprint an OS.  (Note this script does not work on Nessus 2.)
• os_fingerprint_smb.nasl Identifies the remote Windows OS based on a query to SMB.
• os_fingerprint_snmp.nasl If credentials are available to perform an SNMP query, data from the 'sysDesc' parameter is reported.
• os_fingerprint_ssh.nasl Attempts to identify the remote OS by the SSH banner.
• os_fingerprint_telnet.nasl Attempts to identify the remote OS by the Telnet banner.
• os_fingerprint_uname.nasl If SSH credentials of the remote UNIX hosts is provided, the results of 'uname -a' are obtained.
• os_fingerprint_linux_distro.nasl If SSH credentials of the remote Linux host is provided, the  specific release will be obtained.
• os_fingerprint_xprobe.nasl This script attempts to identify the OS type and version by sending more or less incorrect ICMP requests using the techniques outlined in Ofir Arkin's paper 'ICMP Usage In Scanning'.

More OS fingerprinting modules will  be added in the future.

Each of these plugins will report a confidence level for their scan results. For example, "real" OS detects through direct interaction with the operating system such as SNMP probes, running the 'uname' command or performing certain types of Windows registry queries all have a 100% confidence level. Other types of queries such as performing TCP or ICMP fingerprints, or trying to fingerprint an application, have been labeled with a value less than 100%.  The result with the highest confidence level is used to guess the remote operating system.

Nessus users should either enable dependencies while scanning (which is the default value) or manually select which of these new plugins (available in the "General" plugin family)  they wish to be launched. 

New Fingerprints

Several of the plugins will report 'unknown' fingerprints for devices that do not have an existing match. Please email these signatures to os-signatures@nessus.org to be incorporated into future plugin updates.

All Nessus users benefit from these plugin submissions. The more fingerprints that are submitted, the more accurate future Nessus scans will be.

Evasion

No discussion of accurate remote OS identification is complete without understanding how this process can be evaded.

Several years ago, it was considered that TCP/IP stack fingerprinting was the most reliable method of OS identification because application banners could be easily modified. It is fairly trivial to make an Apache web server look like it is an IIS web server or place an Exchange email banner on your Postfix mail server.

Today though, with the presence of technologies like /proc on Linux, sysctl on FreeBSD or the registry on Windows, modifying how your network stack behaves is also very easy.

The bottom line is that if someone wants to be fingerprinted like a different type of operating system, they can configure their system like this. By using many different application and fingerprint methods, and then weighting the results, Nessus will always be able to report something that can be used for auditing.

Example Scan Output

Here is some example text OS IDs from a Nessus 3 scan that included credentials for some systems:

The remote host is running Linux Kernel 2.4
Confidence Level : 70
Method : SinFP

The remote host is running Linux Kernel 2.6.9-5.EL
Confidence Level : 100
Method : uname

The remote host is running Microsoft Windows Server 2003, Enterprise Edition (English)
Confidence Level : 100
Method : SMB

The remote host is running Microsoft Windows XP Service Pack 2
Confidence Level : 99
Method : MSRPC

The remote host is running Linux Kernel 2.6
Confidence Level : 60
Method : ICMP

The remote host is running Mac OS X 10.4.9 (intel)
Confidence Level : 100
Method : NTP

Notice that many of these "confidence levels are 100%. This is because the UNIX check used the 'uname' command and the Windows host had port 445 open. Both of these checks are 100% accurate and there is no room for interpretation.

Plugin Availability and Updates

This new type of detection is available to all Nessus users who have updated their plugins recently with either the Professional or Home Feeds. Security Center users also benefit from the accuracy of these updated methods. The ability to accurately classify an OS is vital for automatic asset discovery and classification.

Tenable sponsored a booth at this year's ShmooCon and ran a Texas Hold'em table to help raise money for the Hackers for Charity organization. We raised close to $400 from conference attendees and scheduled "guest" players such as Paul Asadoorian from PaulDot.Com, Simple Nomad from NMRC, Jericho from Attrition, Chris Hoff and many others.

Playing poker with self proclaimed hackers, security experts, CIOs, CSOs, and students was very enlightening. There was at least one joke about "risk management" each hour. A lot of players liked the chance to get to sit down with some of the other attendees and speakers that have been around for a while.

Not surprisingly, although there were plenty of people playing and donating, there were not a lot of people who wanted to be photographed playing poker when they should have been in the presentations learning about security. Here is a sanitized photograph of the event at one point when we were down to just two players:

Thanks again to everyone that came by the booth, played some poker, asked about Nessus and complained about FDCC or PCI.

The article:

 --German Magazine Says Armed Forces Establishing Cyber Warfare unit
(February 9, 2009)
German magazine Der Spiegel Reports that the country's armed forces are
in the process of establishing a unit dedicated to cyber warfare. The
unit will take on responsibility for protecting German IT infrastructure
from attacks as well as conduct reconnaissance and interventions on
foreign and "enemy" computer networks.
http://www.heise-online.co.uk/news/Report-claims-German-armed-forces-setting-up-cyberwar-unit--/112595

I'm sure there are lots of countries setting up "cyberwar" units. Why? Because they're so very, very l33t!

(This column is one of what I am going to call "afterbites" - extended random commentary on topics raised in SANS' Newsbites column. As some of you know, I am one of the volunteer editors/commenters on the weekly Newsbites and it probably won't surprise you to discover that sometimes the discussions we have on the editors' mailing list can get - interesting. Usually, there's not enough space to rant at length, so I'm going to periodically fire unaimed salvoes from the safety of my blog, here.)

The story:

Parking Tickets as Cyber Attack Social Engineering Vector
(February 4 & 5, 2009)

Cyber criminals in Grand Forks, North Dakota planted phony parking
violation notices on cars. The notices direct the users to a website
for more information, which leads the users through a set of links
that downloads malware onto their computers. That malware then urges
users to download an anti-virus scanner that is worthless.
http://www.techweb.com/article/showArticle?articleID=213200005&section=News
http://news.bbc.co.uk/2/hi/technology/7872299.stm
http://isc.sans.org/diary.html?storyid=5797

A few years ago, I was sitting in a hotel bar at a security conference, matching my tequila-drinking skills against all comers, when we got to discussing the next generations of identity theft attacks. One of the ideas I suggested was related to what we see above, and I'm really unhappy to see that The Bad Guys are showing no sign of stopping their creative engines.

Recently, Tenable added the ability for Nessus ProfessionalFeed users to establish a session with database servers and audit their configurations. Our first major audit policy that utilizes this technology performs a database audit against settings specified in the DISA STIG guide for Microsoft SQL servers. This blog entry discusses the new SQL auditing functionality and how to perform the DISA STIG audit with Nessus.

Why Audit SQL Database Configurations?

SQL databases are widely used to drive web applications, track credit card information, host Personal Identification Information (PII) and store many other types of sensitive data. Previously, Nessus enabled vulnerability, patch and configuration auditing of the operating system that the SQL database was deployed on, but not the actual configuration of the database itself.

With the new SQL auditing functions, Nessus can look “inside” a database to see what sort of internal configuration settings have been put in place. This can help ensure that your database is operating with least privileges and has disabled functionality that is not needed and could be exploited by a hacker.

When analyzing the security of a database server, being able to combine the vulnerability and patch information along with the operating system and database configurations makes it easy to understand where any potential exploit or abuse could come from.

Supported Databases and Audits

The new technology supports SQL audits of these database types:

• DB2
• Informix
• Oracle
• Microsoft SQL
• MySQL
• PostgreSQL

Additionally, Tenable has produced two audit policies to be used against Microsoft SQL servers.
The first implements many of the requirements specified by the Center for Internet Security’s benchmark guide for SQL Server 2005. This guide actually recommends specific Windows 2003 operating system settings as well as SQL Server audits. Tenable has produced two audit policies for Nessus – one to audit the Windows 2003 server settings and another to connect via SQL and audit the actual database settings. The SQL audit policy tests more than 40 different SQL settings. For example, here is a fragment of the CIS audit policy which tests for CIS section 3.12.19 which recommends that the stored procedure “xp_subdirs” should be disabled:

<custom_item>
type        : SQL_POLICY
description : "3.12.19 Check if the stored procedure
               xp_subdirs is disabled"
info        : "Checking that extended stored procedure:
               'xp_subdirs' either does not exist or is
               disabled."
sql_request : "select name, value_in_use from
               sys.configurations where name =
               'xp_subdirs' and value_in_use = 1"
sql_types   : POLICY_VARCHAR
sql_expect  : NULL
</custom_item>

The second audit policy comes from the Defense Information Systems Agency (DISA). DISA maintains a set of hardening and configuration guides known as checklists for a wide variety of technologies. We were very impressed with the depth of recommended SQL settings and content concerning specific regulations. There are more than 100 specific SQL items recommended and required by this guide. Below is an example audit that tests to ensure that a certain account is disabled when not needed:

<custom_item>
type           : SQL_POLICY
description    : "3.154    DM0630: Application object owner
                  account disabling"
info           : "Object ownership provides all database object
                  permissions to the owned object. Access to the
                  application object owner accounts requires
                  special protection to prevent unauthorized access and
                  use of the object ownership privileges. In addition to
                  the high privileges to application objects assigned
                  to this account, it is also an account that, by
                  definition, is not accessed interactively except for
                  application installation and maintenance.  This reduced
                  access to the account means that unauthorized access to
                  the account could go undetected.  To help protect the
                  account, it should be disabled only when access is
                  required."
info           : "ref. DB SRRChklst SQLServer2005 V8r1-1.doc, 3-175."
info           : "Database STIG 3.3.11.3"
info           : "STIG Requirement:(DG0004: CAT II) The DBA will ensure
                  custom application owner accounts are disabled or locked
                  when not in use."
info           : "Checking whether any custom application owner accounts
                  are enabled for master database."
sql_request    : "use master;select suser_sname(p.sid) from
                  sys.database_principals p, sys.server_principals s where
                  p.principal_id in (select distinct schema_id from
                  sys.objects where is_ms_shipped=0) and p.sid = s.sid and
                  s.is_disabled=0 and p.type not in ('A','R')"
sql_types      : POLICY_VARCHAR
sql_expect     : NULL
</custom_item>

Performing a Database Audit

In order to make use of the SQL audits with Nessus, you need the following items:

1. A Nessus scanner subscribed to the ProfessionalFeed
2. An audit file, specifically written to make use of the SQL checks
3. Network connectivity to your database (it can’t be blocked by a firewall)
4. An account to log into the database with

With this information, you can follow the steps below to perform an audit:

1. In NessusClient, create a new scan policy and edit it.
2. Under the “Plugin Selection” tab, make sure to enable the “Database Compliance Checks” plugin.
3. Under the “Advanced” tab, select the “Database Compliance Checks” form and then use one or more “Select…” buttons to specify a SQL .audit file from your local system.
4. Lastly, also under the “Advanced” tab, select the “Database settings” form and specify your database technology and credentials.

The DISA and CIS audit guides also recommended many specific Windows 2003 server settings. Tenable has also written audit polices to reflect those settings as well. When you are configuring your scan, be sure to add the Windows compliance audit polices under the "Windows Compliance Checks" tab and the database policy under the "Database Compliance Checks" tab. Both audit policies can be applied against a server at the same time.

Below are some screen shots of these new features shown within NessusClient, as well as some example results:

 
Selecting the Database Compliance Checks Plugin

 
Example Scan Results for a DISA MS SQL Audit

More extensive documentation of how to perform this type of scan discussed in the Nessus documentation. ProfessionalFeed subscribers can also learn more about writing your own SQL audits in the “Nessus Compliance Checks” document found on the Tenable Support Portal.

(This column commences what I am going to call "afterbites" - extended random commentary on topics raised in SANS' Newsbites column. As some of you know, I am one of the volunteer editors/commenters on the weekly Newsbites and it probably won't surprise you to discover that sometimes the discussions we have on the editors' mailing list can get - interesting. Usually, there's not enough space, nor would it be appropriate for the editors to engage in hand-to-hand combat, so I'm going to periodically fire unaimed salvoes from the safety of my blog, here.)

The story:

 --London Hospitals' Worm Infection "Entirely Avoidable"
(February 2, 2009)
A review of the worm infection that affected three London hospitals last
November found that the incident was "entirely avoidable." The Mytob
worm infected 4,700 PCs at St. Bartholomew's, the Royal London Hospital
in Whitechapel and The London Chest Hospital; as a result, some
ambulances were rerouted and some recordkeeping had to be done with pen
and paper. While administrative systems were running again within three
days, it took two additional weeks to scan all the machines to ensure
they were clear of infection. The review determined that the initial
infection resulted from misconfigured anti-virus software and spread so
widely due to a decision by administrators to disable security updates
because they had caused some computers to reboot while surgery was
underway.
http://www.theregister.co.uk/2009/02/02/nhs_worm_infection_aftermath

There is so much wrong with this picture, that it's hard to know for sure where to start. "Ambulences rerouted" could be extremely unpleasant if you were, say, waiting patiently for help after a car crash, or something. "Recordkeeping with pen and paper" is, perhaps, a useful survival drill. The part that makes my blood run cold is "caused some computers to reboot while surgery was underway." I know that if I were a patient and heard the distinctive "cdrom-whirr, beep" of a computer rebooting, I would leap off the table and make a bloody trail toward the taxi stand, if I had working legs.