Advanced Dynamic Asset Rules

The Security Center can use the vulnerability data obtained by Nessus scans, Nessus patch audits and the data obtained by the Passive Vulnerability Scanner (PVS). Combinations of specific IDs, DNS names, results content and open ports can be used to create a "dynamic" asset list. These lists are updated each time a new scan is completed or passive vulnerability data is processed.

This blog entry will consider two examples of dynamic asset list creation which are more advanced than a typical user might need, but illustrate the flexibility of the type of rules which can be created.

Detecting Potentially infected Nugache Instances

The Nugache virus is a classic type of worm which opens up a backdoor (in this case on port 8) and also connects out to IRC servers for commands.

If the PVS is configured to watch a network, it will see many types of applications in use and it will also see basic open ports and browsed ports. The PVS logs "open port" data to plugin #0 (the same as Nessus open ports). It also logs "browsed port" data to plugin ID #2.

So in Nugache's case, and active infection should have an open port on port 80, as well as having connected out to IRC on port 6667. A dynamic asset rule to detect this is shown below:

Having a TCP port number of 8 open is very simple. Basically, any vulnerability can contribute to an open port, and if the port is 8, the first part of this rule matches.

The second clause is more tricky. In this case, we want to find hosts that have the presence of plugin ID #2 (browsed ports) but also on a specific port of 6667.  Plugin ID #2's data looks like this:

1.2.3.4 -> 80

That would mean that host 1.2.3.4 browses on port 80. Knowing that the port is at the end of the data, we can write a regular expression that looks plugin ID #2 with data that ends in " 6667". The text in the above image says "2: 6667$" which means to look for plugin ID #2 that ends with a space and the string "6667".

If you are not familiar with regular expressions, the dollar sign is used to indicate the end of the match. Without it, the pattern could be matched anywhere. The expression "2: 6667" could match " 6667" as well as " 66677" or " 66671" or any other type of number which started with "6667".

Users that are new to writing dynamic asset rules might want to write this rule as follows:

This is incorrect. The spoken logic for this rule would sound like this:

"Find any hosts for port 8 open, and then make sure that they also have at least one vulnerability on port 6667 AND they also have at least one instance of plugin ID #2 for browsed ports".

So when the dynamic rules say that ALL rules must match, they must indeed match, but they are each evaluated individually across all of the available vulnerabilities for a given host.

We could make this dynamic asset rule a bit more generic by changing the rule for watching network browsing on port 6667, to a more generic PVS rule which finds and identifies IRC clients. These are PVS IDs 3101 and 3471. These rules have the advantage of being port independent. IRC servers can run on many different ports, and the PVS can recognize them through protocol analysis. We will use these rules in our next example.

Detecting the IRC Browsing Web Server

Once users get the hang of writing dynamic asset rules, we often see them create very creative rules that identify a wide variety of potential security issues as well as configuration issues.

One common idea we see often is to look for IRC activity from a server. The idea is to see an attacker's use of IRC after they have compromised a server.

Consider the following rule:

Plugin ID #1442 is a PVS rule to generically find a web server on any port. Plugin IDs #3101 and #3471 find systems that use IRC clients. This rule, spoken in plain English, would say:

"Find any system which runs a web server on it (plugin #1442) and also uses an IRC browser (with either plugin #3101 or #3471 being present)."

Now, consider what we find what we ran this on a large test network:

We can see that plugin ID #1442 (Web Server) is present and that also plugin ID #3101 is also present. However, based on the other passively discovered vulnerabilities such as Media Player and various versions of Mozilla, this might not really be a "server".

Further analysis (not shown here) shows that the web server is indeed a P2P application known as Lime Wire. PVS accurately identified a service that spoke HTTP, but it wasn't really what we intended to seek out in the first place. The Lime Wire server wasn't even running on port 80 in this case.

If we wanted to make our dynamic rule more accurate, we could try adding a regular expression to the rule clause for plugin ID #1442 to match "Apache" or "IIS". Such a rule would look as follows:

Instead of simply matching for plugin ID #1442, we now have a rule which looks at the text of the vulnerability results and does a simple pattern match for "IIS" which occurs in most Microsoft web server banners. If we wanted to add support for Apache or restrict the port, we could add more rules to this initial clause.

For More Information

The Security Center documentation contains many more examples and ideas for creating dynamic asset rules.