Nessus. A short review of the Nessus computer network vulnerability analysing tool. Authors: Henrik Andersson Johannes Gumbel Martin Andersson

Transcription

1 Nessus A short review of the Nessus computer network vulnerability analysing tool Authors: Henrik Andersson Johannes Gumbel Martin Andersson

2 Introduction What is a security scanner? A security scanner is a program that scans a network in search of security holes. The scanner is programmed to search for known vulnerabilities in hosts in the network. It can give a good view of the security of the network in a fast way. The security scanner has some different abilities like port scanning, services recognition, information gathering and check for flaws. The port scanning is done by for every host it is testing it determine if the host is alive and which ports are open. There are many different types of scanning methods available but the most popular are the SYN scan and the TCP connect scan. Service recognition, information gathering, check for flaws and port scanning will be discussed in more detail later in this paper. When you want to know if a security scanner is good or not there are some features you have to evaluate. You should look at the breadth of its scan, the precision of its scan, the depth of its scan, the customizability of its scan and the result of its scan. By the breadth we mean how many vulnerability checks the security scanner performs, by precision we mean how well it does in finding the most important vulnerabilities and how few false positives it returns. By depth we mean if the scanner search for secondary exploits or not, by customizability we mean if the scanner can be updated or modified by hand and by the result we mean of cause if the report produced is useful. A security scanner with many vulnerability checks do not have to be the best. With more checks the more false positives and the scanner will be less precise in its scans. What is it good for? If you are a system administrator you would probably want to know which the security holes are in your system. If you know the holes and the vulnerabilities you can hopefully fix them. You don t have to be a system administrator, in the sense that you administrate a big system, you can just be a regular user of your own system. If you have a PC for example you wouldn t want anybody to use your system without permission. If you have security holes in your system someone can use a hole to take control over your computer. A security scanner can help you to track down the security holes and vulnerabilities. After that it s up to you to fix them. Nessus Nessus is a free open source security scanner. The Nessus Prodject was started in 1998 and the scanner Nessus was released in April Nessus have all the features described, port scanning, services recognition, information gathering and check for flaws. With Nessus you can also use external programs for example NMap for port scanning, Hydra for weak password testing and Nikto for cgi./script checking. The advantage of this is that you can combine the best programs from different areas in a Nessus scan. One thing that makes Nessus so powerful is its client server technology. With this technology servers can be placed in many different places in a network and the network can be tested from various points of view. There is the server that performs the actual testing and the client provides configuration and reporting functionality. You can have one central client or multiple distributed clients controlling all the servers. With this feature there comes a 2

3 great deal of flexibility for the vulnerability tester. 3

4 Information Gathering To make a vulnerability analysis on a remote host we initially need some data to start with. There are some things to consider before we start. From what view(es) do we want observe the host? Possible points of view include a blind (no initial information) scan from the Internet, a somewhat knowledgeable attack from the Internet, a blind scan from a trusted network, or a scan using full system privileges from a trusted network. Next we need to obtaining the correct target IP address(es) of our target machine. A determination of a system's sensitivity to crash is also very important. For example, typically the fallout from a high profile e-commerce server crash would be greater than a crash of a regular user s desktop or a test server. Host identification When performing a blind scan across a subnet, it helps to know if an IP address is active or not. Traditionally this is done with an ICMP ping. Enabling pings on the target host can greatly reduce scanning times. The reduction in scanning time comes from the assumption that an IP which doesn't respond to pings has no system and therefore no further tests will be run against that IP. Firewalls and other systems can be configured such that it does not respond to ICMP pings and thus makes it harder for an attacker to spot the system. There is also the option of doing TCP Pings. An attempt is made to connect to specific ports to determine if a system exists. This is a good option for quickly scanning an Internet facing firewalled subnet. Usually a common port (such as 80, 25 etc) is being used on all Internet facing systems. If these ports respond a host exists at that address. Port scanning Once we have determined that the hosts exist we move on to determine active ports on each IP address and enumerated them. This is done by port scanning. Port scanning seems simple on the surface but is actually a very complex topic. One factor which makes port scanning difficult is the response system. When a port is closed you may receive "this port is unavailable message" in the form of a RST packet but from firewalled ports you may receive nothing. Stealth, speed, and accuracy are the principal factors to balance when port scanning. The parameters which affect these are the type of scan, timeouts, and what ports to scan. The two most commonly used types of scans are the connect() and SYN scans. There are variations of both in Nessus and in the optional NMAP component as mentioned above. The native scans have few configuration options and generally work quite well. The NMAP scans provide a wealth of options which provide valuable flexibility for some situations. A connect() scan is the most basic scan; it attempts to complete a connection to each scanned port. A SYN scan is a bit more stealthy and harder to block since it doesn't complete the connection. SYN scan starts, but doesn't complete the TCP handshake sequence for each port selected which is hard to trace. Since by default Nessus only runs vulnerabilities against ports found to be open, the choice of ports to scan is also a critical factor. When scanning a large number of hosts a small 4

5 selection of commonly used ports is typically scanned. The default approach is to scan all privileged ports IE TCP ports and the ports listed in the NMAP services file. This would cover all the well-known ports which applications "normally" use and ports that some Trojans use. To speed up scans more, a subset of the well-known ports might be scanned. Scanning ports HTTP 80, 8080, Windows 135, 139,445, HTTPS 443, FTP 21, SMTP, and SNMP 161 would identify ports that most often have vulnerabilities associated with them. Service recognition Nessus does not believe that the target hosts will respect the IANA assigned port numbers. This means that it will recognize a FTP server running on a non-standard port (31337 say), or a web server running on port This feature is provided by the find_services.nes plugin that will if enabled try to recognize what kind of service is provided on one specific port. If a host runs the same service twice or more, Nessus will test all of them. Finding flaws Once we have collected all information available it's time to analyze the data and try to find flaws. Although Nessus in its development phase is able to scan for local flaws the stable versions released so far only include remote security that will be the focus of our discussion. To verify remote security we want to know at least what ports are open. Although any extra information will help make a correct analysis. Example of extra information might be: information about what services are running on what port, operating system the host is running, if behind a firewall it's good to know what rules the firewall is enforcing, users on the system, possible entry points (modems, wireless network,...), user behaviour, possible trust relationships, system administrator habits, etc. the list is almost endless. For now we will examine flaws in services and not in the host as a whole. We take three approaches to finding flaws in services: banner comparison, finding change in behaviour and reproduction of flaw. Banner comparison Many remote services (and local) present us with a banner at start-up. This is a short message send by the service before any authentication has been presented and may include things such as version numbers or what type of service it is. As this information is freely available we may collect version numbers and compare them with a database containing vulnerable versions to locate insecure software running on a host. For example if we connect to port 22 where we find the banner "SSH-1.99-OpenSSH_3.6.1p1" simply searching the net for insecure versions of ssh might be a simple way to find a flaw. A good thing about this method is the ease with which we can do it, notably even without any detail about the exploitation processes. For example if we know version OpenSSH 3.6.1p1 is vulnerable to a flaw, although we have no technical detail about the flaw we may find it using the banner in the previous example. The largest problem with banner grabbing is the amount of false positives produced. A banner may not correspond to the software it claims to represent for mainly two reasons: the software is patched or the banner has been modified. Software patching is very common and might even be done by distributions and not only the administrator. Modifying banners to make them report back wrong versions might also be 5

6 done, although this classifies as security-by-obscurity and adds only very little defence. Finding change in behaviour This is really a way to complement the service fingerprinting and banner analysis discussed above. By testing for differences in applications/versions we may be able to determine the service running to a better degree than previously. For example if we try to overflow the USER parameter i MyPOP 1.1 we get an error message, but when doing the same thing in MyPOP 1.0 the service crashes. This has no use when it comes to generic testing since we are looking for differences between applications/version we already know of. These kinds of tests may be dangerous to run, since some tests might include e.g. overflowing a buffer looking for some kind of error code. Reproduction of flaw The only way to really make sure that insecurity is exploitable is by actually exploiting it. This is not completley true, if we are able to exploit an insecurity we know that it is possible, but if we fail it's still possible someone else might succeed. Sometimes exploiting a flaw might be "safe" for the host, in other words the service wont crash, other times we might need to crash the service to try our exploitation. The difference is of obviously large. The tests which won t disrupt a service we may include without worry, such tests might include insecurities where information is improperly disclosed. A test which will crash a service is a lot more questionable to run, you might want to verify if your server is vulnerable but if you actually need it to be functional this is a dangerous test. Running or not running dangerous tests is primarily a question for automated tests and large system administrators as other users probably have the ability to reboot a crashed system or service. The major advantage when reproducing flaws is that you get pretty reliable results. But using generic exploitation techniques on unknown services we might even be able to find flaws not yet discovered. Nessus has been reported to have found among others an overflow in qpopper 4.0 and a few denial-of-service attacks in some web servers. Conclusions Nessus is an excellent tool that will greatly aid your ability to test and discover known security problems. The power that Nessus gives you should be used wisely as it can render production systems unavailable with some of the more dangerous plus-ins. Resources The official site for Nesses: Introduction to Nessus, by Harry Anderson: Part 1: 6

7 Part 2: Part 3: 7