SATAN has created such a controversy that when one of its authors, Dan Farmer, lost his job, SATAN was heavily rumoured to be the cause of the dismissal. April 5th (the release date) came and went, and the Internet is still here. A recent panel session held at the NCSA Conference in Washington D.C. highlighted the fact that despite all of the publicity, many people still don't have even a basic understanding of SATAN. What is it? What can it do and not do?

In this article we will be taking a close look at SATAN; its history, what it does, how to use it safely, how to detect its use and how to fix the holes SATAN finds. First, before we begin, we feel we should mention that if the name SATAN is offensive, you can easily change it to SANTA by running the "repent" option which comes with the program.

What Is This Beast?

SATAN (Security Administrator Tool for Analyzing Networks) is the product of Dan Farmer and Wietse Venema, two well-known UNIX security experts. It performs a scan of a TCP/IP network and the current version uses a World Wide Web-style graphical front-end, which makes finding some holes literally as simple as point and click.

So far it sounds like a hacker's dream has just come true. Well, it isn't, and here is why. First, hackers have had SATAN for a long time, possibly as long as two years. How did that happen? Security experts are tempting targets for hackers, since they have the best tools; the rummaging of Tsutomu Shimomuru's files illustrated this last Christmas. Somehere along the line an unknown hacker did the same to Dan or Wietse, and grabbed an early version of SATAN. It didn't have the nice front end, and it tested for less holes.

Secondly, while it is very easy to run, SATAN is somewhat cumbersome to set up and it would be a rare hacker that would go to all the trouble needed, when tools that perform much the same function but don't require all the fussing are in easy supply. The program itself is fairly large (800 K, uncompiled) and it requires a large, fast machine (80 MHz and 32 megabytes of RAM recommended). In order to run at all you need to have version 5 of the perl language installed, and an X terminal for the Web browser.

Finally, SATAN does not actually break into any system; it only exposes vulnerabilities. Any hacker that wants to use SATAN has to bring his own toolkit with him to exploit the holes it finds for him. As you can see, SATAN is the sort of program that hackers don't really want or need, other than as another cute tool to own. Scripters, (those who haven't learned the particular operating system but rely instead on ready made tools and scripts to gain and keep access to systems) really don't generally have the skill or resources to compile or install SATAN, let alone the disk space!

SATAN could be more useful as an administrator's tool than a hacker's toy. Let's take a look under the hood and seewhat SATAN actually does. There are three levels you can set for SATAN's probes - light, normal and heavy. A fourth level which does exploit the holes found is said to be planned, but that implementation appears to be some time off.

Is He On the Level?

The first level of scanning only looks at a few aspects of the target machine, querying DNS and RPC to see what the machine is like. This is more to find out what sort of machine you are probing (server, firewall, workstation) than to find any vulnerabilities. A check for exported filesystems is included here, however. Obviously, these kinds of checks can be done by simply executing a few commands which are part of the operating itself. For instance, rpcinfo -p hostname will produce a list of remote procedure calls in use by a given machine in many cases. DNS information is available as readily.

The second level establishes the operating system of and what services are actually offered by the host in question (ftp, www, mail, etc), and notes the version of each. This is useful for the administrator who wants to find out if all his machines have the latest version of sendmail, for instance. Some vulnerabilities, such as checking for NIS maps and seeing if "rusers" (which shows what users are logged into each host of the local network) is available, are tested for. Again, these tasks are equally as easily accomplished by using commands that come with UNIX. Telnet to port 25, see the version of sendmail. This is not magic. It is part of the operating system. There are small, elegant utilities available which perform NIS mapping probes; an 800K file is overkill.

The third level does some actual attempts to do various things with the services found by level two. For instance it tries to read the X display, tests to see if it can rsh in and checks the anonymous ftp directores to see if any are writeable. It also checks all ports (both TCP and UDP) for any nonstandard services that might be available. Again, there are ways to do this without all the bells and whistles. Obviously, telnetting to port 21 (the FTP services port), and examining all of the directories and their permissions does not require SATAN; it only requires you have a telnet connection and a basic knowledge of /etc/services!

Obviously, none of the probes or tests SATAN performs are new or startling. The biggest innovation SATAN brings to the security scene is its thoroughness and inference engine. What is an "inference engine"? It is the "decision maker", the part that puts all the pieces together and sees if it can get any further. SATAN was written in part by the same person who wrote COPS, the classic stand-alone UNIX security checker. Included in COPS is "Kuang", which takes the initial data received and sees if matching various pieces together can open up any new holes. This exposes holes of "transitive trust": if A trusts B then finding a hole in B also exposes A, even if A doesn't trust the machine doing the scanning. A simple host-by-host, post-by-port scan would miss this.

All of this makes SATAN sound like the greatest thing since sliced bread. However, the initial release of SATAN actually introduced a new hole into some systems. This appears to be unintentional, and an oversight regarding the capabilities of some web browsers. SATAN was designed with a safeguard against others stumbling onto the vulnerability information; this was necessary since the output of SATAN is simply a Web page listing the vulnerabilities found. It would be a very unfortunate administrator indeed who ran SATAN on his whole network only to have some random Web surfer stumble on the page listing out exactly all of the system's current security problems! To stop this a "session key" was added, so that only a person presenting the key could access the output pages. The key is generated by the "MIT magic cookie" method; this is generally recognized as (usually) secure against guessing.

The problem is that there are some Web browsers which pass on extra information when connecting to a new link. One of the extra pieces of information that gets passed on is the your originating link. This was put in to assist with traffic analysis, so the person who owns the link can tell how people are finding (accessing) his link. Since the "magic cookie" is passed on to SATAN inside a URL (Universal Resource Locator, the name of the link), this information can also get passed on. An unsuspecting administrator could run SATAN, scan his network, and then hop off to his favorite Web page to see what's new. In the process he gives the owner of that favorite page his magic cookie which authorizes him to view the results of SATAN's probes. Some browsers (Netscape, Lynx) have this "feature", some (Mosaic) do not. In version 1.1 you are told about this problem when you try to access non-local links.

At Your Service!

Now, we will take a closer look at the probes SATAN can be used to perform, and how to make sure SATAN won't find those vulnerabilities on your system. Keep in mind, since SATAN does not perform an exhaustive security analysis, this list should not be construed as sufficient for securing any system.

First we will examine FTP. There are three potential problems with standard FTP. There is the SITE EXEC bug in wu-ftpd. (wu-ftpd is a specific version of the ftp server software) This is a bug which allows you to execute any command without an account. Secondly, there is a race condition in wu-ftpd which allows the same thing. Finally, there is the problem of writeable ftp home directories, which could allow hackers to drop in a .rhosts or .forward file. The fix here is to update your version if you use wu-ftp, and make sure your ftp home directory is not writeable.

Next is unrestricted TFTP access. TFTP is like FTP, except no password is required. Careful controls must be put on its use, and if it's not absolutely necessary it should be turned off.

Third, let's examine NFS, the Network File System. There are several problems in NFS. NFS has client-side authentication, which means the server believes the client when he says who he is; this is always a bad idea. This can be fixed with Secure NFS, which uses cryptographic authentication. There is also the problem of NFS' use of the RPC portmapper. When a remote NFS request is made through the portmapper, the local NFS daemon sees the request as coming from a local, trusted source (the portmapper) and not the real origin (possibly somewhere remote and untrusted). The fix here is to use a portmapper that doesn't forward requests. The last NFS hole SATAN checks for is unrestricted exports. If anyone can mount your filesystem, they can read anything they find there (password file, email, user files) and possibly even write to your disks. To fix this you should change your export lists to include only needed hosts or netgroups, and export filesystems read-only if possible.

The fourth area SATAN looks at is NIS, the Network Information Service. The base NIS setup has no control over who can access your administrative databases. This includes such critical files as password and mail alias files; anyone who knows the domain name and map name can get them. There are various solutions to this problem; all of them work by adding some sort of control list to NIS. Check with your vendor for a method compatible with your system.

Next comes REXD, the remote execution daemon. Like NFS, this has client-side user authentication, which means anyone can say they are anyone and the server will believe them. The fix is either to disable rexd or use a different method of authentication (This is available for some systems).

The next area is X Windows. The problem here is that if a remote user can connect to your X session, he or she can read anything on your screen, and also write anything to it. The fix is to add an authorization system like XDM or xauth, and check the permissions granted under it.

After this is rsh/rlogin. If your system has a wildcard ("+") in /etc/hosts.equiv, or if a user has one in his .rhosts, anyone can rsh or rlogin in with no password. The fix is to take out any wildcards taht are there, and install a system to check periodically for wildcards in users' .rhosts files.

Finally there is sendmail. There are many problems with many versions of sendmail, and SATAN checks for them all. This includes aliases like decode, which allow remote users to write to files, and old versions of sendmail, which have holes too numerous to mention. The fix is to remove the alias and update your version of sendmail.

All of these problems will be addressed specifically and in detail in future articles. Here, we are presenting only a generic overview of the problems, in the hope that knowing a little more about SATAN and the capabilities of the program will help put your mind at ease.

After you've run SATAN and fixed all the holes it found in your system, you may want to take a look to see if anybody else is probing your system as well. In the wake of SATAN's release came two SATAN "detectors", Courtney and Gabriel. These monitor a network, watching for unusual activity.

Courtney (named after the author's child) is an addition to the tcpdump general-purpose network monitoring program. It runs on a variety of platforms and watches for a threshold number of probes coming from a single source. Tcpdump is somewhat difficult to handle, and may present a problem for the inexperienced administrator.

Gabriel was written for Sun machines, and is quick and easy to install. It performs much the same function as Courtney, and has extensions that allow notification of a probe via pager, phone, email or screen display.

If your system is secure, why bother watching for probes? It can be useful to know who's interested in you, even if they're not successful. Plus, it's part of being a good neighbor on the Internet; the probe may not be authorized by the administrator, and he'd like to know.

What is in SATAN's future? Dan & Wieste have said they have several ideas for improvement; there are three areas worth mentioning. First, the fourth, "attack" level: this would turn SATAN into something closer to the nightmare many thought it would be. Still too unwieldy for the novice hacker, it would allow a skilled one the freedom to launch full-scale attacks on unsuspecting systems at the click of a button. Secondly, they plan to improve the output of SATAN's results, giving a more graphic representation of the "web of trust" of the target system, allowing administrators & hackers alike to see exactly where the weak points are. And finally, SATAN was built with expansion in mind. When a new hole comes along, just plug in the SATAN scripts for it and click your mouse.

Click.

About the Author

Sarah Gordon's work in various areas of IT Security can be found profiled in various publications including the New York Times, Computer Security Journal and Virus Bulletin. She is a frequent speaker at such diverse conferences as those sponsored by NSA/NIST/NCSC and DEFCON. Recently appointed to the Wildlist Board of Directors, she is actively involved in the development of anti-virus software test criteria and methods. She may be reached as [email protected]