At this point, the ftpd has chrooted to the / directory rather than the ~ftp directory and has suid to root. SATAN specifically avoided testing this because it involved an active intrusion, which is a conflict with the design goal of SATAN’s third level. An unimplemented fourth level of SATAN scanning, “All Out,” would probably be the right place for such a scan.

Most ftp daemons can be configured to prevent the login of users listed in a file called ftpusers. From a SATAN standpoint, this does not matter as long as anonymous FTP is enabled. The wu-ftpd program uses a configuration file called ftpaccess that can permit a wide range of control over what anonymous users are allowed to do. Wu-ftpd also features another configuration file called ftphosts that can be used to specify hosts that are not permitted to use FTP.

Unprivileged NFS Access

Unix supports the concept of privileged ports: only programs that run as root are permitted to send packets from TCP or UDP port s i n the range of 1–1024. The assumption behind this concept is that only trustworthy people are able to get root privileges on any system connected to the Internet. This is an extremely naive concept, because a hacker certainly has root access to his or her own system, and the Internet is not so tightly governed that hackers are not able to gain access. To add to this poor assumption, PCs do not typically support the concept of privileges, and they are connected to the Internet. This means that anyone on a PC can run a program that uses a privileged port.

Regardless of the naive assumption behind privileged ports, many network servers can and do require that clients originate requests from privileged ports. For example, rlogind and remshd (rshd) require client requests to come from privileged ports. The NFS and mountd services can be configured to require client requests to originate from privileged ports.

NFS is a stateless protocol that permits a remote user to mount a file system and then treat that file system as if it were local. The mount of a remote NFS file system causes the local system to generate an rpc procedure call to the mountd program on the remote system. The rpc call asks the mountd for a file handle. The mountd sends the file handle if the request originated from a system listed in the export file list. The mountd determines this by doing a gethostbyaddr() call to resolve the IP address into a domain name. Once the mountd approves and sends the client a file handle for the file system, the client can now request any file operation on that file system by just providing the file handle as authentication, along with any desired uid and gid (they must be valid on the remote system). This is called AUTH_UNIX authentication AUTH_Unix authentication.

Each file system operation done by the client user gets translated into one of 17 rpc requests to the remote NFS server. These rpc calls are directed to the nfsd that services the nfs file operations via a kernel call.

The privileged port check for the mountd (rpc.mountd) is done in the user space daemon itself. The mountd must have been compiled to support this feature. For the standard portmap program, this check is usually done only if a variable called nfs_portmon has been defined.

The privileged port check for the nfs request is not done in the nfsd program, but rather inside the Unix kernel. This means that the nfs_portmon variable can usually be dynamically turned on and off using a debugger such as adb. It is most useful to have both mountd and nfs check for privileged port access. But remember that this is really not a vast increase in the security of the system.

SATAN tests unprivileged access to both the mountd service and nfs service by generating non-root rpc calls to both. SATAN also generates root rpc calls to both. It asks the mountd for a list of exported file systems, and it asks nfs to do an ls -l type listing of each file system.

Unrestricted NFS Exports

Running showmount -e <remote system > prints a list of exported file systems. This list specifies which hosts ar e permitted to mount the file systems. (It corresponds to the remote system’s /etc/exports file.) The hosts can be specified explicitly by name, by netgroups, or by the wild card everyone.

If everyone is permitted to mount the file system, the only authentication done on file access is done on the client. The NFS server believes that the client NFS call has valid uid and gid values. So, if the / file system is exported with read/write permissions and with root access, any host on the network can mount the file system and act as root.

If no root access is permitted, any client can mount the file system and act as any user. The quick way to do this is to su to the correct uid on the remote system, by creating the correct account on that system and then doing the file operation. The quicker way to do this is to use one of the many NFS hacking utilities to change the uid and gid and then call the NFS call directly. Some of the better utilities include nfsbug, nfsmenu, and nfsshell. The FTP locations of these utilities can be found by doing an Archie search.

A bug in older versions of NFS limited the size of netgroups to 256 bytes, creating a hole that would effectively cause the export to default to everyone. The SATAN scan could see this or the everyone export as unrestricted NFS access and report it as a vulnerability.

A hacker who finds this hole has access to the file system to the level specified by NFS. If root access is exported, the hacker has complete control. If non-root read/write access is exported, the hacker has access to all non-root files. A simple .rhosts file in any user’s home directory offers the hacker login access. If the hacker has only read access, damage is still likely. The hacker can get passwd files, NIS domain names, system files, NIS maps, and configuration information; this information can quickly permit a hacker to discover vulnerabilities that will lead to a login.

Another bug in older versions of NFS permitted remote users with a uid of 2^16 to masquerade as root. The NFS check for uid permissions occurred on the 32-bit value passed in the NFS rpc call, which was non-zero, and the system masked this to 16 bits for normal file operations.

The use of netgroups has been the source of many security vulnerabilities. The NIS netgroups file treats empty host fields as wild cards, permitting any host to gain access from the mountd.

Avoid exporting NFS files systems with write permission, especially when root permission is granted. Explicitly list client hosts and netgroups instead of permitting any host to gain access. Carefully review the netgroup’s man page to ensure the correct format for entries.