Historically, active vulnerability scanning of network printers and older Novell NetWare servers could be problematic. Sometimes a simple port scan with any type of auditing tool would cause a network printer to print paper, crash or interrupt real print jobs. Similarly, older Novell NetWare installs were also subject to crashing when having their servers fingerprinted.

Based on the feedback from the Nessus user community, Tenable implemented two scan options for Nessus that can limit how network audits interact with these technologies. These scan options are labeled:

• Scan Network Printers
• Scan Novell NetWare hosts

A screen shot of these scan options as found under the Nessus Client  is shown below:

By default, Nessus won't scan these devices if they are found. When a printer is found, the fact that it won't be scanned is reported. This can cause some confusion for new Nessus users that are running a scan of just a few plugins on a large network. Even though they haven't specifically enabled the plugins to avoid printers and NetWare servers, if one is found it will be reported.

This occurred with one Nessus user I was working with. He was scanning a class B network for just one Nessus plugin, but kept getting plugin #12241 showing up in his results, even though he was not scanning for it and there were no plugin dependency issues. When the user enabled these settings, he no longer got the report that he may have been scanning a printer.

The trade-off of not scanning these types of devices and perhaps limiting the scope of a scan can be a difficult call to make for a new Nessus user of the first time a target network is audited. My recommendation is to first scan with these options enabled so that you can identify potential targets that could be impacted with a full scan. Later on if you are scanning for services or plugins that are likely to not interact with NetWare or network printers, you can make a more educated decision of when to turn these options on or off.

For completely passive and real time network monitoring, the Passive Vulnerabiltiy Scanner has the ability to identify a wide range of vulnerabilities purely from montioring traffic in real time. This solution can solve a variety of political problems, such as end of year IT freezes, where different business users or organizations do not want to submit themselves to active scans.

We've also blogged before about how to limit the scope of Nessus scans:

• Limiting the ports probed by Nessus
• Understanding the Nessus "safe checks" option
• Using Nessus to scan hosts behind a firewall

Over the past few months, there have been a few vulnerabilities in ActiveX controls from MySpace and FaceBook. Nessus users can audit Windows systems running Internet Explorer with the following plugins:

• #30219 myspace_uploader_1_0_0_6_activex_overflow.nasl
• #30152 facebook_photo_uploader_4_5_57_1_activex_overflows.nasl
• #30134 image_uploader_4_5_70_activex_overflows.nasl

These plugins require credentials for Nessus to log into the Windows computer and analyze which ActiveX controls and versions are available. The plugins are available to all Nessus Direct Feed, Registered Feed and Security Center users. These vulnerabilities are unique because they can affect a Windows system that has had its Internet Explorer and Windows operating system fully patched.

If you'd like to know which computers and users on your network are visiting MySpace or FaceBook, this type of monitoring is performed by both the Passive Vulnerabiltiy Scanner and the Log Correlation Engine. The PVS will identify which hosts log into MySpace and FaceBook along with the account username. The Log Correlation Engine can take these events from the PVS and use the usernames to associate with a source IP address for tracking of users with mobile IP addresses. This capability was previously discussed here.

For more information about ActiveX controls, please consider the following links:

• http://isc.sans.org/diary.html?storyid=3929
• http://isc.sans.org/diary.html?storyid=3931
• http://blogs.zdnet.com/security/?p=846

Greetings!

In this column, and in subsequent columns, I am going to develop a set of themes about cyber-stuff. We've all heard a great deal of kerfluffle about cyberterror or cyberwar, but - what, really, is it? It turns out that the terms are being bandied about very loosely and are often used interchangeably in ways that are advantageous to the speaker and confusing to the listener.

This series of columns are written based on a set of talks I gave as the keynote for IDC's CEMA Security Roadshow in 2008, with additional material and commentary. I welcome your constructive feedback at mjr@tenablesecurity.com

CyberCrime

Criminal enterprises have been a persistent threat throughout human history. We could almost dispatch the topic of cybercrime with this observation: it will never go away. But, as always, there's more to it than that. Cybercrime has some interesting properties that make it a more significant problem than "normal" crime:

• Automation
• Low infrastructure cost
• Trans-nationality

Firstly, cybercrime invents a whole new form of criminal enterprise. Typically, if a criminal wants to steal $1,000,000 he needs to steal it all from a small number of places. But with cybercrime, you have the potential of automating attacks, so that the criminal might steal $1 from one million people. That changes the dynamics of crime because human institutions have adopted fairly effective controls on large amounts of valuable items - but historically that has been at the expense of worrying less about "petty" crimes. An individual losing $1 will probably shrug it off as unworthy of attention, whereas nobody is going to write off $1,000,000. Because of the loss-levels involved in cybercrime, the burden of paying attention to the crime transfers to society as a whole - no single individual is hurt enough to care, yet it represents a massive drain on an economy. There are a few things that fall out from this: insurance models don't make sense if you're worrying about such small losses, and classical models of having the wronged individual ("plaintiff") carrying a complaint about the criminal no longer make sense. It doesn't make sense to mount a million-member class action suit against a spyware seller.

This all sounds very theoretical, so far, but there are significant issues that societies need to recognize. Namely, that the current mechanisms of justice simply are not tuned to handle cybercrime effectively. We see proof of this in the way that enforcement attempts are currently aimed at highly active criminals. Law enforcement decides "Let's bust this one guy and maybe it'll 'send a message' to the rest." Here's a hint: when law enforcement is only capable of trying to send a message then the situation is out of hand and they are signalling defeat.

It will only get worse

The low infrastructure cost of becoming a cybercriminal makes it extremely attractive. A friend of mine was involved in a case a 6 years ago in which they discovered a group of cybercriminals who had a fairly substantial IT set-up, all stolen goods purchased on Ebay with compromised PayPal accounts. Nowadays, it's not even necessary to have an infrastructure at all; the criminal can take advantage of online service providers, paid with stolen credit cards. An example of this transition is a nigerian bank scam spammer that was caught in London - he was operating entirely from a local cybercafe, commissioning spams through bot-herders, and harvesting his Email through Yahoo! and Hotmail. The criminal owned, literally, no IT infrastructure beyond a USB memory stick on which he kept track of his "customers."

Compare the cost of being a cybercriminal, and combine with it the near-zero likelihood of getting caught, and it's an incredibly attractive enterprise. This is why it will get worse - possibly dramatically - over the next decade. If you're a stick-up artist and you rob a convenience store, you need a gun and a car and you're running the very real risk of catching a bullet. The typical convenience store robbery nets between $1000 and $2000 for the criminal - compare that to the far larger potential profits of cybercrime and the lack of physical risk and I predict that the current state of affairs is just the tip of the iceberg we're going to have to deal with in the next 20 years.

I know that what I am about to say is not "politically correct" but: the current generation of young people, who do not recognize pirating music or videos online as a form of theft, are going to incubate the next generation of cybercriminals - and they will be truly horrible to deal with.

Cybercrime is trans-national; it respects no boundaries. In fact, the smarter criminals take advantage of this already by recognizing that the cost of international prosecution gives them a safe "ground cover" under which they can operate with impunity.

I predict that the trans-national nature of cybercrime is going to have a number of possible outcomes. The most likely short-term outcome is that trans-national money transfer systems will come under pressure. It will become increasingly difficult to use payment tools across national boundaries. In some cases, this is already happening - I attempted to pay for some Ebay winnings with PayPal from my laptop in a cybercafe in Poland and was surprised (and then pleased, once I thought about it) when PayPal blocked the transaction. Online banks and payment systems are going to increase in complexity in order to deal with this, I predict. In fact, it can't happen soon enough! I would dearly love to be able to go to my credit card company's website and tick off the countries I will be travelling to in the next month and "unlock" them for that month - in return for nobody else being able to use my card outside of this country. Similarly, I predict we will see things like being able to indicate that your card should only be used to pay for goods that are shipped to your billing address, etc. Right now, our defensive techniques are lagging dramatically behind the offensive techniques that the criminals are inventing! We need creativity and innovation on the defensive side - not another 3 digit PIN-code added to our credit card number.

Another longer-term outcome of the trans-national nature of cybercrime is that sometime in the next decade or two, we can expect a unified international response to the problem. It seems unlikely, now, but remember that I'm predicting cybercrime will get a whole lot worse, first. Eventually we will have a standard set of trans-national practices for dealing with online criminals. There will be no extradition, there will be a seamless process whereby trans-national crimes are prosecuted evenly based on where the crime was committed from instead of who the crime was committed against. There are a lot of tricky issues to sort out, but if the costs of cybercrime continue to skyrocket, there will be a coordinated response eventually.

The final point I'd like to make on cybercrime is that the current set of problems show us nothing about how bad it can possibly get. The current crop of cybercriminals are the equivalent of pickpockets and smash-and-grab artists. They are moving up the scale of sophistication, but they are, still, not very sophisticated. At a certain point, you move up-scale from the Reservoir Dogs and to professional gangs that are willing to invest the time and energy to infiltrate targets and take advantage of "insider" positions. We've recently seen the kind of damage that a trusted insider can do with the huge losses incurred at France's Societe Generale - nobody is asking themselves whether an insider could appear to make some incompetent trades while actually lining the pockets of a group of co-conspirators. And, if they were, how could we tell? The potential for insider-based high dollar cybercrimes is vast and the perpetrator does not need to be in a conspicuous position of trust to carry them out. A system administrator, or an operator at an outsourcer, has potential insider information on every aspect of a business. It simply takes a little creativity to figure out how to "monetize" the information. The next obvious step from that is to attempt to hire into a position with the specific intent of monetizing a specific data item. Make the right move and sell the correct copy of the right backup tape, and you could retire comfortably by age 25. What scares me is the suspicion that this could already be happening - most of the systems I've seen are woefully under-capable at backtracking and understanding such a crime, let alone detecting it.

Your future

If you're part of an organzation that does business online, cybercrime is going to be part of your personal future, for the forseeable future. How's that for a cheery prediction? Worse, still, your opposition is completely non-ideological and cannot be dissuaded or negotiated with.

Next up, we will take a look at Cyberterror. Cybercrime is the "boring stuff" and now we've gotten it out of the way.

Let's talk soon,
mjr.

In the next few weeks, I will be posting a series of blog entries which provide examples of analyzing logs and events in large enterprise networks. We will be using the Security Center, Nessus, Log Correlation Engine and the Passive Vulnerability Scanner in these examples, but the principals can be applied to most SIMs, NBAD and network IDS Consoles. Today's blog considers working backwards from a few interesting alerts from a Snort sensor running the Emerging Threats signature set.

Emerging Threats

Tenable recently began supporting logs from Snort sensors running rules from the Emerging Threats project in both Security Center and the Log Correlation Engine. The Emerging Threats project classifies Snort events with a variety of names such as "ET EXPLOIT", "ET POLICY" and "ET SCAN". At one of our test sites (a large university) a typical "day" of logs looks as follows:

There are many ways to analyze this data such as summarizing by port, time, business asset and so on. Visualizing certain types of discrete activity is also useful. Below is a graph of all "Class A" address space that has had at least one Emerging Threats "P2P" event:

You can see that this university has a wide variety of P2P activity that communicates with a wide variety of address space.

Attacks and Exploit Attempts

A quick filter that can be used in the Security Center is to match all event names based on a unique string or text. To see all Emerging Threat Exploits, we'd type in "ET E*" into the query tool. All Emerging Threat exploit rules start with the name "ET EXPLOIT" such as "ET EXPLOIT WinProxy Host port buffer overflow". Similarly, we'd type in "ET A*" to match all attacks. Below are two screen shots
of the events which occurred under these filters:

Attack Events	Exploit Events

Under the attack filter, the events detected were IRC events that might indicate that a host has been compromised and is now receiving command and control instructions over an IRC channel. We will talk more about analyzing potential botnets in a future blog entry. However, in this case, the events were found to be false positives because:

• there was only one host of interest
• it never attacked nor scanned anyone
• there was a history of IRC usage as well as typical email and web browsing
• the IP address was found to be part of the student network

I say that these were false positives because the intent of the signature was to look for a compromised system logging into IRC in a suspicious manner. The signatures themselves looked fine, it is just that the packets involved that matched did not indicate abuse.

Analyzing The Events

In the Exploit screen, there were several denial of service events, a client side embedded GIF attack, a surge of PHP exploit attempts and a Solaris Telnet attack.

DOS Event Analysis

The DOS events were directed against one MS SQL server for which we had been receiving event logs from the underlying system. These logs indicated no interruption in service around the time of the attack. Vulnerability data from previous Nessus scans and continuous updates from the Passive Vulnerability Scanner did not indicate any major vulnerabilties or potential denial of service issues
either.

The actual packets detected in this case may have been real attacks. If we wanted to do deeper analysis, we could consider the sources of the attacks and see if this indicates some sort of  longer term activity. I generally don't like any type of unencrypted SQL access across a perimeter of a university.

Analyzing a Client Side Attack

The client side embedded GIF attack referenced MS05-036. This targets Internet Explorer browsers. In this case, Nessus was not being used to perform a client side audit and the Passive Vulnerability Scanner does not have a plugin to find this vulnerability since there isn't enough data on the wire to determine if it is present. However, we can do a few things.

First, we can look for evidence of a browser being used other than IE. In this case, it was Firefox. The PVS will report what browser is being used through passive analysis.

Second, we can see if this computer is receiving updates from Microsoft. PVS plugins #1925 and #4433 detect if a host is performing updates from Microsoft. And third, we were performing analysis of this host several days after these events occurred. After this IDS event happened, we did not observe any statistical anomalies, any types of scanning, outbound attacks or correlated events which could indicate a compromised system with Malware or a back door recently installed.

Analyzing the Telnet Attacks

The last attack that I felt was interesting were the Telnet attacks against a Solaris system. First, I thought it would be interesting to see how much Telnet traffic was occurring and to where:

Compared to the P2P traffic in the screen shot above, there is much less port 23 traffic. I am surprised at how much port 23 traffic is occurring and originating from multiple places on the Internet. There are likely scanners looking for open Telnet ports to exploit them with vulnerabilities or attempt brute force password guessing.

Analyzing the specific attack further, I found that the source of the attack originated from outside the United States and had not sent previous attacks. Wanting to see if there was other data on this host besides the IDS events, I turned to the Log Correlation Engine we had deployed there. This included logs from the Tenable Network Monitor to collect all network session data as well as system logs from a few servers and applications. Performing the query for our IP of interest we see this following data:

In this graph, we see that there were 70 normalized Emerging Threats Snort events, and slightly more TCP sessions. However, there was only one network session that completed. All of the other sessions "Timed Out" which is very indicative of a network scan. For the one session that was observed to complete (a full, SYN, data and good close with a FIN), it would be very interesting to see what the target and port were and this is shown below:

In this case, the target was an email server. SPAM logs were not being sent to the LCE, but delivered email was. This could allow us to conclude that the 34k bytes in the session on port 25 was likely some sort of spam email. Correlating this with the fact that the same IP address also tried a Solaris Telnet attack means that the remote host is most likely a SPAM source that also probes for vulnerable services.

The Security Center automatically correlates IDS events to discovered vulnerabilities and would have generated such an alert if the target host was vulnerable to the Telnet attack. To manually make sure, looking at the Nessus and Passive Vulnerability Scanner data that has been detected does not show any issues on port 23:

None of the vulnerabilities listed here seem serious enough to be concerned about.

Conclusions

This is the first in a series of several articles on different examples of event analysis. We've covered some related topics previously in this blog and they are listed below here:

• ShmooCon -- Network Monitoring Notes
• Finding Low Frequency Events
• Good and Bad Uses of Vulnerabiltiy Data for IDS Event Correlation
• Tracking Users Through Logs and Network Activity
  
• Blacklist Event Correlation
• Looking for "Never Before Seen" Events
• Example NBAD with the Log Correlation Engine

Nessus plugin #31422 named "Reverse NAT/Intercepting Proxy Detection" enables Nessus users to scan remote IP addresses and determine if they are forwarding multiple ports to different internal systems. This is sometimes also known as an Intercepting Proxy Server.

For example, if a user has configured a firewall or router to send SSH traffic to a hardened FreeBSD server, while sending RDP traffic to a Windows 2003 server, a remote Nessus scanner would be able to identify this.

The plugin can accomplish this sort of audit by comparing the OS fingerprinting results for each targeted port. If they are different enough, the plugin concludes that there is a reverse NAT involved. When using this plugin, use a port scan range which will hit ports that are being forwarded. Also keep in mind if there are multiple reverse NAT rules all going to the same host (i.e., a firewall that has forwarded both port 22 and port 443 to a Linux server), there won't be enough difference in the fingerprints of the ports to detect the reverse NAT.

Below are screen shots of performing this sort of audit with the Nessus scanner and Security Center:

The plugin is currently available to both the registered and Direct Feeds and is a member of the Firewalls Nessus plugin family.

Why is this sort of Audit Important

If offering services such as this is against your corporate policy, then being able to find a reverse NAT with this technique can help you enforce such a policy. This could mean that a user has bought and installed a cheap firewall or wireless access point.

When auditing a smaller company that may not have a DMZ, being able to identify ports being forwarded this way might be identifying target machines in the middle of he office LAN. Smaller organizations that have not invested in a layered infrastructure could be using reverse NATing to offer services such as RDP, HTTPS, and Windows file sharing directly to a server on the local network.

Knowing which services are offered behind a firewall or router allows for better understanding of the network and the impact of the discovered vulnerabilities.

For More Information

A key part to making this sort of technology work is how Nessus performs its operating system fingerprinting. Specifically, the os_fingerprint_sinfp.nasl script implements the SinFP operating system finger printing  on a per-port basis. Tenable and the SinFP project share operating system fingerprints.

If you are passively monitoring your network, Tenable's Passive Vulnerability Scanner also uses a different technique to find NAT devices in general.

And lastly, we've blogged before in general about using Nessus to perform audits of hosts located behind a firewall.

Tenable Network Security is proud to announce the availability of Nessus 3.2.0, as well as NessusClient 3.2.0. Nessus 3.2.0 is a major release, containing several changes from Nessus 3.0.x :

New Features

• Support for IPv6 targets (for the Linux, FreeBSD, Solaris and Mac OS X flavors)
• Support for limiting the number of active TCP sessions in parallel  (per host, per scan, per scanner)
• A new nessuscmd tool that lets one run quick scans from the command-line
• A new nessus-update tool that lets one update the Nessus engine from the command-line (on select platforms)
• The Nessus daemon can now detect hosts which are being turned off during the scan and stop scanning them
• The Nessus daemon can now detect when the network is congested and change the TCP settings appropriately
• Nessus user account access control rules are now more granular and can be used to prevent the scanner from connecting to certain ports or to use certain plugins
• The nessus command-line tool can read and write to and from a .nessus file
• Improved WMI support (see http://cgi.tenablesecurity.com/tenable/WMI.html)

Improvements

• New nasl functions can dynamically alter the plugin selection
• Improved memory management by NASL scripts
• Support for more SSH ciphers (AES-128/AES-192/AES-256/3DES)
• Improved service detection -- a new service detection plugin (find_service.nasl) replaces the old find_service.nes
• On Unix systems, the initial plugin processing now takes advantage of multi-core CPUs
• nessusd.rules now let you tune which plugins are forbidden for a scan, and which ports can or can't be connected to

Improvements to the Nessus TCP Scanner

• Simplified preferences -- a new cursor option (firewall detection) lets the user better tune the scanner when running against a firewall or a slow link
• Improved RTT estimation and congestion detection by regularly probing unfiltered ports

Windows Specific changes

• NessusGUI.exe has been removed in favor of NessusClient.exe which is now bundled with the installer
• It is now possible to authenticate the clients via SSL certificates
• KB saving and other options common to the UNIX version of Nessus are supported on the Windows platform
• Installer now lets the user decide which components to install (server, client or both)
• When the scanner is registered with either a Direct or Registered feed, it will automatically fetch and process the new updates from nessus.org every 24 hours

Mac OS X Specific changes

• Nessus Client 3.2 includes a fixed a memory leak that occurred in the 3.0 version
• Nessus 3.2.0 now is a real universal binary

Linux platforms

Nessus 3.2 is now  available for the following Linux platforms :

• Debian 4 (i386 and amd64)
• Fedora 7 (i386)
• Fedora 8 (i386)
• Red Hat Enterprise Linux 3, 4 and 5 (i386)
• Red Hat Enterprise Linux 5 (x86_64)
• SuSE Linux 9.3 and 10.0 (i386)

NessusClient 3.2.0 specific changes

• A new 'network' tab when editing a policy, lets the user control some Nessus 3.2 specific options  such as maximum TCP sessions.
• Fixed several bugs which might cause the client to crash in the middle of a scan.
• Opening a large .nessus file in the client now takes less time.

For more Information

Nessus 3.2.0 can be obtained at http://www.nessus.org/

Feedback and bug reports can be sent to http://bugs.nessus.org/

Demo videos of Nessus 3.2, including an 12 minute introduction video for new users, are available online.

Nessus documentation is available here:  http://www.tenablesecurity.com/documentation/