More Comments: Security Scanners.

[crowland () PSIONIC COM (Craig H. Rowland)]

As others have done, I am posting from my home domain as an individual and
all opinions should be considered my own.

I work for Cisco Systems and Wheelgroup before that. I'm a lead developer
on our auditing tool NetSonar and my primary responsibility is coding
active network attack tools.

Please bear with me as I share some personal thoughts on this issue:


1) Don't underestimate the frailty of your network.

This subject has been touched on here, but I think a lot of people don't
realize how frail many of the network resources in common use are. It has
been my experience (and the release of new version of nmap has continued
to show to the readership) that many well known devices/OS/daemons have a
hard time handling a simple port scan let alone a full-blown sequence of
active attack probes. Nevermind the fact that these probes are
often intentionally ramming illegal data in hopes the daemon coughs up
useful information.

So when people say "The scanner should do attack XYZ just like a
hacker" you need to really consider the implications when the tool is
being used to scan a large number of hosts. An active probe is a reliable
way to check for a problem, but you need to thoroughly test what the
ramifications will be across a wide variety of hosts when you run it.

A personal experience with this is when I wrote an attack library for
telnet. The library used a common set of default accounts. Not a big
deal, but take a look for yourself and see if you can find the issue:

root
uucp
sys
nuucp
adm
lp
bin
toor
halt
listen
nobody
smtp
oracle
etc.

Everything is going great, you're hacking accounts like a fiend and then
suddenly the system you're probing stops responding. You can't figure out
what happened until you see that the system has been halted remotely.
Looking back you can see that in a list of 50+ default usernames I
accidently included the "halt" username. On most hosts this account is
inactive or non-existent, but on many (especially older) platforms it will
run the /bin/halt command as soon as you login! This was a silly error
that can cause a significant problem on many networks during testing.

This is just one example, what about the remote buffer overflow check that
crashes the parent process? Now you've just shut down that service to all
users. Sure you've found the problem 100%, but now you may have dozens
(hundreds??) of hosts across your network that are probably in a state of
limbo while you frantically try to restore order.

2) Checking for banners is useful.

Virtually all operating systems and many network daemons willingly give
you a banner when you connect to them. It seems to be wasteful to at least
not *consider* this information as part of your security audit scan. This
information is being provided for a reason (I don't agree with the reason,
but that's because I'm a paranoid security type) and while it can be
altered by the user in some instances, I've generally found this case to
be exceptionally rare.

3) Things aren't always what they seem.

As anyone of the authors of these tools will attest to, writing active
probes is time-consuming and requires quite a bit of testing before it can
be accepted into a release product. It's not simply a matter of
downloading some scripts from rootshell.com, pasting them into a wrapper
and then checking it into the source tree. There are regression test
procedures, stability checks, OS impact tests and of course reliability in
detecting the problem stated.

Because a human is coding the attack and they can't possibly know every
configuration of every system or how systems in the field may or may not
react, it is entirely possible that an active probe may in fact not catch
what it is designed to. Many factors can affect this such as:

- Custom user configurations on a system.
- The way a daemon was compiled.
- A remote system error such as a full filesystem.
- etc.

An automated probe in these cases may miss a bug that a human
investigating the problem by hand can work around to get to work
successfully.

A banner check in this area when used with an active probe can report to
the user "This system appears potentially vulnerable, but the active check
can't confirm it." This is certainly a suspicious situation *I'd* want to
be aware of.



With all of that said I would like to add a few things that we do in
NetSonar to differentiate how we detect problems in a host.

Scanning Process.

NetSonar has six phases of scanning:

1) Ping sweep.
2) TCP/UDP Port sweep/banner collection.
3) Banner and port rules analysis.
4) Active attack probes.
5) Active attack probe rule analysis.
6) Present data.

This doesn't mean too much to the average user except for how we handle
the actual classifications of checks which we classify as the following:

Potential Vulnerability (Vp)- These vulnerabilities are derived from
banner checks and active "nudges" against the target host. A potential
vulnerability is a problem that the system is indicating may exist but an
active probe has not confirmed that it does in fact fall victim to.

Confirmed Vulnerability (Vc) - These vulnerabilities have been actively
checked for and almost certainly exist on the target.


How we get a Potential Vulnerability (Vp)

Potential vulnerability checks are done primarily through the collection of
banners and the use of non-intrusive "nudges." A nudge is used on daemons
that don't respond with a banner but will respond with a simple command.
An example of this may be an rpc dump or sending a "HEAD" command to get
a version from a HTTP server.

Once this information is obtained we use a rules engine and a set of rules
to determine if a problem exists. The rules are based on simple logic
statements and the user can add rules as they see fit. Examples (some of
these are off the top of my head so excuse any errors, some from the
included user.rules file with the product):

# Service report section: The system is running netstat
port 15 using protocol tcp => Service:Info-Status:netstat

# Service report section: report the rexd service running on target
scanfor "100017" on port 111 => Service:Remote-Exec:rpc-rexd

# OS Type report section: The system is Ueber Elite OS 1.x
(scanfor "Ueber Elite OS 1.(\d)" on port 21,23) || (scanfor "UEOS
[Ss]mail" on port 25) => OS:workstation:unix:ueber:elite:1

# Vp Report section: The system has a known a buggy FTPD version
Service:Data-Transfer:ftp && scanfor "BuggyFTPD 0.01" on port 21 =>
VUL:3:Access:FTP.BuggyFTPD-Overflow:Vp:888

# User Custom Rule: Someone has a rogue IRC server running.
has port 6667 => VUL:1:Policy-Violation:IRC-Server-Active:Vp:100002

# User Custom Rule: SuperApp 1.0 running on host.
(scanfor "SuperApp 1.0" on port 1234) || (scanfor "SuperApp 1.0 Ready"
on port 1235) => VUL:1:Old-Software:Super-App-Ancient:Vp:100003


This of course becomes very useful to an admin who discovers the latest
vulnerability off of BugTraq and decides to write up a quick rule and scan
their network. This is also a useful feature for sites that run custom
applications and wish to track versioning/usage across a network, or
you found out the hacker you bought the software to help get rid of
likes to put a backdoor on all compromised machines at port 447, etc.


Why this matters.

The above process is important because it is largely non-intrusive and
non-destructive to most systems. Because of this you can safely run this
type of scan and know you *probably* are not going to impact your network.
Indeed this type of scan is perfect for scheduled unattended use because
you know you won't crash critical systems at 3:00AM when your scan starts.

Why it might not work.

Overall the majority of system daemons that return banner information
generally are running the version of the software they are saying they do.
It might be possible that an admin has enough time to go around changing
version numbers on everything. Then again this time would probably be
better spent on applying relevant patches to the problem they are trying
to cover up.

In the end though, many vulnerabilities are simply not going to reveal
themselves unless you poke at them a little. For this case the confirmed
vulnerability checks take over and actual attacks are launched against the
suspect process. In some cases this may produce overlap of a Vp and Vc,
but this is an acceptable situation because now you have informed the
administrator that:

a) This system *may* have this problem.
b) This system definitely has this problem.

I believe this is a nice approach to the issue because you get the best
that each mechanism has to offer: Banner checks report the facts as
offered to them by the system upon initial inspection and the active
checks that disregard banner information and check for themselves
directly.

In either case the admin is left with several options:

1) Run the scan with potential vulnerabilities only. This will give a good
coverage of the systems on your network. This method is by far the least
disruptive option and also the fastest.

2) Run the scan with potential vulnerability and confirmed vulnerability
checks. Here you get the coverage of the rules and the probing of
problems with actively enabled probes. This method may cause system
disruption during the attacks, but no deliberate DoS attacks are done
without letting the user know.

3) Run the scan with your custom rules to find a specific problem.

4) All of the above.


This is just another approach to the problem that a network vulnerability
scanner faces. The variances of a modern network are anything but simple
and it should be remembered that a scanner is just one piece of good
network security practice. All the products on the market attempt to
produce the most accurate and complete results possible. Just like virus
scanning utilities however, there exists a margin of error in whatever
method is chosen.

-- Craig

Speaking for myself.